Uniplus Consultants

The Top PKI-Specific Criteria When Selecting HSM Solutions.

The selection criteria for the HSM within the context of PKI implementations, can be broadly grouped into the following categories: Operational Quality, Scalability, Functionality and Vendor Health.  A description of the selection criteria follows:

Operational Quality: 

Resiliency & reliability: The large capacity HSM customers will expect months of continuous operations and the ability to deploy resilient configurations of HSM(s) where a single HSM failure does not result in an application failure. 

Product lifecycle: Selected HSM(s) should have a product lifecycle compatible with your organization’ needs with the actual lifecycle dependent on the cost of acquiring, distributing and upgrading the customer premises technology.

Durability: Customers should be able to subject HSM to continuous duty cycle for extended periods each day.

Operational support: Vendors should be able to provide service level agreements in line with your 24x7 support model. The large capacity HSM(s) should provide the necessary audit and trace information to enable effective helpdesk & operational support procedures.

Scalability:

Performance: A small capacity HSM supporting 0.25 TPS and a large capacity HSM supporting 40+ TPS. 

Capacity: The large capacity HSM needs to support storage of multiple PKI identities.

Scalable footprint: The large capacity HSM(s) should be able to scale both vertically and horizontally

Functionality:

PKI support: HSM must offer the following security features - 2048-bit (the expected key length size necessary for proper security of PKI) key pair generation, private key storage, and private cryptographic operations. The HSM must be compatible with the Public-Key Cryptography Standards #11 (PKCS#11) standard and certified for usage with Entrust PKI software.

Security level: Vendors that verify their security implementations by subjecting them to government and industry driven security validation programs are preferred. Compatibility with FIPS level-2 or higher is required.

OS certification: Vendors should be capable of certifying their products on your supported Operating Systems. 

Connectivity: Large capacity HSM(s) should be LAN connected and multi-server shareable. The small capacity HSM(s) should allow for USB connectivity.   

Vendor Health & Focus:

Vendor size: Large publicly held vendors are preferred as they would have substantial resources to support our needs and it is easier to monitor their financial health. 

Existing relationship: Vendors with existing relationship are preferred as the organization already has worked out commercial and legal contract terms and conditions with them and has experience working with them.

Mission-critical deployments: Vendors with mission critical customer deployments are preferred.

Status as a ‘top account’: Any new commercial technology needs to be supported by a strong vendor relationship.  Being a top account gives us sufficient leverage to ensure timely resolution of problems.

What are the PKI specific benefits of using Hardware Security Modules (HSM)?

A hardware security module (HSM) is a device that provides a secure and dedicated environment for performing cryptographic operations thus reducing the likelihood of secret key material being compromised as well as improving cryptographic processing performance. Here we try to address the secret key protection aspect of using HSMs.

Confidential electronic keys, such as those used by the PKI private key are critical to application security.  If their confidentiality is compromised, a fraudulent message purporting to be from a legitimate user can be sent to another user.  The receiver of such a message may not be able to detect this fraud, because the signature appended to the message would appear to be valid.  Accordingly, it is critical that confidential keys be adequately protected.

The first step to protecting confidential keys is to have good controls on access to environments where the keys are created and where they reside.  For additional protection, one approach is to employ various software techniques to secure the keys on the host computer where the keys reside, and where they are used for cryptographic operations.  Typically, the keys are encrypted on disk, and memory protection measures are employed to protect the key during cryptographic operations.  Additionally, encryption and other measures can be used to protect keys when they need to be transported to another host computer.

Although software-based approaches can offer significant additional protection, an even greater level of security is possible by employing hardware devices, such as HSMs, that are specifically designed to protect confidential electronic keys.  Typically, these devices are used to safe-store keys.  The keys are created in these devices and cryptographic operations performed with these keys can be carried out within these devices, thus making sure that the keys never need to leave the hardware.  Various physical and logical security features of these devices further minimize the risk of key compromise. 

