Public Key Validity and Private Key Possession: Recent Developments

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 can�t check everyone else�s 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 Don�t Check? If CA isn�t sure of private-key possession, then it might issue a certificate with an adversary�s name and someone else�s public key Relying parties may make flawed assumptions as a result If verifier isn�t sure a signature public key is valid, then can�t be sure either that signatures are hard to forge Dishonest signer may be able to repudiate on this basis If sender isn�t sure an encryption public key is valid, then can�t be sure either that ciphertexts are hard to decrypt And in Diffie-Hellman, if encryption public key is combined with sender�s long-term private key, sender�s 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 doesn�t 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 doesn�t 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 Kaliskibkaliski@rsasecurity.com Mark McCutcheonmmccutcheon@rsasecurity.com