Date post: | 19-Dec-2015 |
Category: |
Documents |
View: | 216 times |
Download: | 0 times |
The State of the PKITechnologies, Directions & Products
William LattinDirector, Security Infrastructure Marketing
510/780-5423 [email protected]
CACR June 1999
Presentation Objectives
The nature of trust
Current certificate technologies
PKI issues:
CA operation & security
Trust policy
Policy management
Implementation considerations
PKI directions
Products & services
Definitions
Certificate
Set of information signed by a Certificate
Authority (CA)
Binds a public key to the identity of its
owner
Person or machine
Can also bind policy and attributes to
the identity of its owner
Definitions - cont’d
Public Key Infrastructure (PKI)
Trust model (CPS)
Certificate format
Certificate management
Creation, Storage, Revocation, Updating
Policies & Attributes
Cross-certification, non-repudiation
Associated protocols
PKIX, SET, etc
The Need to Create Trust
Distributed information
Intranets, extranets, access control, VPN
Electronic commerce
How to do?
Most difficult to quantify and implement
Name > Person > Characteristics > Identity?
Trusted Third Parties (TTP)
Central to dispute resolution
Trust in the Digital Age
Some trust issues are:
How do I know you are you?
How can I trust “your” public key?
How do I know you are authorized to do that?
How can I prove you did that?
How can I prove when you did that?
Liability (How can I sue you? Let me count
the ways…)
Certificate Usage
Identity and
authenticity
Owner and key
Authorization
Access control
Permissions
Non-repudiation
The Venerable X.509 Certificate
X.509v3 Certificate
version (v3)
serial number
signature algorithm ID
issuer name
validity period
subject name
subject public key info
issuer unique identifier
subject unique identifier
extensions
signed by issuer (CA)
X.509 Standards
ANSI X9.57 Certificate
Management
ANSI X9.55 Certificate Extensions
IETF PEM & PKIX (RFC 2459)
ISO
ITU-T X.509
SECG
Issues with X.509 Format
ASN.1
Distinguished names
Global name spaces difficult
Overlapping common names
Names cannot be confidential
Certificate size
Constrained devices
SET Certificates: 1580 - 2600 Bytes
Other Certificate Formats
PGP
email addresses, human names, PK fingerprints
DNS names are useful!
Bottom-up approach via “web of trust”
SPKI/SDSI (Rivest, Ellison, Lampson)
Principals are public keys with “human” names
Globally distinct; locally known
Primary purpose: authorize some action, grant
permission
Certificate Formats
Which is appropriate?
Application Specific
Open / closed network
Bandwidth limited
WAP; FLEX
Cryptographic signature method
CAs support many; apps only one
Certificate Size
RA
Certificate Authority Concepts
Certificate Authority/Registration
Authority structure
RA
CA
• CA/RA could be single unit
Directory
Certificate Authority Concepts
CA Functions
Key pair generation*
Key recovery*
Key backup
Authenticate cert
generation requests
Create/revoke
certificates
Store certificates
Cross-certification
RA Functions
Authenticate requestor
Send cert request to CA
Distribute cert from CA
to requestor
* Application Dependent
Certificate Authority Hierarchy
For Alice to validate CERTJP Bob, she needs: CERTJP Bob, CERTHQJP, CERTHQHQ Ultimately depends on trust model Applications may not support!
Bank of the World
CAHQ
CAUS CAJP
Alice
Dave
Bob
CERTHQJP
CERTJP Bob
CERTHQUS
CERTUS Alice
Japan BranchUS Branch
Architectural Trust?
Different risks associated with PKI
architectures
CA/RA or CA/CA?
RA security as critical as that of CA
Rogue certificates
Root key compromise
Disastrous in any event!
Certificate Authority Interoperability
Cross certification:
Company XCertificate Authority
User A User B User C
CertXA
Company YCertificate Authority
User D User E User F
CertYD
1. CertXX
1. CertYY
2. CertXY 2. CertYX
For D to communicate to A:
D sends CertYD CertYYA validates CertYD using CertXY
Certificate Authority Interoperability
Cross-certification issues:
How do they communicate?
Assignment of risk
Is their trust model as good as yours?
Reality
Implement on an exception basis
Technically simple; legally impossible
The Interoperability Myth
The nice thing about standards…
X.509 does not guarantee it!
Different vendor’s CAs typically don’t
interoperate
Cross-certification and trust models
Directory/Database schema
CRLs
PKIX provides some interoperability
Certificate Validation Methods
PKI is incomplete without validation
Two models:
Assume OK unless told otherwise
Assume invalid unless explicitly told OK
Certificate Validation Methods
Signature chain validation - complex
Must traverse and verify each CA to root
Browsers really don’t support!
Certificate Revocation Lists
On-line Certificate Validation
Merkle Hash Tree
Which to Use?
X.509 Certificate Revocation List
X.509v2 CRL format
Signature AlgorithmIssuer Namethis Update Datenext Update DateRevoked Certificates Serial Number A Revoked on Date
.
. Serial Number X Revoked on DateExtension
CA Signature
Extensions: Reason for Revocation Delta Update
Certificate Revocation Lists
CASecureCRL
Server
??
CRL
CRL
Cert Bob
Cert Alice
CRL
Certificate Exchange
Alice Bob
CRL Distribution
Certificate Revocation Lists
ISSUE: Update frequency
General CRLs impractical
Long lists; network overhead
Delta CRLs
Changes since the original
Distribution Points
Parse the CRL and distribute portions of list
to appropriate local servers
Online Certificate Status Protocol
IETF PKIX proposed standard
draft-ietf-pkix-ocsp-05.txt
Determine current certificate status
without CRL
Risk mitigation via “real-time” checks
Protocol independent
Online Certificate Status Protocol
CASecureOCSPServer
??Cert Bob
Cert Alice
CRL
Certificate Exchange
Alice Bob
Online Certificate Status Protocol
Security
Degree of “freshness”
Replay attack for cached certificates
Performance
Database search time
Signed responses
RSA too slow
ECDSA/DSA to enhance performance
Merkle Hash Trees
Developed by Ralph Merkle
Each message to be signed
corresponds to a node in a tree
Each node consists of a hash of the
prior nodes
Number of messages that can be
signed is limited by depth of tree
Merkle Hash Trees
0-R0 -----> N0,0
R0-R1 -----> N0,1
R1-R2 -----> N0,2
R2-R3 -----> N0,3
R3-R4 -----> N0,4
R4-R5 -----> N0,5
R5-R6 -----> N0,6
R6-Inf -----> N0,7
N1,0
N1,1
N1,2
N1,3
N2,0
N2,1
N3,0
CA Sig
N3,0
CRD
Merkle Hash Trees
Commercialized by ValiCert for
certificate revocation
ValiCert proof of validity (TTP)
CRLs limited to approx 1000 Bytes
(log2N reduction)
Still too large for certain applications
Real World Implementations
A single global hierarchy will never
occur
Communities of Interest
Mutual agreement on trust & risk levels
Overlapping “distinguished names”?
Implementation Issues
What are your security policy, certificate
usage policies, and application(s)?
Signature lifetime; CRL update criteria;
physical security; need for non-repudiation;
frequency of certificate issuance; smart card
support
Liability Issues
Whose fault is it really???
Why blame the CA for all?
Implementation Issues - cont’d
Outsourcing CA Operations:
Does their CA security meet your
requirements?
Audit trails, physical security, operator
access controls
Do they adequately vet the requestor?
RA structure vs direct application
Implementation Issues - cont’d
In-house CA issues:
Physical security for CA, operator roles and
access controls, personnel needs for operation
General issues:
Must a directory be used?
Are you prepared to be limited to a schema?
Acquisition and recurring costs Per certificate fees / maintenance fees
Per certificate fees prohibit policy management?
CA Evaluation ChecklistWhat cryptographic algorithms are supported
(ECDSA, DSS, RSA)?
Field/modulus lengths? RNG?
Supported cert formats (X.509, SET, SSL, etc)
What cryptographic hardware is supported for
secure signature generation?
How is the CA private key backed-up?
What computing platform is the CA based upon?
Use a special O/S?
What databases are supported (flat file, SQL,
RDMS)?
What directories are supported?
What directory access protocol is used?
Must a directory be used?
Is special client S/W required to access CA?
What is the format of the certificate request?
Support RA functionality?
Does CA only generate client key pairs; accept
pub key from client; or both?
Is a CRL maintained? How distributed? When?
Multiple operator roles? Distinct operator login
IDs and passwords?
Completeness of audit trail. Signed by CA?
Permanently stored?
CA actions when a cert is about to expire?
Does CA support smart cards?
How is cross-certification performed?
ANSI, IETF PKIX support
FIPS 140-1 certification
Acquisition Price / Annual Fees
Directories
Directories - the enabling technology
LDAPv2 protocol & schema proposed IETF
stds
Directory Enabled Networks initiative
LDAP & standard schema!
True enterprise & global scalability
Replace full function CAs; attribute certificates?
The mechanism for security policy
ISSUE: Directories must be trusted
Short Certificates
X.509 certificates are too long
Shortest ECDSA X.509 cert approx 350 bytes
Unsuitable for embedded devices
Storage
Bandwidth
Complex management issues
Revocation lists
Distinguished names
Shortening X.509
ANSI X9.68 draft
Allow use of Packed Encoding Rules
Eliminate “redundant” or “inefficient”
fields
Serial number is implicit - hash of certificate
Date encoding minimized
Names can be simplified
SDSI concept of hash of public key & local
name
Bullet Certificates
Introduced in1998 by Certicom
Basic Concepts:
X.509 certificates explicitly bind user
information and public key
Bullets implicitly bind user information
and public key
Public key can be derived from the signature if
public key of the CA is available
Bullet Certificates - cont’d
Advantages:
Bandwidth Savings: Public key of user and the
signature of the CA are combined in a single
element
21 Bytes versus 350 Bytes (X.509 ECDSA cert)
Computational Savings: Bullets can be verified in
half the time of an ECDSA-signed certificate
Bullet certificates can live within current CA
certificate infrastructures
For example, a bullet certificate could be placed in an
X509 certificate extension
Bullet Creation
Client Certifier1. Temporary PK pair (x,X)
2. Create permanent PK pair and bullet
f( Sig values, x, X) = (a, A, BulletA)
3. Publish Ia ,BulletA
(name, X)Permanent PK pair (c,)
1. Create unique name, Ia
2. Compute implicit signature
f(X, Ia,,c )= (Sig values)
3. Send unique name and special sig values
(Ia, Sig values)
Public
Client and Certifier cooperate on creation of a bullet
Bullet Application
Wireless
Network
Wireless Client
1. Requests Server’s Bullet
3. Client “derives” the server public key from the bullet, using CA’s public key.
4. Client completes authentication of the server by verifying the data signed under server’s private key, using the public key of the server derived in step 3.
2. Sends Bullet and data signed under server’s private key - this information is sent over the air link
The user of the wireless device wishes to retrieve his/her account information and therefore, needs to authenticate the bank.
Bank Server
Considering the bandwidth limitations over the air link, bullets are an efficient choice for this application.
Certified Time
The business need:
Determining “when” an event occurred
Imprecise in our paper world
Applications: arbitrage, patent filing, e-
business
PKI can deliver:
Authentic, traceable time (UTC to NIST)
Non-repudiation
Certified Time - or is it?
Timestamps to withstand the test of
time
What modulus length is appropriate?
512 - 15,000 RSA bits
113 - 512 ECC bits
What hash is appropriate?
SHA-1 at 80 bits of security
SHA-2 at ???
Certified Time - cont’d
Two IETF tracks:
Secure distribution of time via NTP
S/Time Working Group
draft-mills-ntp-auth-coexist-01.txt
Document time stamping
PKIX Time Stamp Protocols
draft-ietf-pkix-time-stamp-01.txt
Many CAs will support
Product & Service Listing
Products:
Baltimore Technologies*
Diversinet*
Entegrity Solutions
Entrust Technologies
GTE CyberTrust
Microsoft
Motorola*
Netscape
Xcert International*
Services:
Digital Signature Trust Co.*
GTE CyberTrust
GlobalSign
InterClear
Thawte
VeriSign
* Supports ECC
Summary
The PKI is ready for business
Products/services abound
Select to match application
Implementation as much a business
decision as a technology decision
business re-architecting, risk management,
economics
Have we got it right?
Evolution (revolution?) continues