cryptography and security services: mechanisms and applications manuel mogollon...

Cryptography and Security Services: Mechanisms and Applications

Manuel [email protected]

M. Mogollon – 1

Chapter 9Chapter 9Certificates and Public-Key Infrastructure

2

M. Mogollon – 2Certificates PKI Life-cycle Processes Trust Models Algorithms

Session 7 – Contents

• Certificates X.509 Basic Certificate Fields RSA Certification

• Public Key Infrastructure PKI Management Components CA Trust Models Encryption Algorithms Supported In PKI

3


Authentication and Confidentiality

Recipient

Sender’s Public Key

Yes/NoVerification

Session Key

Encipher RSA

Decipher

Decipher DES

Encipher DES

Session Key

Signed Cipher Message

Hash SHA-1

Decipher DSS / RSA

Hash

Signed Cipher Message

Digital Signature

Deciphered Message

Sender’s Private Key

Encipher RSA

Message

Cleartext Message

Hash

Hash SHA-1

Sender’s Certificate

Digital Signature

Sender’s Certificate

Hash

Sender

Digital Envelope

Digital Envelope

4


What is a Public Key Certificate?

public key certificate / n. Information provided by an issuing organization, a Certificate Authority, that has a copy of the end-user’s public key signed by the Certificate Authority, the hash value of the end-user’s public key, the name of the key’s owner, and a digital signature of the Certificate Authority. Certificates are used to identify the owner of a particular public key.

5


Certificates

• Secrecy of the public key is not required.

• Authenticity of the public key is necessary to avoid spoofing and playback attacks.

• A public key can be authenticated (signed by a Certificate Authority).

• A user can send his public key with a certificate which can then be used to verify the authenticity of the public key.

• Certificates may also include additional user information.

• Any user with access to the public key of the CA can recover the user public key that was certified.

• No party other than the CA can modify the certificate without being detected.

Certificates provide a safe method of distributing public keys via electronic media.

6


Certificates

Who certifies the Certificate Authority’s public key?

Authority’s Public Key

Authority’s Private Key

Certificate AuthorityAlice’s Computer

Alice’s info and public key

Alice’s Public Key

Alice’s Private Key

Random Number

Generator

Generates

Keys

Signed certificate

Sign

Alice

Decipher

Alice’s public key and info

I am Alice. This is my certificate to prove it. It includes my public key.

Certificate Authority’sPublic Key

7


X.509 Certificate

Certificate version

Certificate serial number

ID of the algorithm used by the issuer (CA) to sign the certificate

CA’s name issuing the certificate

Certificate validity period (not before, not after)

End-entity’s name

Subject public key information

Issuer CA’s unique ID (optional)

End-entity’s unique ID (optional)

Extensions (optional)Authority-Key IdentifierSubject-Key Identifier

●

Certificate Authority’s Private Key

Encipher

Hash SHA-1

Digital Signature

Subject’s Certificate

Information

RADIX 64

ASN1

+

DER

ASN1: Abstract Syntax One NotationDER: Distinguish Encoding Rules (tag, length, value)

8


RSA Certification

• The Certificate Authority generates its own secret prime numbers, pca and qca, its own secret encryption exponent, PrivCA, and its corresponding public decryption exponent, PubCA.

• The Certificate Authority's public numbers, PubCA andNCA (NCA = pCA . qCA), are provided to all users in the network.

• The CA certifies Alice's public key and identification number by computing the certificate public number of Alice:

• Upon receiving the certificate, Alice verifies the certificate by checking:

• When Alice wants to establish a secure communication with Bob, she sends her certificate CA to Bob and, since he has PubCA and NCA, then Bob can obtain Ident Alice and Pub Alice by computing the following:

