Transcript Compliance Defects in Public-Key Cryptography Don Davis

Compliance Defects
in Public-Key Cryptography
Don Davis
SystemExperts Corp.
[email protected]
July 25, 1996
Preview
•
•
•
•
•
What is a Compliance Defect?
PK Infrastructure & Admin
PK’s Compliance Defects
Repair
Conclusions
What is a Compliance Defect?
• Rule of secure operation
– Indispensible for security
– Difficult to fulfill
– Unenforceable
• Familiar example: Private-key mgt.
– Rule: Don’t keep long-lived keys in memory
– But, SSO requires physical security
– Desktop users don’t keep CPUs locked up.
Public-Key Infrastructure
• Three services
– Certification Authority: Signs public keys
– Directory: Public-access DB of valid certs
– Cert. Revocation List: DB of invalid certs
• Hierarchy of servers for each
Root CA
CA
CA
CA
CA
CA
CA
CA
CA
Administrative Ease
Security
Service
Highly
Available
Trusted
Cert Authority
Directory
CRL Server
No
Yes
Yes
Yes
No
Yes
Key-Dist Ctr
Yes
Yes
Transferring Admin Burdens
• Less trust, lower availability means:
– Better network performance
– Reliability
– Servers are easier to administer
• The Price:
– User becomes the security admin
– Long-lived key-pairs are good targets
– Asymmetric-key admin tasks are hard
• So, key-mgt gets done badly, if at all
Key-Mgt Life-cycle
1. Key-creation:
CA signs certificate
User gets Root’s Pub-Key
2. Single Sign On:
3. Validation:
4. PW-change:
5. Revocation:
PW unwraps private key
Check certs’ sigs & CRL
User changes passphrase
Cert expires, goes to CRL
PK’s Compliance Defects
•
•
•
•
•
Authenticating users
Authenticating the CA
CRL checking
Private-key mgt.
Passphrase Quality
(1. Key-creation)
(3. Validation)
(5. Revocation)
(2. SSO)
(4. PW-change)
Compliance Defect 1:
Authenticating Users
• CA doesn’t just sign certificates
• New user should meet CA face-to-face
– Shows photo ID
– CA signs user’s public key into certificate
• CA provides Root CA key, face-to-face
– Electronic delivery can’t be authenticated
• None of this scales well
• “Certs by E-mail” are meaningless
Compliance Defect 2:
Authenticating the CA
• User validates a chain of certificates:
CertCA-1
signed
CertCA-2
Root CA
signed
?
signed
• User should validate Root key by hand
• Corrupted Root-CA key
MITM attack
• Protocol can’t block this MITM
Compliance Defect 3
CRL Scaling
• Rule of Thumb:
Constant cost for Issuance + Revocation
Public Key:
Issuance  Revocation
Symmetric-Key: Costs are about equal
• CRL server must be highly-available
– Commerce needs prompt revocation
• CRL is a bottleneck & point-of-failure
• CRL-validation is slow
• Users and app’s will skip CRL-checks
Compliance Defect 3:
CRL Checking
• Check CRL for every cert, at every use
• CRL-server signs “Cert OK” reply
• Min. CRL-check for 1 cert, no chaining:
CertCA-1
CertBob
Certcrl-1
CRL1
Total:
1 CRL-query
1 signature
3 sig-checks
Compliance Defect 3:
CRL Validation
Root CA
Root CRL
CRLR
CertCA-1
Certcrl-1
CRL1
signs
CertBob
Total:
6 sig-checks
2 CRL-queries
Compliance Defect 4:
Private-Key Management
• SSO means, “Private key in memory”
• Client must be physically secure
– Long-lived keys are worth stealing
– Short-lived key-pairs aren’t useful
• Protocol solution for signatures only:
– Use secret sig as short-lived private key
– Guillou & Quisquater, Eurocrypt ‘88
– NetWare Directory Services (V4)
Compliance Defect 5:
Passphrase Quality
• Corporate sites insist on PW-QA
– Length & complexity checks
– Password expiration
– PW history
• PK Infrastructure can’t enforce PW-QA
• Dictionary attack on passphrase
• Only a central authority can ensure
strong passphrases
Repair
• Smartcards
– Solves Root-CA’s key validation
– Compliance defect: Card stays in reader
– No help for issuance & revocation
• Hybridize public-key with KDC:
– Only servers have asymmetric key-pairs
– Clients use symmetric keys (from KDC)
– Consistent key-mgt, but less privacy
If PK is Flawed,
Why is it So Popular?
• Very strong security, if used correctly
• Geographical reach
– Low admin cost, in dollars per mile
• Scales well, for dispersed users
• Good for growing a secure infrastructure
• Hard parts haven’t come yet: Revocation
Conclusions
Defect
Public-Key
Symm-Key
Add New Users
Revocation
Out-of-Band Valid’n
Theft Vulnerability
PW-Quality
bad scaling
bad scaling
hard, often
long-lived key
optional
bad scaling
easy scaling
easy, once
short-lived
enforced
Network Bottleneck
Physical Security
Key-Management
CRL service
everyone
end-user
KDC
servers
sys-admin
Conclusions
• PK admin tasks are often unappreciated
– Key-mgt responsibility is local
– Hard for users to manage long-lived keys
– Sys-admins can do this job, users can’t
• Public-key is a good technology
– Good for server-to-server security
• Misapplication makes trouble
– PK is not a consumer technology
Conclusions
•
•
•
•
•
Public key technology is sound
Users are the weak point
Key-mgt is for admin professionals
We’ve underestimated practical difficulties
Great for admin applications & srvr-srvr