Browse Prior Art Database

A client certificate store and authentication proxy system

IP.com Disclosure Number: IPCOM000244326D
Publication Date: 2015-Dec-02
Document File: 4 page(s) / 136K

Publishing Venue

The IP.com Prior Art Database

Abstract

This invention introduces a system to manage the client certificates and control the authentication between clients and remote resources. The system splits the certificates in a random way and obfuscates the store of the certificate snippets by introducing random numbers of fake snippets. Once the certificates are imported in the system, the physical certificate files are removed, and the snippets of the certificates are hidden in the system. When the client authenticates with remote resources, it is done through the system. The client can not view or copy the certificate files, and the certificate files do not actually exist in the system or in the client, so the system can provide high level secure support to the certificate based authentication to prevent the certificates from being lost or being copied. The advantages of the system are listed as follows, the system can provide more secure software way to do the certificate based authentication by 1. Do not store the certificate files directly in the system or in the clients. 2. Do not need any additional password to obfuscate or encrypt the certificates

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 4

A client certificate store and authentication proxy system

Certificate based authentication is widely used as client access control method nowadays. Users should manage their private certificates in a secure way. There are some existing solutions to store user certificates in the client system, which are done either using software or dedicated hardware, but both ways have their own set of usability issues. The two main problems which will arise are: 1) the user loses the certificates, and
2) an attacker obtains a copy of the certificates. Especially when the certificates are shared between several systems, the certificates are unlikely to be well protected against attackers. The known software solution for certificate store and access control is password-based encryption, it encrypts the certificate using a symmetric key which is derived from the password, but the management of the password introduces a security risk of this solution.

This invention introduces a system to manage the client certificates and control the authentication between clients and remote resources. The system is called "Certificate Management System(CMS)" in the following parts of this document. The system splits the certificates in a random way and obfuscates the store of the certificate snippets by introducing random numbers of fake snippets. Once the certificates are imported in the system, the physical certificate files are removed, and the snippets of the certificates are hidden in the system. When the client authenticates with remote resources, it is done through the system. The client can not view or copy the certificate files, and the certificate files do not actually exist in the system or in the client, so the system can provide high level secure support to the certificate based authentication to prevent the certificates from being lost or being copied. The working principle of the CMS is shown in Fig 1

1


Page 02 of 4

Fig

Fig

111 certificate management system

certificate management system

.1

1. 1The work process of Certificate Management System (CMS)

Before the client authenticates with the server via CMS, the certificate should be imported to CMS and splitted into snippets, a certificate id

2


Page 03 of 4

"c_id" is assigned to uniquely identify the certificate. The client should register with CMS first by recording its physical IP address "ip" in CMS and connect its "ip" with one or more "c_id". As the Fig1 shown, when the server requires the client to provide the "client certificate", firstly, the client sends a request to CMS for certificate verification, and the request should include the "ip" of the client and the certificate id "c_id" which uniquely identifies the client certificate the server wants to verify. When CMS receives the request of the client, it will look forthe location information of the splitted snippets of the certificate in the local store or distributed systems based on the "ip" and "c_id" provided by the request. If the "...