WO2005060206A1

WO2005060206A1 - Public key infrastructure credential registration

Info

Publication number: WO2005060206A1
Application number: PCT/GB2004/005200
Authority: WO
Inventors: Kevin Paul Bosworth; Nigel Tedeschi; Trevor Wright; Alexander Selkirk
Original assignee: British Telecommunications Public Limited Company
Priority date: 2003-12-18
Filing date: 2004-12-10
Publication date: 2005-06-30
Also published as: GB0329338D0

Abstract

Validated digital certificate information (5) relating to a user (2) can be associated with other information relating to that user held in a user database (12), by creating a secure communications connection (30) between a server system (10) associated with the user database (12) and a client system (20). The secure connection is based upon an initial login identifying the user information in the user database (12) associated with the initial login details. A re-negotiation of the secure connection (30) is then performed, requiring a client authentication process. The user's digital certificate (5) is then accessed. If the digital certificate (5) is not already recorded in the user database (12), the authentication process of the secure communications connection (30) is used to validate the digital certificate submitted in the registration process. The validated digital certificate 5 can then be stored in the user (database12) , associated with an existing information record relating to the user (2).

Description

Public Key Infrastructure Credential Registration

This invention relates to the secure registration of users with a service provider, making use of digital certificates. Many online services require user authentication, using means such as usemames with passwords, or more secure methods such as digital certificates. In order to allow a user to employ such an authentication scheme, he needs to register his identity and his means of authentication with the service provider. For example, he needs to supply a usemame and password, or provide a digital certificate, which must be mapped to his account with the online service provider. A digital certificate is an electronically encoded set of data that associates a digital public "key" with other identity, validity and issuer information. The certificate is digitally signed by the Issuer (the certification authority). The digital public key is one of a pair of codes, the other being a "digital private key". These keys are selected such that data encrypted using the public key can only be decrypted using the private key, thereby providing confidentiality, and also such that data that can be decrypted using the public key can only have been encrypted using the private key, thereby providing authentication and data integrity. The private key cannot be derived from the public key. The public key can therefore be used to ensure data encrypted thereby can only be read by the holder of the private key. Moreover, if encrypted data can be recovered by using the public key, that is evidence that the data had originally been encrypted by the holder of the private key. A digital certificate is issued by a Certification Authority, which is a trusted third party, together with a private key, to be known only to the certificate owner. The certificate contains details of the owner's identity, checked by the Certification Authority prior to issuing, so the online service can trust these details too. The owner uses the private key to digitally sign data; the certificate contains the public key, which can be used to validate, signatures made by just that private key and no other. This allows the owner to prove his identity, as only he has access to the correct private key. The authenticity of the certificate may be verified by checking with the issuing authority. Thus the digital certificate can be used to confirm that the user transmitting the message is the holder of that certificate. An online service may hold copies of digital certificates for those of its customers who have registered them, so that the customer may be readily identified when accessing the service, by using the private key. The customer may use the same digital certificate to access the services of several service providers, without the risk of his account details being passed from one service provider to another, since only the customer has the private key. This is a difference from the password system, in which the operator of one service would be able to access any other services for which the user has allocated the same password. The private key is held securely by the user in some form from which it can be readily used to validate any authentication requests, such as carried on a smart card of the type defined by ISO standard 7816 - ideally with some further protection such as a PIN or password. Should the private key become compromised the certificate can be declared invalid by reporting to the issuing authority, which will then render invalid all attempts to use the private key to access any service provider. This is done by publishing the certificate on a Certificate Revocation List (CRL), which is a signed blacklist of revoked certificates. Service providers check all certificates submitted to them against the latest CRL, and reject those that appear on it. However, the digital certificate merely identifies that the person accessing the service has the private key corresponding to that certificate. It is important to recognise that the certificate merely identifies that the user is the same person who supplied the certificate to the service provider in the first place. It does not itself provide a positive identification that the owner of the certificate is a customer of the service provider. The web server could validate a client certificate, but would have no means to identify the user beyond reading the details in the certificate and checking with the issuer of the certificate that it has not been revoked. It would not be able to map the certificate to a particular, registered customer account without a manual association process. To avoid impersonation at the registration stage, a user needs to be able to prove to the service provider that the owner of the certificate is also the person whose customer details are held by the service provider. It is therefore necessary for users to be able to register their certificate on the online service, ideally as part of the service registration process, replacing the part where the password is set. The registration process must therefore include setting up the account details, submission of certificate and providing a digital signature so that the service provider can check the user does own the private key corresponding to the submitted certificate. According to the invention, there is provided a method for associating validated digital certificate information relating to a user with other information relating to that user held in a user database, by creating a secure communications connection between a server system associated with the user database and a client system, the secure connection being based upon an initial login identifying the user information in the user database associated with the initial login details, performing a renegotiation of the secure connection requiring a client authentication process, accessing a user's digital certificate, identifying whether the digital certificate is already recorded in the user database, and if the digital certificate is not so recorded, using the authentication process of the secure communications connection to validate a digital certificate submitted in the registration process, and thence storing the validated digital certificate information in the user database, associated with an existing information record relating to the user. According to another aspect, there is provided a data handling system providing access to secure data, comprising interface means for establishing a secure communications connection with another processor, authorisation means for checking the authenticity of a digital certificate received by the data handling system over a secure communications connection established by the interface means, and for checking other authentication information received over the same connection against previously stored data instances, and means for associating the digital certificate data with the previously stored data instances for future retrieval. In this way, once a secure connection has been set up to allow the account to be set up securely, the connection is renegotiated, using the authentication mechanism of SSL as a registration mechanism to submit the certificate and prove ownership. There is no need to distribute specialised code for. the web server or client to perform the login process. The client merely submits a digital certificate, which is designed as a public document. In prior art systems a secure communications system is used merely to authenticate previously-registered certificates, and the registration process is normally manual or requires special software to be installed on browsers. Web servers can be set up to map a digital certificate to an account on a service. In the process according to the invention, if the user details do not match a certificate already stored in the user database, the user will reach a point when he can provide a client certificate for authentication, and prove he is the rightful owner. To do this, he initiates a mutually-authenticated secure communications session. In the preferred embodiment the secure connection is provided by a Secure

