20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Electronic Payment Systems20-763
Lecture 7Digital Certificates
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Digital Certificate
• A digital identity document binding a public-private key pair to a specific person or organization
• Verifying a digital signature only proves that the signer had the private key corresponding to the public key used to decrypt the signature
• This does not prove that the public-private key pair belonged to the claimed individual
• We need an independent third party to verify the person’s identity (through non-electronic means) and issue a digital certificate
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
ISO X.500 Directory Standard
RDN: RELATIVE DISTINGUISHED NAME
O: ORGANIZATION
C: ISO COUNTRY CODE
CN: COMMON NAME
EACH RDN MAY HAVE ATTRIBUTES
STANDARD FOR HIERARCHICALDIRECTORIES
SOURCE: XCERT.COM
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
X.509 Version 2 Certificate
SOURCE: FORD & BAUM,SECURE ELECTRON IC COMMERCE
VERSION # OF X.509
UNIQUE # ASSIGNED BY CA
EXAMPLES: MD5RSA,sha1RSA
USUALLY A DOMAIN NAME
EXAMPLES: RSA
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
VISA 768-bit Public Key
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Digital Certificate Verification
• Is the CA trusted?– If not, follow the certificate chain
• Is the certificate genuine?– Verify the integrity through the CA’s digital signature– Look up the CA’s public key; use it to decrypt the signature– Compute the certificate’s hash; compare with decrypted sig
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Certification Chains
SOURCE: FORD & BAUM,SECURE ELECTRON IC
COMMERCE
X.500 Name Directorysimilar to domain naming
Children have uniquerelative names
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Digital Certificate Verification
• Possession of a digital certificate proves nothing• Why? Digital certificates are digital. Copies are
identical to the original• Certificates are sent frequently over the Internet.
Anyone can eavesdrop• Question: is the person presenting the certificate the
same person listed as the subject?– Issue a challenge (e.g. nonce) to the holder to encrypt a
random string using his private key– If the encrypted nonce decrypts correctly to the challenge,
then holder has the private key paired with the public key listed in the certificate.
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Authentication by Digital Certificate
• Possession of a digital certificate means nothing• The certificate holder must be challenged• If you’re Shamos, then you must know his private key• So, encrypt “701837454127186522” using it• Holder sends back “62663952975631”• If that number decrypted with Shamos’s public key
gives the original number, then the holder knows Shamos’s private key
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Certification Paths
• Alice has a certificate issued by authority D• To verify Alice’s certificate, Bob needs the public key
of authority D (to decrypt D’s signature on the certificate)
• How does Bob get it so he is sure it is really the public key of D? This is another verification problem.
• Solution: Alice sends Bob a certification path, a sequence of certificates leading from her authority D to Bob. The public key of D is in D’s certificate
• (D’s certificate is not enough for verification since Bob may not know D’s certification authority G)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Certification Paths
ALICEBOB
CERTIFICATEISSUED BY D
D<<A>>
CERTIFICATEISSUED BY F
F<<B>>
ALICE WILL TRUST ANYPARTY TRUSTED BY D
CERTIFICATION PATH: D<<G>>, G<<J>>, J<<H>>, H<<F>>, F<<B>>
CERTIFICATIONAUTHORITY
END USER
=
=
“REVERSE”CERTIFICATE
D TRUSTS G G TRUSTS J J TRUSTS H H TRUSTS F F TRUSTS B
ALICE NOW HAS (AND TRUSTS) BOB’S CERTIFICATE
SOURCE: SILVAAND STANTON
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Authentication
• B sends a certificate to A (A now knows B’s public key)• A constructs an authentication token
M = ( TA, RA , IB, d )
• A sends B the message ( B A, SKA { M } )
• B obtains A’s public key PKA, trusted because of B A
• B recovers M by using PKA to decrypt SKA { M }
TIMESTAMP NONCE TO PREVENTREPLAY ATTACK
ID OF B DATA TO BE SIGNED
A’S CERTIFICATION PATHINCLUDING A’S CERTIFICATE
AUTHENTICATION TOKEN ENCRYPTED WITHA’S PRIVATE KEY (ONLY A CAN DO THIS)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Authentication
• B checks IB to make sure he is the intended recipient
• B verifies that the timestamp Ta is current• B verifies that RA has not been used before (no replay)• B knows A’s certificate really belongs to A since only A
could have encrypted M with SKA
• B can send A an authentication token so A will know that B is authentic
AT THIS POINT, B HAS AUTHENTICATED A.THIS IS “ONE-WAY AUTHENTICATION”
IF A AND B AUTHENTICATE EACH OTHER,WE HAVE “TWO-WAY AUTHENTICATION”
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Public Key Infrastructure (PKI)
• Digital certificates alone are not enough to establish security– Need control over certificate issuance and management
• Certification authorities issue certificates• Who verifies the identify of certification authorities?• Naming of entities• Certification Practice Statement• Certificate Revocation List• The metafunctions of certificate issuance form the
Public Key Infrastructure
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Functions of a Public Key Infrastructure (PKI)
• Generate public/private key pairs
• Identify and authenticate key subscribers
• Bind public keys to subscriber by digital certificate
• Issue, maintain, administer, revoke, suspend, reinstate, and renew digital certificates
• Create and manage a public key repository
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Corporate PKI Components
SOURCE: INFOSEC ENGINEERING
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Certification Practice Statement
• Satement by a CA of the policies and procedures it uses to issue certificates
• CA private keys are on hardware cryptomodules• View Verisign Certification Practice Statement• INFN (Istituto Nazionale di Fisica Nucleare) CPS
LITRONIC 440CIPHERACCELERATOR
IBM S/390 SECURECRYPTOGRAPHIC MODULE
CHRYSALIS LUNA CA3TRUSTED ROOT KEY SYSTEM
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Certificate Revocation List
• Online list of revoked certificates• View Verisign CRL• Verisign CRL usage agreement
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Format of Digital Certificates
• Certificates contain many fields, must be read by computers all over the world
• X.509 certificates are in a standard format described in ASN.1
• Data is encoded by the Distinguished Encoding Rules (DER), similar to BER
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
ASN.1 Definition of X.509 Certificate
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,--
If present, version shall be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,--
If present, version shall be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL --
If present, version shall be v3 }
“TO BE SIGNED” CERTIFICATE= INTERMEDIATE (NON-ROOT)CERTIFICATE
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
ASN.1 Definition of X.509 CertificateVersion ::= INTEGER { v1(0), v2(1), v3(2) }CertificateSerialNumber ::= INTEGERAlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,parameters ANY DEFINED BY algorithm OPTIONAL}
Name ::= CHOICE { RDNSequence }RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,value AttributeValue }
AttributeType ::= OBJECT IDENTIFIERAttributeValue ::= ANY DEFINED BY AttributeTypeValidity ::= SEQUENCE {
notBefore Time, notAfter Time }Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime }UniqueIdentifier ::= BIT STRINGSubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF ExtensionExtension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,critical BOOLEAN DEFAULT FALSE,extnValue OCTET STRING }
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Basic Encoding Rules
• Content field may be primitive (value) or structured (content has subcomponents)
Person ::= SET { name IA5String, age INTEGER female BOOLEAN }.BER encoding (in hex) of the instance {“Maggie”,4,TRUE}:
SET M a g g i e 4 TRUE31 0E 16 06 4D 41 E7 E7 69 65 02 01 04 01 01 FF
LENGTH OFCONTENT (BYTES)
LENGTH OF“Maggie”
DATACODE FORIA5STRING
CODE FORI NTEGER
LENGTH OFINTEGER
CODE FORBOOLEAN
LENGTH OFBOOLEAN
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Signed Document Markup Language (SDML)
• Designed by Financial Services Technology Consortium (FSTC) for Electronic Check Project
• Tag individual text items in a document
• Group items for individual or group signing
• Parts can be added/deleted without invalidating previous signatures
• Can sign, co-sign, endorse, co-endorse, witness
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
SDML Example<sdml-doc docname="doc87" type="sample">
<action><blkname>act1<crit>true<vers>1.0<function>sample<reason>process</action>
<attachment><blkname>att0123<adata encoding="text">This is a sample attachment</adata></attachment>
<signature><blkname>sig7<crit>true<vers>1.0<sigdata><blockref>act1<hash alg="sha">278B7F348EECE3822A48C4D197FD5B920001C2E8<blockref>att0123<hash alg="sha">BC59D2FE5566F506910C5020B628E4136E1C6B39<nonce>9D9BC5AA75<sigref>cert-111111111-00000001<algorithm>sha/dsa<location>us</sigdata><sig>2489E1E376F5CD823274010B0A6028EA3F2763F2:290B95F8F02CF6616B9C3A03DF0B50295A162295</signature>
TEXT OF DOCUMENTGOES HERE
DIGITAL SIGNATUREBLOCK
ATTACHMENTBLOCK
ACTION BLOCK
HEADER
DIGITAL SIGNATURE
MESSAGE DIGEST OFACTION BLOCK
MESSAGE DIGEST OFATTACHMENT BLOCK
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
SDML Example
<cert><blkname>cert-111111111-00000001<crit>true<vers>1.0<certtype>x509v1<certissuer>/C=US/ST=NY/O=FSTC/OU=NYCA/<certserial>1<certdata>308201F0308201B0020101300906072A8648CE380403303D310B3009060355040613025553310B3009060355040813024D44310E300C060355040A130542414E4B413111300F060355040B13...910CE325DB7E</cert>
<cert> <blkname>cert-111111111 <crit>true <vers>1.0 <certtype>x509v1<certissuer>/C=US/O=FSTC/OU=FSTC CA/<certserial>1<certdata> 308201DF3082019F020101300906072A8648CE380403303F310B300906035504012314BDBEB300906072A8648CE380403032F00302C021456A0A84E997EB0772DD592753338E9D65B0795750214269AAE91801D9E80B8004A89225E27915044EA40</cert>
</sdml-doc>
CERTIFICATE OF SIGNER
CERTIFICATE OF ISSUEROF SIGNER’S PUBLIC KEY
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Cryptographic Notation
{ A, B, C, D } means
strings A, B, C and D concatenated together
SKSENDER( A ) means
string A encrypted with SENDER’s secret key
PKBANK( B ) means
string B encrypted with BANK’s public key
H(A) means
one-way hash of string A