You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Project overview

Contact data

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

Contact data of Parties involved

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

Organisation Name
Person names
Person emailRole within pilot

 

 
 
  
 
  
 
Description

This project investigates the usability of recently developed Cryptech HSM modules for various usecases we have in T&I in eduGAIN, eduroam, eduTEAMS, InAcademia and generally for federation operations.

The goal of the 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.

In this phase we set up the devices to allow for testing and we collect the initial usecase we want to test and the people who will be testing.


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

Background information

Project Details

Technical details

Please describe the technical details for this pilot.

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/usage layer - Access methods and interfaces to be used by the client services with mapping/path towards the fulfillment of service requirements; this layer allows or at least facilitates substitution of underlying solutions, if/when needed.
  • HSM platform and its working environment (this could be split in two sub-items)
    • Technical features, performance levels and direct interfaces offered by the platform, including the implementations of widely used specs and standards (such as PKCS#11 or KMIP) and platform specific operational functions like import/export of cryptographic materials, access to logs, health check, clear/reset. 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;
      • Key storage capacity;
      • Programmability of the device (ability to execute code within the secure boundary);
      • Support for key cryptographic algorithms - e.g. RSA, DSA, ECC, 3DES, AES, SHA-1, MD5 etc.;
      • Form factor and connectivity - PCI, USB, Ethernet etc.;
      • Audit and management capabilities;
      • Operating system and application support;
      • Crypto API support - PKCS#11, MSCAPI etc.

    • Associated operational procedures, their practicality and suitability for the environment where the platform is deployed, physical/electromagnetic security arrangement. 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; preliminary audit/analysis/observations, supporting evidence, what is required or good to have/know, are there some recognised/possible weaknesses, open issues.
Business 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>


Data protection & Privacy

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

<Enter here>


Sustainability

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

Minutes

February 19, 2019

Kickoff meeting

  
    
    
    
    

Documents

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



  • No labels