Lecture 4 PKI – Component, Architecture & Management

1. SVU University MWS Course 2011 Lecture 4PKI – Component, Architecture & Management Dr. Moutasem Shafa’amry t_mshafaamri@svuonline.org

2. Outline Key/certificate life-cycle management • a) initialization phase, b) issued phase, c) cancellation phase • Certificate Revocation Lists (CRLs) PKI components: • Registration Authority (RA) • Certification Authority (CA) • Repository • Archive Introduction to non-repudiation • • types of non-repudiation • • technical model • • Non-repudiation service based on PKI • • mechanisms for non-repudiation

3. Life-cycle management Key/certificate life-cycle management covers the functions associated with: creation, issuance, andcancellation of public-private key pairs and their associated certificates • • note that this definition concerns the keying material associated with an entity—not the identity of the entity

4. Main Phases • Initialization Phase • Issuing Phase • Cancellation Phase

5. Initialization phase • Initialization: • 1. end-entity registration • 2. key pair generation • 3. certificate creation • 4. certificate dissemination • 5. key backup

6. PKI components PKI components : • Registration Authority (RA) • Certification Authority (CA) • Repository • Archive

7. RA(Registration Authority) • Assume that each user shows up in person at RA • The RA first verifies the information presented by a user requesting a certificate: • driver’s license • passport • employee badge with picture • credit limit • signature authority

8. RA ... • Finally, the RA initiates the certification process with a CA on behalf of the user • observe that the RA does not issue any certificate, this is only done by the CA

9. Key generation • User initiates the generation of a key pair (e.g. inside a tamper resistant smart card) • the private key is kept secret • the public key is given to the RA • In some cases the keys are generated by the RA and the private key is given to the user • It must be possible for the CA to verify that a user owns a particular key pair

10. Two-key pair model • Key-pairs: • one key pair for confidentiality services • one key pair for non-repudiation services • Different key-pairs are needed because they must satisfy different management requirements (see next page)

11. Why use two key-pairs?

12. More than two key-pairs? • It may be necessary to have different pairs of keys for digital signing, e.g. • one private key for signing of large purchase orders, • another key to sign rental forms at the video store, • and yet another key to sign e-mails

13. Private-key protection • Several methods exist to protect private keys: 1. storage in a tamper-resistant smart card or PCMCIA card (recommended method) 2. storage in an encrypted file on a hard drive or other storage medium 3. storage on a server • Access to a key needs to be protected via a password or PIN in all cases

14. 1. End-entity registration CA RA End-Entity 1.Registration form Request 4.Registration Setup Request 2.Registration form reply 5.Registration Setup results 3.Registration form Submission 6. Registration Results 7. Certificate Request 8. Certificate Response

15. CA (Certification Authority) • A CA maintains a list of RAs it trusts • The CA performs two functions: 1. issuing certificates 2. maintaining CRLs (Certificate Revocation Lists)

16. Issuing certificates • A CA issues certificates to users and, in some cases, other CAs • The CA guarantees that the entity named in a certificate has the private key corresponding to the public key in the certificate • The CA also asserts that any additional information, e.g. policy and contact information, in the certificate is valid

17. Issuing certificates ... • • When a CA issues a certificate to another CA, it (the first CA) asserts that the certificates issued by the other CA are trustworthy • The issuing CA inserts its name in every certificate and CRL it generates, and signs them with its private key • Users verify the signature of the certificates and CRLs using the issuing CA’s public key

18. Certificate creation • A secure protocol is needed to request a new certificate and to receive a certificate from a CA • Two RFCs of interest are: • RFC2510, The Internet X.509 Public Key Infrastructure Certificate Management Protocols (CMP) • RFC2511, The Internet X.509 Certificate Request Message Format (CRMF)

19. Issuing certificates ... • The CA’s digital signature is the basis of trust for all issued certificates • If an attacker can obtain the CA’s private key, then users will trust certificates generated by the attacker

