VaultHSM report: The way to confirm whether the Smart Card (J3H145) supports RFC-6979 ECDSA implementation
The original implementation of DSA-type signature algorithm (including ECDSA) needs a random number which belongs to the same mathematical object of the private key (an element of GF(p), in which p is a prime number). This random number should also have these three property below:
If the random number comes from a flawed RNG, its randomness and uniqueness will become difficult to guarantee, for the attacker may find the pattern of the flawed RNG by collecting enough payload-signature pairs, and then calculate the private key. The industry think “we can take bear of this” until LadderLeak was being made public. The biggest problem here is: 1) Neither can’t keep the k-value secret nor “maliciously” repeat it 2) In worst-case, the attacker only cost 300k USD for P-224:
It doesn’t make sense to ignore this issue especially in post-LadderLeak era. One of the methods to solve this problem is to derive the “random number” deterministically from the hash value of private key and payload with irreversible algorithm (such as hash or message authentication code algorithm): The participation of private key in the derivation process guarantees property 1 and 3, if only the private key is not leaked. This method has been standardized as RFC 6979, and applied to the (EC)DSA implementation of libgcrypt by default. In addition, EdDSA does not use RNG anymore. The “random number” used internally is completely and deterministically derived from the hash value of private key and payload.
