Internet Security Cryptographic Principles, Algorithms and Protocols - Chapter 6 potx

6 Public-key Infrastructure This chapter presents the profiles related to public-key Infrastructure (PKI) for the Internet. The PKI manages public keys automatically through the use of public-key certificates. It provides a basis for accommodating interoperation between PKI entities. A large-scale PKI issues, revokes and manages digital signature public-key certificates to allow distant parties to reliably authenticate each other. A sound digital signature PKI should provide the basic foundation needed for issuing any kind of public-key certificate. The PKI provides a secure binding of public keys and users. The objective is how to design an infrastructure that allows users to establish certification paths which contain more than one key. Creation of certification paths, commonly called chains of trust, is established by Certification Authorities (CAs). A certification path is a sequence of CAs. CAs issue, revoke and archive certificates. In the hierarchical model, trust is delegated by a CA when it certifies a subordinate CA. Trust delegation starts at a root CA that is trusted by every node in the infrastructure. Trust is also established between any two CAs in peer relationships (cross-certification). The CAs will certify a PKI entity’s identity (a unique name) and that identity’s pub- lic key. A CA performs user authentication and is responsible for keeping the user’s name and the associated public key. Hence, each CA must be a trusted entity, at least to the extent described in the Policy Certification Authority (PCA) policies. The CAs will need to certify public keys, create certificates, distribute certificates, and generate and distribute Certificate Revocation Lists (CRLs). The PCA is a special purpose CA which creates a policy-setting responsibility: that is, how the CA’s and PCA’s functions and responsibilities are defined and how they interact to determine the nature of the infras- tructure. Therefore, PKI tasks are centred on researching and developing these functions, responsibilities and interactions. This chapter presents the interoperability functional specifications that are carried out by CA entities at all levels. It describes what the PAA, PCAs and CAs perform. It also describes the role of an Organisational Registration Authority (ORA) that acts an intermediary between the CA and a prospective certificate subject. In the long run, the Internet Security. Edited by M.Y. Rhee  2003 John Wiley & Sons, Ltd ISBN 0-470-85285-2 202 INTERNET SECURITY goal of the Internet PKI is to satisfy the requirements of identification, authentication, access control and authorisation functions. 6.1 Internet Publications for Standards The Internet Activities Board (IAB) is the body responsible for coordinating Internet design, engineering and management. The IAB has two subsidiary task forces: • The Internet Engineering Task Force (IETF), which is responsible for short-term engi- neering issues including Internet standards. • The Internet Research Task Force (IRTF), which is responsible for long-term research. The IETF working groups meet three times annually at large conventions to discuss standards development, but the development process is conducted primarily via open e- mail exchanges. Participants of IETF are individual technical contributors, rather than formal organisational representatives. The most important series of Internet publications for all standards specifications appear in the Internet Request for Comments (RFCs) document series. Anyone interested in learning more about current developments on Internet standards can readily track their progress via e-mail. Another important series of Internet publications are the Internet Drafts. These are working documents prepared by IETF, its working groups, or other groups or individuals working on Internet technical topics. Internet Drafts are valid for a maximum of six months and may be updated, replaced or rendered obsolete by other documents at any time. Specifications that are destined to become Internet standards evolve through a set of maturity level as the standards evolve, which has three recognised levels: Proposed Standard, Draft Standard and Refined Standard. To review the complete listing of current Internet Drafts, Internet standards associated with PKI will be briefly summarised in the following. A public directory service or repository that can distribute certificates is particularly attractive. The X.500 standard specifies the directory service. A comprehensive online directory service has been developed through the ISO/ITU standardisation processes. These directory standards provide the basis for constructing a multipurpose distributed directory service by interconnecting computer systems belonging to service providers, governments and private organisations. In this way, the X.500 directory can act as a source of information for private people, communications network components or com- puter applications. When the X.500 standards were first developed in 1984–1988, the use of X.500 directories for distributing public-key certificates was recognised. Therefore, the standards include full specifications of data items required for X.500 to fulfil this role. Since the X.500 technology is somewhat complex, adoption of X.500 was slower than expected until the mid-1990s. Nevertheless, deployment of X.500 within large enter- prises is increasing and some organisations are finding this repository a useful means of public-key certificate distribution. The Internet Lightweight Directory Access Protocol (LDAP) is a protocol which can access information stored in a directory, including access to stored public-key certificates. PUBLIC-KEY INFRASTRUCTURE 203 LDAP is an access protocol which is compatible with the X.500 directory standards. However, LDAP is much simpler and more effective than the standard X.500 protocols. The X.509 certificate format describes the authentication service using the X.500 direc- tory. The certificate format specified in the Privacy-Enhanced Mail (PEM) standards is the 1988 version of the X.509 certificate format. The certificate format specified in the Amer- ican National Standards Institute (ANSI) X9.30 standards is based on the 1992 version of the X.509 certificate format. The ANSI X9.30 standard requires that the issuer unique identifier field be filled in. This field will contain information that allows the private key to sign the certificate and be uniquely identified. The certificate format used with the Message Security Protocol (MSP) is also based on the 1988 X.509 certificate format, but it does not include the issuer unique identifier or the subject unique identifier fields that are found in the 1992 version of the X.509 format. The ISO/IEC/ITU X.509 standard defines a standard CRL format. The X.509 CRL format has evolved somewhat since first appearing in 1988. When the extension fields were added to the X.509 v3 certificate format, the same type of mechanism was added to the CRL to create the X.509 v2 CRL format. Of the various CRL formats studied, the PEM CRL format best meets the requirements of the PKI CRL format. ITU-T X.509 (formerly CCITT X.509) and ANSI X9.30 CRL formats are compared with the PEM CRL format to show where they differ. For example, the ANSI X9.30 CRL format is based on the PEM format, but the former adds one reason code field to each certificate entry within the list of revoked certificates. All CAs are assumed to generate CRLs. The CRLs may be generated on a periodic basis or every time a certificate revocation occurs. These CRLs will include certificates that have been revoked because of key compromises, changes in a user’s affiliation, etc. All entities are responsible for requesting the CRLs that they need from the directory, but to keep querying the directory is impractical. Any CA which generates a CRL is responsible for sending its latest CRL to the directory. However, CRL distribution is the biggest cost driver associated with the operation of the PKI. CAs certifying fewer users result in much smaller CRLs because each CRL requested carries far less unwanted information. The delta CRL indicator is a critical CRL extension that identifies a delta CRL. The use of delta CRLs can significantly improve processing time for applications that store revocation information in a format other than the CRL structure. This allows changes to be added to the local database while ignoring unchanged information that is already in the local database. 6.2 Digital Signing Techniques Since user authentication is so important for the PKI environment, it is appropriate to discuss the concept of digital signature at an early stage in this chapter. Digital signing techniques are employed to provide sender authentication, message integrity and sender non-repudiation, provided that private keys are kept secret and the integrity of public keys is preserved. Provision of these services is furnished with the proper association between the users and their public/private key pairs. When two users A and B communicate, they can use their public keys to keep their messages confidential. If A wishes to hide the contents of a message to B, A encrypts 204 INTERNET SECURITY User A One-way hash function Signature algorithm M Internet Message (M) Message digest A’s private key User B Digital signature (S) M DecryptionHash function A’s public key = Message digest Message digest computed at B Comparison Yes RejectAccept No S S If the comparison is successful, It is authentic. If the comparison fails, the message is tempered with. ? Figure 6.1 Overall view of a typical digital signature scheme. PUBLIC-KEY INFRASTRUCTURE 205 = ? No Yes Authentication is verified Authentication fails A (client) B (server) CA Session key RSA encryption DES Plaintext One-way function H RSA decryption H CA h = H(m) h d A d A K e B K Y = E K (m) e B (B’s public key) e A (A′s public key) (A ′s private key) (Certification Authority) (Certification Authority) Hash function Plaintext m d B (B′s private key) H (m) h h ′C Message digest RSA encryption (h d A ) e A Session key Session key K K Ciphertext m m DES decryption h ′ Message digest MD5 C e A Figure 6.2 Signature and authentication with DES/RSA/MD5 (compatible with PEM method). it using B’s public key. If A wishes to sign a document, he or she must use the private key available only to him or her. When B receives a digitally signed message from A, B must verify its signature. B needs A’s public key for this verification. A should have high confidence in the integrity of that key. The scenario of a typical signature scheme is described in Figure 6.1. The following example is presented to illustrate one practical system (Figure 6.2) applicable to the digital signature computation for user authentication. The combination of SHA-1 (or MD5) and RSA provides an effective digital signature scheme. As an alternative, signatures can also be generated using DSS/SHA-1. For digital signatures, the content of a message m is reduced to a message digest with a hash function (such as MD5). An octet string containing the message digest is encrypted with the RSA private key of the signer. The message and the encrypted message digest are represented together to yield a digital signature. This application is compatible with the Privacy-Enhanced Mail (PEM) method. For digital envelopes, the message is first encrypted under a DES key with a DES algorithm and then the DES key (message- encryption key) is encrypted with the RSA public key of the recipients of the message. The encrypted message and the encrypted DES key are represented together to yield a digital envelope. This application is also compatible with PEM methods. Example 6.1 Utilizing the practical signature/authentication scheme shown in Fig- ure 6.2, the analytic solution is as follows: 206 INTERNET SECURITY Client A 1. DES encryption of message m: The 64-bit message m is m = 785ac3a4bd0fe12d The 56-bit DES session key K is K = ba0c2b3c484ff9 (hexadecimal) The 64-bit ciphertext Y (output of 16-round DES) is Y = a78791c0c8f0b444 2. RSA encryption of K: K = 52367725502681081 (decimal) Split K into blocks of two digits: K = 05 23 67 72 55 02 68 10 81 Obtain B’s public key e B = 79 from CA and choose public modulo n = 3337. Encrypt every two-bit block of K as follows: 5 79 (mod 3337) ≡ 270 23 79 (mod 3337) ≡ 2524 . . . 81 79 (mod 3337) ≡ 3198 Encrypted K = 0270 2524 1479 0285 1773 3139 2753 3269 3198 This encrypted symmetric key is called the digital envelope. Send this encrypted key (digital envelope) K to B. 3. Computation of hash code using MD5: Compute the hash value h of m: h = H(m) = H(785ac3a4bd0fe12d) = 6a26ee0ed9ce3963ec8b0f98ebda8476 ( hexadecimal) h = 141100303223912907143183747760118203510 ( decimal) Choose d A = 13 (A’s private key) and compute: c = h d A PUBLIC-KEY INFRASTRUCTURE 207 Let us break the hash code into two decimal numbers as follows: h = 1411003032239129071 43 18 37 47 76 01 18 20 35 10 Using d A = 13 and n = 851, compute the RSA signature: 1 13 (mod 851) ≡ 1 41 13 (mod 851) ≡ 545 . . . 10 13 (mod 851) ≡ 333 c = h d A = 001 669 084 400 400 091 348 719 157 303 635 439 333 047 089 001 439 520 466 084 Send c to B. A → B Send (ciphertext Y , encrypted value of K and signed hash code c)toB. Server B 1. Decryption of secret session key K: Received encryption key K: K = 0270 2524 1479 0285 1773 3139 2753 3669 3198 Choose d B = 1019 (B’s private key) and decrypt K block by block: 270 1019 (mod 3337) ≡ 5 2524 1019 (mod 3337) ≡ 23 . . . 3198 1019 (mod 3337) ≡ 81 K = 05 23 67 72 55 02 68 10 81 or K = 52367725502681081 (decimal) = ba0c2b3c484ff9 (hexadecimal) 2. Decryption of m using DES: Ciphertext Y = a78791c0c8f0b444 Restored DES key K = ba0c2b3c484ff9 208 INTERNET SECURITY Using Y and K, the message m can be recreated: m = 785ac3a4bd0fe12d 3. Computation of hash code and verification of signature: Apply MD5 algorithm to the restored message in order to compute the hash code: h  = H(m) = H(785ac3a4bd0fe12d) = 6a26ee0ed9ce3963ec8b0f98ebda8476 Obtain A’s public key e A = 61 from CA and apply e A to the signed hash value c: c = 001 669 084 400 400 091 348 719 157 303 635 439 333 047 089 001 439 520 466 084 Using e A , compute h = c eA as follows: 1 61 (mod 851) ≡ 1 669 61 (mod 851) ≡ 41 . . . 084 61 (mod 851) ≡ 10 Hence,h= 1411003032239129071 43 18 37 47 76 01 18 20 35 10 Convert it to the hexadecimal number: h = 6a26ee0ed9ce3963ec8b0f98ebda8476 Thus, we can easily check h = h  . Digital signing techniques are used in a number of applications. Since digital signa- ture technology has grown in demand, its explosive utilisation and development will be expected to continue in the future. Several applications are considered in the following. • Electronic mail security: Electronic mail is needed to sign digitally, especially in cases where sensitive information is being transmitted and security services such as authentication, integrity and non-repudiation are desired. Signing an e-mail message assures all recipients that the sender of the information is the person who he or she claims to be, thus authenticating the sender. For example, the DSS is using MOSAIC to provide security services for e-mail messages. The DSA has been incorporated into MOSAIC and is used to digitally sign e-mails as well as public-key certificates. Pretty Good Privacy (PGP) provides security services as well as data integrity services for messages and data files by using digital signatures, encryption, compression (zip) and radix-64 conversion (ASCII Armor). MIME defines a format for text messages being PUBLIC-KEY INFRASTRUCTURE 209 sent using e-mail. MIME is actually intended to address some of the problems and limitations of the use of SMTP. S/MIME is a security enhancement to the MIME Internet e-mail format, based on technology from RSA Data Security. Although both PGP and S/MIME are on an IETF standards track, it appears likely that PGP will remain the choice for personal e-mail security for many users, while S/MIME will emerge as the industry standard for commercial and organisational use. • Financial transactions: This encompasses a number of areas in which money is being transferred directly or in exchange for services and goods. One area of financial trans- actions which could benefit especially from the use of digital signatures is Electronic Funds Transfer (EFT). Digitally signing EFTs are a way of providing security services such as authentication, integrity and non-repudiation. Secure Electronic Transaction (SET) is the most important protocol relating to e- commerce. SET introduced a new concept of digital signature called dual signatures. A dual signature is generated by creating the message digest of two messages: order digest and payment digest. The SET protocol for payment processing utilises cryptog- raphy to provide confidentiality of information, ensure payment integrity and identity authentication. • Electronic filing: Contracting requirements expect certain mandated certificates to be submitted from contractors. This requirement is often filed through the submission of a written form and usually requires a handwritten signature. If filings are digitally signed and electronically filed, digital signatures may be used to replace written signatures and to provide authentication and integrity services. One of the largest information submission processes is perhaps the payment of taxes and the request for tax-related information will require signatures. In fact, the IRS in the USA is converting many of these processes electronically and is considering use of digital signatures. The IRS has several prototype under development that utilise digital signatures generated by using DSA. At present, individuals send their tax forms to the IRS in bulk transactions. The IRS will require them to sign the bulk transactions digitally to provide added assurances. In future, the electronically generated tax returns may be digitally signed. The taxpayer may send the digitally signed electronic form to the IRS directly or through a tax accountant or adviser. • Software protection: Digital signatures are also used to protect software. By signing the software, the integrity of the software is assured when it is distributed. The signature may be verified when the software is installed to ensure that it was not modified during the distribution process. • Signing and authenticating: Signing is the process of using the sender’s private key to encrypt the message digest of a document. Anyone with the sender’s public key can decrypt it. A person who wants to sign the data has only to encrypt the message digest to ensure that the data originated from the sender. Authentication is provided when the sender encrypts the hash value with the sender’s private key. This assures the receiver that the message originated from the sender. Digital signatures can be used in cryptography-based authentication schemes to sign either the message being authenticated or the authentication challenge used in the 210 INTERNET SECURITY scheme. The X.509 strong authentication is an example of an authentication scheme that utilises digital signatures. Careful selection and appropriate protection of the prime numbers p and q,ofthe primitive element g of p and of the private and public components x and y of each key are at the core of security in digital signatures. Therefore, whoever generates these keys and their parameters is a vital concern for security. PCAs are responsible for defining who should generate these numbers. When generating the key for itself and its CA, each PCA needs to specify the acceptable algorithms used to generate the prime numbers and parameters. For example, a larger p means more security, but requires more computation in the signing and verification steps. Thus, the size of p allows a trade-off between security and performance. Each PCA must specify the range of p for itself, its CAs and its end users. The range of p is largest for the PCA and smallest for the end user. One-way hash functions and digital signature algorithms are used to sign certificates and CRLs. They are used to identify OIDs for public keys contained in a certificate. SHA-1 is the preferred one-way function for use in the Internet PKI. It was developed by the US government for use with both the RSA and DSA signature algorithms. However, MD5 is used in other legacy applications, but it is still reasonable to use MD5 to verify existing signatures. RSA and DSA are the most popular signature algorithms used in the Internet. They combine RSA with either MD5 or SHA-1 one-way hash functions; DSA is used in conjunction with the SHA-1 one-way hash function. The signature algorithm with the MD5 and RSA encryption algorithm is defined in PKCS#1 (RFC 2437). The signature algorithm with the SHA-1 and RSA encryption algorithms is implemented using the padding and encoding mechanisms also described in PKCS#1 (RFC 2437). 6.3 Functional Roles of PKI Entities This section describes the functional roles of the whole entities at all levels within the PKI. It also describes how the PAA, PCAs, CAs and ORAs perform. 6.3.1 Policy Approval Authority The PAA is the root of the certificate management infrastructure. This authority is known to all entities at all levels in the PKI and creates the overall guidelines that all users, CAs and subordinate policy-making authorities must follow. The PAA approves policies established on behalf of subclasses of users or communities of interest. It is also responsible for supervising other policy-making authorities. Figure 6.3 illustrates the PAA functions and their performances. Each PAA performs the following functions: • Publishes the PAA’s public key. • Sets the policies and procedures that entities (PCAs, CAs, ORAs and users) of the infrastructure should follow. • Sets the policies and procedures, if any, for a new PCA to join the PKI. TEAMFLY Team-Fly ® [...]... policy and procedures which specify the following items: – – – – – – – – – • • • • • • • • 213 Who generates key variables p, q , g , x and y The ranges of allowed sizes of p for itself, its CAs and end users Identification and authentication requirements for the PCA, CAs, ORAs and end users Security controls at the PCA and CA systems that generate certificates and CRLs Security controls at ORA systems Security. .. areas The X.509 certificate format is used in S/MIME for e-mail security, IPsec for network-level security, SSL/TLS for transport-level security, and SET for secure payment systems 6. 5.1 X.509 v1 Certificate Format As stated above, the X.509 certificate format has evolved through three versions: version 1 in 1988, version 2 in 1993 and version 3 in 19 96 We start by describing the v1 format This format contains... algorithm and one-way hash function used to sign a certificate or CRL is indicated by use of an algorithm identifier The algorithm identifier is an OID, and possibly includes associated parameters RSA and DSA are the most popular signature algorithms used in the Internet PKI The one-way hash functions commonly used are MD5 and SHA-1 • Issuer name: This identifies the entity which has signed and issued... : User ID Certification of the user’s public key PUBLIC-KEY INFRASTRUCTURE 219 The signature algorithm and one-way hash function used to sign a certificate are indicated by use of an algorithm identifier or OID The one-way hash functions commonly used are SHA-1 and MD5 RSA and DSA are the most popular signature algorithms used in the X.509 Public-Key Infrastructure (PKIX) Because no one can modify the... processing PUBLIC-KEY INFRASTRUCTURE 223 certification paths in the Internet environment Encryption and authentication rules are provided with well-known cryptographic algorithms X.500 specifies the directory service X.509 describes the authentication service using the X.500 directory A standard certificate format of X.509 which was defined by ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 959 4-8 was first... issuing CA and CA’s predecessors Receiving and authenticating revocation requests Generation of CRLs Directory to store certificate and CRLs Figure 6. 5 Functions of certificate authority (CA) • • Archives certificates, CRLs and audit files Delivers the certificates and the CRLs it generates to the directory 6. 3.4 Organisational Registration Authority The ORA is the interface between a user and a CA The... functions that are illustrated in Figure 6. 6: • • Carries out identification and authentication of users Sends user identification information and the user’s public key to the CA in a signed message • Receives and verifies certificate creations or new certificates from the CA PUBLIC-KEY INFRASTRUCTURE 215 ORA functions Carry out identification and authentication of users Receive and verify certificate creations... of failure 6. 4.2 Policy-making Authority Chains of trust are based on appropriate policies at all levels in the infrastructure Associated with the entire PKI is a policy-establishing authority which will create the overall guidelines and security policies that all users, CAs and subordinate policy-making authorities must follow • The PAA has the responsibility of supervising other policy-making authorities... issued and have not expired The CA returns the signed certificate and its certificate or an error message to the end user The CA posts a new certificate and CRL to the repository 6. 4.3 Cross-certification Suppose the CA has its private/public-key pair and the X.509 certificate issued by the CA If a user knows the CA’s public key, then the user can decrypt the certificate with the CA’s public key and verify... together by cross-certifying their root CA directly or using bridge CAs Figure 6. 8 illustrates a bridge-type scheme joining a hierarchical tree structure to a mesh structure PAA (root CA) PCA PCA CA CA CA CA RA U1 U2 U4 U3 Figure 6. 7 U5 U6 U7 U8 Hierarchical tree structure Bridge CA U9 U4 Root CA Root CA CA CA CA U5 CA CA RA U1 U2 U3 U6 Hierarchical structure U7 Mesh structure Figure 6. 8 A mixed structure . CA and a prospective certificate subject. In the long run, the Internet Security. Edited by M.Y. Rhee  2003 John Wiley & Sons, Ltd ISBN 0-4 7 0-8 528 5-2 202 INTERNET SECURITY goal of the Internet. ≡ 1 66 9 61 (mod 851) ≡ 41 . . . 084 61 (mod 851) ≡ 10 Hence,h= 1411003032239129071 43 18 37 47 76 01 18 20 35 10 Convert it to the hexadecimal number: h = 6a26ee0ed9ce3 963 ec8b0f98ebda84 76 Thus,. 785ac3a4bd0fe12d The 5 6- bit DES session key K is K = ba0c2b3c484ff9 (hexadecimal) The 64 -bit ciphertext Y (output of 1 6- round DES) is Y = a78791c0c8f0b444 2. RSA encryption of K: K = 52 367 72550 268 1081 (decimal) Split