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

[Peter Schober <peter.schober AT univie.ac.at>]

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

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

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

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

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

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

> Dare I mention Microsoft MSCAPI. Any takers?

Not here.

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

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

<Shudder/>

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

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

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.

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

-peter