PKI

Overview

  • PKC & PKI
    • PKC is about math, but PKI is about binding a pair of key to one person
  • definition
    • PKI is a set of hardware, software, people, policies and procedures needed to create, manage, distribute, use, store, and revoke digital certificates
    • PKI is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA)
      • the binding is established through the registration and issuance process
      • the PKI role that assures this binding is called the registration authority (RA): it ensures that the public key is bound to the individual to which it is assigned in a way that ensures non-repudiation
    • law for digital signature, e.g., ETO (Electronic Transaction Ordinance) in Hong Kong
      • PKI is always about digital signature
  • scenario

Public Key Certificate

Problems in public key cryptography

  • private key
    • users have to keep in secret
  • public key
    • make sure everyone can get a correct copy (store in a public key certificate)
  • scenario

CA’s public key

  • root certificate
    • CA’s public key is stored in a special PKC
    • CA self signed
    • assumption: root certificates are correct
  • intermediate certificate
    • purpose -> purely security
      • everything in the whole trust model relies on root CA private key, so we use lock-it-out to protect it
      • someone in the middle can balance the lock-it-out and usage
      • use intermediate certificate, we can lock the root certificate and only use it a few times
      • if the root cert does not work, the whole system would be crash. but if the intermediate cert does not work, we can revoke it and establish a new one
    • process
  • certificates can be distributed without any protection
    • no confidentiality needed
    • the certificate contains a digital signature which provides authenticity and integrity
  • a large population of users can participate in a PKI, every user only need to know CA’s public key
  • usually more secure than a normal user key
    • normal user -> 1024 bits
    • CA -> 2048 bits
  • CA is responsible for subject authentication
    • verfication of user id before issuing the PKC

Validity period

  • PKC format
  • a certificate has a life time (just as keys)
    • a certificate contains start date/time and expiration date/time
    • expired certificate are only used to verify signature on a old document (e.g. for auditing purpose)
    • a new certificate should be issued to the subscriber when his/her old certificate is expired
    • in event of suspected key compromise, a new certificate should be issued, and the old certificate should be “revoked” prior to its expiry date
  • verify digital signature
    • verify the digital signature with signer’s public key in signer’s PKC
    • verify signer’s PKC using CA’s public key in the root cert
    • confirm the signer’s PKC is not yet expired

Features

  • to associate a public-key value to a particular person, device, or entity
  • used to facilitate distribution of public keys
    • user keeps his own private key
    • user keeps his own PKC
    • CA keeps all PKCs for all users
  • each PKC contains a public-key, and the certificate is signed by a “Certification Authority” or some “Intermediate Certification Authority”, which has confirmed the identity and other attributes of the holder of the corresponding private key
  • assumption: everyone knows how to verify the CA’s digital signature (i.e. everyone knows CA’s public key)

Certificate distribution

  • certificates are digitally signed
  • directory service
    • a data base of (valid and update) certificates
    • ISO standard: X.500
    • proprietary directory service such as Microsoft Exchange, Lotus Notes, Novell NDS
    • internet Lightweight Directory Access Protocol (LDAP)
  • certificates can be distributed through insecure channels such as email (S/MIME and MOSS) or WWW
    • protected by the digital signature of CA

Certificate revocation

  • reasons
    • detected or suspected key compromise
    • change of data (e.g. subject name)
    • change of relationship between subject and CA (e.g. employee quitting a job from an organization which uses the current CA)
  • who can revoke
    • the subject
    • the CA
    • an authorized third party
  • CRL (Certificate Revocation List)
    • a time-stamped list of revoked certs, digitally signed by the CA, available to all users
    • each revoked cert is identified by a certificate serial number
    • users of public key certificates should checks a “suitably-recent” CRL
      • problem: what is “suitably-recent”?
    • CRL will not contain certificates that are expired
    • CRLs are distributed regularly, e.g. hourly, daily, etc.
    • CRLs are digitally signed, thus can be sent via unprotected channels

Procedures

  • digital signature
    • verify the digital signature with signer’s public key in signer’s PKC
    • verify signer’s PKC using CA’s public key in the root cert
    • confirm the signer’s PKC is not yet expired
    • check the signer’s PKC is not yet revoked (using the CRL)
    • check the digital signature of the CRL
    • extract the signer’s public key
    • use signer’s public key to verify
  • encryption
    • verify the receiver’s public key in receiver’s PKC
    • verify the receiver’s PKC using CA’s public ket in the root cert
    • confirm the receiver’s PKC is not yet expired
    • check the receiver’s PKC is not yet revoked (using the CRL)
    • check the digital signature of the CRL
    • extract the receiver’s public key
    • use the receiver’s public key to encrypt the message

Certification path

  • the certificate chain is a list of certificates used to authenticate an entity
  • the chain begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain
  • the chain terminates with a root CA certificate: a certificate signed by the CA itself
  • the signatures of all certificates in the chain must be verified until the root CA certificate is reached
  • the number of levels is depend on the number of intermediate CAs

Key Management

Certificate request

  • scenario
    • Alice generates her own key pair
    • Alice brings the public key to the CA and some signed request showing that she knows the private key

Common system in key-pair generation

  • key-pair holder system
    • private key owner performs the generation
    • private key never goes to other places
    • best for non-repudiation requirement
  • central system
    • private key has to be transported to the owner
    • key-pair generated in central Registration Authority (RA) associated with CA, RA generates a key on behalf of an end-user
    • central site specialized in key generation, more resources, better algorithm, stronger control, etc.
    • related functions like key archival can provided

Certificate generation steps

  • CA is presented with the required certificate content information from the “applicant”
  • CA verifies the accuracy of the information
  • the certificate is created, and signed by a signing device using the CA’s private key
  • a copy of the certificate is sent to the subscriber
  • a copy of certificate may be submitted to some directory services
  • CA records the certificate generation process in the audit journal

RA

  • supporting role to CA: support subject authentication
  • RA does not issue certificates
  • key functions of RA
    • registering, de-registering, and changing attributes of subscribers
    • authenticating subscribers (most common and useful function)
    • authorizing requests for key-pair or certificate generation, or recovering backed up keys
    • accepting and authorizing requests for certificate suspension or revocation
    • physically delivering tokens to the authorized users, and recovering obsolete tokens from users

Private key protection

  • stored in a tamper-resistant hardware token, e.g. smart card, PCMCIA card
  • stored in encrypted date file, with authentication control by PIN, the encryption key is derived from the PIN
  • hardware token is more expensive and more secure

Backup

  • for digital signature, private key should not be backup (someone may sign the document on behalf of you)
    • if it is lost, apply a new one
  • for encryption, private key can be stored for a short time or periodically in some cases
    • if your private key is lost, new arrival documents should be decrypted
  • solutions
    • use two sets of key
    • for digital signature
      • the public key certificate together with the stored public key for digital signature verification should be properly archived
    • for encryption
      • decryption private key should be archived properly (false)
      • public key certificates are usually archived

Questions

Q: Why the definition of PKI is only about public keys?

A: The keys are always in pair. If you define the public key, the private key would also be defined.

Q: Do you need a law for encryption?

A: No, it just for confidentiality. Although encrpytion is important, it is not legally important. More importantly, digital signature is liable.