Secure Electronic Commerce

1
Secure Electronic Commerce ECT 582 Spring 2006
Session Number 3

• Session Date April 11, 2006
• Session Objectives
• Administrative Items
• Student Survey Results
• Session Topics
• Session Topics
• Cryptography (continued)
• Digital Certificates

2
Public Key Certificates

• Public-key certificate
• To achieve the association of a public-key value
  to a particular person, device, or other entity
• Signed by a Certification Authority
• Subject must trust the CA
• CA need to confirm the identity or other
  attributes of the holder of the corresponding
  private key
• One assumption
• everyone knows how to verify the CAs digital
  signature (i.e., everyone knows CAs public key)

An interesting link
3
Public Key Certificates (continued)

• Used to facilitate distribution of public keys
• Public key certificate contains a public-key
• Each user in secure communication system must
  contains (at least) one certificate from a CA
• Each certificate contains a public-key value and
  information that uniquely identifies the
  certificates subject (a.k.a. a subscriber of
  the CA)

4
Characteristics of Certificate

• Certificates can be distributed without needing
  to be protected
• No confidentiality needed
• The certificate is self-protecting the
  certificate contains a digital signature which
  provides authentication and integrity
• Certificate is useful only if public-key user
  trusts the CA
• Certificate user inherit trust from CA
• Scalability
• A large population of users can participate in
  the public key certification system
• All only need to know CAs public key
• The public key (as thus private key) of the CA is
  extremely important

5
Characteristics of Certificate
6
Characteristics of Certificate
7
Certification Path

• There are normally more than one Certification
  Authorities
• Each CA has its subscribers
• How to make a subscriber of a CA1 able to be a
  relying party of CA2?
• Solution 1 let a person knows every CAs public
  key (extremely hard to maintain, if not
  impossible)
• Solution 2 let a person able to find CA2s
  public key from another CA, such as CA1 (more
  feasible)
• Cross Certificate the public key of CA2 signed
  by CA1
• A model where more than two CAs are involved
• Hierarchical trust model
• root CA start point of the certificate chain,
  all parties trust the root CA
• A certificate chain or certification path is a
  chain from the root CA to another CA or subscriber

8
Validity Periods and Revocation

• 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)
• In event of suspected key compromise, a new
  certificate should be issued, and the old
  certificate should be revoked prior to its
  expiry date
• A new certificate should be issued to the
  subscriber when his/her old certificate is
  expired
• Secure revocation schemes are needed for a sound
  public key certification system

9
Legal Relationship (CA subscriber)

• Model 1 -- Closed Community
• all part of a legal entity, e.g., ATMs of a bank,
  and the EDP department of the bank
• Third-party CA is not needed.
• Model 2 -- Open Community
• CA is an independent legal entity, e.g. Internet
  service provider, or Post Office as CA. Also
  known as third-party CA.
• Some in-between cases
• commercial organization and employees
• school and students
• club and members
• For third-party CA and its subscribers, there are
  certain obligations toward each other
• the CA acts as role of notary who may acknowledge
  a document

10
Public-Private Key-pair Management

• Key-pair generation
• generation of private and public key
• archiving/back-up of private key
• sending of public key for certification
• Where a key pair is generated?
• Key-pair holder system
• private key owner performs the generation
• In hardware token or software module
• private key never goes to other places
• best for non-repudiation requirement
• Public key value has to be transported to CA
  securely, for example, in a self-signed
  certificate
• Central system
• key-pair generated in central site associated
  with CA
• private key has to be transported to the owner
  through a secure channel

11
Public-Private Key-pair Management

• Private-key protection
• Methods
• stored in a tamper-resistant hardware token
• e.g. smart card, PCMCIA card
• stored in encrypted data file
• The data file is protected by a password
• Ex. The data file is encrypted by symmetric key
  that derived from a password
• stored in a credentials server
• Key access the server authenticates user
• Pros and cons
• hardware token is more expensive and more secure
• software solution is vulnerable to
• Password-guessing attack
• Attacks on the server

12
Key Management Requirements

• Digital signature key-pairs
• No party other than the holder of private key
  should be able to access the private key
• In ANSI X9.57, it requires the private key to
  NEVER leave the device it is created, used,
  destroyed
• No backup or archiving is needed for a digital
  signature private key
• Digital signature private key is destroyed
  securely at the end of its life time
• Digital signature public key (or its certificate)
  should be properly archived

