HSS private key import/export in the context of XML based testing and high availability / load balancing

[Michelle Brochmann <mbrochmann@infoseccorp.com>]

Hi all,

 

I know that in last Wednesday’s meeting (as well as the face-to-face meeting) we came to the conclusion that HSS private keys should never be exportable in the PKCS framework.

 

However after a bit more discussion with colleagues and taking another look at the email Daniel Minder sent objecting to this on 2-19-2020 (same day as the F2F, subject: “HSS export / key format definition”), I am again uncertain.

 

It seems that we would like to strive for comprehensiveness in the specification, for general usability and also, more specifically, to make it “possible to create reasonable test cases”, as Daniel pointed out.

 

Since I need to discuss with Tim Hudson what is going in the profiles document for the XML based testing – Tim, do you have any feedback about this?

 

I agree that backup and restore, if they are handled by the vendor, are less crucial, but I have been thinking about key import/export in the high availability/load balancing scenarios.

 

Originally I was thinking of the entire hierarchy as being “stored” on one HSM – in the implementation I was studying, it was, and in this case, using the keys sequentially and storing the state via an index of the next key to be used made sense. But if we are going to be splitting trees across multiple devices, then we start wanting a more flexible state specification – not so much “what one-time key must be used next” as “what one-time keys may/may not be used”. Then, something like a list of indices of available or unavailable subtrees makes more sense for the state. The vendor may also have some internal way of storing the state that is unsafe for export but that shouldn’t matter from the PKCS standpoint.

 

Is it possible via the PKCS mechanisms to enforce (or at least provide guidance) that one-time keys are never marked as usable on more than one device at a time? What I’m imagining is that when exporting a private key, it is possible somehow to specify which subtrees in the hierarchy are actually permitted to be used in that exported version, and that those subtrees are marked as unavailable in the HSM from which the key was exported. Then, when the exported key is imported to another HSM, only the available subtrees are marked for use.

 

Michelle

Attachment: smime.p7s
Description: S/MIME cryptographic signature