Transcript Public Key Infrastructure

Digital Signatures
A Brief Overview
by
Tim Sigmon
October, 2001
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
– problem: how to (securely) share the key
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: verify Bob’s signature on a signed doc
CA1Bob
CA2CA1
CA3CA2
.
.
.
CANCAN

cert containing Bob’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 that is
trusted for reasons outside of the PKI
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 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)
Simple Hierarchical Trust
Relying Party
e.g., email or web form application
1) path construction
CA1Tim
CA1 CA1
2) path validation
3) signature verification
CA1 Tim
Trust Domain
CA1 CA1
Trust Domain
CA1 CA1
Trust Domain Expansion

Hierarchical CA’s
(Governor)
CA1CA1
(SoED)
CA1CA2
CA2CA4
CA1CA(DGIF)
3
CA2CA5(UVa)
CA5CA6(Darden) CA5EE1(tms)
Note: relying party follows
issuer chain to verify cert of EE1
CA5EE1
CA2CA5
CA1CA2
CA1CA1 trusted
Trust Domain Expansion

Hierarchical CA’s
CA1CA1
CA1CA2
CA2CA4
CA2CA5
CA5CA6
 Multiple
CA1CA3
Note: if CA1’s private key
is compromised, the entire
hierarchy collapses
CA5EE1
root certificates
– disservice of Microsoft and Netscape?
CAACAA
CABCAB
CACCAC
...
...
...
...
CAZCAZ
...
Trust Domain Expansion (cont’d)

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CAA
...
CABCAA
CABCAB
...
CABEE1
– N2 problem if N CA’s want to cross-certify with each
other
Bridge Certification Architecture
addresses the N2 problem by providing a central
cross-certification hub for a group of CA’s who
wish to interoperate
 each CA does one cross-certification with the
bridge CA

 Certificate
path processing (construction & validation)
CA5EE2
CAbridgeCA5
CA1CAbridge
CA1CA1 trusted
BCACA1
CA1BCA
Digital Signature Demo in a bridge
cross-certification environment
BCACA2
CA2BCA
Relying Party
e.g., web form application
1) path construction
CA1Tim
CA1CA1
CA2CA2
CA1Tim
Trust Domain
CA1CA1
Trust Domain
CA2CA2
BCACA1
CA1BCA
Digital Signature Demo in a bridge
cross-certification environment
BCACA2
CA2BCA
Relying Party
e.g., web form application
1) path construction
CA1Tim
BCACA1
CA2BCA
CA2CA2
CA1Tim
Trust Domain
CA1CA1
2) path validation
3) signature verification
Trust Domain
CA2CA2
Other Important Issues
 Protection
and storage of private keys
– Users’ private keys
 passwords or passphrases
 biometrics
 hardware tokens for mobility, e.g., smartcards
– CA’s private key
 HSM (hardware security module) for generating, storing, and
protecting the CA’s private signing key
 Key
escrow for encryption keys but not signing
keys
Other Important Issues (cont’d)
 Certificate
revocation
– CRL (certificate revocation lists)
– OCSP (online certificate status protocol)
 Certificate
profiles
– use of extensions
– identity vs. attribute certs
 Binding
a human to the act of signing
– did they see the document?
– did they intend to sign? that particular document?
– is the signing computer secure?
Where are we now?
 Technologies
are still evolving but are usable
 Policies and legal standing exist but still
developing (e.g., need case law)
– Code of Virginia, Federal law
– Uniform Electronic Transactions 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 (a COTS workgroup)
pursued pilot deployments ending in Sept., 2000
 DSI final report and recommendations:
http://www.sotech.state.va.us/cots
 Recommissioned Digital Signature
Implementation (DSI) team has been pursuing
the implementation of the recommendations –
but it is currently stalled.
 CoVA PIN currently receiving a lot of attention