An open discussion list for topics related to the eduGAIN interfederation service.

[Shannon Roddy <sroddy AT internet2.edu>]

On 3/28/19 5:33 AM, Peter Schober wrote:
> * Alan Lewis <alan.lewis AT geant.org> [2019-03-28 10:21]:
>> Yes I agree that generating the keys outside the HSM has benefits in
>> terms of key backup and recovery. The key thing is that the process
>> for doing this is itself secure. I don’t know what mechanisms the
>> USB tokens have to do this, so it would be useful to take a look if
>> you can point me at any examples.

> I think the point he (and Shannon and myself) was making is that if you
> generate key material outside the HSM by defintion the HSM can do
> nothing for you to make this (more) secure, i.e., it's all in your own
> processes.

Yes.  It's as much about process and procedures as it is tech.

Ultimately, there are two obvious choices regarding key generation.

1) Have a key that is impossible to exist outside of the HSM.  This
makes backup, HSM vendor changes, disaster recovery, etc. challenging
and likely are vendor specific methods.  Security of things like
metadata signing are still only as secure as the process(es) that have
access to the HSM to request signing.  The ideal case for security of
the signing process is an air gap, but this means there will always be a
highly manual and cumbersome signing process.

2) Have a key that is generated in such a way that it can exist outside
of the HSM (off-HSM generation or exportable key).  This makes DR,
backup, and vendor changes less difficult.  The security of key
generation and backup key storage security becomes one of process as
much as it is technical.

I know of at least one HSM that will not allow one to set the
non-exportable flag for a key that is imported.  I believe the logic
here is that the key is already known to exist outside of the HSM, so
there is no value to setting the flag.  I personally feel it is flawed
logic.  There are workarounds that are equally effective, but it is
still IMO a flaw on that HSM.

For the storage of a backup key, there are technical and process methods
that can be used to ensure the security of the key beyond just storing
it in a physical safe.  One can encrypt the key such that a minimum
quorum is needed to decrypt the key material.  The key as stored at
rest, even if physically compromised/copied, is useless to a malicious
actor (as long as, say, AES256 isn't broken).  All of the steps to get
there require a well thought out plan and process.  Who has access to
the safe, who and how many does it take to reach quorum, ensuring that
the key exists for as little time as possible in a decrypted form while
it is being imported into the HSM, etc.

-Shannon