1. Digital Signatures A Brief Overview by Tim Sigmon April, 2001

2. GO DUKE!

3. 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

4. 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

5. 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

6. Digital Signature example

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

8. 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?

9. 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 this third party's credibility that provides "trust"

10. X.509 v3 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

11. 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)

12. Distribution of Certificates u since certs carry public info and are integrity- protected, they can be distributed and shared by any 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

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

14. Trust Domains u A trust domain is defined by the root (or self- signed) 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)

15. CA 1  Tim CA 1  CA 1 Simple Hierarchical Trust Relying Party Signed doc and CA 1  Tim e.g., email or web form application Trust Domain 1) path construction CA 1  Tim CA 1  CA 1 2) path validation 3) signature verification Trust Domain CA 1  CA 1

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

17. Trust Domain Expansion u Hierarchical CA’s CA 1  CA 1 CA 1  CA 2 CA 1  CA 3 CA 2  CA 4 CA 2  CA 5 CA 5  CA 6 CA 5  EE 1 Note: if CA 1 ’s private key is compromised, the entire hierarchy collapses CA A  CA A CA Z  CA Z CA C  CA C CA B  CA B... u Multiple root certificates –disservice of Microsoft and Netscape

18. 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 CA A  CA A... CA B  CA B... CA A  CA B CA B  CA A CA B  EE 1 –N 2 problem if N CA’s want to cross-certify with each other

19. 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 CA bridge  CA 5 CA 1  CA bridge u Certificate path processing (construction & validation) CA 5  EE 2 CA 1  CA 1  trusted

20. CA 1  Tim CA 2  CA 2 Digital Signature Demo in a bridge cross-certification environment Relying Party Signed form data and CA 1  Tim e.g., web form application Trust Domain 1) path construction CA 1  Tim CA 2  CA 2 BCA  CA 1 CA 2  BCA BCA  CA 2 CA 1  BCA CA 1  CA 1 Trust Domain CA 1  CA 1

21. CA 1  Tim CA 2  CA 2 Digital Signature Demo in a bridge cross-certification environment Relying Party Signed form data and CA 1  Tim e.g., web form application Trust Domain 1) path construction CA 1  Tim CA 2  CA 2 2) path validation 3) signature verification BCA  CA 1 CA 2  BCA BCA  CA 2 CA 1  BCA CA 2  BCA BCA  CA 1 Trust Domain CA 1  CA 1

22. 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

23. 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

24. 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

25. 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