5

I'm looking for a standard, or sound industry practice, for the equivalent of a Key Check Value, applied to the private key of a public key algorithm, like ECDSA.

For DES or 3DES keys, practice (as worded e.g. in EMV Card Personalization Specification) is:

6.1.5 Key Check Value
Purpose: The data is used to prove that a card/processor has access to a specific DES key value.
Format: Binary, 3 bytes
Contents: The three leftmost bytes of the result of encrypting eight bytes of zeros by the DES key concerned.

Notice that the above definition is slightly wrong: the KCV as defined does not prove anything beyond knowledge of the KCV. The actual purpose (and the one I'm interested about) is to guard against a wrong value of the key, either accidental, or deliberate from one participant in a scheme where the key is rebuilt from shared secrets (for simplicity, assume that's by XOR of the components, and that at least one participant does not cheat).

Raoul722
  • 3,003
  • 3
  • 23
  • 42
fgrieu
  • 149,326
  • 13
  • 324
  • 622

1 Answers1

3

PKCS10 looks like relevant industry practice for private keys.

See "Note 2" at page 4, Certification Request Syntax Specification - RFC 2986: The signature on the certification request prevents an entity from requesting a certificate with another party's public key.

That is, soneone requesting a certificate on a public key demonstrates his knowledge of corresponding private key by producing a signature verifiable with the public key from PKCS10 request.

Another technique could be found at Join protocol, Direct Anonymous Attestation for Trusted Platform Module chip. It could be considered a proof that TPM "has access" to "keys" $f_0$ and $f_1$.

Community
  • 1
Vadym Fedyukovych
  • 2,347
  • 14
  • 19