Asymmetric cryptography presents a powerful approach to protecting information. Users who want to use asymmetric cryptographic mechanisms need to possess an asymmetric keypair that can be used for encryption and data signing. The private key is secret and can be considered equiv-alent to a user password; the public key can be made available to all users on the Internet and is not secret.
An asymmetric keypair — be it an RSA or a DSA keypair — by itself does not contain information about the user to whom it belongs. However, in many cases, it is useful to be able to identify the user to whom an asymmetric keypair belongs. It is also important to have assurance that a particular public key belongs to a specific user, rather than to an imposter.
One of the approaches used by some applications, such as SSH, is to use the public key as a means to identify the user and the private key as a means to authenticate the user. The public key, which is known to everyone, can be mapped to the user’s identity. The private key is secret and the individual uses it to ascertain his identity. Because the public and the private key are mathematically bound to one another, the identity of the user (the public key) is bound to the secret key (the private key).
However, using only keys does not provide for much flexibility. For example, there is no information as to when the keys were created and for how long will they be valid; nor is there information on the purposes for which these keys can be used. Certificates provide for such information.
A certificate is a collection of publicly available user attributes (metadata about the user) and a public key, all signed by a trusted third party that guarantees that it has verified the information in the certificate as correct.
The trusted third party is called certification authority (CA).
Because each certificate contains the identity of the user, along with the user’s public key, certificates can be used for user authentication. The private key is not part of the certifi cate but every certificate has a corresponding private key that is mathematically bound to the public key contained in that certificate.
The X.509 standard was defined by ITU-T in 1988 (X.509 version 1) and then revisited in 1993 (X.509 version 2) and 1995 (X.509 version 3).
It defines digital certificates as an authentication method and describes how asymmetric keys can be bound to user identity using such certificates.
More details on the actual standards can be found in [134, 135].
X.509 version 1 of the standard defines the basic certificate format, and X.509 version 3 defines the extended certificate format. Table 1.1 shows the X.509 certificate fields and their usage.
AU5219_book.fm Page 26 Thursday, May 17, 2007 2:36 PM
User Identification and Authentication Concepts 27
Table 1.1 X.509 Certificate Fields
Field Name
X.509
Version Description
Subject 1 Name of the certificate holder. This name can virtually take any format but commonly used are X.500 distinguished name, e-mail address, DNS name, and LDAP name.
Serial Number 1 A unique identifier of the certificate Issuer 1 The name of the party that issued the
certificate. This is typically a certificate authority. The format can be X.500, LDAP, or DNS.
Valid From 1 Date and time when the certificate became (or will become) valid
Valid To 1 Date and time until when the certificate will be (or was) valid
Public Key 1 The public key portion of the asymmetric keypair for the certificate holder
Version 3 X.509 version on which this certificate is based (1, 2, or 3)
Subject Alternative Name
3 Another name by which the holder of the certificate is known
Provided that the Subject field is an LDAP name, the Subject Alternative Name may contain the user logon name for users, or the computer account name for computers CRL Distribution
Points (CRL-DP)
3 URL of the Certificate Revocation list of the Certification Authority
Authority Information Access (AIA)
3 URL with information about the Certification Authority
Enhanced Key Usage
3 Purposes of the certificate — what will it be used for
This is a collection of ISO-defined object identifiers (OIDs), one for each purpose of use for the certificate
Application Policies
3 Defines applications and services that can use the certificate by specifying OIDs
AU5219_book.fm Page 27 Thursday, May 17, 2007 2:36 PM
28 Mechanics of User Identification and Authentication
The following example shows the content of an actual certificate:
C:\> openssl x509 -text -in dt.pem Certificate:
Data:
Version: 3 (0x2) Serial Number:
11:9f:5e:a8:00:00:00:00:00:05
Signature Algorithm: sha1WithRSAEncryption Issuer: DC=com, DC=ins, CN=INS CA
Validity
Not Before: Jul 13 00:22:30 2005 GMT Not After : Jul 13 00:32:30 2006 GMT
Subject: CN=Dobromir Todorov/[email protected] Subject Public Key Info:
Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit)
3 Specifies the assurance policies and mechanisms that the Certification Authority observes in order to receive requests for, handle, authorize, issue, and manage certificates.
Signature Algorithm
1 The algorithm used by the Certification Authority to sign the certificate
This is typically RSA or DSA, with SHA-1 or MD5 hash
Signature Value 1 The actual signature using RSA or DSA (or potentially other signature algorithm) on the certificate
Table 1.1 X.509 Certificate Fields (continued)
Field Name
X.509
Version Description
AU5219_book.fm Page 28 Thursday, May 17, 2007 2:36 PM
User Identification and Authentication Concepts 29
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
S/MIME Capabilities:
X509v3 Subject Key Identifier:
2C:3E:29:D3:C5:56:D3:8D:6A:E5:45:97:96:C6:9A:3F:A5:29:9A:4C X509v3 Extended Key Usage:
TLS Web Client Authentication X509v3 Authority Key Identifier:
keyid:18:FB:CB:95:2D:59:AC:16:4F:B0:02:4D:1D:6D:92:AC:FE:29:
8B:4C
X509v3 CRL Distribution Points:
URI:ldap:///CN=INS%20CA,CN=BILL,CN=CDP,CN=Public%20Key%20 Services,CN=Services,CN=Configuration,DC=ins,DC=com?
certificateRevocationList?base?objectClass=cRLDistribution Point
URI:http://bill.ins.com/CertEnroll/INS%20CA.crl
Authority Information Access:
CA Issuers - URI:ldap:///CN=INS%20CA,CN=AIA,CN=Public%20Key%
20Services,CN=Services,CN=Configuration,DC=ins,DC=com?cA Certificate?base?objectClass=certificationAuthority
CA Issuers - URI:http://bill.ins.com/CertEnroll/BILL.ins.com_
INS%20CA.crt AU5219_book.fm Page 29 Thursday, May 17, 2007 2:36 PM
30 Mechanics of User Identification and Authentication
ExBEb2Jyb21pciBUb2Rvcm92MRwwGgYJKoZIhvcNAQkBFg1UZXN0QHRlc3QuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1FpIhs1QsknIzRLsEqu3 hJfED38WSMkKbskbzMFhxfvLznIwRvbLEPqrdc69zA3gznNtvvqzibMU1grR63/9 GMLCslmpugmZNAPzY41xeASbNqqKdj0mp0sBDKEAj5ULmkkdCZ+eWlA/4z9X6XLc m5E2UrMj0ukW/nqXY1HKuaRVsG8AzywUdoCBw+10+s2JU8LGFeaHEeNGa4l0GNbg f4HczXeWTtj3EBQ5kfUfzbHTU+UIiDiXrkW6sffD3FAjqLcmWiVKVQHu2Wx9U0ed T94A85uNb2aL+q2L/J0BulmGFfuFtDIVX+wEol9gcFe1pLyljmcm0hyduZRkOeZy BwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgTwMEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG 9w0DBzAdBgNVHQ4EFgQULD4p08VW041q5UWXlsaaP6UpmkwwEwYDVR0lBAwwCgYI KwYBBQUHAwIwHwYDVR0jBBgwFoAUGPvLlS1ZrBZPsAJNHW2SrP4pi0wwgewGA1Ud HwSB5DCB4TCB3qCB26CB2IaBqGxkYXA6Ly8vQ049SU5TJTIwQ0EsQ049QklMTCxD Tj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1pbnMsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0 cDovL2JpbGwuaW5zLmNvbS9DZXJ0RW5yb2xsL0lOUyUyMENBLmNybDCB/AYIKwYB BQUHAQEEge8wgewwgaMGCCsGAQUFBzAChoGWbGRhcDovLy9DTj1JTlMlMjBDQSxD Tj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1pbnMsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9v YmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MEQGCCsGAQUFBzAChjho dHRwOi8vYmlsbC5pbnMuY29tL0NlcnRFbnJvbGwvQklMTC5pbnMuY29tX0lOUyUy MENBLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAkQh4vpXzJmBT3DE9K2bFSDpleNY0 6UZHBDfKJvOrP9ElajFHV3aqYEro4CD33L4sqmVd951slU9K/C88Gst6JzV8Lg1Z 6AjABkbRooumMBdXy09BM4d62BQHi9i4rcSMEcFTOah1Y7Mx3ip6+Vh8KqMO5V6H Oft8lADhIDpfo5AYeAUysJK95JpQzp3G228sC+WuDmxfL0miErD7PE+4XgxeqOyP C0gS83AWBmEtHnHZE3UHzc/gJFTxlvKKJJwUAh5MSA7TRL+vygpMw40MXSUtjqB0 3W/VeqwqaMYBUisos+4sWf5xMVlCDn+1c27rqO2n7+qe07qcTdR7RzXJOA==
---END CERTIFICATE---C:\>
All users and services within a single domain of administration trust one or more certification authorities (CAs). Each CA is responsible for receiving, verifying, and issuing certificates, as well as managing certificate revocation information. Typically within an organization, there is one top-level CA; there may be zero or more top-levels of subordinate CAs. Any certificate issued by any of the CAs within the CA hierarchy is trusted by each other CA and all the users and services in the same CA hierarchy.
The X.509 PKI model defines hierarchical relationships between cer-tificates that correspond to the model of trust. Top-level CAs are known as root CAs. Because there is no CA above them, these CAs sign their own certificates. Due to the fact that these CAs are well known and have strong identity and assurance policies, users trust them to be the ultimate verifier of information stored in certificates throughout the organization.
CAs below the top-level CA have their certificates signed by the root CA.
Because users trust the root CA, they also trust each certificate of subor-dinate CAs, as they have been signed by the root CA that has verified the identity of the subordinate CA.
Cross certification provides for trust with certificates issued by other domains (PKI Hierarchies). If a trusted CA signs the certificate of an
AU5219_book.fm Page 30 Thursday, May 17, 2007 2:36 PM
User Identification and Authentication Concepts 31
untrusted CA, the untrusted CA becomes trusted along with all the certif-icates issued to its subordinate CAs and user/service certifcertif-icates. Such cross certification may become the model for authentication between organizations.
Users, services, and CAs choose which CAs to trust. The CA must provide for strong identity assurance mechanisms to be trusted by other parties. Before a CA issues a certificate to a requestor, the CA needs to ensure that the information that the user has requested in the certificate request is genuine and truthful. To validate this information, a CA (more precisely, an issuing committee that manages the CA) may request a user to bring a photo ID, or the CA may use other means to ensure that the information is correct. The X.509 model of trust is based on the fact that if information has been included in a certificate, this information is correct and a trusted CA has verified it. In some cases, before issuing a certificate to a user, a committee of individuals may need to consider the request and decide whether to issue a certificate or reject the request. Using hardware security modules, it is possible that the CA private key will be spread to a number of smart cards, so that all (or a qualified quorum of) committee members need to provide their cards so that that CA private key can be retrieved from them, and the request can be signed.
To obtain a certificate and have it signed by a CA, users generate an asymmetric keypair and submit a certificate request. Once the CA has verified the information requested by a user or a service, the CA must sign it. Signature is performed by first generating a hash of the certificate fields, and then signing the hash using some signature algorithm such as RSA Signature or DSA. The CA signs the hash using its own private key.
Because this private key is secret, no one but the signing CA can generate this signature. The signature can be verified using the CA’s public key, which is included in the CA certificate.
Each user or service can trust one or more root certification authorities (root CAs). Each certificate issued directly or indirectly (following the model of trust of subordinate certificate authorities) by a trusted CA is automatically trusted. A user or service that needs to verify whether a certificate is valid only needs to verify the signature on the certificate, which is an offline process and does not require any connectivity to the issuing CA. The verifying user or service has both the peer certificate that must be verified and the trusted CA certificate. To verify the peer certificate, the verifying user or service needs to decrypt the Signature field in the peer certificate using the signing CA’s public key, and compare it with a locally calculated hash for the certificate. If the two match, the certificate is genuine and has a valid signature from a trusted CA. As a result, the certificate and the information contained within it may be considered valid, because it has been verified by a trusted party.
AU5219_book.fm Page 31 Thursday, May 17, 2007 2:36 PM
32 Mechanics of User Identification and Authentication
Each user, application or computer, or other entity may request and potentially obtain a certificate. The typical process of obtaining a certificate involves the following steps:
1. A user or a service generates an asymmetric key pair (RSA or DSA).
2. The user or computer generates a certificate request to a CA. The request includes only the public key from the asymmetric keypair and additional attributes that the user or service wants to add to the certificate, such as a Subject Name (the user directory name), the Subject Alternative Name (such as the user logon name), and potentially key usage information. The request is typically signed with the user’s newly generated private key, and the signature can be verified using the newly generated public key, which is included in the certificate request.
3. A CA receives the request either online (through a Web page or through a certificate enrollment protocol) or offline (a file contain-ing the request from the user or service).
4. The CA starts a process to verify that the information provided by the requestor in the certificate request is correct. For example, the CA may need to verify that the user who requested the certificate can really use the Subject Name and the Subject Alternative Name in the request. The user or service may therefore be required to provide identification information, or an internal organizational process may be used to verify the information.
5. After verifying that the request from the user or service is genuine and that requested attributes correspond and properly identify the user or service, the CA adds attributes such as validity period (Valid From/Valid To), CRL, and AIA URLs, and potentially other attributes, and generates an SHA-1 or MD5 hash for all the fields.
6. The CA signs the hash using its own private key.
7. The CA constructs a certificate with all the signed fields and the actual signature added to them.
8. The CA returns the certificate to the requestor.
9. The requesting user or service stores the certificate in its local certificate store and associates it with its secretly stored private key that corresponds to the certificate’s public key.
10. Either the CA or the user (or service) can optionally publish the certificate into a directory where other users can find it.
Certificates used as credentials by themselves can be considered a single-factor authentication mechanism (“something you know”). How-ever, certificates are very often used along with smart cards. When the user first generates a keypair, a smart card can be used for the actual
AU5219_book.fm Page 32 Thursday, May 17, 2007 2:36 PM
User Identification and Authentication Concepts 33
calculation. The user private key can therefore be generated and stored on the smart card and protected by a PIN code. The user private key is typically not saved in the file system in this case. If the user needs to use his private key — for example, to authenticate, to decrypt data it has received from a peer, or to sign data that he wants to send to a peer — the smart card must be provided along with the protecting PIN code and the private key will be read from the card. The use of smart cards to store private keys corresponding to X.509 certificates makes certificate-based authentication a two-factor authentication method. Smart card authentica-tion is a relatively popular authenticaauthentica-tion method that provides for very good security.
The model of trust for certificates used as authentication credentials is that user identification information is contained within the certificate (verified by a trusted third party — a CA), and that only the trusted third party can generate a verifiable signature for the certificate in question. If an attacker is able to steal the identity of a CA (i.e., steal the private key), the attacker can sign and issue new certificates compromising the model of trust.
To protect against and mitigate the effects of compromise, certificates use two mechanisms: (1) validity period and (2) certificate revocation checking (CRC). Each certificate is valid for a limited period of time, specified in the certificate itself. If a certificate is not within its validity period when a user or service checks it, this certificate is invalid. Parties that have expired certificates must renew them before they can successfully use them.
On the other hand, if a certificate is compromised (e.g., its private key is stolen), then this certificate can no longer be trusted and therefore should be revoked. The user or service to which this certificate belongs is responsible for notifying the CA that their certificate has been compro-mised. The CA can then add the certificate to a list of revoked certificates, known as a certificate revocation list (CRL). Users and services that use certificates may choose to verify every certificate against the CRL before using it. In this way, even if a certificate is compromised before its validity period has ended, this certificate can be immediately invalidated and the party to which it belongs can request a new certificate.
The security of X.509 certificates as user credentials depends on a number of factors. First, X.509 certificates are considered strong due to the fact that cryptographic signing algorithms (RSA Signature and DSA) cannot be easily compromised at the time of this writing. Second, it is vitally important that all levels of CAs and the actual certificate owner keep their private keys secret. If even one private key in the certificate chain is compromised, the entire chain from the point of compromise downward can be considered compromised and certificates must be
AU5219_book.fm Page 33 Thursday, May 17, 2007 2:36 PM
34 Mechanics of User Identification and Authentication
revoked and reissued. Third, CAs must have a reliable way of checking information in certificate request before actually signing and issuing cer-tificates to individuals.
X.509 certificates and corresponding private keys can be used as very secure authentication credentials, especially if the private key is stored on a smart card, as this provides for two-factor authentication.
PGP (Pretty Good Privacy) is a public key system similar in many respects to X.509. The major difference is that instead of relying on a hierarchical trust, PGP relies on the so-called “web of trust.” With PGP, anyone can play the role of a CA and can generate a signed PGP certificate for another user. PGP parties that sign other parties’ public keys are known as introducers. Each introducer can be trusted by a party (such as a user or a service), which means that certificates that he has signed will be trusted as well by that party. For example, if Bob trusts Alice as a trusted introducer, and Alice has signed a public key for another user, then Bob trusts the public key signed by Alice.
Enterprise trust is typically easier to model using the hierarchical and centralized X.509 model based on trusted root and subordinate certificate authorities. PGP, on the other hand, sometimes appears to be mor e convenient for open user communities exchanging information over the Internet. Both X.509 and PGP certificates can be used as credentials for user authentication, depending on the requirements and the environment.