digital signatures a brief overview by tim sigmon october, 2001
TRANSCRIPT
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 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
Certification Paths To validate a cert containing the signer’s PK, relying
party needs an assured copy of the issuing CA’s PK.
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
In general, a chain of multiple certificates that ends at a trusted root is needed
CA1Bob cert containing Bob’s PK (signed by CA1 )
Example: verify Bob’s signature on a signed doc
Follow the
issuer chain!
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)
CA1 Tim
CA1 CA1
Simple Hierarchical Trust
Relying Party
Signed doc and CA 1 Tim
e.g., email or web form application
Trust Domain
1) path construction CA1Tim CA1 CA1
2) path validation
3) signature verification
Trust DomainCA1 CA1
Trust Domain Expansion
Hierarchical CA’sCA1CA1
CA1CA2 CA1CA3
CA2CA4 CA2CA5
CA5CA6 CA5EE1
CA2CA5CA1CA2
Note: relying party followsissuer chain to verify cert of EE1
CA5EE1
CA1CA1 trusted
(Governor)
(UVa)
(SoED)
(tms)(Darden)
(DGIF)
Trust Domain Expansion
Hierarchical CA’sCA1CA1
CA1CA2 CA1CA3
CA2CA4 CA2CA5
CA5CA6 CA5EE1
Note: if CA1’s private keyis compromised, the entirehierarchy collapses
CAACAA CAZCAZCACCACCABCAB
... ... ... .... . .
Multiple root certificates– disservice of Microsoft and Netscape?
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
CAACAA
...CABCAB
...
CAACAB
CABCAA
CABEE1
– 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
CAbridgeCA5
CA1CAbridge
Certificate path processing (construction & validation)CA5EE2
CA1CA1 trusted
CA1Tim
CA2CA2
Digital Signature Demo in a bridgecross-certification environment
Relying Party
Signed form data and CA 1Tim
e.g., web form application
Trust Domain
1) path construction CA1Tim CA2CA2
BCACA1
CA2BCABCACA2
CA1BCA
CA1CA1
Trust DomainCA1CA1
CA1Tim
CA2CA2
Digital Signature Demo in a bridgecross-certification environment
Relying Party
Signed form data and CA 1Tim
e.g., web form application
Trust Domain
1) path construction CA1Tim CA2CA2
2) path validation
3) signature verification
BCACA1
CA2BCABCACA2
CA1BCA
CA2BCABCACA1
Trust DomainCA1CA1
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