13
Key Management Requirements (continued)

• Encryption key-pairs
• Encryption private key should be properly backed
  up, archived, and escrowed
• A encryption private key does not need to be
  securely destroyed at the end of its life time
• Conflictions from above
• Digital signature and encryption should use
  separate key pairs
• Keys for digital signature and encryption have
  different key management requirements
• How many key pairs does a user need?

14
Key Management Requirements (continued)

• Other reasons for separate key pairs
• Encryption software is generally subjected to
  more strict export controls than those used in
  digital signature
• They may have different crypto-periods
• some digital signature schemes (e.g. DSA) cannot
  support encryption
• Requirement of mandated key escrow system
• Encryption private key have to be made available
  to the government (e.g. US)

15
Certificate Issuance

• Registration Authorities
• RA manages the interactions between a CA and its
  subscribers
• Enrolling, de-enrolling, and approving or
  rejecting changes to the certificate attributes
• Validating cert application
• Authorizing request for
• Key-pair
• Certificate generation
• Recovery of backed-up keys
• Accepting and authorizing request for cert
  suspension or revocation
• Physically distributing personal tokens and
  recovering obsolete tokens from authorized people

16
Certificate Issuance

• Certificate generation steps
• CA is presented with the requisite certificate
  content info
• CA verifies the accuracy of the info (in
  accordance with applicable policies and
  standards)
• The certificate is created, and signed by a
  signing device using CAs private key
• A copy of the certificate is forwarded to the
  subscriber. Optionally a confirmation of
  acceptance of the certificate is given by the
  subscriber
• A copy of certificate may be submitted to some
  directory services
• Optionally, a copy of certificate is archived by
  the CA
• CA records the certificate generation process in
  audit journal

17
Certificate Distribution Methods

• Certificate accompanying digital signature
• One drawback is the waste of bandwidth (consider
  A sends 5 messages to B, and As certificate will
  be submitted 5 times)
• If certification path is unknown, this method
  cannot be used properly
• Distribution via Directory Services
• Directory is a data base of (valid and update)
  certificates
• One common technology used
• ISO X.500 standard (originally aimed at, say,
  looking up of email address from a persons
  name), evolved to X.509, specially for public-key
  certificates

18
Certificate Distribution Methods (continued)

• Proprietary directory service such as Microsoft
  Active Directory, Lotus Notes, Novell NDS
• Internet Lightweight Directory Access Protocol
  (LDAP) an X.500 compatible access protocol that
  is more implementer-friendly
• Adopted by MS Outlook Express and VeriSign

19
X.509 Certificate Format

• A most popular certificate format
• Certificate fields
• Version 1, 2, 3. (version 4 in 2000)
• Serial number assigned by the issuing CA
• Signature signing algorithm used by CA
• Issuer X.500 name of issuing CA
• Validity start/expiry date and time
• Subject X.500 name of the holder of the private
  key
• Subject public-key information value and
  algorithm of the public key being certified
• Issuer (and subject) unique identifier optional
  bit string to make the issuer (subject) name
  unambiguous

20
The Structure of Certificate
21
X.500 Names

• X.500 names is a way to specify a subject in
  X.500 directories, which uses a public key
  certificate
• A subject can be a person, organization, or
  device.
• X.500 name is a distinguished name (DN)
• It is a global unambiguous name for a subject
• X.500 names are created from Directory
  Information Tree (DIT)
• DIT is logical organization of entries in a X.500
  directory
• Each non-root vertex is a directory entry and has
  a DN
• DN is the path name of DIT
• e.g. DNCUS, ODePaul University, CNJohn Smith

22
X.500 Names (continued)

• Is DN really unique?
• DNCUS,ODePaul University, CNJohn Smith
• Problem what happens if John Smith leaves the
  company, and another John Smith joins DePaul one
  year later and was assigned the same DN?
• In Version 2 of X.509 Certificate, issuer/subject
  unique identifier is used to solve this problem
• issuer/subject unique identifier will be assigned
  a different value whenever a DN is reused
• Problem difficult to manage
• A better way is to use some unambiguous
  identifier in a part of RDN
• Ex.
• DNCUS, ODePaul University, CNJohn Smith,
  Emailjsmith_at_depaul.edu
• DNCUS, ODePaul University, CNJohn Smith,
  Employee Number0012345
• This also solves the problem of two john smith in
  an organization

