Versions Compared

Key

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

...

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

...