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

Digital Signatures

A Brief Overview

by

Tim Sigmon

April, 2001

GO DUKE!

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

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

– passwords or passphrases– biometrics– hardware tokens for mobility, e.g., smartcards

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?

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

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 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 now pursuing the implementation of the recommendations

Looking for a number of early adopters