nCipher Security Response to SSTIC HSM Security Vulnerability

Dear customers and partners

nCipher Security response to: Everybody be cool, this is a robbery!

Security researchers from Ledger recently reported exploiting a hardware security module (HSM) attacked via the PKCS#11 interface. The presentation entitled ‘Everybody be cool, this is a robbery!‘ presented on June 5 at Symposium sur la sécurité des technologies de l’information et des communications (SSTIC) 2019 in Paris highlighted a number of security related issues that could be combined to perform a key extraction attack on a HSM. Although Thales/Gemalto has disclosed working with Ledger and remediated the reported issues on its vulnerable HSM products, some customers are understandably concerned that the attacks reported are generic and do not target a specific device.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Based on our understanding of the presentation, nCipher Security has carried out investigations and determined that its products are not vulnerable to the attacks described for the following reasons:

• The nCipher nShield HSM only permits loading of cryptographically signed binaries and verifies signatures on loading.
• The firmware signature verification keys, loaded during the production process, are solely owned by nCipher and protected in offline HSM systems.
• Firmware upgrades are cryptographically secure and do not allow roll back to earlier versions with reported vulnerabilities.
• User loaded code can only execute within our patented secure execution environment, CodeSafe, that runs in isolation from the HSM core and kernel environment.
• Within CodeSafe it is not possible to execute user code on the HSM with root privileges or gain shell access in this environment. Debug facilities are also not available.
• We do not implement the Milenage algorithm that was shown to have multiple implementation flaws.
• Memory-safety issues are limited to the process hosting the PKCS#11 library. Our PKCS#11 library runs entirely on the host and translates API calls into nCore application programming interface (API) commands, sent via a serialized (marshalled) interface to the HSM. Extensive checking is performed during unmarshalling of commands.
• We do not implement a native PKCS#11 interface. nCore commands and access control list (ACL) policies are used to filter out weak mechanisms that allow for insecure and unsafe operations on keys.

As part of Common Criteria EAL4+ evaluation, the firmware module undergoes external vulnerability testing, review of our secure development lifecycle, development environment and production processes.

In summary, the attacks described by the researchers above are prevented on nCipher products by following a defence in depth approach that includes only permitting trusted firmware updates on our HSM. User loaded payloads are not permitted to execute with elevated privileges and remote attacks are prevented by validating inputs and by a secure implementation of the interface stack.

The above activities demonstrate a mature security development lifecycle that mandates best practices including threat modelling, secure design, static and dynamic analysis, dedicated security code reviews, penetration testing, flaw remediation and vulnerability response, alongside operational and procedural controls that assure entire supply chain for the product.

In addition to following best practices, nCipher places great emphasis on developing security-aware development teams and has a dedicated Security Office that puts product security first and foremost.

Should you still have any questions or concerns please contact your account representative or local technical support team.

Dr. Pali Surdhar
Chief Security Officer, nCipher Security