All,
I object to our conclusion that PKCS#11 should not support HSS key export and, thus, should not define key or state formats but leave it as an exercise to the token vendor.
I agree that reusing leaf nodes puts keys at risk. However, the conclusion is not to strictly keep a key inside a single HSS and to deny export. Otherwise, we would need to deny GCM with external IV immediately since
reusing an IV will put keys at risk in the same way.
However, read
https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf page 185 where the IV restoration conditions for GCM are specified. I expect that similar conditions will be set other stateful algorithms
in the future.
Moreover, without export/import functionality the practical applicability of HSS is quite limited. You need to have backup&restore, you need to have high availability and load balancing where cryptographic operations
with the same key can be executed on more than one token.
But this should be enforced by procedures and not by the token.
Finally, without specifying the key and also state format it will not be possible to create reasonable test cases. But that’s what we are aiming for now.
So, what we need is
- Specification of public and private key format
- Specification of state format
- Specification of a key derivation mechanism that splits the Merkle tree, modifying the state of the base key and creating a derived key with the part of the tree that was split off. Then,
this key can be exported and transferred to a 2nd token.
Thus, our task is to provide the necessary mechanisms to enable users to work with HSS keys in a secure way if they stick to certain procedures. But they are not under the token’s control – and we must not enforce this.
It’s similar to GCM: the cited document allows its use for 3 protocols only – but the token does not need to enforce it and cannot do it because it just provides the basic GCM functionality.
Best,
Daniel