Sockets Layer (SSL) connection. Mutual authentication is possible with SSL, from version 3 and subsequent versions, and with TLS. Both the server and client (browser) use a certificate - the web server signs a random challenge from the client and the certificate contains the DNS name of the web site, whilst the browser signs a server challenge, using a key pair and certificate selected by the user. The present invention provides a secure way of registering the user's digital certificate when first subscribing to a service, and thereby prove ownership of the private key corresponding to an existing certificate, using standard technology available in web browsers and servers. This could be used as part of a registration process, in the way that users provide passwords currently, so they can authenticate themselves in future. This method has the advantages that the authentication is more secure than a password, which may be intercepted, since the private key itself is never transmitted. This invention uses the tried and tested security of SSL (for authentication) to secure the registration process. Moreover, the same certificate can be registered for several services without compromising the security of the individual services. For example, a user may use the same certificate for access to a retail service and a bank account, without risk of the retailer thereby gaining access to the bank account. The server storing the registered certificate only has the means to authenticate that user's signature or logon attempt; this information cannot be used to impersonate that user. This is an improvement on most password authentication schemes, in which anyone having access to the server could misuse the information. The invention may also be used to validate and register several user certificates against a single Service Provider's user account for the purpose of an emergency certificate cancellation service, or for the purpose of supporting multiple personalised user-contexts driven by the user's choice of certificate at login, or for the purpose of supporting access to that one user account by multiple independent users (e.g committee members accessing a sports society bank account). An embodiment of the invention will now be described, by way of example, with reference to the drawings in which: Figure 1 illustrates schematically the elements participating in the process according to the invention Figure 2 is a flow chart illustrating an overview of both the prior art process and the process according to the invention Figure 3 is a flow chart illustrating a set-up process common to the prior art and the invention; Figure 4 is a flow chart illustrating a process according to the invention Figure 5 is a flow chart showing a variant of the process of Figure 4 As will be understood by those skilled in the art, any or all of the software used to implement the invention can be contained on various transmission and/or storage mediums such as a floppy disc, CD-ROM, or magnetic tape so that the program can be loaded onto one or more general purpose computers or could be downloaded over a computer network using a suitable transmission medium. Figure 1 shows a server computer 1 and a client computer 2, connected over an open, insecure network 3, such as the Internet. The server and client are also capable of communication with a server 4 controlled by a certification authority - in the case of the server 10, this is through an authentication engine 14. The server computer 1 operates a web server 10 that supports a Secure Sockets Layer (SSL) interface. (This embodiment uses SSL v3 or TLS v1, or any later version, but this is not to be taken to be limitative on the scope of the claims.) The server also includes an authentication processor 11 for handling mutual (server-to-client and client-to-server) certificate authentication. The server also hosts a user database 12 for holding user details, including certificates, when they register. For security the user database 12 is preferably accessed by a link 13, rather than being held on the server 10 which faces the Internet 3 directly. The client computer 2 can be any device with a modern web browser 20 compatible with the Secure Sockets Layer. The process of registering operates as follows. Before starting, the user must previously have obtained at least one digital certificate 5 from the certification authority 4, and made it available to his web browser 20. The server 1 also has such a certificate. A digital certificate is a set of computer data containing details relating to the user and to the authority that issued it. It can be transmitted between computers to prove the authenticity of the sender, and allow encryption of messages between them. Its essential elements are a code 50 identifying the certificate owner, a code 51 identifying the issuing authority 4, and a public key 52. These three elements can be transmitted to another party to identify the owner, to allow the authenticity of the certificate to be checked, and to allow encryption of signals between the two users. The authenticity is checked by using a digital signature of the issuer that allows a party to check the certificate is valid and issued by that Certification Authority 4. The public key 52 can be used to decode any transmission encoded using a corresponding private key 53, which is not part of the certificate 5 but held separately by the user. Thus, if the a transmission can be decoded using the public key 52 that is a guarantee that the transmission was indeed generated by the holder of the matching private key 53. The public key 52 may also be used to encode data: such encoded data can only be decoded by the holder of the private key 53 - in particular it cannot be decoded by another holder of the public key. The public key therefore has two purposes: it can be used to positively identify the owner of the private key as the originator of data, and it can also be used to protect data so that it can be read only by the owner of the private key. The user is responsible for protecting the private key 53 corresponding to the registered certificate 5. This may be stored on the hard disk of the computer 2, with local password protection, or on a PIN-protected smart card. Unlike other security systems, neither the key nor the password protecting it are ever transmitted over the open network, so the risk of it being compromised is considerably reduced. As shown in the flow charts of Figures 2 and 3, a user 2 wishing to access the service connects to the web server 1 (step 100). An SSL connection is then created (step 101) - this is a secure connection between the client 2 and the server 1, and is well known in the art. As shown in more detail in Figure 3, to do this the server 1 first presents its own web server certificate details (step 102), and ownership is proved by the sending of a random challenge (103) by the user 2 (using the server's public key), to which the server 1 generates a response (104) with its private key. The user's web browser checks the signature and the authenticity of the certificate from the issuing authority 4 before proceeding (step 105). The user then selects his own certificate 5, and the web browser 20 sends this to the authentication processor 11 of the server 1 (step 106), which issues a random challenge (step 107) which the user's browser digitally signs with the matching private key (step 108), thereby proving ownership of the certificated public/private key pair. The authentication processor 11 next interrogates its cryptographic authorisation engine 14. This is contained in a browser or server, for instance, with the root certificate of the issuing Certification Authority (to trust), and possibly the latest CRL if revocation is being checked. Alternatively, it may establish a connection with the issuing authority 4 (which need not be the same one as in step 105 above) to ensure that the certificate 5 is valid (step 109). This conventional SSL (with mutual authentication) therefore checks that a user's digital certificate is valid, by ensuring it is not expired or revoked and that it is issued by a certification authority it trusts. If the certificate has been revoked (for example because the owner has allowed the private key to be compromised) the certification authority informs the authentication processor 11 and the user is not permitted to progress further (step 110). Otherwise, the SSL initiation is concluded and the server 10 is enabled so that the user's web browser 20 can access the link through an encrypted SSL tunnel 30. This link 30 comprises server side code (which may be an Active Server Page, server-side Java or a CGI, or any other means of running code on the web server). The user has now been proved to be the rightful owner of the certificate 5, as the SSL tunnel setup proved that the user had the matching private key 53. In addition, the certificate has been proved to have been issued by a reputable and trusted Certification Authority 4. Note that at this stage the certificates have been used only to create the encrypted SSL link 30. The server 10 has not at this stage associated the client 2 with its records in the user database 12. What happens next depends on whether the certificate has already been recorded in the user database 12. If the certificate 5 is valid, the authentication processor 11 next checks the user database 12 (step 111) to identify whether the certificate 5 has been recorded therein. If it has, this may be used as positive identification of the user 2, and the server 10 can thus be enabled to give access to his account details or other confidential data over the SSL connection 3 (step 112). It should be understood that although the digital certificate 5 is a public document, only the authorised user has the private key 53. As noted above, the public key can only be used to extract data generated using the private key. Any unauthorised user who attempts to use the certificate 5 will therefore be unable to complete the authentication process since this requires generation of such data. Thus, matching the certificate 5 to the user record 12 is sufficient to ensure that only the certificate holder can transmit data that can be decoded using the public key. Thus far,, the process is the same as in the prior art arrangements. A user can only access his account details over the SSL connection 30 if his digital certificate 5 has previously been registered on the user database 12. In the prior art arrangement, if the check on the user database 12 (step 111) does not identify the certificate, the user cannot be identified and access is denied (step 113) - or some other means of identification must be requested such as a password. As shown in Figure 4, the invention provides a novel process for initial registration of a certificate 5 with the server. The initial stages of the process 1, 101, 111 are the same as in the prior art (Figure 3), but in the event of a certificate not being found in the user database 12, instead of denying access (113, Figure 3), a process is initiated to register the certificate over the secure link 3. Since SSL has already checked the certificate and private key ownership during the link setup, the online service can copy the certificate (by interrogating the web server on which it is running and map it to the user account. The user is invited to register his certificate (step 114) and the user responds with a password or other security process (step 115) over the secure link 30. This password will have been issued to the user previously when the user first asked to use the service accessed by the server 10. It may have been provided to the customer in person, if positive identification or inspection of other documents is required to open an account, and/or sent by post, to ensure address details provided to the service provider are correct. The password is only required for initial registration, and therefore does not need to continue to be memorised by the user once registration has succeeded. In order to avoid misuse, it may be made valid for only a limited period, or for only a single use. In an alternative arrangement, shown in Figure 5, the user may use the usemame and password for the service, previously issued by the service provider, at initial login (step 115) to obtain basic rights to the service, without SSL. When he selects "register certificate", he initiates SSL and through this submits and registers the certificate, to the account already identified by password, (step 116, 117, 118, 119). It should be noted that in either case, the certificate 5 once registered may be used as identification on subsequent logins (step 101). The user 2 having now been identified, the certificate 5 can be associated with the user's records in the user database 12 (step 120). On future logins, presentation of the certificate (step 106) is sufficient identification to allow the authentication processor 11 to enable the server 10 to transmit the user's records to the user over the link 3, encrypted using the public key 52 (step 112). When the user 2 wishes to authenticate himself to the server, he can access the appropriate service page, protected by SSL (step 101). He can either use his usemame/password (step 115) for basic rights on the service, or select a previously- registered certificate (step 106). The authentication processor 11 accepts the certificate 5 and compares it to those in the user database 12 (step 111). As the certificate 5 is now in the user database the user can be authenticated as being the registered owner of the account and can proceed to provide access (step 112) as described above. The certificate 5 itself is in the public domain, but it would be of no use to any unauthorised person who might attempt to use it to access the user's records. The server 10 would indeed transmit the records to such a user, but would encrypt them using the public key 52. Only the authorised user 2, who has the private key 53, can decode them. The invention may be used to validate more than one certificate for the same user record. This may be used, for example to each holder of a joint bank account to have independent access to it. It may also be used to allow a single user to have access using different user-contexts. For example, a user may wish to have an identity providing limited access, such as cash withdrawal to a predetermined limit, when in a non-secure environment. This could be accessed using a private key carried on a portable medium, such as a smart card. Another identity, giving full access, including account details and facilities to transfer larger amounts may be used when in a more secure environment, using a private key maintained in a less vulnerable medium, such as the user's home computer. A single user may also validate a number of certificates, provided for different purposes, with the server of a cancellation service. As with known card cancellation services, this would allow the user to revoke all his certificates simultaneously with a single instruction. The cancellation service would then contact the certificate issuing authorities to carry out the revocation, and if required to issue one or more replacement certificates.

Claims

1. A method for associating validated digital certificate information relating to a user with other information relating to that user held in a user database, by creating a secure communications connection between a server system associated with the user database and a client system, the secure connection being based upon an initial login identifying the user information in the user database associated with the initial login details, performing a renegotiation of the secure connection requiring a client authentication process, accessing a user's digital certificate, identifying whether the digital certificate is already recorded in the user database, and if the digital certificate is not so recorded, using the authentication process of the secure communications connection to validate a digital certificate submitted in the registration process, and thence storing the validated digital certificate information in the user database, associated with an existing information record relating to the user.

2. A method according to claim 1 , wherein the initial login process makes use of the digital certificate and a further authentication code, previously associated with the user record, supplied by the user to allow matching, and automatic storage, of the digital certificate.

3. A method according to claim 1 , wherein the initial login process makes use of an authentication code previously associated with the user record, and the renegotiation process makes use of the digital certificate to be stored.

4. A method according to claim 1 wherein several user certificates can be validated and registered against a single Service Provider's user account.

5. A computer program or suite of computer programs for use with one or more computers to carry out the method as set out in any one of claims 1 to 4.

6. A data handling system providing access to secure data, comprising interface means for establishing a secure communications connection with another processor, authorisation means for checking the authenticity of a digital certificate received by the data handling system over a secure communications connection established by the interface means, and for checking other authentication information received over the same connection against previously stored data instances, and means for associating the digital certificate data with the previously stored data instances for future retrieval.

7. A data handling system according to claim 6, wherein the interface means has means for establishing the secure communications system making use of information in a digital certificate and its matching private key.

8. A data handling system according to claim 6 or 7, wherein there are means for storing a plurality of digital certificates in association with the same, or related, data instances.

9. A computer program or suite of computer programs for use with one or more computers to provide any of the apparatus as set out in any one of claims 6 to 8.