23
Object Registration in X.509

• Object registration is a way to register objects
  that are used in certificate
• Objects can be public-key algorithms,
  organizations,
• Standard ISO/IEC 9834-1
• Object identifier
• Object identifier is a unique sequence of numbers
  that is assigned to a registered object
• e.g. 2.16.840.1.15678.1.66, or represented as
  joint-iso-itu-t (2) country (16) us (840)
  organization (1) sharons (15678) algorithms (1)
  sharons-super-algorithm (66)
• Object identifier for digital signature RSA
  with SHA-1 1.2.840.113549.1.1.5 iso (1)
  member-body (2) us (840) rsadsi (113549) pkcs (1)
  pkcs-1 (1) sha-1WithRASEncryption (5)

24
Object Registration in X.509 (continued)

• The object identifier works on the basis of a
  hierarchical structure of distinct
  value-assigning authorities
• ANSI assigns the value 113549 to RSA Data
  Security Inc.
• RSA Data Security Inc. has the right to assign
  component values at lower levels for its own
  purposes

25
X.509 Version 3 Certificate Format

• Improvement on V.1, V.2 for various reasons
• One subject can have several certificates for
  different public keys (for different purpose, at
  different time)
• A cert often needs to convey additional
  subject-identifying information beyond an X.500
  name
• Some applications need to identify users by
  application-specific name forms
• E.g. email address
• Cert users need to know the assurances and
  practices applied to issuance of each cert
• e.g. encrypting casual email, or authenticating
  high-value transactions
• Some CA only cross-certifies a subset of
  certificates issued by another CA

26
X.509 Version 3 Certificate Format (continued)

• X.509 v3 has additional extensions fields added
  to implement a general extension mechanism
• Each extension field contains
• a type which needs to be registered (i.e. assign
  an object identifier)
• a criticality indicator
• non-critical means the cert can be used by
  ignoring this extension, if the system cannot
  recognize it.
• critical means the system must recognize the
  extension if it wants to use the cert
• a value it can be a complex data structure,
  format and semantics depends on the type

27
Standard X.509 V3 Cert Extension

• Key and policy information
• Subject and Issuer attributes
• Certification path constraints
• Extensions related to CRLs (Certificate
  revocation List)

28
Naming in X.509 v3

• Subject and issuer can be identified not only by
  X.500 names but also more names of a variety of
  different forms.
• Name formats in X.509 v4
• Internet e-mail address
• Internet domain name
• X.400 email address
• X.500 directory name
• EDI party name
• Web Uniform Resource Identifier (includes URL)
• Internet IP address (for Internet connection
  end-points)
• Registered identifier (an object identifier)
• Other name (other name form that is registered)

29
Certification Path Constraints

• Certification Path Constraint is useful for CA1
  issues a cert for CA2s public key (cross
  certification case)
• Three types of constraints
• Basic constraint
• whether the subject is a CA or an end-entity
• If subject is CA, how long is the certification
  path length permitted
• e.g. only cross certify subscribers of CA2
• Name constraint
• which subset of subscribers of CA2 can be cross
  certified, by restricting the name of the
  subscribers
• Policy constraint
• more complicated, describing the policy mapping

30
Certificate Revocation

• Reasons for revocation
• Detected or suspected 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 revokes?
• the subject
• the CA
• an authorized third party
• e.g. the organization with an employee quitting
• Authentication of the source of revocation
  request is needed, probably via a local
  registration authority

31
Certificate Revocation List (CRLs)

• What is CRL?
• CRL is a time-stamped list of revoked
  certificates, 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
• CRL contains digital signatures, thus can be sent
  via unprotected channels
• Problem what is suitably-recent?
• CRLs are distributed regularly
• e.g. hourly, daily, biweekly, etc
• off-cycle CRL can be issued, however, missing
  of off-cycle CRL is hard to detect

32
Certificate Revocation List (CRLs) (continued)

• Methods to distribute CRL
• Pull method deposit CRL to directory
• Push method broadcast a message of the new CRL
• Push method more appropriate for critical
  situation like key compromise
• Need protected communication
• Attackers may be able to intercept and obliterate
  the CRL
• Both methods can be used together
• e.g. Defense Messaging System by DoD in
  Multi-level Information System Security
  Initiative (MISSI)
• Real-time revocation checking
• when a user wants to use a certificate, he/she
  checks the certificate directory for the most
  updated CRL
