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 and usage - 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.
- 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;
- 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, KMIP, etc.
- 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; preliminary audit/analysis/observations, supporting evidence, what is required or good to have/know, are there some recognised/possible weaknesses, open issues.
|
