Transcript Public Key Infrastructure

Digital Signatures
A Brief Overview
by
Tim Sigmon
September, 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
electronic signatures
 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 integrityprotected, 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

Certification Paths
 To
validate a cert containing the signer’s PK, relying
party needs an assured copy of the issuing CA’s PK.
 Example:
CA1Tim
CA2CA1
CA3CA2
.
.
.
CANCAN
 In
cert containing Tim’s PK (signed by CA1 )
cert containing CA1’s PK (signed by CA2 )
cert containing CA2’s PK (signed by CA3 )
where does this end?
cert containing CAN’s PK (signed by CAN )
Note: this is a self-signed or root certificate
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 selfsigned) 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