Digital Certificate Operation in a Complex Environment
Sections in this document:search
The DCOCE PKI Architecture and Requirements
4. Architecture and Procedures
To request a new certificate, a user first has to create a new key pair. The is sent together with her personal information to the central RA System ( - see ). This step can be performed in two ways:.
The holds the request until an RA has approved it and the attributes that it contains. Then the certificate is created and signed by the CA and sent back to the user via the cRAS. The user can opt to store the certificate and (in an encrypted, secure form) in the as well, in case she needs to move to a different machine and still use her certificate for , later. Users who do not wish to use the LICS or who have generated a certificate/key pair from a secure device, such as a smart card or USB device with 'crypto chip', can choose not to use the LICS.
The investigations of the team resulted in the proposal of two main procedures. These were due to the need for different initial user registration procedures in different types of departments or colleges. Some organisational units (OUs) are able to process the necessary data about new starters beforehand and to send them letters that contain the URL and a few instructions regarding how to apply for their certificates. Some OUs will not be able to do this and the RAs will enter the new starter's details as he stands in front of them. Therefore, the initial few steps differ in each case, although both have components in common. The latter option may involve more work for the , but this is a procedure that our architecture must take into account.
(above) is a summary of the certificate request and procedures. Figure 4.2 continues on from this diagram and outlines the procedures with respect to the certification authority (CA) and includes the options of storing the certificate and private key in the LICS (see ).
A good infrastructure should attempt to have one token (a personal digital certificate) and leave multiple roles to a sophisticated authorization system. However, there are some 'real world' challenges that serve to constrain this theoretical advantage. For example, a user who works part time in the Department of Physics may also be studying at a College. Only one organisational unit can be placed on a certificate, but the user clearly has two roles. We believe that a higher education PKI will often have to tie identity to organisational unit. This is certainly the case at Oxford University. The problem is compounded by devolved s being unable to 'vouch' for the attributes delivered due to the membership of an unrelated organisational unit. For these reasons, we find it necessary to issue more than one certificate to the same individual in certain cases.
The cases of the same individuals having multiple roles is relatively uncommon, but by no means rare. Our proposed solution can accommodate this technically. However, the cost is probably that end users may have to handle the complexity of having multiple certificates. Where the is to be used, the container will house all of the users certificates.
Where it is possible that the has prior knowledge of the new starter and is able to send a letter or set of instructions beforehand, the procedures are as follows. The technical shorthand for this approach is the request first procedure.
The sends a letter to the new starter, encouraging her to apply for a digital certificate from a computer where she will usually be based. The letter contains the URLthat should be used and very few instructions. Before visiting the RA, the user connects to that URL, with her preferred web browser and fills in her details via an HTML form and makes a certificate request as set out in the section below.
The user then visits her local and is physically authenticated using a photo ID and/or employing the usual registration procedures for new starters to the organisational unit. The RA marries up the user to the request that is lodged with the and checks the name, organisational unit and any other attributes that are included with the request. Where the cRAS database is not fully integrated with the institution's directory service, a reconciliation is made between the name given alongside the certificate request and the institution's data held in the directory service. This may mean that it would be efficient for the RA to be able to amend the centrally-held data if they are found to be inaccurate. *
* As noted above, theproject employed a discrete Pseudonyms Database but in a production system the data would be held within the institutional directory service and therefore discrepancies in data may present at this stage.
If the user has made a mistake (e.g. by selecting a wrong 'status'), the RA should be able to correct the information at this stage. If the request is valid, the user is whom she appears to be and is truly affiliated with the organisational unit, then the asserts to the that the request should be processed (and a flag is set in the relevant database). From here on, the procedures are as outlined in , below and onwards.
In many cases the user will visit the as part of his initial starting or registration procedure. In such cases, the RA can verify the user directly before he has made his certificate request (from the computer). Thus, the user is physically using a photo ID and/or employing the usual registration procedures for new starters to the organisational unit. He is given instructions encouraging him to apply for a digital certificate from a computer where he will usually be based. The letter contains the URL that should be used and very few instructions. The letter also includes a 9 digit code that must be supplied when he applies for the certificate. The technical shorthand for this approach is the 'RA first' procedure request or (pre-authentication).
The user applies for the certificate in the same way as outlined in the paragraphs within the section below. The only exception to those procedures is that he is prompted to enter his nine digit code. The personal details (name, status etc.) are presented to him and cannot be changed. (If the user considers that any of the details in the application are wrong, then he can make an application as per the method outlined in and visit his RA again.
If the pre-authenticated request is valid, then a flag is set in the relevant database within the . There is no need for the further attentions of a RA. From here on, the procedures are as outlined in the section below and onwards.
The user indicates whether she is going to employ a hardware token or software (browser or operating system) to generate her key pair. (This is phrased in a more user-friendly way). In addition, at this time, she is presented with the option of using the LICS to save an encrypted backup of her private key and certificate*. Once all details in the form have been completed, she submits the request and a certificate request is generated (in a variety of formats depending upon the browser). For those users who opted to use the LICS, this process is mediated by a Java applet.
This procedure is reliant upon the existence of a Java Virtual Machine installation and this can therefore be a constraint for some users. The Java version is tested and users are sometimes encouraged to update the Java installation. If the user cannot make use of Java, then she can still apply for a certificate. However, no backup will be possible (and therefore it can be a more technically challenging task to use their certificate in different places or to re-install their certificate after a desktop system change).
If using the applet, a short test of the quality of the pass phrase is undertaken at this stage, and a warning given if the string is not of sufficient quality (i.e. not containing mixed case and non alphanumeric characters etc.). This ensures that good encryption is used for the encrypted private keys in the LICS.
The request is then stored at the . For those using the applet and the LICS, a copy of the encrypted private key is also stored within the cRAS. The applet ensures that the private key cannot be obtained without the pass phrase, even by a sysadmin working on the LICS/cRAS.
Upon arrival at the , a (DN)is created as part of the request. The Subject Name field of the DN is populated with a short name that reflects their organisational unit, followed by a random number. The unique is stored in the Pseudonyms Database. *
* The Pseudonyms Database was part of thein the pilot. However, as noted , this database should be integrated with a directory service in production.
For those users storing their in the browser or operating system key store, the browser/operating system's procedure will probably prompt for a pass phrase with which to protect the key store. The user will already have seen some text informing her of how to create a good pass phrase. She will also be aware that the security of the pass phrase will be tested later. (Note that a pass phrase may already be in place, as the user may already have personal digital certificates). The user is encouraged to type a reminder for the pass phrase on the screen. The user can then print out a summary that includes the pass phrase reminder. The reminder is stored in the in case the user forgets the pass phrase in future.
Many Registration Authorities ( s) exist in this architecture, but there is one central point to which requests are made, before they are passed on to the Certification Authority ( ). This central point is under the control of the central Registration Authority - where logs and audits are kept/actioned and from where the devolution to the actual (local to the user) RAs takes place. The server(s) or holding point for certificate requests (and their signed returns) is therefore referred-to as the central Registration Authority System (which also includes other functionality).
The receives the user's request along with her supporting information (as outlined ). As outlined, the user's local approves her request, as long as she has been positively verified and her Oxford University attributes are valid. At the same time information, including the pseudonymous Subject Name, is added to her record in the organisation's directory service*, thereby creating a 'mapping' between her unique but unintelligible Subject Name and a real, traceable identity. A flag is set next to the record in the cRAS so that it can be passed to the in the next 'batch' so that the certificate may be issued (see below).
* Again, the DCOCE project pseudonyms database and cRAS was not integrated with the 'Oxford LDAP' (Directory Service) as they should be if this system were to come into production for the majority of users at the institution.
Note that users may apply for the differing types of certificate: authentication, signing and encryption and the may have to process each. We propose that, if a were to support signing and encryption certificates, then these could be applied for using an certificate (no physical authentication step required)**.
**As noted in thesection, above, the project only sought to build a system of issuing and using authentication certificates.
The 'piece' is designed to be technically independent of the rest of the architecture. Therefore, the CA could be any commercial provider or independent organisation that respects the that is implicitly described by these registration procedures.
There are a variety of ways of doing this, and each external CA will have its preferences. The CA for the DCOCE project received requests in batches from the cRAS and these were processed and returned to the cRAS in a few seconds. Where appropriate, the cRAS can email the user to indicate that the certificate is ready for collection.
This stage has two possibilities: a manual (non-Java) download to a software key store or secure hardware device, and a Java-assisted similar download where the user is making use of the . In both methods, the user will have either received an email containing the URL of the certificate container to download and/or will have a code to enter to download the certificate. The user thus visits the certificate issuing web site and either goes straight to the certificate download or enters the code and initiates the certificate download process.
The user must do this from the same machine using the same browser from which the request was made. The signed certificate is downloaded from the cRAS and is installed in her key store in her operating system or within her browser software or on her secure hardware device.
If this 'self management' option is chosen and a hardware device is not being employed, the browser's own process for importing the certificate is invoked (which will usually prompt for the pass phrase) and the registration and certificate issuing processes are thus complete (and may be ignored). Similarly, if the request was made using a hardware token, the hardware device's API may be called to import the certificate into the device, or the user may be instructed to 'follow the manufacturers instructions' and then the registration and certificate issuing processes are complete (and again may be ignored).
In this case, the download of the certificate does not need to be carried out from the same machine (or browser) from which the request was made. After entering the emailed URL or entering his code, a Java applet is invoked. Upon entering the original pass phrase (used at the time of application), the signed certificate is downloaded from the cRAS and is installed in the key store in his operating system or within his browser software. See for further details.
This is explained within the above sections (especially and ). It is the objective of this design that the private key cannot be obtained without the pass phrase, even by a sysadmin working on the LICS/cRAS. Therefore, the strength of the pass phrase is critical.
The LICS server incorporates a routine that attempts to decrypt the containers. If it succeeds, the user is sent a notification that her certificate has been revoked (see the ) and she must repeat the procedure of applying for a new certificate (back to the stage outlined ).
When the user accesses a web-based service that requires certificate , he is prompted for the certificate to use (most relevant if there are >1 certificates in his store). The first time that this occurs in a browser session (or an operating system session, depending on the operating system and browser used), the user may be prompted for his key store pass phrase*. Once, this has been supplied correctly, the digital certificate is provided to the service with data that is also signed by his private key. The service checks the validity of the certificate (trusted and expiry date etc.) and may check the certificate revocation list ( - see ). Once, all of these checks have been passed successfully, authentication is completed and authorization may begin.
This is dependent on the browser. Further, it is possible for the user to choose not to pass phrase protect the key store, or for the pass phrase prompt to appear every time the certificate is used.
Once authenticated to the service (i.e. the certificate appears valid, not revoked etc.), the service may read the contents of the certificate. A local service may allow access to all members of the organisational unit. For example a service that allowed access by all people with a Keble College or Computing Services certificate, would add the following to a configuration file (e.g. to the virtual host configuration within an Apache server using mod_ssl, after the trust of the certificate chains had been established separately).
According to our requirements gathering exercise, the filtering of certificates using the organisational unit (OU) will be the most common, and clearly takes moments to set up. However, some services may still require the equivalent of user lists. In these cases, the authorization is established within the RA interface to the certificate issuing server.
For example, the project helped to establish certificate-mediated access to applicant data for a particular application with widespread (across the organisation), but relatively few users. The users of the application were distributed across all of the Oxford colleges. Therefore, the pseudonyms of all authorized users could be added to the appropriate .htaccess file. This file could contain lines similar to the following:
The pseudonyms can, as above, be included in the main configuration file itself. However, the advantage of the main configuration file calling an another file to be read means that the list of users/pseudonyms can be updated daily, or hourly, or on any change, depending on how the system administrator would wish to configure it.
Thus, the reading of OU is very simple to establish. However, the use of lists of pseudonyms requires a little more work. More pertinent to the possible difficulties with maintaining the pseudonym lists is the authorization level of the RA. For example, the RA may be trusted to establish whether the person is on the Oxford University IT Support Staff list (by checking their identity and checking the ITSS list) and therefore authorize the user to access the ITSS pages. However, the RA may have difficulties authorizing the user to be able to access the web site of the drama society (which may not publish the list of its members). Nevertheless, the DCOCE project succeeded in overcoming these issues for the few services that it established and trialled.
This 'scenario' assumes that the user has moved to a computer other than the one where she usually works, and where her digital certificate and private key are safely held. The 'other computer is one that is relatively secure and not shared with many other users. This could be her computer at home or in another office within the University or Colleges. An alternative scenario is where the user moves to a public computer, such as a machine in an internet café or a multi-user library computer. This scenario is dealt with in .
Users who have chosen to use secure hardware devices (such as smart cards or USB devices containing a 'crypto' chip) are not usually able to extract the from such a device, and therefore may not store their private key and certificate in the . These users need only be concerned that the correct drivers are installed on the new computer so that the hardware device will work at this point.
From the new machine, the user accesses a web page that represents the on-line interface of the LICS. She is asked whether she is at a relatively secure point or at a public computer. In the former case, she will download an applet that mediates the process of obtaining her private key and certificate from the LICS. In scenarios covered by the latter case, please see .
, below shows the general procedure of the interaction with the via the Java applet. The procedure is as follows:
Note that, as outlined in section above, a user may be forced to have more than one certificate, due to her roles within different organisational units. In this case, after entering her pass phrase, she will be prompted with a choice of certificates. She can choose the certificate that she wants or she can repeat the procedure if she needs both (or all) of her certificates.
The concept of a 'public computer' was first raised in above, and includes machines in internet cafés or multi-user computers in situations, such as libraries or colleges. The general solution, as outlined above, should not be used in these situations, as private keys can be left, all too easily, on public computers to create easy pickings for would be attackers. However, the educated user could possibly do this safely if he was to carefully remove his from the machine afterwards. It is possible that an applet could be written that does just this and some institutions have already developed examples of this, but the applet tends to be browser and probably operating system specific.
Our proposed solution for this would be to use short-term certificates, having minimum level assurance (see above). There are two main ways that these could be accessed or used and these are outlined below in sections and .*
* TheOf course, in future, having certificates and private keys on secure USB devices (and possibly even smart cards) may be the simplest and most reliable solution. Drivers are likely to be available in operating systems by default for such devices, and this would be by far the easiest and most secure solution. project did not fulfil this part of the architectural design. However, this architecture, and the two options outlined formed our solution to this problem.
When the user needs to access a protected service from a public workstation, he will probably visit the same web page as outlined in above. Upon indicating that he is in a public place, the applet prompts him for his pass phrase (the same one that he protects his 'usual' key store and his container in the ). The of that password passes over the network, protected by / (as in 2) above) and, once it has been verified, he is sent a temporary certificate and private key to install on the alien computer. As mentioned above, this certificate conveys minimum level assurance, but this will probably be sufficient for most of his needs.
At the University, there are other mechanisms available. Some, such as those involved in single sign on, may be used to give access to a range of services. It is possible that a user could authenticate via one of these other trusted mechanisms and obtain a temporary certificate and in that manner.
At Oxford University, there is a new single sign on mechanism, based on Kerberos, known as WebAuth. There may not be a precedent of using a digital certificate to to WebAuth (as opposed to presenting a username and password), and this may prove technically difficult, but it seems theoretically feasible. Alternatively, a system could be built that could issue temporary certificates after authenticating to WebAuth via username and password. One other alternative could be to protect the via WebAuth and for users to receive their certificates and private keys after successful in WebAuth.
Various options exist for the co-existence of certificates alongside, or in front of an institional single sign on system. However, care needs to be taken to avoid the combined system from being too cumbersome and to avoid the need for new passwords (as much of the demand for single sign on comes from the desire to avoid multiple passwords) when the user's key store needs to be protected.
One issue to consider when downloading temporary certificates is that the certificate or key store in the browser or operating system may already be . This may occur if a user has already made use of the key store and password protected it. It may be that the subsequent user cannot access this store so that she can use it, even temporarily. This could effectively 'lock' that workstation and exclude the use of certificates entirely for most users.
The reliability of the applet that allows the user to obtain a short-term certificate could also be a threat. This threat comes from what is now often termed as 'phishing'. The web page or site that issues the applet is guaranteed via the use of an / certificate. This is a reliable mechanism, but one which is poorly understood by many users. Therefore, this site and applet can be spoofed by attackers, whereby a very similar looking site and applet may be presented to the user (phishing) who then gives up his pass phrase as part of the process. This kind of attack is relatively unlikely to succeed when working on a University-managed workstation, but the likelihood of the attack being successful is much higher in public places. Therefore, when in an internet café, the user could reveal his pass phrase whilst obtaining a short-term certificate. This would then give an attacker access to the user's key stores on the . If this was perceived to be a major threat if/when taking the architecture into wide-scale production, one defence could be to insist upon longer pass phrases and, for example, users would know that they only ever give the first ten characters of these pass phrases to obtain a short-term certificate from a public workstation.
Another problem is general security. In public places, especially internet cafés, the likelihood of threats from trojans or keystroke recorders, etcetera is much greater. This could give rise to the pass phrase to the key store (and therefore the containers themselves) becoming known to attackers. In one sense, this is a danger of any mechanism that can be employed outside the managed University domain and this is mitigated for partly by policies that insist on passwords being changed frequently. However, it is arguably more of a challenge when certificates are used as the installation mechanism is quite an onerous step, and it would be desirable to avoid forcing the user to change pass phrases on a very frequent basis. Nevertheless, this could be introduced.
Renewal is the term generally used to describe the process of applying for another certificate when the certificate that the user holds is about to expire or has already expired. For example, user certificates may be issued for 13 months and each user (e.g. a student) is encouraged to obtain a new certificate before the old one expires. If the user does this, then she does not have to go through the onerous registration procedures again, and can carry out the operation merely on-line (i.e. she does not have to re-visit her local ).
The reasons for renewal are multiple. Users may move departments, get married and change name (although this is relevant only where the name appears on the certificate). However, most importantly, digital certificates can contain attribute fields that confer privileges. These privileges can change and this may require a certificate renewal.
Note that the renewal process will be limited by an 'account expiry date' that is held in the user database. The institution must update account expiry dates periodically. Users will not be able to renew certificates beyond the 'account expiry date'. Similarly, that date will also act as an upper limit to the new certificate expiry date. *
*Theproject did not build this as part of the prototype, but the architecture outlined here is our recommended solution .
In the case of a user's certificate about to reach expiry and the institution is certain that the user is eligible for another year's certificate use (e.g. students entering their second year of study), the procedure is as follows:
Some possible reasons for self-initiated renewal are outlined in, above. The procedures are very similar to those outlined above in section , with the exception that:
Certificates that have been revoked will appear on a Certificate Revocation List ( ) as a minimum. Online Certificate Status Protocol ( ) should also be used, where possible, to give as wide support to procedures as possible. However, this is in the hands of the Certification Authority ( ). One of the approaches that the project team has taken is to attempt to avoid putting extra CA procedures in place that could preclude the use of an external or commercial CA.
It is good practice for lists to contain the serial numbers of revoked authentication certificates that have not yet reached their expiry date. Once revoked authentication certificates are expired, they are removed from the list.
This is beyond the scope of the project but is noted here due to the importance of these kinds of certificates that would certainly have to be considered if this architecture were to move into production. It may be best practice to keep lists of authentication, signing and encryption certificates separate.
As noted above (see sections , and ) certificates have a variety of uses, but each certificate should be limited for use for authentication, signing and encryption. Authentication certificates will have a reasonable expiry period, typically thirteen months in a higher or further education environment, but signing or encryption certificates may never expire. Procedures for the escrow of encryption certificates may need to be invoked, but this goes beyond the scope of this document.