OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: HSS export / key format definition


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

 




Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen – Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]