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 - Access methods and interfaces to be used by the client services with mapping/path towards the fulfilment of service requirements; this layer allows or at least facilitates substitution of underlying solutions (if/when needed) thorough some form of hardware and cryptographic algorithms abstraction, which, depending on service needs, may include consistent methods of remote access, front-end GUIs or applications, or wrapper APIs. Probably the most 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, while the the additional features and human-handled procedures would be handled in a custom and application specific manner. 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.

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

Resulting documents are provided below.