Enabling Electronic Commerce through Public Key Infrastructures ENTEGRITY Solutions J. Hughes
[email protected] www.entegrity.com
© Entegrity Solutions
CST 1st July 99/1
What is PKI? It is a technology: Public Key/Private Key algorithms that can be used for key distribution, encryption and digital signing.
It is an infrastructure: Certificates - a document that ties a specific Public Key to an individual or entity. Certification Authority - registers certificates providing assurance to the veracity of the Certificate and the relationship between the Certificate and individual. Administrative tools for storing, distributing, revoking, verifying status, backup of, recovery of Certificates
© Entegrity Solutions
CST 1st July 99/2
Best Known PKI Example, SSL v2
© Entegrity Solutions
CST 1st July 99/3
Why Public Key Cryptography? Distribution of “client” keys using traditional secret key cryptography not scaleable Any given two parties wishing to communicate need to share the same (secret) key material n(n-1)/2 problem. 3 entities=>3 keys: 10 entities=>45 keys: 1000 entities=>499,500 keys
Requirements for Non-repudiation dictate that: Secret key cryptography not viable (both parties know secret) Originator needs a “secret” that the recipient does not possess Onus on protecting the “secret” is on the originator
© Entegrity Solutions
CST 1st July 99/4
Summary of Public Key Cryptography Technology uses two keys : Public Key - can be made public, i.e. published Private Key - must be held secret (e.g. on a Smart Card)
The two keys are mathematically linked and are generated at the same time - however when generated it is “impossible” to determine one key from the other Three primary technologies available RSA: based on a factorization problem Diffie-Hellman: based on a discrete logarithm problem DSA: based on a discrete logarithm problem
Although Public keys can be made Public they need to be “signed” i.e. certified by an authority as being “Good and True” © Entegrity Solutions
CST 1st July 99/5
Why Certificates? On the Internet, no one knows who you are.
You want to maintain integrity and non-repudiation of signed documents You cannot trust a simple public key Trivial to forge -- just generate another key pair Need to tie key and identification together
Need to have the concept of a Public Key being “certified” by a known and trusted entity
© Entegrity Solutions
CST 1st July 99/6
How a Certificate Works
•Certificate is returned to end entity
Alice
Alice’s Certificate
• Third party (CA) verifies supporting documents and signs certificate • CA signs certificate containing user’s DN, public key, and •User creates key pair other attributes User attaches public key to userid information •User sends to 3rd party authority
© Entegrity Solutions
CST 1st July 99/7
Using A Certificate If the extensions are valid & the certificate valid, the site may use the certificate to grant access & allow the user to conduct & sign a variety of transactions.
Alice
Alice’s Certificat e “Token”
Check CRL & add’l data elements
User presents their certificate to a remote site.
© Entegrity Solutions
CST 1st July 99/8
Certificate Verification: Chain of Trust Certificate Authority
Alice trusts the CA and the veracity of its certificate
The CA has vouched for Bob’s identity and public key
Alice
Can Alice Trust Bob?
Bob
Alice trusts Bob’s identity and public key © Entegrity Solutions
CST 1st July 99/9
Certificate Revocation Certificate Revocation Lists (CRL)
CRL Distribution Points (CDP) Open CRL Distribution Points OCSP (Online Certificate Status Protocol)
© Entegrity Solutions
CST 1st July 99/10
CRL Processing CERTIFICATE AUTHORITY
1 CA Publishes A CRL on timed basis
DIRECTORY SERVICE
2 Local CRL is stale Client fetches latest CRL
Bob
© Entegrity Solutions
CST 1st July 99/11
Key Management Requirements Key Generation
Key Distribution Key Activation Key Replacement or Key Update
Key Revocation Key Termination
© Entegrity Solutions
CST 1st July 99/12
Certificate Management Protocols END ENTITY
PUBLISH CERT
OUT OF BAND LOADING
REGISTRATION RECOVERY UPDATES REVOCATION
CERT CRL REPOSITORY
FETCH CERT- CRL (LDAP/FTP)
END ENTITY
RA PUBLISH CERT PUBLISH CERT & CRL
LOCAL CA QUERY CERT/CRL (OCSP)
OUT OF BAND PUBLICATION
X. CERT
REMOTE CA © Entegrity Solutions
CST 1st July 99/13
“Certification” Approaches Face to Face User goes to RA/CA and issued with some type of Token with keys loaded Tokens are: • Proprietary • PKCS#12 -import/export • PKCS#15 - v1.0 of spec now issued - at least 2 products claim support
Client Web Client generation typically combination of web and e-mail
Hybrid (split keys) Token issued + client generation (typically conf keys at RA/CA auth keys at client) © Entegrity Solutions
CST 1st July 99/14
Client Generation There are many permutations. Add in Token variations then always need to “qualify” a CA - especially if “close integration” is required. encapsulation protocol • PKCS#7/PKCS#10, VeriSign, PKIX CMP/CRMF or PKIX CMC/CMS
transport • http or e-mail plus “MIME” encodings. It could also be multi stepped. Possible to perform this manually
Authentication • Whether performed, and how.
© Entegrity Solutions
CST 1st July 99/15
Client Generation CERTIFICATE AUTHORITY
1
Manual or automatic authentication
Web Request to get Trusted Cert
3 Request Cert of Public Key (SSL)
4 Email of URL for Cert location
5
Web “get” of Cert
2
Alice
Create Key Pairs
© Entegrity Solutions
CST 1st July 99/16
Token issuing model CERTIFICATE AUTHORITY
1
5 Publish Certificates
Create Alice’s Token
DIRECTORY SERVICE
using LDAP
“Post” Token to Alice
2 4 Request Certification of Public Keys
3
Alice
Create Key Pairs (Signature & Confidentiality) © Entegrity Solutions
CST 1st July 99/17
PKI Infrastructure - (Centralized and Client Generation) CERTIFICATE DIRECTORY
1
AUTHORITY Create Confidentiality Key Pair
2
6 Publish Certificates
SERVICE
using LDAP
Create Alice’s Token
“Post” Token to Alice
5
3
Back Up Private Key
Request Certification of Signature Public Key
4
Alice
Create Signature Key Pair © Entegrity Solutions
CST 1st July 99/18
Secure messaging THIS IS A zCT?*Dtyshd SENSITIVE jT67e9&54n REQ (gHya£@][Tlq Signed: PO
Supplier Project Office
Client Project Office
Verify from Supplier HQ
CONTRACT T&C zCT?*Dtyshd jT67e9&54n (gHya£@][Tlq
Verify from P.O. CONTRACT T&C zCT?*Dtyshd jT67e9&54n (gHya£@][Tlq
Contracts
Verify from Client Contracts
Signed: PO Signed: SUP HQ
Signed: PO
Signed: Contracts
Verify from Supplier HQ
ACK RECEIVED ITT
SUPPLIER HQ
Signed: SUP HQ © Entegrity Solutions
CST 1st July 99/19
SECURE MESSAGING - KEY EXCHANGE (CONFIDENTIALITY) RECIPIENT GENERATES KEY PAIR
ORIGINATOR. GENERATES DEK
CA SIGNS PUBLIC KEY -> CERT
2
1
4
CA ORIGINATOR FETCHES CERT
DEK ENC BY KEK
6
5 KEK DECRYPT DEK
9
3
DECRYPT DATA
10 X.500 HOLDS USER’S CERT
7 DATA ENC BY DEK
8 © Entegrity Solutions
CST 1st July 99/20
Secure Sockets Layer Originally developed and published by Netscape Communications. Has now been superceded by the TLS (Transport Layer Security) definition approved in RFC 2246. Provides link at the Transport Level. Secures the channel of communication and not the application. Widely deployed in browsers and web servers
Provides following security services
Server authentication Confidentiality Integrity Optional client authentication
© Entegrity Solutions
CST 1st July 99/21
SSL Handshake
Client
Server
ClientHello ServerHello Certificate* CertificateRequest* ServerKeyExchange
ClientKeyExchange Certificate* CertificateVerify* Changecipherspec Finished
Application Data © Entegrity Solutions
Changecipherspec Finished
Application Data CST 1st July 99/22
SSL Data Stream Data is transmitted with a Message Authentication Code (MAC) - not a digital signature
HEADER
MAC
DATA
Encrypted Content
© Entegrity Solutions
CST 1st July 99/23
Plugging in the gaps SSL does not address: Access Control • Access control can only be provided using client-side authentication. • Access control solutions using SSL differ between different operating systems.
Non-repudiation • SSL does not support non-repudiation.
© Entegrity Solutions
CST 1st July 99/24
Form Signing Ability for a Web User to submit a signed “form”
Provides digital signature verification and basis of nonrepudiation Products UWI AssureWeb
© Entegrity Solutions
CST 1st July 99/25
Analyzing Current Options PRO S/MIME
SSL
IPSEC
© Entegrity Solutions
Able to provide non-repudiation services based on digital signature technology
Fine granularity on protection of objects (e.g. messages, web pages)
CON
Intrusive into an application, That is a messaging application would have to be extended to support S/MIME
It is application protocol independent
Minimal impact on applications – can easily be placed in a communication stack under the Winsock layer.
Only protects a communications channel – not objects within the channel
No non-repudiation services
Current implementations not well integrated into PKI products
Only protects IP packets – no objects within the connection
No non-repudiation services
Current implementations not well integrated into PKI products
Set up and use is complicated
Well suited for securely linking “islands of trust” in which simple confidentiality and integrity services are provided. For instance linking branch offices through the world within a single company.
CST 1st July 99/26
Application restrictions to watch out for! Many “out of the box” PKI-enabled applications are poorly integrated into a PKI. For instance:
no automatic fetching of CRLs no automatic fetching of recipients certificates no support for cross-certification or hierarchies generating a certificate is a slow multi-step process
The above is particularly true for Web Browsers and to a less extent secure e-mailers
© Entegrity Solutions
CST 1st July 99/27
Questions & Answers
© Entegrity Solutions
CST 1st July 99/28
