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