During the early phases of the project, the PKI Applet on the card was a contentious issue. Although the purpose of the PKI applet was understood and the need for e-services realized, the application and services associated with it were only broadly understood at the time. It was decided to have a container that would have three key pairs, one for logical access or authentication, one for digital signing, and a third reserved for possible future use for data encryption and decryption. The container was designed to be personalized with the rest of the card and protected with a user PIN. The validity of the digital certificates (keys) in the card has the same lifetime as the card, which could be a maximum of up to five years. A new set of keys would need to be reissued with a new card and the expired public key certificates published in a revocation list.

From a system perspective, no copy is kept of the keys that are generated for an ID card. The keys are generated by the HSM and securely exported and loaded onto the card, after which the keys are deleted from the system. No key backup or archival (except for the CA root key) is done. Due to the fact that no data encryption and decryption is done, there was no need for key recovery at that stage. However, if a third certificate is implemented for data encryption and decryption, the need for key recovery has to be investigated. Not only is private key recovery important for data decryption purposes, but also public key archival might be needed for digital signature certificates. For example, when a legal document is signed and has a lifespan that exceeds the validity period of the card and therefore the certificates, the signature can no longer be verified unless the public key of the original digital signature is archived with the document or available from the CA authority for verification.

It is clear that the use and application of the PKI component of the ID card needs to be well defined and communicated in the Certificate Practice Statement. All partners and role players will also play a significant role in determining the scope and parameters of PKI use of the ID card. Finally, federal and international law will dictate certain aspects of PKI usage and aspects like key recovery, usage, and conditions for non-repudiation will determine implementation requirements. Taking all this into account, the current PKI is only in its beginning phase. In order to fulfill the usage requirements of the PKI component on the ID card, it will be necessary to plan a proper and well-designed architecture for the PKI needs in context of other government departments and GCC1 countries. The following subsections elaborate on the primary components of the UAE PKI project.

ID Card PKI Applet

The PKI applet provides the digital signature and authentication features in the form of digital certificates. The applet can accommodate three separated key sets and their associated digital certificates, as well as a user PIN code to prevent unauthorized use of these functions. One certificate is for authentication, one is for the digital signature, and one free empty key container is for future use. With the installed certificates and keys the user can be authenticated and can digitally sign e-commerce and e-government applications.

The certificates are in accordance with the X.509 standard. Together with the PKCS#11 cryptographic library and a CSP (cryptographic service provider for Microsoft Cryptographic API) the user uses Web Browsers (SSL v3 sessions), e-mail (S/MIME), VPN, and other PKI applications securely. For the hashing function SHA-1 is used and for asymmetric cryptographic functions the RSA algorithm is used.

During card personalization, the digital signature and the authentication certificates are loaded onto the ID card chip. The keys on the ID card are able to perform cryptographic functions but the decryption function is blocked. The blocking is necessary so that a key cannot be misused for a decryption function. For additional encryption and decryption and/or digital signature keys, the

GCC is the acronym for Gulf Cooperation Council, also referred to as the Cooperation Council for the Arab States of the Gulf (CCASG). It includes six countries: Bahrain, Kuwait, Oman, Qatar, Saudi Arabia, and the United Arab Emirates. The number of GCC population is estimated to be around 40 million people.

additional container can be used, but the keys are not loaded during the personalization. If the keys for encryption/decryption are loaded, a mechanism of key recovery must be implemented to guarantee that the private key can be restored in case of a lost or damaged card. Otherwise, the user would not be able to decrypt any data that has been encrypted previously.

The private keys for the digital signature and authentication functions are not held in the system, but are loaded once into the smartcard. It cannot be offloaded later on and will be used by the smartcard to perform cryptographic functions. If a card has been damaged, lost, or renewed, the user should be issued with a new card with new certificates.