20. Cryptographic modules • The CA’s private key is often stored in a cryptographic module • A hardware cryptographic module performs cryptographic operations on an external processor • because these operations are not done in the CA’s memory, the security is less dependent on the CA’s OS

21. NIST requirements • The National Institute of Standards and Technology (NIST) developed FIPS 140-2, Security Requirements for Cryptographic Modules • FIPS 140-2 describes four increasing levels of security • Accredited third-party laboratories perform validation testing of modules

22. Certificate profile • A CA has a certificate profile defining the types of information to include in the certificates • Example: If a CA specifies that it only issues e-mail certificates, it cannot issue a certificate for contract signing

23. Certificate profile ... • The CA must • ensure that every certificate conforms to the profile • protect the profile by restricting access to CA components

24. Certificate revocation • A certificate must be revoked before it expires when there is a • private-key compromise • change in job status • termination of employment • An end user or an authorized administrator may request a certificate revocation

26. 2. Maintaining CRL • A CRL may contain the information: • list of revoked certificates • the date each certificate was revoked • the reason why each certificate was revoked

27. Repository • A repository accepts certificates and CRLs from one or more CAs • It provides these certificates and CRLs upon request • requests based on name of user or CA • A user accepts the certificates and CRLs because they are signed by a trusted CA

28. Repository ... • Note that the distribution of certificates and CRLs is about availability and performance, not security

29. Archive • An archive maintains information to identify the signer of an old document based on an expired certificate • must keep information to identify the person named in the certificate • prove that the person requested the certificate • show that the certificate was valid at the time the document was signed

30. Archive ...

32. Non-repudiation • Non-repudiation. Offers a person protection against a false claim by another person that a communication never took place • Non-repudiation of origin. A person cannot falsely deny having originated a message or document • Non-repudiation of delivery. A person cannot falsely deny having received a message or document

33. Legal view • Non-repudiation consists of the ability to convince a third party that a specific message or document originated with, or was delivered to a certain person Credible evidence is needed to persuade a • judge, • jury, or • arbitrator

34. Trusted third party needed • To obtain a high degree of non-repudiation, it is essential that at least one Trusted Third Party (TTP) collects, validates, time stamps, signs, and stores relevant non-repudiation evidence

35. Non-repudiation of origin • Non-repudiation of origin protects a recipient from disputes where he claims to have received a message • but the party identified as sender claims not to have originated the message • different from that which the sender claims to have originated • originated on a specific time and date, but the party identified as sender claims not to have originated the message at that specific time and date

36. What is the real problem? • The originator is lying • The recipient is lying • A computer or communications error has occurred • An intervening third party has deceived the two parties

37. Needed evidence • The identity of the originator • Content of message • Date and time when origination occurred • Identity of the intended recipient • Identity of any TTPs involved in generating or retaining records

38. Non-repudiation of delivery • Non-repudiation of delivery protects an originator in a dispute where he claims to have sent a message • but the party identified as recipient claims not to have received the message • different from that which the recipient claims to have received • on a specific date and time, but the recipient claims not to have received the message at a time and date consistent with the originator’s claim

39. What is the real problem? • Same problems as before: 1. the originator is lying 2. the recipient is lying 3. a computer or communications error has occurred 4. an intervening third party has deceived the two parties

40. Needed evidence • The identity of the recipient • Content of message • Date and time at which delivery of the message occurred • Identity of originator • Identity of any TTPs involved in generating supporting records

41. Implementation:technical model • The non-repudiation process can be divided into five phases: 1. non-repudiation request 2. record generation 3. record distribution 4. record verification 5. record retention

42. Non-repudiation service • A non-repudiation service utilizing digital signatures can be built on top of a standard PKI • Basic PKI services must be combined with the correct combination of legal and technical non-repudiation protocols

43. Dispute resolution • Dispute resolution involves 1. retrieval of the non-repudiation records, 2. presentation of the records to the parties, 3. presentation of the matter before the arbiter, and 4. the arbiter’s decision.

44. Concluding remark • A high level of non-repudiation requires three TTP services • • archive • • secure time stamping • • notarization • This makes for a very expensive and complicated implementation