N ) Pub ,Ident (= C CAPriv

AliceAliceAliceca mod

N C= ) Pub ,Ident ( CAAlicePub

AliceAliceca mod

N C= ) Pub ,Ident ( CAAlicePub

AliceAliceCA mod)(

9


What is a PKI?

public-key infrastructure / n. (abbr. PKI) (1) a mechanism for (a) establishing trust according to a defined trust model; (b) making entities uniquely identifiable within a domain; (c) distributing information regarding the validity of the binding between a particular key pair and an entity.* (2) An authentication mechanism.

* Adams, C., Lloyd S. “Understanding PKI”

PKI is about managing certificates and keys during their complete life

cycles; as well as the entities involved.*

10


PKI

• When public-key is used, it is necessary to have a comprehensive system that efficiently delivers security services such as confidentiality, access control, data integrity, authentication, and non-repudiation in a cohesive manner.

• That system is called Public Key Infrastructure or PKI.

• PKI enables organizations to set-up and define secure networks in a consistent manner across a wide variety of applications.

11


Public Key Infrastructure

• Manages the complete life cycle of keys and certificates.

• Provides key backup and recovery.

• Updates automatic key pairs and certificates

• Manages key histories

• Supports cross-certification

• A Certificate Authority

• A certificate repository

• A certificate revocation system

• Key backup recovery

• Support for non-repudiation of digital signatures

• Automatic update of key pairs and certificates

• Management of key histories

• Support for cross certification

• Open standards and support for legacy applications.

Functions Elements

12


PKI Management Model1. Alice registers with the certificate

authority and applies for a certificate.

2. The CA verifies Alice’s identity and issues a certificate.

3. The CA publishes the certificate at a repository site

4. Alice sends her enciphered message and certificate to Bob. The message was signed with Alice’s private key to ensure authenticity, message integrity, and non-repudiation.

5. After receiving the message, Bob goes to the repository site to check the authenticity of Alice’s certificate.

6. The repository site gives the status of Alice’s certificate.

7. Bob verifies the message’s integrity using Alice’s public key.

Repository SiteCertificate Authority / Registration Authority

Digital Signature

Enciphered Message

Alice Bob

651 2

3

4 7

13


PKI Management Entities

ReposItory

SITe

End-Entity (PKI User)

Search, Read

Published Certificates Out-of-band loading

Certificate Authority -1

Registration Authority


Out-of-band publication

Publish Certificate

PKI Users

Certificate Revocation List (CRL) Issuer

Publish CRL

PublishCertificate

14


PKI Management Model• End-Entities (PKI Users)

An end-entity is a user of PKI certificates and/or an end-user system that is the subject of a certificate.

• Certification Authority The identity and public key of each PKI user can be authenticated (signed) by a

Certificate Authority. A CA can issue several kinds of certificates including: User (end-entity) certificates, CA

certificate (a certificate for itself or for another CA), and cross certificates (an authentication process across security domains).

• Registration Authority An RA is an optional system to which a CA can delegate certain management

functions. Functions will vary from case to case, but they may include the end-entity verification

process, personal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs, etc.

RAs do not issue certificates or CRLs.

• Repository Site The repository site is a system or collection of distributed systems that stores

certificates and Certificate Revocation Lists (CRLs) and serves as a means of distributing these certificates and CRLs to end-entities.

Certificates are stored at a repository site so that applications can retrieve them on behalf of a user.

15


PKI Management Requirements

1. Conform to the ISO /IEC 9594 -8 / ITU – T X.509 standard.

2. Update regularly any key pair without affecting any other key pair.

3. Kept to a minimum the use of confidentiality (encryption) in order to ease regulatory problems.

4. Allow the use of different industry-standard cryptographic algorithms.

5. Allow the generation of key pairs by end-entity, the CA, or the RA.

6. Support the publication of certificates by the end-entity concerned, by an RA or by a CA

7. Support the production of Certificate Revocation Lists (CRLs) by allowing certified end-entities to make requests for the revocation of certificates.

8. Use a variety of "transport" mechanisms, including specifically mail, http, TCP/IP and ftp.

9. The CA is the final authority for certification creation.

10. Support scheduled, non-compromised CA key updates.

11. The CA itself may in some implementations or environments, carry out the functions of an RA.

12. An end-entity requesting a certificate containing a given public key must be able to demonstrate possession of the corresponding private key value.

16


Certificate Life-Cycle

Initialization• Key pair generation• Registration• Certificate creation• Key & certificate

distribution• Certificate

dissemination• Key backup

Issued• Certificate retrieval

• Certificate validation

• Key recovery

• Key update

• Certificate update Cancellation• Certificate expiration• Certificate revocation• Key history• Key archive

17


Key Lifecycle Management

Key Generation

CertificateIssuance

Key Usage

or

Certificate Validation

Key Expiration

Key Update

Initialization

18


Certificate Life-Cycle

Key Generation

Certificate Expiration

Certificate Revocation

Certificate and Certified Key Usage

Certificate Suspension

Certificate Creation

End-Entity Certificate

Acceptance

Certificate Resumption

Certificate Application

Key Recovery and Update

Certificate Distribution

Dissemination

19


Digital Signature

Pair Key

Signed Document

Public Key in Certificate

Certificate

Renewed Certificate

(s)

Certificate Policy Example:The pair key lifetime is 5 years.The digital signature (public key) is valid for 10 years.A certificate must be renewed every year.

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 …. 2021

Document 1

Document 2

20


PKI Management Operations

CertIfIcates ReposItory

&

CRL

End-Entity (PKI User)

Search, Read

Out-of-band loading

• Initialization• Registration• Certification• Issuance

• Key Pair Recovery and Update• Certificate Renewal and update• Certificate Revocation Request




Out-of-band publication

• Cross-certification request• Cross-certificate update

Publish Certificate

CRL: Certificate Revocation List

PKI Users

PKI Management Entities

Certificate Revocation List (CRL) Issuer

Publish CRL

PublishCertificate

Published Certificates

1 Registration Form Request2 Registration Form Replay3 Registration Form Submission.4 Registration Setup Request5 Registration Setup Results6 Registration Results7 Certificate Request8 Certificate Response

2, 6

1, 3

4

5

7 8

21


End Entity−CA/RA Processes Exchanged

• Certificate Creation Only the CA can generate certificates.

• Certificate and Key-pair Dissemination Certificate is sent to the end-entity using physical delivery, off-line distribution. Certificate is sent to an end-entity application (S/MIME), online distribution. Key-pair is sent to the end-entity, if the key-pair was generated by the CA.

• Key Backup (Optional) Key pair is stored by a trusted third key.

• Registration Identity of the end-entity is established and verified.

• Key Pair Generation Generation of public key pair, either by the end-entity,

the RA, or by the CA. In some environments, a trusted-party may generate the key pair.

If the key-pair is going to be used for non-repudiation, then it should be generated by the end-entity, the owner of the public-key pair.

End Entity (PKI User)



2 61

1

3 87

5

4

1 Registration Form Request2 Registration Form Replay3 Registration Form Submission.4 Registration Setup Request5 Registration Setup Results6 Registration Results7 Certificate Request8 Certificate Response

22


End Entity−CA/RA Processes Exchanged

• Key Pair Recovery Key pair recovery allows end-entities to recover key material from a CA or RA

when they lose key material or forget passwords, or when the devices where key material are stored get corrupted.

Key pair backup and recovery refers to the encrypting key pair; the organization can recover the end-entity private key if the key is lost, so loss of a private key doesn’t mean loss of valuable data.

The backup and recovery of signing keys should not be allowed because it destroys the basic requirement of non-repudiation.

• Key Pair Update The key pair update process supports the regular update of every key pair.

Key pairs need to be updated regularly (i.e., replaced with a new key pair), and a new certificate should be generated for the new key pair.

• Certificate Renewal and Update Certificates are assigned a valid time period. When a certificate expires, it can

be renewed or updated, Renewal means that the public key and information remain the same and a new certificate is issued. Update means that a new public key pair and information are generated and a new certificate is issued.

23


End Entity – Repository Processes Exchanged

• Certification Retrieval Certification retrieval is the process by which an end-

entity retrieves an end-entity certificate to either (1) encrypt data destined for another end-entity using the public key included in the certificate, or (2) verify a digital signature received from another entity.

• Certificate Validation The certificate was issued by a trusted CA. The

certificate needs to be validated. The certificate has not been changed. The certificate has not expired. The certificate has not been revoked. The CRL should

be check.

CertIfIcates CRL

ReposItory

End Entity (PKI User)

Search, Read

Published Certificates

24


CA1 – CA2 Processes Exchanged

• Cross Certification “Alice” has been certified by CA1 and “Bob” has been

certified by CA2. Alice trusts only the certificates signed by CA1, and

Bob trusts only the certificates signed by CA2. It is not possible for Alice to certify Bob because Alice

and Bob are in different domains. If CA1 cross-certifies CA2, Alice can extend her trust to

the end-entities certified by CA2, including Bob.



Cross-Certification

• Inter-domain cross-certificate When the subject and issuer CAs belong to different administrative domains.

• Intra-domain cross-certificate When the CAs belong to the same domain.

• Cross certification controls are possible Trust can be extended to certain groups within an organization within another CA;

e.g., organization “A” may set cross certification so their customer account managers can only accept certificates from the purchasing department of organization “B”.

25


CRL Structure

CRL version

ID of the algorithm used by the issuer (CA) to sign the CRL

CA’s name issuing the CRL

Date & time this CRL was issued

Date & time next CRL will be issued

List of revoked certificates (S/N, revocation time)

Extensions (optional) Authority Key IdentifierSubject Key Identifier

●●

Certificate Authority’s Private Key

Encipher

Hash SHA-1

Digital Signature

Subject’s Certificate

Information

RADIX 64

ASN1

+

DER

ASN1: Abstract Syntax One notationDER: Distinguish Encoding Rules (tag, length, value)

26


Hierarchical Trust Model

Level n CA3

Level 1 CA1

End Entity A

Root CA

Level 1 CA2

End Entity B

End Entity E

End Entity G

End Entity D

End Entity C

End Entity F

End Entity H

Level n CA4

Level n CA5

Level n CA6

Advantage: Relatively simple to implement

Disadvantage: No cross certification between CAs. If end-entity A wants to certify end-entity F, it needs to go all the way to CA5.

27


Mesh Trust Model

• All root CAs are cross-certified with each other, or whenever their respective communities need to communicate with each other.

Level n CA3

Level 1 CA1

End Entity A

Root CA (1)

Level 1 CA2

End Entity F

Level n CA5

Root CA

Cross-Certification

Level 1 CA2

End Entity B

Level n CA5

Root CA (2)

28


Web Trust Model • The Web trust model is the most widely used trust model. There are only two leading browsers in the

market. Certificates are included in the initial web

browser distribution. Web browsers are distributed with more than

100 CA public keys pre-installed.

• Browsers use pre-installed certificates to sign, verify, encrypt and decrypt S/MIME email messages and to establish Secure Socket Layer (SSL) sessions.

• It is a very difficult task for an end-user to manage the numerous “trusted CA certificates” installed in a browser.

• There is no practical way to prevent either users, or others with access to their workstations, from making unauthorized alterations to the list.

• There is no practical mechanism to revoke certificates. If Netscape or Microsoft makes a mistake

and installs a “bad” CA, there is no way to revoke that certificate from the millions of web browsers in use.

Level 1 CA1

End Entity A

Entrust CA

Level 1 CA2

End Entity C

Web Model

Equifax CA

Level 1 CA2

End Entity B

VeriSign CA

29


User-Centric Model

• Used by Pretty Good Privacy (PGP) in a decentralized environment.

• Any user can act as a certifying authority and validate another user’s public key certificate.

• Not all certificates generated by users are valid certificates. A certificate generated by Alice,

who is acting as CA, may not be valid to other users because they know that Alice cannot be trusted as a CA.

• Each user is directly responsible for deciding which certificates to accept and which ones to reject.

Root CA Alice

Root CA Sandra

Root CA Bob

Root CA Jason

Root CA Rick

User-Centric Model

30


Comparison of Trust Models

Characteristics Hierarchical Mesh Trust-List (Web)

Trusted key(s) “Root” CA CA that issued user’s certificate.

File of (usually) many trusted CA certificates in each browser.

Trust paths Chain of parent-child certificates.

Mesh of bi-directional cross certificate pairs.

Pre-ordered certificate list.

Trust path finding Directory-Based, comparatively simple.

Directory-Based, complex. Minimal; finds individual certificates in LDAP directory.

Cross-certification May be supported. Basis of PKI No direct capability.

Certificate status Certificate Revocation List.

Certificate Revocation List None (may add support for On-line Certificate Status Protocol in future).

31


Certificate Path and Validation

End Entity A

Root CA

● ● ●Issuer:

CA1● ● ●

Subject: End Entity A

End Entity Certificate

● ● ●

● ● ●Issuer:

CA2● ● ● Subject: CA1

Intermediate CA Certificate

● ● ●

● ● ●Issuer: CA

Root● ● ● Subject: CA2

Intermediate CA Certificate

● ● ●

● ● ●Issuer: Root

● ● ● Subject: Root

Self Signed Certificate

● ● ●

Intermediate CA 1

Intermediate CA 2

Same

32


Encryption Algorithms Supported in PKI

• Signature Algorithms Mandatory Algorithm: DSA/SHA-1 Other Algorithms: HMAC/SHA-1, RSA/MD5 and ECDSA/ECDH

• Public Key (Asymmetric) Algorithms Mandatory Algorithm: Diffie-Hellman Other Algorithms: RSA, ECDH.

• Symmetric Algorithms Mandatory Algorithm: 3DES and AES in CBC mode. Other Algorithms: RC5, Cast 128,.

33


Models for PKI Deployment

• In-Sourcing Gives an organization full control of a PKI implementation by utilizing its own resources,

including personnel and hardware, and/or hiring external resources. Allows organizations to issue and manage certificates in a consistent manner.

• Out-Sourcing Takes the PKI management burden from the organization and gives control of the PKI

operation to an external party.

• Factors in Choosing PKI Deployment Model Total cost of ownership − software, hardware, personnel, facilities, training, legal fees,

etc. Degree of control that the organization wants to maintain during the PKI operation. Perceived sense of trust that customers will have from knowing that the PKI operations

are out-sourced or in-sourced. Response time associated with PKI related services. Level of help desk support. Flexibility and scalability. Ability and willingness of the vendor to evolve to meet the future needs of the

organization. Disaster planning and recovery.

34


To Probe Further• [NEW01] Newman, D. PKI: Build, Buy, or Bust. Networkworld Magazine, December 10,

2001. Retrieve on January 6, 2002 from http://www.nwfusion.com/research/2001/1210feat.html

• [RFC 2510] Adams, C., Farrell. S. “Internet X.509 Public Key Infrastructure Cer-tificate Management Protocols.” RFC 2510, March 1999.

• [RFC 2511] Myers, M., Adams, C., Solo, D., Kemp, D. "Internet X.509 Certificate Request Message Format." RFC 2511, March 1999.

• [RFC 2527] Chokhani, S., Ford, W. “Internet X.509 Public Key Infrastructure Cer-tificate Policy and Certification Practices Framework.” RFC 2527, March 1999.

• [RFC 2528] Housley, R., Polk, W. “Internet X.509 Public Key Infrastructure Repre-sentation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key In-frastructure Certificates.” RFC 2528, March 1999.

• [RFC 2898] Kaliski, B. “PKCS #5: Password-Based Cryptography Specification Version 2.0.” RFC 2898, September 2000.

• [RFC 2315] Kaliski, B. “PKCS #7: Cryptographic Message Syntax Version 1.5.” RFC 2315, March 1998.

• [RFC 2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C. “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.” RFC 2560, June 1999.

• [RFC 2585] Housley, R., Hoffman, P. “Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP.” RFC 2587, May 1999.

• [RFC 2587] Boeyen, S., Howes, T., Richard P. “Internet X.509 Public Key Infra-structure LDAPv2 Schema.” RFC 2587, June 1999.

35


To Probe Further• [RFC 2985] Nystrom, M., Kaliski, B. “PKCS #9: Selected Object Classes and At-tribute

Types Version 2.0.” RFC 2315, November 2000. • [RFC 2986] Nystrom, M., Kaliski, B. "PKCS #10: Certification Request Syntax Specification

Version 1.7." RFC 2986, November 2000.• [RFC 3029] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R. “Internet X.509 Public

Key Infrastructure Data Validation and Certification Server Proto-cols.” RFC 3029, February 2001.

• [RFC 3039] Santesson, S., Polk, W., Barzin, P., Nystrom, M. “Internet X.509 Pub-lic Key Infrastructure Qualified Certificates Profile.” RFC 3039, January 2001.

• [RFC 3161] Adams, C., Cain, P., Pinkas, D., Zuccherato, R. “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).”. RFC 3161, August 2001.

• [RFC 3279] Bassham, L., Polk, W., Housley, R. “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” Rfc 3279, April 2002.

• [RFC 3280] Housley, R., Polk, W., Ford, W., Solo, D. “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” RFC 3280, April 2002.

• [RFC 3447] Jonsson, J., Kaliski B. “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1.” RFC 3447, February 2003.

• [RFC 3494] Zeilenga, K. “Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status.” RFC 3494, March 2003.

• [WH99] Wing, P. O’Higgins, B. Using Public-Key Infrastructure for Security and Risk Management. IIEE Communications Magazine September 1999.

36


Value of Digital Signatures (from VeriSign)

37


Value of Digital Signatures (From VeriSign)

38


PKI-Enable Application List

(From PKI Forum)

39


PKI-Enable Application List

(From PKI Forum)

cryptography and security services: mechanisms and applications manuel mogollon...

Documents

public key certificate

user public key

endusers public key

particular public key

public keys

certificate cas

certificate sign alice

pki slide