Public Key Infrastructuresignoril/cs363/notes-old/private-key-infrstucture.pdf · key represented as Alice’s public key really is hers (and vice versa). 2. A means to know if the

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.


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.


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.


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

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


6

The Response - Bob to Alice

EncryptedResponse

&Challenge

Signature

Response&

ChallengeDigest

Digest

Hash

Response&

Challenge

Hash


Bob Transmitted Alice

Compare

Bob’sPrivateKey

Bob’s Public Key

Application: Integrity of document, non-repudiation of source, secrecy of response/challenge

Signature


Alice’sPrivate Key


7

Key Exchange

EncryptedSecretKey

Signature

SecretKey Digest

Digest

HashSecretKey

Hash


Alice Transmitted Bob

CompareAlice’sPrivate Key


Application: Integrity of key, non-repudiation of source, secrecy of the key

Signature

Bob’sPublic Key

Bob’sPrivate Key


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.


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.


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.


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.


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.


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?)


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


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


16


• 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.


17


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).


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.


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.


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.


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.


22


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.


23


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.


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


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.


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.


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!


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


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).


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).


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


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.


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.).


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).


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).


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.


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.


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!


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).


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.


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.


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.


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.


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.


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):


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.


47


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.


48


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).


49


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.)


50


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.


51


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)


52


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).


53


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.


54


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.


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.


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.


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

Documents

Public Key Infrastructuresignoril/cs363/notes-old/private-key-infrstucture.pdf · key represented as Alice’s public key really is hers (and vice versa). 2. A means to know if the