If a user’s private key were only protected by a software-based approach, a successful attack could occur if there were co-ordinated security breaches at two customer institutions or two branches of an institution.  Such an attack would be relatively difficult but not impossible. Use of an HSM instead of software-based protection would likely make this attack more difficult since it is harder to steal HSM private key information without being detected.

How to make sense of your hardware-assisted cryptographic needs.

A hardware security module (HSM) is a device that provides a secure and dedicated environment for performing cryptographic operations thus reducing the likelihood of secret key material being compromised as well as improving cryptographic processing performance.

Cryptographic devices can be divided in two categories: smart cards/tokens and Box HSM(s). Smart cards/tokens are slow but are cost-effective and easy to administer. Box HSM(s) offer performance and security benefits, but are relatively more expensive and complex to administer than smart cards.

Both Box HSM(s) and smart cards offer improved security over software implementations but choosing one or the other will require customers to balance security, cost, performance, and administrative overhead.

nCipher and SafeNet are the market leaders in the Box HSM segment due to their incumbent status, size, and technical fit. Other Box HSM vendors are either small private companies, or niche players in this market like IBM.

In the smart card space there are vendors, like Axalto, Gemplus, Oberthur, etc., that produce smart cards for varied applications (like mobile telephony, credit-cards, national identity cards, etc) and niche vendors, like SafeNet, that specialize in cards and tokens for user identification. Vendors generally use standard chips from manufacturers like Philips, Infineon, STMicroelectronics, etc, so product differentiation is hard to sustain.

FIPS 140 certification is widely used for selecting HSM products, since FIPS 140 is an industry standard for assessing the security of HSMs.

How to translate regulatory compliance into plain old IT security practices

At the heart of most regulations (SOX, GLBA, HIPAA, PCI, etc) is the intention of protecting the confidentiality, integrity, and availability of information that impacts a corporation's stakeholders. These laws can be distilled down to their essential goals:

• Establish and implement controls
• Maintain, protect, and assess compliance issues
• Identify and remediate vulnerabilities and deviations
• Provide reporting that can prove your organization's compliance

Let's explore the available best practices that can help IT professionals who have been charged by the CEO, CFO and Audit Committee with making the comany compliant. These best practices can be divided into one of two orientations: process or technology.

• CobiT, Process Control and Managment, a process standard for PCAOB
• COSO, Process Enterprise Risk Managent, Used by PCAOB as guide for SOX
• ITIL, IT Service Process, Detailed process-oriented approach to IT services managment
• ISO 17799, Technology, Provides guidance on creating an IT security Program
• NIST SP 800 Series, Detailed IT security implementations adoped by FISMA and FIPS

If your enterprise is embroiled in SOX compliance issues, the best approach would be to use a combination of CobiT and ISO 17799. If your organization is a financial services enterprise trying to meet the requirements of BSA/AML, USA PATRIOT Act, and GLBA, a best approach would be to use ISO 17799 since the FFIEC audit criteria align most closely with it. If your company is working to comply with HIPAA, a blended approach would be the best, with elements of ISO 17799 and the direct requirements of the HIPAA Final Rule from the U.S. Office of Health and Human Services.

If you're not an expert yourself, it isn't easy to figure out which best practice is right for you. That's where IT Security and Compliance specialists can help, by providing you with the least costly method for compliance. The cost reductions come from a deep understanding of all components of all best practices and how they match the requirements of the law or regulation you must comply with.

What is the Sarbanes-Oxley Act?

Among the most critical laws impacting public corporations passed in years is the Sarbanes-Oxley Act of 2002 — referred to as SOA throughout this paper — enacted on July 30, 2002 and signed into law by President George  W. Bush. SOA was created by Congress in the wake of the major corporate accounting scandals that occurred in 2001 and 2002, notably Enron & Tyco, in an effort to restore investor confidence and to improve corporate governance and financial ransparency.

There are many elements to SOA, including sections that were intended to enhance and tighten financial disclosures, improve “whistle-blower” processes and the well-known requirement for the corporation’s financial statements to be certified by the CEO and CFO. Very importantly, SOA also creates and expands on existing criminal penalties for misrepresentations. No longer will “I didn’t know” provide any legal protection for management.