Public Key Infrastructure
A Brief Overview by
Tim Sigmon May, 2000
Fundamental Security Requirements
(all addressed by PKI)
X Authentication - verify identity of communicating parties
X Access Control - who can access what
X Privacy - protect info from indiscriminate viewing
X Integrity - guarantees info not altered
X Non-Repudiation - inability to disavow a transaction
X Management and Audit - ability to manage and ascertain security
Public Key Infrastructure
-Definitions
X Infrastructure for enabling and supporting
e-transactions (e-commerce, e-business, etc.)
X System that verifies the identity and authority of each party involved in any transaction over the Internet
X Includes technologies/functions such as public key encryption, digital certificates, certification authorities, registration authorities, certificate management services, time-stamp services, and directory services
Public Key Cryptography
X First, “secret key” or symmetric cryptography
– same key used for encryption and decryption – orders of magnitude faster than public key
cryptography
X Public key technology solves the key exchange problem
X Public key and private key that are mathematically linked
X Private key not deducible from public key
X Confidentiality: one key encrypts, other decrypts
Confidentiality example
X Sender generates a symmetric encryption key and encrypts document with it
X Sender encrypts symmetric key with recipient’s public key
X Encrypted symmetric key and encrypted document sent to recipient
X Recipient uses private key to decrypt symmetric key
Digital Signatures
X Legal concept of “signature” is very broad
– any mark made with the intention of authenticating the marked document
X Digital signatures are one of many types of
electronic signatures
X 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”
Digital Signatures (cont’d)
X “digital signature” means the result of using specific cryptographic processes
X Digital signatures operate within a framework of hardware, software, policies, people, and
processes called a Public Key Infrastructure (PKI)
X For more info,
http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html
Digital Signature example
X Sender signs (i.e., encrypts) a hash of the
document; sends that and document to recipient
X Recipient uses sender’s public key to retrieve the sender’s hash of the document
X Recipient computes hash of the received document
X If hashes are the same, the transaction is valid
Signed Email example
X (show example of sending/receiving digitally signed email using Netscape Messenger)
Problem: relying party needs to
verify a digital signature
X To do this, needs to have an assured copy of the signer’s public key
– signer’s identity must be assured
– integrity of public key must be assured
X 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.
X But, what about strangers? what about integrity of the public key?
Public Key (or Digital) Certificates
X Purpose: validate both the integrity of a public key and the identity of the owner
X How: bind identifying attributes to a public key (and therefore to the keyholder of the
corresponding private key)
X Binding is done (i.e., digitally signed) by a trusted third party (Certification Authority)
X It is this third party's credibility that provides "trust"
X.509 v3 Certificates
X Subject’s/owner’s identifying info (e.g., name)
X Subject’s/owner’s public key
X Validity dates (not before, not after)
X Serial number
X Level of assurance
X Certification Authority’s name and signature
X.509v3 Certificate Extensions
X subject key identifier
X authority key identifier
X key usage (digital signature, encryption, etc.)
X extended key usage (TLS server auth, code signing, etc.)
X private key usage period (rfc2459 against)
X certificate policies (e.g., CPS URI)
X.509v3 Extensions (cont’d)
X subject alternative name
X issuer alternative name
X subject directory attributes (rfc2459 against)
X basic constraints (denotes CA or not)
X path length constraint (CA only)
X name constraints (CA only)
X policy constraints (CA only)
X NOTE: extensions can be marked critical or non-critical
Example Certs
X (this is where I show and describe the contents of the actual certificates that were used to verify a digitally signed email message)
Certificate Profiles
X RFC2459 defines cert profiles for Internet use
X Profiles need to be further refined
(constrained/simplified) for the Va DSI pilots
X Identity vs. Attribute
– certs should carry only subject identity info
» static, long-lived info
– X.509 defines attribute certificates
» not public key certs » typically short-lived
» carry pointer to associated public key cert
– authorization info should be maintained by relevant application or carried in attribute certs
Distribution of Certificates
X 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)
X distribution via directories is the ultimate solution
X however, many important applications and uses of digital signatures can be implemented without the implementation or use of sophisticated directories
More about Digital Certificates
X Formats: X.509v3, PGP, others
X Storage and retrieval
– public: LDAP, X.500, personal keyrings
– private: hard disk, smartcard; password or biometric to unlock
X Cert should contain minimum necessary identification info
X Key escrow for encryption but not signing
X Users will need at least two (signing and
Trust and Certification Paths
X User needs an assured copy of the PK of the issuing CA in order to validate a certificate containing a required PK
– how do you know that a student didn’t set up a CA and issue certs?
X In general, a chain of multiple certificates may be needed
X How to organize the CA’s?
– pure top-down hierarchy (yikes!)
– “web” of trust (e.g., CREN, Federal Bridge, CBCA)
Where are we now?
X Technologies are still evolving but are very usable
X Policies and legal standing exist but still developing (need case law)
– Code of Virginia
– Uniform Electronic Transctions Act
X Browsers already contain a lot of capability
X Particular uses widely taking place, e.g., SSL
X Some universities making more use, e.g., MIT
DS efforts in Virginia
X Digital Signature Initiative (COTS workgroup) formed to pursue first wave deployments
X UVa will lead development of a bridge
certification architecture (modeled after federal bridge)
X First wave sponsors
– VIPNet
– Dept. of Game & Inland Fisheries – DMV, DOT, DIT, DGS
– Counties of Chesterfield, Fairfax, Wise – City of Norfolk
For More Information
X http://csrc.nist.gov/pki/
– information from the National Institute of Standards and Technology who are taking a leadership role in the development of a Federal PKI
X http://gits-sec.treas.gov
– lots of info about the federal PKI efforts
X http://www.itc.virginia.edu/atg/pki
– Richard Guida’s presentation (both video and slides)
X http://www.law.upenn.edu/library/ulc/uecicta/ueta st84.htm
For More Information (cont’d)
X http://www.verisign.com
– Verisign has a number of PKI products/services and their web site contains a lot of documentation
X http://www.entrust.com/
– Entrust Technologies has a number of PKI related products and their web site contains a nice demo
X http://www.ibm.com/security/technologies/index. html
– IBM has a number of PKI related products and info at this site
For More Information (cont’d)
X http://www.sotech.state.va.us/cots
