33ccffea37060ed14cf92c85e44482fd.ppt
- Количество слайдов: 20
Compliance Defects in Public-Key Cryptography Don Davis System. Experts Corp. don. davis@systemexperts. com 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
Administrative Ease Security Service Highly Available Trusted Cert Authority Directory CRL Server No Yes Yes No Yes Key-Dist Ctr 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: Key CA signs certificate User gets Root’s Pub- 2. Single Sign On: 3. Validation: PW unwraps private key 4. PW-change: User changes 5. Revocation: Cert expires, goes to CRL passphrase CRL Check certs’ sigs &
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: Cert. CA-1 signed Cert. CA-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: Cert. CA-1 Cert. Bob Certcrl-1 CRL 1 Total: 1 CRL-query 1 signature 3 sig-checks
Compliance Defect 3: CRL Validation Root CA Root CRLR Cert. CA-1 Certcrl-1 CRL 1 signs Cert. Bob 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 – Net. Ware Directory Services (V 4)
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 hard, often long-lived key optional bad 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
33ccffea37060ed14cf92c85e44482fd.ppt