1 / 29

Public Key Validity and Private Key Possession: Recent Developments

Confidence for Public-Key Implementations. Cryptography in general, and public-key cryptography in particular, can provide great security in practice

kane
Download Presentation

Public Key Validity and Private Key Possession: Recent Developments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Public Key Validity and Private Key Possession: Recent Developments Burt Kaliski, RSA Security (joint work with Mark McCutcheon) RSA Conference Japan 2004

    2. Confidence for Public-Key Implementations Cryptography in general, and public-key cryptography in particular, can provide great security in practice but only if correctly implemented Good engineering, code reviews, standards and validation testing all contribute to correctness But: Some things can't be checked for in advance (e.g., attacks) Some initial checks might no longer hold in operation (e.g., due to errors) And you cant check everyone elses implementations! Additional checking during operation can thus be quite valuable

    3. Two Important Checks Public key validity (PKV) Assurance that a public key satisfies a given mathematical definition RSA modulus n is the product of two primes of the same length discrete logarithm (DL) public key is in the proper subgroup Private key possession (POP) Assurance that the owner has the corresponding private key Assurance can come in many forms, from explicit checks to confirmations by other parties

    4. PKV and POP Background PKV, POP emerged at different points in the development of public-key cryptography standards Private-key possession in early Privacy-Enhanced Mail e.g., S. Kent, c. 1989 Public-key validity from small subgroup attacks on Diffie-Hellman e.g., S. Vanstone, c. 1996 Later incorporated into standards, but somewhat separately: POP initially into PKIX, PKV into some ASC X9F1 documents NIST Key Establishment Schemes work and new X9F1 documents bringing concepts together D. Johnson (Certicom/Entrust) has been the key driver of this work

    5. What If I Dont Check? If CA isnt sure of private-key possession, then it might issue a certificate with an adversarys name and someone elses public key Relying parties may make flawed assumptions as a result If verifier isnt sure a signature public key is valid, then cant be sure either that signatures are hard to forge Dishonest signer may be able to repudiate on this basis If sender isnt sure an encryption public key is valid, then cant be sure either that ciphertexts are hard to decrypt And in Diffie-Hellman, if encryption public key is combined with senders long-term private key, senders private key may be at risk due to small subgroup attacks

    6. Four Ways to Check Examine the keys Use the keys Rely on assertions e.g., this public key is valid, this module correctly generates key pairs Trust someone else to do this for you

    7. The Players Owner: the party associated with the private key Relying party: another party interested in employing the public key TTP: a trusted third party, e.g., CA

    8. Taxonomy of Assurances Assurances organized among the players: Owner assurances Self-assurances TTP assurances to owner Relying party assurances Self-assurances Owner assurances to relying party TTP assurances to relying party TTP assurances similar to relying party assurances These assurances are currently being discussed in ASC X9F1 (but this presentation is our opinion only)

    9. Initial, Minimum and High Assurance Initial assurance comes from correctness of key generation module, or perhaps from assertions At a minimum, parties should obtain some additional assurances For high-assurance systems, one or more specific additional assurances recommended (denoted *)

    10. Owner Self-Assurances: PKV Key pair validation* Examine both keys for validity, consistency Full public-key validation* Examine public key for validity easy for DL systems hard for RSA without witness Partial public-key validation Examine some properties of public key: plausibility tests Key pair regeneration* Regenerate public key from private key, or key pair from seed

    11. TTP Assurances to Owner: PKV TTP full public-key validation* May be interactive with owner for RSA TTP partial public-key validation If TTP trusted with private key: TTP key pair validation* TTP key pair regeneration*

    12. Owner Self-Assurances: POP Current use* Use the private key now and check with public key Prior use Check that the private key was used correctly before e.g., self-signed certificate Key pair validation*

    13. TTP Assurances to Owner: POP TTP confirmation of owner current use* TTP confirmation of owner prior use If TTP trusted with private key: TTP key pair validation*

    14. Relying Party Self-Assurances: PKV Full public-key validation* Partial public-key validation

    15. Owner Assurances to Relying Party: PKV Full public-key validation* interactive or with witness Owner assertion: Trust me root keys

    16. TTP Assurances to Relying Party: PKV Full public-key validation* Partial public-key validation TTP key pair generation* TTP key pair regeneration* TTP confirmation of owner assertion

    17. Relying Party Self-Assurances: POP None

    18. Owner Assurances to Relying Party: POP Current use* Prior use Owner assertion

    19. TTP Assurances to Relying Party: POP TTP confirmation of owner current use* But how current is the confirmation? TTP confirmation of owner prior use TTP key pair validation*

    20. Harmonizing the Assurances The various assurances are really just attributes (or consequences) of key management methods PKV and POP assurances have historically been developed separately, but have significant overlap and can readily be treated together Some PKV assurances help with POP, and vice versa: e.g., owner current use is a type of partial public-key validation Key pair regeneration also provides assurance of possession POP assurance level depends on PKV assurance level

    21. Example Harmonization: Owner Self-Assurances

    22. Example: Typical Browser-Based PKI Client generates key pair Client sends certificate request to CA includes public key, user name, signed by private key CA verifies signature CA returns certificate Relying parties obtain certificate

    23. Typical Assurances Obtained POP: Owner and relying party: TTP confirmation of owner prior use via certificate CA: owner prior use via certificate request Binding to correct user name is a separate issue PKV: Owner and relying party: TTP confirmation of owner prior use (as partial public-key validation) CA: owner prior use Owner assertion may also play a role, if owner is obligated by agreement with CA, or compelled by reputation with relying party

    24. Some Enhancements Owner current use achievable if certificate request includes nonce from CA Full public-key validation easy for DL keys, but also possible for RSA with interaction or witness

    25. Beyond Key Validity: Assurance of Correct Generation Public-key validation only provides assurance that a public key satisfies a given mathematical definition It doesnt provide assurance that key pair was generated at random Also, some properties are hard to validate efficiently, e.g., certain strong prime conditions

    26. Why Does This Matter? Key generation module might use a prime more than once, which would make the RSA modulus subject to a GCD attack (D. Johnson observation) Owner might deliberately choose a prime that doesnt meet some hard-to-validate strong prime condition, in order later to repudiate a signature An optimized implementation might select a DSA private key that is too small - e.g., < 80 bits In all these cases, the key pair would be valid, yet insecure

    27. KEGVER: Checking Correct Generation KEGVER (Juels-Guajardo 2002) is an example of a protocol that generates RSA key pairs with a zero-knowledge proof that the generation was done correctly i.e., by incremental search, or close Idea: CA influences random starting points for prime search, and owner demonstrates (in zero-knowledge) that primes are near starting points Can be made noninteractive with witness, which can be used to give assurance to other parties Deliberate construction of primes infeasible with this method, hence outputs are large random primes

    28. Conclusion Public-key validity and private-key possession are essential assurances for the security of a public-key implementation These assurances can be expressed as dual attributes of various key management methods Assurance of correct key pair generation is a next step forward in checking correctness of an implementation

    29. Contact Information Burt Kaliski bkaliski@rsasecurity.com Mark McCutcheon mmccutcheon@rsasecurity.com

More Related