• This approach is costly, but most accurate

33

• Online status checking
• Online Certificate Status Protocol (OCSP)
• Format for request and response message to
  ascertain whether or not a certificate is revoked
• OCSP request message contains
• protocol version
• service request
• target certificate identifier
• optional extensions which may be processed by the
  OCSP Responder
• Responder must belong to one of the following
• the CA who issued the certificate in question
• a Trusted Responder whose public key is trusted
  by the requester
• a CA Designated Responder (Authorized Responder)
  who holds a specially marked certificate issued
  directly by the CA, indicating that the responder
  may issue OCSP responses for that CA

34

• OCSP response message contains
• version of the response syntax
• name of the responder
• responses for each of the certificates in a
  request
• optional extensions
• signature algorithm OID (object identifier)
• signature computed across hash of the response
• The response for each of the certificates in a
  request consists of
• target certificate identifier (same as in
  request)
• certificate status value (good, revoked, unknown)
• response validity interval
• optional extensions

35
Short-Lived Certificates

• CA issues a new short-lived certificate for the
  public key, with a lifetime of, say, 25 hours,
  every day throughout the valid time of the public
  key
• Suitable for limited resource systems
• e.g. mobile wireless systems
• Certificate revocation
• CA ceases issuing further short-lived certificate

36
Who bears the risk of key compromise?

• Who bears the risk of key compromise depends on
  the time the wrong verification is carried out.
• time b to c subscriber
• time c to d probably CA
• time d to e depends, either CA or the
  certificate user
• With periodic CRLs, it may be the best interests
  of the certificate user to wait until CRL 2 is
  issued
• With online status checking, the certificate user
  should know about the revocation during this
  period
• time after e the certificate user

a. Issue of CRL 1
b. Key Compromise
d. Revocation Time
e. Issue of CRL2
c. Revocation Request
Time
37
X.509 CRL format

• Version 1 or 2, v2 contains CRL entry extension
  and CRL extension
• Signature indicator of algorithm signing this
  CRL
• Issuer the creator of this CRL, most likely the
  CA
• This update date/time of issue of this CRL
• Next update date/time of issue of next CRL
• list of revoked certs
• user certificate cert serial number
• revocation date
• CRL entry extension additional info
• CRL extensions

38
Key-pair and Certificate Validity Periods

• Validity period of an un-revoked cert tells the
  users the following
• the public key is valid for use for its
  designated purpose
• the binding between public key and other info in
  the cert (esp. identification info) is
  trustworthy
• revocation notifications will be published by CA
• Relationship between cert validity period and
  periods for which the public-private key pair
  can be reliably used depends on the usage
• Encryption-related key pairs
• Digital Signature key pairs
• CA signature key pairs

39

• Encryption-related Key Pairs
• Public key should be used (for encryption) when
  the cert is valid
• the private key can be used for decryption long
  after the public key cert is expired
• Certificate validity
• Public key usage
• Private key usage

CRL, Check validation, Encryption
Decryption
40

• Digital Signature Key Pairs
• for Historic validation (checking a historic
  records signature, say, for non-repudiation
  services)
• need to ensure the signature is valid in the
  signing period
• should record the cert validity and all
  revocation status information like CRL as it
  existed at the time of signing
• cert validity should not extend beyond the period
  of use of private key
• Cert validity
• Cert usage
• Public key usage
• Private key usage

CRL (The first one after signing)
Check validation
Signing
41

• for Real-time validation (e.g. software
  publishers signature in an electronic document)
• need the cert to be valid at time of verification
  (more convenient)
• require the cert validity period to be longer
  than the private key
• e.g. private key is used for 1 year, the public
  key cert is valid for 2 years
• better security save as far as the private key
  is not compromised within the Private Key Usage
  Period
• Cert validity
• Public key usage
• Private key usage

CRL, Check validation
Signing
42

• CA Signature Key Pairs
• CA signatures would be used for
• Historic validation (e.g. non-repudiation)
• Real-time validation (e.g. in long certification
  path)
• Private Key Usage Period used for security
  reason as well
• Valid life time of a cert depends on
• its validity period
• validity of the CAs signature, which in turn
  needs validity of the CAs public key cert
• CA should ensure validity period of its public
  key (and the corresponding cert) extends over an
  intended validity period of any cert that the CA
  signs

43
Next Session Highlights

• Chapter 7 of Ford and Baum