by Pierre-Jean Aubourg, Director of Bull’s Payments Systems and Public Key Infrastructure division
After five years at SYSECA – the Swiss-based services subsidiary of the Thomson group (now Thales) – Pierre-Jean Aubourg joined Bull Engineering as head of electronic messaging projects. He contributed to its very first security projects in 2001, and later became Director of the payments Systems and PKI division in Bull’s security business unit. In this role, he is responsible for developing services activities in these areas, as well as for developing MetaPKI, Bull’s PKI solution. Pierre-Jean Aubourg has a higher degree (DESS) in electronics and industrial computing, and is a graduate of the French Ecole des Techniques du Génie Logiciel.
In an Open World, where there is an ever-increasing number of exchanges with distant or unknown correspondents, and where mobility is blurring the boundaries of the information system, the capacity to identify the author of any message, transaction or document with some degree of certainty is becoming fundamentally important. So Public Key Management infrastructures (PKIs) are vitally important as they are both flexible and rigorous, they are recognized by the majority of players, and they are capable of being deployed at every level of the infrastructure. With PKI, a single application can be used to implement a centralized security policy, providing coherent management of all identities (keys and certificates) issued for the extended information system.
Based on the principles governing asymmetric cryptography, and using pairs of private and public keys (the X.509 standard), a PKI builds electronic certificates – in effect, ‘digital identity cards’ – that establish an irrefutable link between the user of an information system and a physical person. These certificates, which can also be attributed to hardware items such as a computer or a router, or to applications (software packages or applets…) enable the entities concerned to set up mutually recognized security functions such as encryption, authentication, digital signatures, integrity, or non-repudiation.
So establishing a PKI is a sensitive project. Just as in the public sphere there are authorities responsible for protecting identities and individuals, such as the Commission Nationale de l’Informatique et des libertés or CNIL in France, the role of a certifying authority (CA) is to guarantee the security of technical and non-technical provisions of the entire PKI platform, potentially involving every ‘citizen’ in the organization. This authority’s ability to prove to interested parties that the chosen solution is appropriate, documented and applied is therefore fundamental. Once confidence in the PKI is established, confidence in the information system components that it is responsible for securing naturally follows.
To achieve this, the scope of a PKI project should not be restricted simply to technical issues, but should be widened to take in several other aspects including:
1. Organizational issues
2. Functional issues
3. Specific documentation issues
4. Change management support and training
5. Regulatory and legal aspects issues.
1. Organizational issues
In order to produce reliable identities – PKI’s principle objective – it is important to ensure that a coherent and efficient organization is in place, so any necessary personal information can be reliably collected and controlled. For this to happen, the project must draw on the existing organization, taking into account the roles and usual behavior of each entity.
The latest thinking insists that a face-to-face interview is essential, before handing over an electronic certificate. This information gathering procedure is a simple operation, but one that requires close local proximity. The best solution is exploit existing channels in the organization, such as the HR department, the person in charge of identity badges, or an IT Manager. The choice of the right person to operate the scheme, depending on the data to collect, will also ensure that the necessary ethical and confidentiality considerations are respected.
Another key organizational aspect concerns error handling and user support. It is vital to be able to guarantee that users can access their working environment at any moment, even when, for example, they have forgotten to bring with them the relevant smart card containing the certificate, or if it is temporarily blocked or unusable. This kind of assurance is essential when the certificate is used for sensitive applications, or for applications in constant use like messaging systems or first-line authentication for a workstation. Similarly, it is essential to anticipate the organizational processes that will need to kick in if someone forgets his or her card (or cryptographic USB key), or in the event that a card is locked if someone puts in the wrong PIN code several time (something that typically happens when people get back from holiday, for example). This could be an automated procedure, to be implemented by the card-holder on the basis of information only known to him or her, or a manual procedure carried out with the help of a member of the organization’s security staff.
Defining responsibilities for validating certificate requests, or, in even more sensitive cases, for controlling CA keys, is also an important organizational issue.
2. Functional aspects
When we talk about PKI functionality, we mean the full set of characteristics describing the certificate life-cycle management process: in other words, every procedure involved in creating, issuing, using, modifying, renewing or canceling certificates… One of the critical points at this stage is to carry out an in-depth study that aims to simulate every possible scenario where the PKI may be used. This kind of study is usually carried out with a view to securing a particular application or system, but its inherent flexibility and universal application means it could easily be used with other elements of the information system. However, these kinds of changes will invariably be easier to implement if they have been anticipated from the outset, because the stages in this life-cycle are interrelated and, depending on what level of security is expected, the creation or modification of any use of the PKI can undermine the balance of the whole structure. And it goes without saying that system robustness and clarity are essential when it comes to maintaining user confidence.
Several points deserve particular attention:
- The way certificates are used
- The choice of an overall organization structure
- The information system.
There are two distinct types of certificates, requiring very different handling: authentication and signature certificates, which must be controlled exclusively by their owners, and encryption certificates, that require the entity producing them to set up a back-up and restore capacity, in particular to comply with the legal requirements associated with encryption. Authentication and signature certificates must, therefore, be generated as close as possible to the card-holder, on his or her smart card or the desktop browser on his or her workstation, so as to eliminate any risk of copying and to guarantee secrecy for the key (which will verify his or her signature)! Encryption certificates, on the other hand, must be generated centrally so that a copy can be reliably made (sequestering function). This copy will enable any user who looses his or her private key to retrieve it, and above all to retrieve the encrypted data (certificate recovery function). While most PKI technical solutions support both these functions, their level of security as well as ease of implementation vary widely. Identifying the kind of certificate profiles to produce, as well as all the authorized usages, will help to establish a comprehensive PKI specification, and also ensure the standard pitfalls are reduced or avoided: user mistrust, loss of data, inability to respond to queries…
The type of organization chosen also has a direct impact on the PKI’s functions. If, for example, an automated system is chosen to handle the unlocking of smart cards, this function will have to be secured so that only the card-holder will be able to activate the process. The solution will therefore have to offer a secondary identification method. Other functional consequences will arise from this, particularly when the certificate-holder registers in the first instance – extra items of personal information will need to be recorded, for example). Another example is the handover procedure for certificates, the process whereby the certificate is produced must be systematically followed up with the sending on of the card unlock code.
The availability of PKI services is another subject that falls just at the crossover point between the organizational and the functional. While it is generally accepted that the availability of the certificate production function is not critical – it can be tailored according to usage – the availability of the revocation function is vital because the security of applications depends on it. A card-holder must be able to request the revocation of their certificate immediately, at any time, to prevent it being used again (with the certificate added to a centralized ‘blacklist’ or revocation list). For example in the RGS, the general security database drawn up by the French government, the availability of the revocation function is an important quality criteria when it comes to classifying a certificate on a scale of between one to three stars.
Finally, any review of the PKI’s functionality must obviously take into account the existing IS environment. In particular, the existence and regular use of the enterprise’s central directory is a constant concern for all the projects that involve using the PKI. In terms of inputs, in some instances the directory might be used to feed the process of registering new certificate-holders, avoiding the need to re-key existing information. In terms of outputs, the PKI could publish a list of certificates it has issued and lists of revocation via the directory.
3. Documentation considerations
The body of documentation that supports the PKI is fundamentally important when it comes to instilling trust. It describes all the ways in which the PKI is implemented. lt is aimed at any group of people linked with the PKI: users, operators, auditors… The CA is responsible for the PKI, as well as for establishing, maintaining and executing the content of this documentation, which breaks down into four parts:
Certification policy (CP) is the fundamental document relating to the PKI. The CP details the governance of the infrastructure as well as all the organizational demands/requirements – both technical and non-technical – providing a guarantee of security for the PKI, and the accuracy of the identities it holds. According to the latest thinking, there should be one CP for each type of certificate.
Declaration of certification policy (DCP) brings together all the procedures and actions aimed at guaranteeing the infrastructure’s conditions for operation. This covers a wide variety of subjects including staff induction procedures, the conditions governing physical access to buildings, data archiving and backup procedures, networks security… The DCP provides a global guarantee of the security of the PKI.
The Key Ceremony document describes the conditions and actions to be taken during the key ceremony. This ceremony represents the initiation of the PKI certificate production process, in other words the generation of a bi-key for the certifying authority (CA) and its deployment to enable the production of certificates. From this point on, the CA is identified by his/her own certificate, and the private key for this certificate serves to electronically sign any further certificates produced.
General Conditions of Use (GCU) is a document destined for users of the PKI, in other words the holders of any certificates produced. It specifies how certificates are to be used, aims to make the holder aware of how important it is to safeguard the device used to store the certificate, and provides instructions for actions to be taken in the event of any problem.
4. Change management support and training
This is of crucial importance for PKI projects. Ideally, training should be available for everyone involved. Administrators and operators of the solution will be trained to use the computing tools provided, and given details of the conditions of use described in the DCP. The operators (responsible for information gathering and first level support…) are the primary target for this information since they are the ones that oversee the accuracy of the information collected, and represent the visible face of the PKI: if users are to trust the device, they first have to trust these people. This means their training will be the source of their efficiency and their legitimacy. Finally, users must be made aware of the benefits as well as the requirements of the PKI, through an effective channel of communication, suited to the culture and to the use that the organization plans to make of it. If no change management support is provided, there is a significant risk that the PKI will be used in inappropriate ways, resulting in the growth of a defiant attitude to internal ‘policing’…
For example, if an organization wants to activate the Windows ‘smart card login’ function, to secure access to the workstation, using an e-certificate becomes mandatory for all users of the information system. This kind of implementation requires a far-reaching communication strategy, to prepare and train staff for the changes. This should stress the individual and collective advantages this technology offers, emphasizing the fact that the workstation will no longer be used without its owner’s knowledge, and that a four-figure PIN will replace the usual complicated password which also has to be changed frequently…
5. Regulatory and legal issues
The regulatory and legal dimensions should be taken into account, depending on the context of the PKI implementation.
Using cryptographic resources is subject to special legal constraints. These apply even more strongly when encryption operations are involved. If the sale of e-certificates is envisaged, the certifying authority will clearly define its responsibilities. Finally, respecting people’s identities also has to be considered and, if necessary, an application should be filed with the relevant authorities (such as the CNIL in France).
For public sector projects in France, the regulatory aspect will involve applying the standards set out by the RGS (the general security database). An external audit will have to verify that the PKI complies with these standards. If the organization wishes to be attached to the root PKI organization in France, and it falls within its area of application, it should approach the Agence Nationale de la Sécurité des Systèmes d’Information, the ANSSI to make sure that the certification policy for its PKI is compatible with that of the French government. Similar arrangements apply in all major economies worldwide.
Looking at the various issue that have to be tackled as part of a PKI implementation, it is clear that a diverse range of skills is needed, over and above the technical aspects alone. Identifying the right organization to put in place, actively managing the change, and taking into account the legal impact are all key factors for the success of the project and the acceptance of the solution by everyone involved: not just card-holders, but also senior management teams, operators, IT management & operation…
Through its work on at least 20 similar projects over the past few years, in a wide variety of contexts, Bull now benefits from in-depth experience on each of these points and understands how to approach them in a global, coherent and methodical way. Bull is therefore well placed to support organizations from start to finish, in implementing an effective key management infrastructure and ensuring that it engenders the necessary trust.