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

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

Hello Peter,

Thanks very much for your swift reply. My comments and some further questions 
(sorry) 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 Peter Schober
Sent: 26 March 2019 18:27
To: edugain-discuss AT lists.geant.org
Subject: Re: [eduGAIN-discuss] HSM use cases

Alan,

* Alan Lewis <alan.lewis AT geant.org> [2019-03-26 17:08]:
> One of the things I would like to understand is what requirements 
> there might be for use of such an HSM in the R&E community and outside 
> of those services which are currently being offered by GEANT.

Since you sent this to the eduGAIN-discuss mailing list I'll be answering 
this as far as Identity Federation topics are concerned.
>> Excellent - noted.

> So I would be interested to know for any services you are aware of that 
> might benefit:
> 
> 1.    The use cases for secure storage;

Protecting cryptographic (secret/private) key material.
Mostly for the federation's signed metadata feeds (SAML 2.0) or software 
statements (OIDC+fed). Possibly some TLS servers' keys.
>>  O.K so the principal operation here is signing. Are there any specific 
>> requirements for the type of key and the strength (RSA, ECDSA etc.)? Also 
>> what types
>> of hashing algorithms need to be supported? (MDS, SHA-n etc).
>> Is there a use case for the HSM being used to support symmetric crypto 
>> algorithms for the encryption of data? Is the volume of transactions such 
>> that a crypto
>> accelerator would be of benefit?
>> Aside from the HSM itself do you see any need to have additional physical 
>> and logical security mechanisms to protect the key material? For example, 
>> does the HSM >>need to be protected by physical barriers to access? Should 
>> the HSM have mechanisms to ensure access to the HSMs key stores cannot be 
>> easily afforded? These >>questions are fundamentally about the value of 
>> the information that is being protected.


> 2.    The current situation – what is being done today;

A few federations have deployed NetHSMs (I know about ~3), others may be 
using smartcard-based HSMs (maybe 3-6?), the large majority (eduGAIN 
currently has 60 member federations) probably still signing with 
software-based keys?
I'm not aware we've asked federations to disclose this information yet.
>>For those federations that are using some form of hardware protection - and 
>>HSM or token are you aware of ay criteria that may have been applied in 
>>selecting the >>hardware security mechanism? (I'm trying to shortcut a bit 
>>of work here is some federations have already gone through a process of 
>>defining the requirements for such >>devices).
>> Assuming there are requirements to use HSMs do you think there is a 
>> requirement for the federations to physically host the HSMs, or do you 
>> think a service approach >>(c.f AWS Cloud HSM) might be applicable?

> 3.    The data that is being stored and the quantity;

Mostly RSA keys in the 2-4k range, I think.
As for quantity I doubt it's more than an handful, for most of us.
>> Right. I think I asked this question above and you have already answered 
>> here. Sorry for repeating myself)

(If dozens or hundreds of partitions were available in the HSM some services 
-- e.g. GEANT's own FaaS offering -- would actually make use of dozens, not 
quite hundreds, of keys. Since that's not the case with the current NetHSM as 
used by GEANT the FaaS infrastructure currently uses a single key pair for 
all signed aggregates.)
>>I see - I didn't realise only a single key pair was being used. Are there 
>>any examples of other services that might want more key pairs than are 
>>currently used?

> 4.    The value of the information that is being protected;

Were a federation participating in eduGAIN unable to provide a trusted feed 
that would lead to their exclusion from the global trust fabric, i.e., 
institutions and servics within that federation would vanish from other 
federations' view and the affected federation would lose access to services 
offered by others via eduGAIN.

That trust does not derive purely from (and therefore cannot be reduced to) 
the technical properties of the method chosen to protect key material, of 
course.

And the existing real-world trust that allowed federations to get established 
in the first place (and that enables their members to trust the federation's 
keys) would likely allow to re-bootstrap a federation's trust anchors from 
scratch as long as that doesn't happen regularly (say, more than once/very 
few times).
>> Thanks, that it a good qualitative description of the value of protecting 
>> the trust behind federations. It implicitly leads to a quantitative 
>> description of the information >> >>being secured, but calculating that 
>> would be hard and probably, not entirely worthwhile. Nevertheless, a 
>> justification for improved protection of key material seems clear.

> 5.    Specific HSM requirements for
> 
> a.    Cryptographic performance;

With MDQ (siging several thousand[1] of small text files individually, 
instead of signing one ~50MB file) on the horizon that's increasingly going 
to be a factor. You'd want those thousands of signature ops to be performed 
at least daily, possibly more often.

Personally I think resigning everything in eduGAIN would probably work up to 
3 or 4 times the number of entities of the current eduGAIN aggregate (with 
15-20k signing ops taking a few hours) even when using smartcard-based HSMs 
(that typically have a signing performance around
1-2 signature operation per second) but views will widely differ here across 
federations.
>> Yes, this is probably the largest performance requirement I have seen so 
>> far.  So with multiple signings/day we could estimate some 10's of 
>> thousands of signatures/day.

> b.    Cryptographic algorithm support;

Today pretty much only RSA with SHA2 based hashes is being used, AFAIK.
I'll leave that to others.

> c.    Management, connectivity and access mechanisms;

Obviously PKCS#11 for access but if we snuck in some newer
(non-standard) method such as TLS-protected pyeleven-style HTTP (and maybe 
standardised that while we're at it) that would probably make a few people's 
lives quite a bit easier.
>> Dare I mention Microsoft MSCAPI. Any takers?

> d.    FIPS level or CC compliance;

Don't know/care.
>> O.K but are there some desirable characteristics that would be a part of 
>> FIPS compliance that would be useful. For example a tamper resistant or 
>> tamper evident HSM?

> e.    Other stuff I haven’t thought of yet.
>> I have thought of a couple more things
>> Any need to execute code securely within the boundary of the HSM?
>> For federation that have an existing HSM to protect key material is there 
>> any set of circumstances that might make them adopt a new HSM offering e.g.
>>Lower cost of ownership;
>>Equivalent or improved level of security;
>>Non-commercial HSM (potentially) providing greater transparency (think 
>>Huawei)


I'll leave that to others as well.

Best regards,
-peter

[1] The current edUGAIN aggregate contains 5445 entities as per today and has 
been growing by 50-100 entities per month in recent times.

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