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

[Alan Lewis <alan.lewis AT geant.org>]

Hello Shannon,

Thanks for your comments - feedback below.

Best regards

Alan

Alan Lewis
Trust and Identity Services Product Manager

GÉANT 
Direct Tel: +44 (0)1223 371409
Mobile: +44 (0) 7500 891616
Switchboard: +44 (0)1223 371300
Networks • Services • People 
Learn more at www.geant.org​
​
GÉANT Vereniging (Association) is registered with the Chamber of Commerce in 
Amsterdam with registration number 40535155 and operates in the UK as a 
branch of GÉANT Vereniging. Registered office: Hoekenrode 3, 1102BR 
Amsterdam, The Netherlands. UK branch address: City House, 126-130 Hills 
Road, Cambridge CB2 1PQ, UK.

-----Original Message-----
From: edugain-discuss-request AT lists.geant.org 
<edugain-discuss-request AT lists.geant.org> On Behalf Of Shannon Roddy
Sent: 28 March 2019 18:26
To: edugain-discuss AT lists.geant.org
Subject: Re: [eduGAIN-discuss] HSM use cases

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.

>>>Yes - got that. However, the process to protect keys when outside the HSM 
>>>can be supported by tech to some extent. More with respect to the master 
>>>key of the device, but nonetheless I agree that outside an HSM (by 
>>>definition) an HSM can do nothing for you.

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.

>>Yes agreed, these are your options. 1) is problematic from a usability 
>>point of view (as you say), 2) has the weakness of exposing the key 
>>material to risk. However, I have seen some clever schemes that mitigate 
>>this risk by adding protections to the key material when outside the HSM.

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.

>>Yes, I'm not convinced by this approach either.

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.

>>Yes I agree, and it was type of process that I was alluding to above when I 
>>mentioned '..adding protections to the key....'. To do that you do (as you 
>>say) need a well thought out and 
>> tested process, most likely also backed up by some tech.

-Shannon

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