[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
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]