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

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

Hello Peter,

Thanks for your replies - a few more comments below, but no further 
questions! (at this time).

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: Peter Schober <peter.schober AT univie.ac.at> 
Sent: 27 March 2019 12:01
To: Alan Lewis <alan.lewis AT geant.org>
Cc: edugain-discuss AT lists.geant.org
Subject: Re: [eduGAIN-discuss] HSM use cases

* Alan Lewis <alan.lewis AT geant.org> [2019-03-27 12:08]:
> 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).

As I had written previously, currently we're using pretty much exclusively 
RSA signing (2k-4k bite size keys) with SHA2 hashes.

But obviously things change and therefore algorithm agility is an important 
ongoing concern.

Given the contraints of having to update hundreds or thousands of metadata 
consumers all over the world though severly limits the
(glacial) speed at which we can move. So an HSM moving slightly faster than 
that probably suffices. ;)

>> Right, that is good to know. One of the key things is not to over-specify 
>> the functionality so getting a view of the 'realistic' needs rather than 
>> the desired 'wants'.

> 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?

I cannot speak to symmetric crypto requirements. The transaction volume you 
already guesstimated based on my earlier description.
>> Yes thanks for that.

> 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.

Well, sure. I guess risk analysis will vary widely here across federations. 
E.g. with NORDUnet/SUNET spending the equivalent of 10s of thousands of EUR 
on HSM equipment their requirements for a replacement will certainly be 
higher than my own from use of 50 EUR smarcard-in-usb-form-factor toy HSMs 
(some active in running hardware, some in secure offline storage).
>>Understood. I can think of ways of coming up with an aggregated risk value 
>>if there was a common service, but if each federation takes their own view 
>>of risk (and thus associated costs) this is more difficult - but of course 
>>not impossible.

> 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).

I can only speak for my "from the very bottom of the scale" approach, and the 
criteria were:
* No direct key access from the OS/network (d'oh), except for Portability 
(below)
* Redundancy/no SPOF (not necessarily via shared state or clustering)
* Replacability 1 (swap out defective/not behaving model with
  other of same build; requires some portability of key material)
* Replacability 2: Portability of the key material to a different
  platform altogether if needed and provided controls can be
  satisfied. (Can be handled outside the HSM with additional
  processes, of course, by not relying on the HSMs to create key
  material. "Infineon. Generating weak keys since 2012." ;))
* For server-based (not over-the-network) HSMs some PCI-card form
  factors are becoming increasingly unsuitable to high-density/blade
  computing environments, so those are probably a kind of anti-pattern
  for that reason alone.
>>Thanks - very helpful

> 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?

The UKfederation did some thinking on this, AFAIK, as part of their own 
"Federation (toolset) as a service" service.

Currently GEANT is using one or two (AFAIK) partitions of NORDUnet's HSM for 
the FaaS offering and so isn't hosting the HSM themselfs.
(Granted it doesn't host the VMs connecting to those HDMs over the network, 
either. ;))

>>Good point - I hadn't  spotted that.

> 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?

Well, more as in "a handful" very likely, e.g. to support algorithm agilty 
and provide metadata feeds with different cryptographic properties 
(signatures, hashes; canonicalization & transformation rules, maybe).

I don't think many more for identity federations, unless we're talking about 
models we have to invent yet (e.g. a federation hosting the HSM on behalf of 
its members, providing each member with remote access to a federation-hosted 
key).

Of course once you have the HSM other uses will likely emerge, DNSSEC, etc.

>>Yes to corrupt Parkinson's Law - Uses expand to fill the space available 
>>for their implementation

> Dare I mention Microsoft MSCAPI. Any takers?

Not here.

>> O.K (note that I also didn't mention Blockchain)

> 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?

Since 50 EUR smartcard-in-USB-stick kind of equipment claims temperevidence 
and some form of FIPS compliance, sure, throw that in as well. It can't be 
much worse than what I have right now. ;)

>>O.K added

> Any need to execute code securely within the boundary of the HSM?

<Shudder/>

(But then I don't really know what that mean.)

>>So for example, it may be necessary to have some trusted agents 
>>(application software ) operating within a secure zone where it cannot be 
>>tampered with. For example, mission-critical code that operates in a large 
>>system ( a large financial enterprise is a good example) may need to be 
>>employed where it is not feasible to employ trustworthy humans. A practical 
>>example would be to secure the CA signing process, where although the key 
>>is held within the HSM the signing policy (and process) is implemented on 
>>the server and can thus be subverted. I'm not sure the level of risk exists 
>>within federations for this to be a necessary use case.

> 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)

Add in "Fully usable from open source systems without any proprietary 
drivers/software" (something I should have had on my list of criteria when I 
started out) and I'll say "any/all of the above".
>> Right noted.

More realistically noone is (well, I'm not!) going to throw out a perfectly 
functioning piece of hardware and have the cost of changing systems and 
processes and documentation just because some new product popped up.
>> Very fair point and that probably helps define who the HSM or service 
>> might be targeted at.

(But then I'm wearing my clothes until they practically fall of my body and 
all computers used in my household are pre-owned and between
8 and 13 years old. We all produce enough waste every day, I don't replace 
working things with shiny new working things. And yes, my phone still has 
physical buttons and was included in the above list of
computers.)
>> Thanks Peter - I may also fall into your camp, but I did buy a new shirt 
>> recently. And sometimes change is forced upon us by non-compatibility in 
>> the case of computers and potential nudity in the case of your clothes 
>> example.

-peter

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