Digital Signatures A Brief Overview by Tim Sigmon

Digital Signatures A Brief Overview by Tim Sigmon April, 2001

GO DUKE!

Digital Signatures u Legal concept of “signature” is very broad – any mark made with the intention of authenticating the marked document u Digital signatures are one of many types of electronic signatures u Example electronic signatures – – – loginid/password, PIN, card/PIN digitized images of paper signatures digitally captured signatures (UPS, Sears, etc. ) typed notations, e. g. , “/s/ John Smith” email headers

Digital Signatures (cont’d) u “digital signature” means the result of using specific cryptographic processes u Digital signatures operate within a framework of hardware, software, policies, people, and processes called a Public Key Infrastructure (PKI) u Note: PKI also supports other security requirements; in particular, confidentiality, both during transmission (e. g. , SSL) and for storage

Public Key Cryptography u First, “secret key” or symmetric cryptography – same key used for encryption and decryption – orders of magnitude faster than public key cryptography – problem: how to (securely) share the key u Public key technology solves the key exchange problem (no shared secrets!) u Public key and private key that are mathematically linked u Private key not deducible from public key u Confidentiality: one key encrypts, other decrypts u Digital signature: one key signs, other validates

Digital Signature example

Signed Email example u (show example of sending/receiving digitally signed email using Netscape Messenger) u (uses S/MIME)

Problem: relying party needs to verify a digital signature u To do this, must have an assured copy of the signer’s public key – signer’s identity must be assured – integrity of public key must be assured u Potential options for obtaining public keys – signer personally gives their public key to relying party – relying party obtains the desired public key by other “out of band” means that they trust, e. g. , transitive relationships, signing parties, etc. u But, what about strangers? what about integrity of the public key?

Public Key (or Digital) Certificates u Purpose: validate both the integrity of a public key and the identity of the owner u How: bind identifying attributes to a public key (and therefore to the holder of the corresponding private key) u Binding is done by a trusted third party, a Certification Authority, who digitally signs the certificate u It is third party's credibility that provides "trust"

X. 509 v 3 Certificates u Subject’s/owner’s identifying info (e. g. , name) u Subject’s/owner’s public key u Validity dates (not before, not after) u Serial number u Level of assurance u Certification Authority’s name, i. e. , the issuer u Extensions u Entire certificate is digitally signed by the CA

Example Certs u (this is where I show and describe the contents of the actual certificates that were used to verify a digitally signed email message)

Distribution of Certificates u since certs carry public info and are integrityprotected, they can be distributed and shared by and all means, e. g. , – – distribute via floppies or other removable media publish on web sites distribute via email (e. g. , S/MIME) directory lookups (e. g. , LDAP, X. 500) u distribution via directories is the ultimate solution u however, many important applications and uses of digital signatures can be implemented without the implementation or use of sophisticated directories

Certification Paths u To validate a cert containing the signer’s PK, relying party needs an assured copy of the issuing CA’s PK. u Example: verify Bob’s signature on a signed doc CA 1 Bob cert containing Bob’s PK (signed by CA 1 ) CA 2 CA 1 CA 3 CA 2 cert containing CA 1’s PK (signed by CA 2 ) . . . CAN u In cert containing CA 2’s PK (signed by CA 3 ) where does this end? cert containing CAN’s PK (signed by CAN ) Note: this is a self-signed or root certificate that is trusted for reasons outside of the PKI general, a chain of multiple certificates that ends at a trusted root is needed

Trust Domains u. A trust domain is defined by the root (or selfsigned) certificate(s) that the relying party knows and trusts (for reasons outside of the PKI) u Very Important: Root certificates are not integrity-protected since they are self-signed u Expansion of relying party’s trust domain – single top-down hierarchy (yikes!) – multiple hierarchies (Netscape/Microsoft disservice) – cross certifications (e. g. , bridge certification architectures)

Simple Hierarchical Trust Relying Party e. g. , email or web form application 1) path construction CA 1 Tim CA 1 2) path validation 3) signature verification im CA 1 Tim Trust Domain CA 1 ne Sig nd oc a T A 1 C dd Trust Domain CA 1

Trust Domain Expansion u Hierarchical CA’s (Governor) CA 1 (So. ED) CA 1 CA 2 CA 4 CA 1 CA(DGIF) 3 (UVa) CA 2 CA 5 CA 6(Darden) CA 5 EE 1(tms) Note: relying party follows issuer chain to verify cert of EE 1 CA 5 EE 1 CA 2 CA 5 CA 1 CA 2 CA 1 trusted

Trust Domain Expansion u Hierarchical CA’s CA 1 CA 2 CA 4 CA 2 CA 5 CA 6 u Multiple CA 1 CA 3 Note: if CA 1’s private key is compromised, the entire hierarchy collapses CA 5 EE 1 root certificates – disservice of Microsoft and Netscape CAA CAB CAC . . . CAZ . . .

Trust Domain Expansion (cont’d) u Cross certification – two CA’s issue certificates to each other (a cross-certificate pair), i. e. , sign each other’s public keys CAA CAB CAA . . . CAB CAA CAB . . . CAB EE 1 – N 2 problem if N CA’s want to cross-certify with each other

Bridge Certification Architecture u addresses the N 2 problem by providing a central cross-certification hub for a group of CA’s who wish to interoperate u each CA does one cross-certification with the bridge CA u Certificate path processing (construction & validation) CA 5 EE 2 CAbridge CA 5 CA 1 CAbridge CA 1 trusted

BCA CA 1 BCA Digital Signature Demo in a bridge cross-certification environment BCA CA 2 BCA Relying Party e. g. , web form application 1) path construction CA 1 Tim CA 1 im d. C CA 1 Tim Trust Domain CA 1 rm d fo ne an data T A 1 CA 2 Sig Trust Domain CA 2

BCA CA 1 BCA Digital Signature Demo in a bridge cross-certification environment BCA CA 2 BCA Relying Party e. g. , web form application im d. C CA 1 Tim Trust Domain CA 1 Sig rm d fo ne an data T A 1 1) path construction CA 1 Tim BCA CA 1 CA 2 BCA CA 2 2) path validation 3) signature verification Trust Domain CA 2

Other Important Issues u Protection and storage of private keys – passwords or passphrases – biometrics – hardware tokens for mobility, e. g. , smartcards u Binding human to the act of signing – did they see the document? – did they intend to sign? that particular document? – is the signing computer secure? u Key escrow for encryption keys but not signing keys

Other Important Issues (cont’d) u Certificate revocation – CRL (certificate revocation lists) – OCSP (online certificate status protocol) u Certificate profiles – use of extensions – identity vs. attribute certs

Where are we now? u Technologies are still evolving but are very usable u Policies and legal standing exist but still developing (e. g. , need case law) – Code of Virginia, Federal law – Uniform Electronic Transactions Act u Browsers/email already contain a lot of capability u Particular uses widely taking place, e. g. , SSL u Some entities making more use, e. g. , DGIF, MIT u Federal government taking a leadership role u Many deployment projects are underway in both the public and private sectors

DS efforts in Virginia u Digital Signature Initiative (a COTS workgroup) pursued pilot deployments ending in Sept. , 2000 u DSI final report and recommendations: http: //www. sotech. state. va. us/cots u Recommissioned Digital Signature Implementation (DSI) team now pursuing the implementation of the recommendations u Looking for a number of early adopters