The UAE system employs multiple Certificate Authorities (CAs) to deal with key requirements for the population, time, and technical aspects of the system. For the purpose of this discussion we are concerned with the population CA, which issues and sign keys and certificates for use in the ID card. The next subsections highlight possible caveats of the PKI infrastructure.
Activating the Private Key
The private key is the most important piece of data that needs to be protected. For the CA, the private key security is so important that it is physically stored on a hardware cryptographic module and protected by split authentication and various other physical access controls. Compromise of this key invalidates all the issued certificates by the CA and thus any digital transaction performed with the keys and certificates in question. The CA private key is stored in a hardware security module and protected adequately through various means.
The ID cardholder’s private key is generated in the HSM and transferred to the ID card during personalization. The private key is activated through the use of a user PIN. This means that the most important piece of data, as far as an ID cardholder is concerned, is currently only protected by a minimum four-digit numeric password, better known as a PIN. If the ID card is stolen and the PIN very easily stolen through mechanisms like social engineering or shoulder surfing, the private key is compromised.
A more secure way to protect a private key is to activate it using a biometric instead of a PIN—in some cases using both. Match-on-card technology is a great way to authenticate a cardholder using his smartcard without having to have a complex online system available. Because the cardholder can be uniquely authenticated using his biometric, it serves as the best way to unlock protected information on his/her card (like the private key). In the UAE system, the match-on-card functionality is separate and serves no access control purpose, only cardholder authentication.
There is always a balance between security, ease-of-use, and functionality in any system—increase one and the other two will decrease. By using the biometric to activate the private key will provide the ultimate security but will limit the use of the PKI services to match-on-card-only applications and readers. The decision to use the biometric as access control mechanism for the PKI applet instead of a PIN can only be made once the nature of e-services is better defined and the requirements from partners and role players better understood.
Verifying Digital Signatures
As already explained, digital signatures are verified with a signer’s public key and the public key certificate is verified with the CA’s root certificate. Furthermore, the validity of both the public key certificate and the CA root certificate is verified against the CRL. Off hand, there is some serious infrastructure needed to fulfill the requirements just mentioned.
First of all, public key certificates must be distributed to all partaking entities to verify digital signatures. Depending on the application, the public keys might be queried from a central repository or embedded as part of the signed transaction and thus verified without any additional infrastructure. This is the preferred way but is not always supported by the application software of a specific digital signature application. The problem with the central repository for public keys is not only the fact that it requires infrastructure but also heavy maintenance: Once cards get renewed there will be more than one version of a public key for a particular cardholder; transactions signed must be verified with the correct version of the public key; obsolete public keys must be removed, and so on.
Secondly, the public key certificate of a cardholder must be verified against the CA root certificate. This is to ensure that the cardholder is whom he says he is and his certificate has indeed been issued and signed by the Identity Authority. In a commercial scenario the root certificates of the most popular CAs are embedded in software like browsers, but for standalone CAs the root certificate has to be made available to any entity that requires validation. The pitfall is that the certificate itself does not need to be secure (it has already been signed with the CA’s private key) but the mechanism in obtaining It has to be secure. This is because a fraudulent certificate, checked against the correct CA but fraudulent one, will validate correctly.
Many organizations embed their root certificates as part of the PKI-enabled applications. Although this mostly solves the problem, it is difficult to keep up to date as to the correct version of the root certificate (if it was renewed or compromised). Other organizations prefer to publish the certificate on their corporate websites. This might sound like the best and simplest idea, but it is not secure and an entity may never be sure whether it is referring to the correct site and correct certificate. The alternative is to install the root certificate on the card, together with the cardholder’s certificates. This way, the root certificate is always accessible and up to date because when the card gets replaced so does the root certificate. It travels with the cardholder and can always be verified without any external checking.
Thirdly, both the public key certificate and the CA root certificate have to be validated against the CRL. The CRL simply keeps a list of certificate serial numbers and whether they are valid or not. Currently the CRL is published and stored as a single file in the Demilitarized Zone (DMZ).2 However, no infrastructure currently exists to access and check against this file from an external entity. The CRL will be explained later in more detail.
Verifying Access Control Certificate
The second certificate in the card is used for authentication, or more technically, logical access control. This includes things like SSL client authentication, for example. Because logical access is one-time only or while a session exists, it is considered temporally and therefore does not have the certificate lifetime and archival issues associated with digital signature certificates and data encryption certificates. Instead, the only issues are validating the CA root certificate and CRL-related issues, as explained in the previous section with digital signature validation.
Certificate validation is what it is all about. Verifying the authenticity and validity of a certificate (it is the public key) is a crucial process in ensuring the integrity of a PKI system. The CRL performs this function and the CRL is generated on a daily basis and stored in a single file output and transported to the DMZ. There are basically three problems to address when dealing with CRL information:
A single CRL file grows too big—as certificates gets added to the CRL the file will grow in size, and each time a client requires the CRL information it will attempt to download the file in order to check it. In a relatively small environment this will still suffice, but dealing with thousands of certificates will make the single file solution inadequate. In the context of the UAE system, in which millions of certificates will eventually end up on the revocation list, a single file will grow up to hundreds of megabyte and will be impractical to use in this environment.
A single file is not suitable for a distributed environment—accessing a single file is fine when the environment and the number of CRL queries are fairly small. However, from industry evolution it is clear that a single file solution for any scenario has its limitations and cannot scale very well. Take Windows NT and its single authentication file in the form of a SAM file: It was just a matter of time before Microsoft had to replace this technology with something that could scale and be distributed across a large infrastructure. The answer was a directory service, and Active Directory (like NetWare, iPlanet, IBM, and others) is a lightweight directory access protocol (LDAP). A LDAP is usually implemented with an online certificate status protocol (OCSP). A directory service with an access protocol makes the update and query much more efficient and reliable.
A CRL is accessed by both the secure CA as well as the less secure client queries—with a single CRL file, both secure agents, like the CA and less secure agents such as clients, require access to the CRL file. This is not the ideal way to maintain the level of security usually associated with a CA environment.
As the CRL grows in size and the number of requests increases, a distributed environment is the only proper solution for the demands of such an infrastructure. In a distributed environment multiple nodes, called responders, provide up-to-date CRL information in multiple points across the PKI footprint.
Security is also addressed in the sense that the responders live in an unsecured environment but receive signed copies of the revocation information from the secured LDAP and distribution server, which can either be online or offline. With the size of the UAE PKI infrastructure in the form of number of certificates and role players in the future, this is definitely a recommended option to look at in order to comply with scalability, reliability, and security needs.
Level of Trust
As already mentioned, validating the CA certificate is an important part of the trust associated with a PKI infrastructure. The identity issuing authority implemented a standalone CA, which does not have a trusted path associated with the commercial CAs. This in itself is not a problem, but it means that the root CA certificate of the issuing authority has to be distributed to all entities that will require CA certificate validation. This becomes a challenge, as other departments or even other countries use their own CAs with their own infrastructure. In the commercial world, cross-certification is the way to carry the trust of one CA over to another CA, resulting in implied trust through a trust path.
Due to security, autonomy, and other considerations, this might not be an appropriate solution, especially not when other countries are involved. Using a concept called bridge-CA might be a better solution, in which different departments or countries may use a joint bridge-CA instead of explicitly signing each other’s root certificates. With the focus on GCC cooperation and interoperability, this solution might be considered in the future and is recommended above cross-certification.
The final point to discuss is that of data encryption services, the one thing that currently does not exist in the UAE PKI infrastructure. Although a third certificate slot has been reserved in the PKI applet of the ID card for future purposes of data encryption/decryption, a very important aspect of the PKI infrastructure needs to be considered first—that of key recovery.
In an environment in which data is encrypted for storage—not only for the duration of a session like with the authentication certificate—key recovery becomes an issue. First of all, a private key holder (typically a cardholder) may lose his/her card or damage it. In this scenario the private key is lost and any data encrypted with the particular person’s public key can no longer be decrypted. The ramifications might be huge if large amounts of sensitive information and even personal information are lost this way.
Second, in today’s information age, in which criminal activities usually have a digital footprint and trail, the necessity for authorities to have access to data of any organization or individual when the need arises is crucial. Having no way to access encrypted information literally puts a blindfold on law enforcement activities.
It is clear that both from availability and law enforcement points of view, the need for key recovery has to be evaluated and considered very closely. An issue with having a form of private key backup is the fact that these keys need to be protected very well and the process of recovery has to be well defined and justified. This aspect of any PKI infrastructure has to be communicated to all certificate holders in very clear terms in the certificate practice statement. The certificate holder should have the confidence that he/she may be able to recover lost data in the event of a lost private key, but also that the Certificate Authority will not abuse its position of maintaining a copy of the backup keys.
A very important point to highlight is that the keys for digital signatures and data decryption will preferably not be the same keys. This might sound strange, but think of it for a moment. If the private key is backed up or escrowed (managed by a third party), the non-repudiation associated with a digital signature is no longer valid. This is because another private key exists, which is fine for recovering encrypted data in the event of key loss, but not fine when it comes to ensuring non-repudiation with singed transactions. This is the reason why there are two distinct certificates—digital signature certificates require archival of the public keys while data encryption certificates require archival/back-up of the private keys.
In the UAE system no key recovery or private key escrow exists. It was very important that key recovery requirements be understood before attempting to implement data encryption services within the ID card. It is recommended to have the architecture in place before any decisions are made as to making data encryption/decryption available on the ID card.