5/3/2006 some thoughts on Public Key Infrastructure
1
Public Key InfrastructureAn infrastructure is required to use these in a network.
It supports public key (asymmetrical) cryptography as well as the option to use secret key (symmetric) systems for confidentiality.
5/3/2006 some thoughts on Public Key Infrastructure
2
Re-Cap of a Robust Exchange
Users generate private/public key pairs, keep private keys secret and exchange public keys with others.
Assume Alice wants to communicate with Bob. She wants:
- strong authentication,- to exchange confidential information, - be sure messages arrive with high integrity, and - ensure she has non-repudible evidence that Bob
received and opened her messages.
5/3/2006 some thoughts on Public Key Infrastructure
3
• Bob wants to be assured he is communicating with Alice and only Alice.
• 1. Challenge from Alice to Bob.• 2. Response from Bob to Alice and
Challenge from Bob to Alice.• 3. Exchange of secret keys.• 4. Exchange of secret information.
5/3/2006 some thoughts on Public Key Infrastructure
4
Step in a Robust Exchange
Alice initiates communication and Bob responds
Alice Challenges Bob.
Bob responds to Alice and Challenges her.
Once they are mutually authenticated, they:Exchange secret keys.Exchange of secret information.
Each exchange can be tested for integrity.
5/3/2006 some thoughts on Public Key Infrastructure
5
The Challenge - Alice to Bob
Signature
Challenge Digest
Digest
HashChallenge
Hash
Digest Signature Signature
Alice Transmitted Bob
CompareAlice’sPrivate Key
Alice’s Public Key
Application: Integrity of document, non-repudiation of source, secrecy of challenge
Signature
Bob’sPublic Key
Bob’sPrivate Key
EncryptedChallenge
5/3/2006 some thoughts on Public Key Infrastructure
6
The Response - Bob to Alice
EncryptedResponse
&Challenge
Signature
Response&
ChallengeDigest
Digest
Hash
Response&
Challenge
Hash
Digest Signature Signature
Bob Transmitted Alice
Compare
Bob’sPrivateKey
Bob’s Public Key
Application: Integrity of document, non-repudiation of source, secrecy of response/challenge
Signature
Alice’s Public Key
Alice’sPrivate Key
5/3/2006 some thoughts on Public Key Infrastructure
7
Key Exchange
EncryptedSecretKey
Signature
SecretKey Digest
Digest
HashSecretKey
Hash
Digest Signature Signature
Alice Transmitted Bob
CompareAlice’sPrivate Key
Alice’s Public Key
Application: Integrity of key, non-repudiation of source, secrecy of the key
Signature
Bob’sPublic Key
Bob’sPrivate Key
5/3/2006 some thoughts on Public Key Infrastructure
8
Requirements
1. Bob and Alice need a trusted means of exchanging public keys, otherwise Eve could impersonate either of them. This exchange does not have to be secret, but Bob must have a means of trusting that the key represented as Alice’s public key really is hers (and vice versa).
2. A means to know if the keys are still valid at the time of use (a key may have been compromised or changed).
3. A means to identify and agree on the digest and encryption algorithms to use (there are several options for digests as well as encryption algorithms.
5/3/2006 some thoughts on Public Key Infrastructure
9
Alternatives
Using secret key technology, Bob and Alice could meet in person and exchange keys.
They could also use other methods (e.g., Diffie Hellman key exchange, symmetric encryption, etc.).
However, Bob and Alice may need to communicate with others. They also must ensure that their public keys are remain valid, and they need to be able to change technology without meeting again. Doing this for many users is not practical if they have to meet all the time.
5/3/2006 some thoughts on Public Key Infrastructure
10
Requirements - Simplified
1. Create, manage, and securely exchange public keys.
2. Serve trusted credentials to bind user’s to their keys.
3. A means to know if the keys are valid or trusted (initially and over time - some time may have elapsed since the keys were initially exchanged).
4. A means to identify or agree on the digest (hash) algorithm and/or encryption/decryption algorithms.
5/3/2006 some thoughts on Public Key Infrastructure
11
A Solution
A Public Key Infrastructure (PKI) provides all these functions.
A PKI is a policy-based, technology infrastructure for reliably and securely delivering cryptographic services to users on a local, national, and/or international basis, even if they never meet in person.
Web commerce is supported by PKI.
5/3/2006 some thoughts on Public Key Infrastructure
12
Elements of a Public Key Infrastructure
1. Public Key Certificates - a data structure.
2. Public Key Certificate Authority (CA) – a server thatcreates/validates/manages public key certificates.
3. Public Key Repository - Directory server for certificates.
4. Registration Authority (RA) - a remote site proxy for the CA.
5/3/2006 some thoughts on Public Key Infrastructure
13
Elements of a Public Key Infrastructure (more)
5. A Certificate Revocation List (CRL) - a list of invalid certificates that were previously issued.
6. A Certificate Practices Statement issued by the CA describing the policies and procedures of the CA. Sometimes described in two parts:
A certificate policy statement (the CA rules).A certificate practices statement (the CA procedures).
7. A validation process to certify the CA (does it do what the rules and procedures say it does?)
5/3/2006 some thoughts on Public Key Infrastructure
14
PKI Structure
CertificateAuthority
DirectoryServer (LDAP)
User A User B
RevokedCertificateList Signed
Certificates
Private key Private keyA’s Certificate B’s Certificate
Enrolls usersCreates certificatesSigns & issues certificatesSends certificates to directory serverRevokes certificatesPublishes Policy & Practices Cross certifies with other CA’s
Keeps certificate &revocation list database
5/3/2006 some thoughts on Public Key Infrastructure
15
Certificate Authority - Policy Statement
Scope: Policy for the issuance, management, and use of public key certificates & cryptographic technology used for:
Identification,Authentication,Confidentiality,Integrity, andNon-repudiation
5/3/2006 some thoughts on Public Key Infrastructure
16
Certificate Authority - Policy Statement
• Indicates the assurance level for the policy (this can be low,
• medium, or high assurance and defines the rigor of the policy).
• High assurance would imply the strictest policy.
• Defines the roles & responsibilities of all participants in issuing,
• managing, and using certificates and cryptographic materials.
5/3/2006 some thoughts on Public Key Infrastructure
17
Certificate Authority - Policy Statement
Assurance: Indicates the assurance level for the policy (this can be low, medium, or high assurance and defines the rigor of the policy).
High assurance would imply the strictest policy (and the most secure implementation).
Roles & Responsibilities: Defines the assignments and behavior of all participants in issuing, managing, and using certificates and cryptographic materials (the dos And don’ts).
5/3/2006 some thoughts on Public Key Infrastructure
18
What are Certificates?
Certificates are electronic identifiers issued by the CA to bind the name of a subject of a certificate to the subject’s public key and any other information in the certificate.
Entities can be individuals, corporations, or systemsThe binding is certified as valid by the CA
Certificates are generated, issued, managed and signed (authenticated) by the CA using the private key of the CA.
Certificate content is defined in the CA policy - Usually this mean the international standard called X.509, V3.
5/3/2006 some thoughts on Public Key Infrastructure
19
X.509 Certificates – Data Content
Version: Version 3; Identifies the version being used by the CA. Multiple versions may be in use.
Serial Number: 1234567; Unique in the domain served by the CA. Ensures that the certificate is unique (no duplicates).
Signature Algorithm: RSA with MD5; A number registered with a recognized standards organization that specifies the signing (Hash) and the public key encryptionalgorithm used by the CA.
5/3/2006 some thoughts on Public Key Infrastructure
20
X.509 Certificates – Data Content
Certificate issuer X.500 name: c = US, o = Acme Corp. This is the X.500 (another international standard) distinguished name of the issuer of the certificate, where c = country code and o = organization code.
Validity Period: Start and expiry dates for the certificate.
Subject X.500 Name: c = US, o = Acme Corp., cn = John B. Doe, where cn = subject’s distinguished name. This is the name of the person (or entity) holding the private key corresponding to the public key contained in the certificate.
5/3/2006 some thoughts on Public Key Infrastructure
21
X.509 Certificate Contents - Continued
Subject Public Key: KEY value, RSA encryption with MD5 digest.
Holds the actual VALUE of the public key and identifies the algorithm that is to be used with the key (others cannot be used – they will not work, or would potentially breach the CA policy).
Why? The CA policy statement describes appropriate uses of issued certificates. Any other use violates the CA’s policy.
5/3/2006 some thoughts on Public Key Infrastructure
22
X.509 Certificate Contents - Continued
Issuer Unique identifier: Any bit string. Used to uniquely identify the issuing CA in case duplicate X.500 names are issued (OPTION).
Needed if CA’s need to cross-certify. Since certificates are issued by specific CAs, it is possible for a CA to be created with the same X.500 name as another - there is no central clearing house for these names. This number reduces duplication possibilities.
This points out a problem with CAs. An optional field isLeft to the developer to specify – bad idea.
5/3/2006 some thoughts on Public Key Infrastructure
23
X.509 Certificate Contents - Continued
Subject Unique Identifier: Any bit string. Used to uniquely identify the subject in case of a duplicate subject name (OPTION).
Reasoning is the same as in the case of the issuer.
Certificate Authority (CA) signing key: The CA’s public key used to decrypt a digital signature on a message thatwas signed (read authenticated) by the CA.
Usually this message will contain a certificate that was requested.
5/3/2006 some thoughts on Public Key Infrastructure
24
X.509 Certificate Contents - Summary
Certificate format version
Certificate serial number
Signature algorithm identifier
Issuer X.500 name
Validity period
Subject X.500 name
Subject public key information
Issuer unique identifier (optional)
Subject unique identifier (optional)
CA Signature
Version 3
1235467
RSA with MD5 (for the CA)
c = US, o = Acme
Start = 01/08/99, expiry = 01/08/00
C=US, o=Acme, cn=John B. Doe
A$%*bDf…., RSA with MD5
RSA on MD5 hash of the certificate
5/3/2006 some thoughts on Public Key Infrastructure
25
Certificate Authority
A CA is operated in a secure environment and in accord with a strict set of rules (its policy and practices statement).
The reason for strict policy and operating rules is that this server must be trusted by all users including other CA's.
1. Users register with a CA by providing their subject name and public key information.
2. The CA issues an X.509 certificate that:
Binds the user's identity to a public key, contains the user’s public key, andis hashed and the hash signed by the CA.
5/3/2006 some thoughts on Public Key Infrastructure
26
Certificate Authority Registration
To register, a user presents his(her) public key and some credential of personal identification (driver's license, badge, a pint of blood for DNA analysis, etc.). The CA policy statement will indicate what forms of identification are acceptable.Higher security requires better credentials.
The CA creates an X.509 certificate for the user and stores it on the CA, and/or on a Directory server (LDAP), and sends a copy to the user. The CA issues the user a registration number and identifier.
5/3/2006 some thoughts on Public Key Infrastructure
27
Certificate Authority Registration
NOTE: The initial transaction between the user and the CA is not cryptographically secure since the CA has no knowledge of the user's identity or public key.
Neither does the user have a copy of the CA's public key. A user might look it up on the network, but there is no means to encrypt the exchange. Thus, the user cannot trust that a CA's public key really belongs to that CA –
These exchanges need to happen securely!
5/3/2006 some thoughts on Public Key Infrastructure
28
CA - Registration Process
User A
RegistrationAuthority
CertificateAuthority
1. Deliver Certificate Client2. Install Client3. Generate keypair.4. CompleteCertificate request
5. Present request to RA
6. Approve Request
7. Sign Request8. Send to CA I…. Do..
Certify…………..
9. Approve request10. Generate certificate
11. Send Certificateto LDAP Server
12. Send Certificate to Requestor
5/3/2006 some thoughts on Public Key Infrastructure
29
Certificate Authority - Registration Process
Assume an organization has purchased a CA license and set up a CA server. A user typically registers as follows:
1. User appears in person with proof of identity.
2. CA issues a registration number, and user identity. This is a one-time password that will be used to access the CA to electronically enroll.
3. User installs the PKI client software (this could occur before the previous steps, but must be before step 4).
5/3/2006 some thoughts on Public Key Infrastructure
30
Certificate Authority - Registration Process
4. The user logs in using the identifier and registration number.
5. The PKI client software generates a private/public key pair, user selects a pass-phrase, a profile is built and sent to the CA.
6. The CA creates the user's certificate, signs it with the CA's private key and sends it to the user.
From this point on, the cryptographic services of the CAcan be used (e.g., encrypt e-mail for transmission to another user by simply clicking on an e-mail plug-in).
5/3/2006 some thoughts on Public Key Infrastructure
31
Certificate Authority - Typical Exchange
Alice CA Bob
QueryResponse
ValidateAlice's publickey with CA,
proceedwith
processingMD5 Digest
Message
Message+
Signature
Alices Signing Key
Request for Alice's Certificate
Alice'sCertificatesigned withCA private
key
5/3/2006 some thoughts on Public Key Infrastructure
32
Certificate Authority - Typical Exchange
Alice sends a message to Bob signed with her private key. The message might also be encrypted. Bob receives the message and forms a request to the CA for Alice's public key. The CA returns Alice's certificate. The returned certificate is signed by the CA (signed means the certificate digest (hash) is encrypted with the CA's private key.Bob uses the CA's public key to open the digest and validates the integrity of Alice's certificate. If OK, Bob has Alice's signing key.Bob uses Alice's public signing key to open the digest and validate the message as being from Alice & unchanged in transmission.If the message had been encrypted, Bob would do all of the aboveand then get the secret key from Alice. Alice would also need toverify Bob through the CA.
5/3/2006 some thoughts on Public Key Infrastructure
33
Certificate Authority - Result
Seems like a lot of trouble. Bob and Alice could have done this using challenge-response, Diffie-Hellman, etc.).
The value of a CA is that it provides all these functions in a very generalized way, most notably:
1. Everything is done within a common infrastructure with a common rule set - good business practice to have consistent, centralized, and enforceable rules.
2. The CA avoids negotiation and manual public key exchange between all of Bob's partners (Fred, Alice, etc.).
5/3/2006 some thoughts on Public Key Infrastructure
34
Certificate Authority – More Functions
1. Creates & manages certificates over their full life cycle.
2. Source repository for validated certificates.
3. Maintains a list of valid certificates, replicates them to the site directory server. The directory server actually serves them on request to users.
4. Maintains a list of invalid certificates. Certificates expire or are otherwise invalidated (e.g., compromised key,Stolen computer, employee dies, etc.). Called a Certificate Revocation List (CRL).
5/3/2006 some thoughts on Public Key Infrastructure
35
Certificate Authority – More Functions
5. Maintains a key backup and recovery system.
6. Maintains a key history capability (may need to use an old key to authenticate stored data).
7. Performs cross-certification with other CA’s in a trust relationship.
8. Most CA's also support the concept of a Registration Authority (RA).
5/3/2006 some thoughts on Public Key Infrastructure
36
Registration Authority - Functions
If the CA is located at some distance from its users, we need a remote authority that can act as a proxy for the CA.
An RA is empowered to identify users and issue registration and identity numbers, but not generate certificates.
RAs validate user identities and securely enroll them in the CA since the RA can do secure communications with the CA. RA's must appear in person at the CA when they are first identified and enrolled.
5/3/2006 some thoughts on Public Key Infrastructure
37
Registration Authority – Functions
Once an RA is enrolled:
1. User contacts RA with proof of identity. 2. RA authenticates and issues identifier and registration number (one-time password).3. User can then log into the CA and complete the process as before.
All users must agree to comply with the policies of a CA. This usually involves signing a statement of compliance.
5/3/2006 some thoughts on Public Key Infrastructure
38
Key Backup - Escrow
One CA consideration is key recovery (escrow).
Lost or forgotten keysTerminated employees or employees that die
If the holder of a key used to encrypt information is not available, it may be necessary to recover the key.
It is easy to assume all keys need a recovery mechanism
NOT TRUE - Must distinguish between signing keys and encryption keys!
5/3/2006 some thoughts on Public Key Infrastructure
39
Different Types of Keys
Signing Key:
Private half of a public key pair used solely for the purpose of authenticating a message (sign with private key, open with public key)
Also called
Digital signature (encrypt a hash with a private key, decrypt with a public key).
5/3/2006 some thoughts on Public Key Infrastructure
40
Different Types of Keys
Encryption key:
Either a public key pair, where the public key is used to encrypt and the private key to decrypt (Alice sends a secret message to Bob encrypted with Bob’s public key - only Bob can open the message)
OR,
a symmetric key, exchanged with a public key pair and used to encrypt message traffic between Alice and Bob.
5/3/2006 some thoughts on Public Key Infrastructure
41
Key Escrow - Signing Key
Non-repudiation is provided by a signing key.To ensure signing security, the owner of a signing key should NEVER disclose the signing key to anyone else. It must be kept secret for the life of the key. SO…..
1. Signing keys are never backed up (except by the user).2. Signing keys are never archived or escrowed.3. Signing keys are never disclosed to another party.4. Signing keys are securely destroyed at the end of their active life. To do otherwise means it might be disclosedand could be used to forge signatures on old documents.
5/3/2006 some thoughts on Public Key Infrastructure
42
Key Escrow - Other Keys
Symmetric secret keys need to be backed up or archived in order to recover information that is encrypted in certain situations:
Keys are lostEmployee that encrypted the data is unavailableOn legal request (courts, law enforcement)
Public Keys used to encrypt information (not sign or authenticate) also need to be archived. They can be recreated from the private key. A private encrypting key does need to be archived.
5/3/2006 some thoughts on Public Key Infrastructure
43
Key Escrow - Summary
This means we need to have three kinds of keys:
Signing key pairs: never escrowEncrypting key pairs: always escrowEncrypting secret keys always escrow (except
when used as session keys)
A session key is created for a specific session and used to encrypt data traffic. The volume would be large.
5/3/2006 some thoughts on Public Key Infrastructure
44
Certificate Policy Statement
Recall: A statement of policy for issuing, managing, and using certificates and cryptography for identification, authentication, confidentiality, integrity, and non-repudiation. Specifies:
1. Certificate type and version # (typically X.509, V 3).2. Intended use of certificates (typically only to bind an identity to a public key).3. Types of keys used and their intended use (e.g., signing, encryption).4. Escrow requirements.
5/3/2006 some thoughts on Public Key Infrastructure
45
Certificate Policy Statement
5. Components of the CA:
CA and any agents of the CARA and any agents of the RARepositoriesUsers and other entities certified
6. Applicability - intended use (next page):
5/3/2006 some thoughts on Public Key Infrastructure
46
Certificate Policy Statement - Continued
A. Public key encryption or session key exchange for (defined classes of information like sensitive, business sensitive, etc. - organization dependent). May include what are not approved uses.B. Verify integrity of messages, documents, and data transmission through the use of digital signatures.C. Verify the signer of electronic messages, files, documents, and data transmission using a digital signature.D. Verify the identity of client computers, servers, and other computer systems in the organization.E. Verify the identity of recipients of sensitive information.
5/3/2006 some thoughts on Public Key Infrastructure
47
Certificate Policy Statement - Continued
7. Where CA names must be registered (e.g., in the corporate office of CA policy).8. Permissibility of cross-certification with other CA’s and assurance required prior to cross-certification.
Cross certification allows a CA to trust the users of another CA (e.g., between two companies).
9. Liability. When things go bad, who is responsible? ItIs never a commercial CA – or at least they attempt todeny liability.
5/3/2006 some thoughts on Public Key Infrastructure
48
Certificate Policy Statement - Continued
10. Roles and obligations:
Certificate Authority (accuracy, rejection policy, protection of keys, types of certificates issued, revocation, escrow).
Registration Authority (approval, delegation, etc.).User (expected behavior protecting keys, notifications to CA for lost keys, agreement to escrow policy).Sponsor (someone approving the issue of a certificate to anemployee, customer, collaborator, etc.).
Relying party (anyone relying on the certificates issued).
5/3/2006 some thoughts on Public Key Infrastructure
49
Certificate Policy Statement - Continued
11. Publications and repositories (identifies available data):
Method of publication (typically an on-line repository)Copies of the policy & practices statementCopies of any cross-certification assurance agreements (who else does this CA trust?)Copies of public key certificates issued by the CACopies of the Certificate Revocation List (CRL)Copies of the Assurance Revocation List (ARL), if any
12. Confidentiality (rules associated with access to private keyboth normal and exceptional operations (data recovery, disclosurto third parties, diagnosing and troubleshooting problems, etc.)
5/3/2006 some thoughts on Public Key Infrastructure
50
Certificate Policy Statement - Continued
12. Confidentiality (rules associated with access to private keys) in both normal and exceptional operations (data recovery, disclosure to third parties, diagnosing and troubleshooting problems, etc.).
13. Identification & Authentication – registration:
Names and uniqueness, proof of identity (credentials).Forgotten passwords (usually re-start from scratch).Re-key after compromise.Revocation requests.
5/3/2006 some thoughts on Public Key Infrastructure
51
Certificate Policy Statement - Continued
14. Operational Requirements:
Certificate application processUser acceptance of the certificate (e.g., written agreement)Certificate suspension & revocation (conditions invoking)
15. Audit Requirements:
OS account creation, upgrades, patchesConfiguration control, backups, shutdowns, re-startsAudit log dumps (anytime the audit log is reset)
5/3/2006 some thoughts on Public Key Infrastructure
52
Certificate Policy Statement - Continued
16. Records Archival Requirements.
17. Key Lifetime (CA, RA, End users).
18. CA Compromise and Disaster Recovery.
19. Termination of a CA (what is to be saved, who is notified?).
20. Physical Security Controls - CAs, RAs, users (locked doors, entry controls, logs, inspections, backup storage).
5/3/2006 some thoughts on Public Key Infrastructure
53
Certificate Policy Statement - Continued
21. Procedural Controls - Who can do what? Required forCA and System administrator, Security Officer). May include a 2-person rule.22. Personnel Security - Training requirements for users.23. Technical Security Controls - key pair generation, private key delivery, delivery of public keys, CA public key delivery, key sizes, key usage, private key protection, algorithm standards, controls, etc.24. CA Computer Security Controls. 25. Network Protection - protection for the domain and segment where the CA resides.
5/3/2006 some thoughts on Public Key Infrastructure
54
Certificate Policy Statement - Continued
26. Life Cycle Controls - Applied over the complete life cycle of the CA. System development, security management, change control, integrity control.27. X.509 Certificate profile - rules for use of X.509 certificate fields - what is permissible, and what isn’t.28. Policy Change Control Procedures - approvals and notifications for any change to the policy document.
5/3/2006 some thoughts on Public Key Infrastructure
55
Why All These Rules?
CAs hold the keys to the kingdom and must be carefully managed.
Others rely on the accuracy and integrity of the CA.If the relying party is in another organization, chancesare that organization has no control over the CA.
In some settings, a CA must meet legal requirements.
TRUST. A CA is a trusted third party.
5/3/2006 some thoughts on Public Key Infrastructure
56
Trusted Third Parties
Defined: Someone trusted by all participants in action to behave fairly, securely, and with no ulterior motive.
Commerce generally uses trusted third parties:
We trust the government to back the currency we useSeller trusts the bank to honor a credit cardOther trusted instruments – checks, notarized documents,drivers license, passport, judicial system, etc.
5/3/2006 some thoughts on Public Key Infrastructure
57
Trusted Third Parties
CA’s are trusted third parties, so must behave in strict accordance with a set of rules so we know they can be trusted (most of the time).
They are also subjected to rather rigorous audits and the policies and practices statements give the auditors abasis for determining compliance.
Example: eBay fraud – offer an item, sell it, get funds, don’t deliver – real cases have been prosecuted