Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Participants

...

Panel
titleContact dataProposers


NameOrganisation
GEANT Association
SUNET



Please provide contact details for participants involved in this activity
 
Panel
title
GN4-3 project
team


Name
Email
OrganisationRole
Submitter name & email:Brooke
Leif
P.I.

Other participants

 Scrum master
GEANT AssociationPI
SUNETPI
Michael SchmidtDFN-LRZScrum master
Branko MarovicAMRES-UoBTeam
GEANT AssociationTeam
SURFnet
... Dev...Dev...
Mentor




Please provide names and contact details for additional (external) organisations involved in this Incubator project

 
Panel
titleContact data of Parties involved
Organisation Name
Person names
Person emailRole within pilot

 

       
Stakeholders


Name

Organisation

Role 
Nicole Harris GÉANT AssociationGN4-3 Operational perspective on HSM
Stefan WinterRESTENAGN4-3 eduroam service development lead
Miroslav MilinovicSRCEGN4-3 eduroam service owner
Davide VaghettiGARRGN4-3 eduGAIN service owner
Tomasz WolniewiczPSNCGN4-3 eduGAIN servivice operations manager
Dariusz JannyPSNCGN4-3 FaaS servivice operations manager


Activity Overview

Panel
titleDescription

This project investigates the usability of recently developed open-source and affordable Cryptech HSM modules for various usecases we have in use cases that exist within T&I in services delivered via GEANT project (eduGAIN, eduROAMeduroam, eduTEAMS , and InAcademia) and generally for federation operations.

The goal of the CrypTech Cryptech project is to create an open-source hardware cryptographic engine that can be built by anyone from public hardware specifications and open-source firmware and operated without fees of any kind. The team working on the project is a loose international collective of engineers trying to improve assurance and privacy on the Internet. Several GEANT participating NRENs are principle investors and participants in this project.

The goal is to set up the Cryptech devices to allow for testing and to identify the initial use cases and the service teams who will be participating in the testing.


Panel
titlePilot goals

Please describe the goals of pilot, including activities, participants, the community(ies) that require a solution. Describe when the pilot is done and how to measure the success of it, in a SMART way.

<Enter here>

...

Goals
  • Gather the requirements for HSM usage by GEANT T&I services and the T&I community.
  • Investigate the usability of the Cryptech devices technically and functionally.
  • Discuss our findings with the community and the Cryptech project team.
  • We set up a testbed so service teams may test specific requirements against the devices. The testing itself is likely being done in a followup activity.


Panel
titleBackground information

https://cryptech.is/

Activity Details

Panel
titleTechnical details

Please describe the technical details for this pilot.

<Enter here>

Panel
titleBusiness case

What is the business case for this Incubator project? Who would be customers of this solution and what would potential business case look like?

<Enter here>

Panel
titleData protection & Privacy

How do data protection and privacy impact this Incubator project? Think about e.g. handling of personal data of users

<Enter here>

Panel
titleSustainability

When this Incubator project is completed, do you intend to continue using the solution? If yes, can you describe how you intent to sustain it? (E.g. through own staff, by using an e-Infrastructure provider, ...)

<Enter here>

Meetings

...

Date

...

Activity

...

Owner

...

January 1, 2017

...

Kickoff meeting

...

Documents

Top-down scheme of interests/work areas:

  • Service needs and adoption path - Identifying (client) service-specific requirements, scenarios and usage patterns, in terms of use of the HSM platform and its supporting cryptoservice. Could extend towards actual implementation by some services.
  • Interoperability - We want to test if and how the devices can be accessed in an interoperable way. Most likely way to achieve some level of interoperability is to stick to an API such as PKCS#11. Another possibility for service related software implementations that have a coarse internal crypto API of their own is to produce a mapping layer that would adapt to one of (finer-grained) APIs provided by the HSM platform.
  • HSM platform and its working environment:
    • Technical features - Performance levels and direct interfaces offered by the platform, including implementations of widely used specs and standards and platform-specific operational functions for import/export of cryptographic materials, access to logs, health check, disaster recovery, clear/reset, etc. A detailed list of technical criteria for evaluation (depending on the use cases and requirements) could include:
      • Performance for key generation and signing, and for asymmetric and symmetric cryptography algorithms;
      • Support for key cryptographic algorithms - e.g. RSA, DSA, ECC, 3DES, AES, SHA-1, MD5, etc.;
      • Programmability of the device (ability to execute code within the secure boundary);
      • Key storage capacity;
      • Form factor and connectivity - PCI, USB, Ethernet, etc.;
      • Audit and management capabilities;
      • Operating system and application support;
      • Remote access mechanisms;
      • Provided/supported user and admin tools;
      • Crypto API support - PKCS#11, MSCAPI, KMIP, JCA, etc,;
      • Supported/used cryptomaterial formats.

    • Operational aspects - Procedures, their practicality and suitability for the environment where the platform is deployed, physical/electromagnetic security arrangements. A detailed list of operational criteria for evaluation (depending on the use cases and requirements) could include:
      • Redundancy capability - suitability of procedures in the event of device failure;
      • Physical and logical security mechanisms;
      • Authentication mechanisms for access and/or defining the 'master secret';
      • Certifications - FIPS 140-2 (Level), Common Criteria;
      • Suitability of vendor documentation;
      • Vendor support and maintenance policy - bug fixing, patches, etc.;
      • Vendor credibility - business model, stability, etc.
      • Cost of ownership.

  • Trustworthiness of the HSM platform - How one can attest that the offered platform is secure; system integrity and hardware tamper resistance; preliminary audit/analysis/observations, supporting evidence, what is required or good to have/know, are there some recognised/possible weaknesses, open issues.


Panel
titleBusiness case
In many of the T&I services in the R&E sector, the services from GEANT included, we need to securely store sensitive data like key material. Currently it is very rarely done using HSMs, even though it is well understood such a solution is significantly more secure. Access to and cost of HSM technology is typically cited as the barriers for adoption of HSMs.
The Cryptech project offers a relatively low cost HSM solution, with seemingly similar characteristics as compared to generally available commercial offerings.


Panel
titleData protection & Privacy
This activity does not deal with personal data directly. However use of HSM technologies may in various use case improve the security of the encryption used to store and process personal data.


Panel
titleDefinition of Done (DoD)

The activity is successfully finished when:

  • A report on the requirements is delivered, and
  • A testbed is made available.


Panel
titleSustainability
The HSM devices may be use in followup Incubator activities.

Activity Results

Panel
titleResults

The work could not be concluded as Diamondkey seased operations during the evaluation period.

Resulting documents are provided below.

Meetings

Date

Activity

Owner

Minutes

February 19, 2019

Kickoff meeting


 HSM kick off.pdf
















Documents

HSM Use case and Requirements Matrix

Cryptech HSM - Service Use Cases

Attachments
(Attach any documents to this page to get them listed.)