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 layer - Access methods and interfaces to be used by the client services with mapping/path towards the fulfillment fulfilment 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 - 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 for import/export of cryptographic materials, access to logs, health check, 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.
- Associated operational proceduresOperational aspects - Procedures, their practicality and suitability for the environment where the platform is deployed, physical/electromagnetic security arrangementarrangements. 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.
|
