Digital Signatures A Brief Overview by Tim Sigmon November, 2000
Digital Signatures • Legal concept of “signature” is very broad • any mark made with the intention of authenticating the marked document • Digital signatures are one of many types of electronicsignatures • 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) • “digital signature” means the result of using specific cryptographic processes • Digital signatures operate within a framework of hardware, software, policies, people, and processes called a Public Key Infrastructure (PKI) • Note: PKI also supports other security requirements; in particular, confidentiality, both during transmission (e.g., SSL) and for storage
Public Key Cryptography • First, “secret key” or symmetric cryptography • same key used for encryption and decryption • orders of magnitude faster than public key cryptography • Public key technology solves the key exchange problem (no shared secrets!) • Public key and private key that are mathematically linked • Private key not deducible from public key • Confidentiality: one key encrypts, other decrypts • Digital signature: one key signs, other validates
Digital Signature example
Signed Email example • (show example of sending/receiving digitally signed email using Netscape Messenger) • (uses S/MIME)
Problem: relying party needs to verify a digital signature • 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 • 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. • But, what about strangers? what about integrity of the public key?
Public Key (or Digital) Certificates • Purpose: validate both the integrity of a public key and the identity of the owner • How: bind identifying attributes to a public key (and therefore to the holder of the corresponding private key) • Binding is done by a trusted third party, a Certification Authority, who digitally signs the certificate • It is this third party's credibility that provides "trust"
X.509 v3 Certificates • Subject’s/owner’s identifying info (e.g., name) • Subject’s/owner’s public key • Validity dates (not before, not after) • Serial number • Level of assurance • Certification Authority’s name, i.e., the issuer • Extensions • Entire certificate is digitally signed by the CA
Example Certs • (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 • 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) • distribution via directories is the ultimate solution • however, many important applications and uses of digital signatures can be implemented without the implementation or use of sophisticated directories
Example: verify Bob’s signature on a signed doc CA1Bob cert containing Bob’s PK (signed by CA1 ) CA2CA1 cert containing CA1’s PK (signed by CA2 ) CA3CA2 cert containing CA2’s PK (signed by CA3 ) . . . where does this end? CANCAN 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 Certification Paths • To validate a cert containing the signer’s PK, relying party needs an assured copy of the issuing CA’s PK. • In general, a chain of multiple certificates that ends at a trusted root is needed
Trust Domains • 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) • Very Important: Root certificates are not integrity-protected since they are self-signed • Expansion of relying party’s trust domain • single top-down hierarchy (yikes!) • multiple hierarchies (Netscape/Microsoft disservice) • cross certifications (e.g., bridge certification architectures)
Other Important Issues • Certificate profiles • use of extensions • identity vs. attribute certs • Certificate revocation • CRL (certificate revocation lists) • OCSP (online certificate status protocal) • Protection and storage of private keys • passwords or passphrases • biometrics • hardware tokens for mobility, e.g., smartcards • Key escrow for encryption keys but not signing keys
Where are we now? • Technologies are still evolving but are very usable • Policies and legal standing exist but still developing (e.g., need case law) • Code of Virginia, Federal law • Uniform Electronic Transctions Act • Browsers/email already contain a lot of capability • Particular uses widely taking place, e.g., SSL • Some entities making more use, e.g., DGIF, MIT • Federal government taking a leadership role • Many deployment projects are underway in both the public and private sectors
DS efforts in Virginia • Digital Signature Initiative (COTS workgroup) formed to pursue pilot deployments • Pilot project sponsors • VIPNet, DIT, DGIF • DMV, DOT, DGS, DCR, VDOT, VEC • Counties of Chesterfield, Fairfax, Wise • Cities of Norfolk, Charlottesville • UVa led development of a bridge certification architecture (modeled after federal bridge) • http://www.sotech.state.va.us/cots • Virginia’s Council on Technology Services
