Is a Test Vector feature a Security Hole?

Question

I have a system where a block cipher key (likely AES) is entered via a 'command line' over a serial console, probably as hex. The system has no 'print key' feature, so the key is hopefully 'ingest only'.

I was considering offering a 'output of known test vector V with new key K and known/fixed IV is X', where X is printed over the console. This would give the key installer confirmation that the key had been transcribed correctly, since they would compare X with a pre-computed version. V could be e.g. the standard AES test vector 00 01 .. 0F. Its length would be 16 bytes, matching the cipher's block length.

So, although the key itself is not readable from the system, an output that USED the key is, in X. V is then a 'known plaintext'.

Is such a feature a bad idea? Does it allow an adversary, who might snatch the system, to obtain the key any faster than if the feature had not been present?

For now, I don't want to consider any other avenues the attacker might have to physically break into the system, I just want to consider the known plaintext question.

Answer 1

What you're trying to do is to construct a Key Check Value or KCV.

Your scheme is dangerous, as you don't know if such a plaintext is used somehow. For instance, imagine using an all zero plaintext to create a KCV (like many HSM's do) and then using the key for counter mode. If the nonce starts at zero, then the counter block is all zero as well. Now your KCV contains (part of) the key stream, letting an attacker decrypt ciphertext.

What you could do is to establish a 128 bit constant value using a random number generator and then use that value as salt (or label) for a KDF, which uses the key as input keying material. You could use "DO NOT USE" or something similar as label for the Info parameter. That way you get a Key Check Value that is certainly not used in any protocol.

Or, slightly less secure but a lot easier, just use a SHA-256 hash over the key as KCV. It's a one way function, and the SHA-256 hash over the key is generally never used. If you mix that with a salt and a label (using concatenation) it becomes even less likely to be used as sometimes SHA-256 is used as a poor man's KDF (which is what we're doing here).