Compliance Defects in Public-Key Cryptography Don Davis SystemExperts Corp. don.davis@systemexperts.com

1. Compliance Defectsin Public-Key CryptographyDon DavisSystemExperts Corp.don.davis@systemexperts.com July 25, 1996

2. Preview • What is a Compliance Defect? • PK Infrastructure & Admin • PK’s Compliance Defects • Repair • Conclusions

3. 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.

4. Root CA CA CA CA CA CA CA CA CA 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

5. Administrative Ease Security Highly Trusted Service Available Cert Authority No Yes Directory Yes No CRL Server Yes Yes Key-Dist Ctr Yes Yes

6. 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

7. Key-Mgt Life-cycle 1. Key-creation: CA signs certificate User gets Root’s Pub-Key 2. Single Sign On: PW unwraps private key 3. Validation: Check certs’ sigs & CRL 4. PW-change: User changes passphrase 5. Revocation: Cert expires, goes to CRL

8. PK’s Compliance Defects • Authenticating users (1. Key-creation) • Authenticating the CA (3. Validation) • CRL checking (5. Revocation) • Private-key mgt. (2. SSO) • Passphrase Quality (4. PW-change)

9. 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

10. ? CertCA-1 CertCA-2 Root CA signed signed signed Compliance Defect 2:Authenticating the CA • User validates a chain of certificates: • User should validate Root key by hand • Corrupted Root-CA key MITM attack • Protocol can’t block this MITM

11. Compliance Defect 3CRL 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

12. CertCA-1 Certcrl-1 CRL1 Total: 1 CRL-query 1 signature 3 sig-checks CertBob 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:

13. Root CA Root CRL CRLR signs CertCA-1 Certcrl-1 CRL1 Total: 6 sig-checks 2 CRL-queries CertBob Compliance Defect 3:CRL Validation

14. 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)

15. 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

16. 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

17. 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

18. Conclusions Defect Public-Key Symm-Key Add New Users bad scaling bad scaling Revocation bad scaling easy scaling Out-of-Band Valid’n hard, often easy, once Theft Vulnerability long-lived key short-lived PW-Quality optional enforced Network Bottleneck CRL service KDC Physical Security everyone servers Key-Management end-user sys-admin

19. 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

20. 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