20-763 ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 7 Digital Certificates

20-763 ELECTRONIC PAYMENT SYSTEMS

FALL 2001

COPYRIGHT © 2001 MICHAEL I. SHAMOS

Electronic Payment Systems20-763

Lecture 7Digital Certificates


FALL 2001


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


FALL 2001


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


FALL 2001


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


FALL 2001


VISA 768-bit Public Key


FALL 2001


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


FALL 2001


Certification Chains

SOURCE: FORD & BAUM,SECURE ELECTRON IC

COMMERCE

X.500 Name Directorysimilar to domain naming

Children have uniquerelative names


FALL 2001


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.


FALL 2001


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


FALL 2001


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)


FALL 2001


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


FALL 2001


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)


FALL 2001


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”


FALL 2001


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


FALL 2001


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


FALL 2001


Corporate PKI Components

SOURCE: INFOSEC ENGINEERING


FALL 2001


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


FALL 2001


Certificate Revocation List

• Online list of revoked certificates• View Verisign CRL• Verisign CRL usage agreement


FALL 2001


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


FALL 2001


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


FALL 2001


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 }


FALL 2001


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


FALL 2001


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


FALL 2001


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


FALL 2001


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


FALL 2001


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


FALL 2001


QA&

Documents

20-763 ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 7 Digital Certificates