<- Back to the blog

PKCS#11 Compliance Criteria

Graham Steel
November 5, 2014

Updated March 2018

We originally published our compliance criteria for PKCS#11v2.20 back in 2014. We recently completed an update for v2.40, which contains new criteria for the extra attributes added in the new version, as well as revised references that take you directly to the right section of the HTML document of PKCS#11v2.40. Since we started applying these criteria to commercially available PKCS#11 devices using our Analyzer, we have found multiple vulnerabilities and non-compliances in several major manufacturer's products, all of which had FIPS/CC certifications. As a result, some of our customers have changed suppliers, and some have changed the strategy on major projects. To try Analyzer on your HSM installation just get in touch.  We've mentioned before that the PKCS#11 crypto token API standard doesn't come with a set of compliance criteria. However, the 407 page standard is full of vital implementation notes that affect not just interoperability and compatibility, but robustness and security, which is why we built a compliance testing tool.

Estimating Criticality

We have 118 compliance criteria in our initial list for PKCS#11v2.20, all of which come with a direct reference to the section and page in the standard where the compliance requirement comes from.Of these 118 conditions, 16 are rated "High" criticality, 53 "Medium" and 49 "Low". What do these ratings mean? Broadly speaking, if we were testing your P11 implementation, this is the order that we would recommend you prioritize fixes. In more detail, High means that there is a "direct" attack if the device is not compliant, Medium means that an attack is plausible if the application is using the interface in a particular way, while "Low" means the issue seems to be one of compatibility or interoperability.Most cases are clearly in one category or another, but some are not so clear. We may well update the list over time. But it's important to have a starting point. Using the compliance tester, we have already unearthed a serious issue in a major manufacturer's HSM. They're working on a patch - more about that in a future post.In the meantime, find out more about PKCS#11 security in our whitepaper.

Further Reading

At last, Secure HSMs in the Cloud

Sam Ross-Gower

Exciting new research from Cryptosense Chief Scientist Riccardo Focardi provides a simple and proven method to remove the risk of API-level attacks and enable widespread adoption of cloud HSMs. 

READ ARTICLE ->

Understanding Cryptography Jargon

Jarred McGinnis

Or ‘Wait, what does SCEP stand for again?’ Cryptography is the study of secure communication, but you would be forgiven if you thought it was a mathematician's hobby of creating unpronounceable acronyms. HSTS, really? What's wrong with something like Radar or Crispr? In this article we’ll go through some of the key terms and acronyms that pop up when working in the cryptography field.

READ ARTICLE ->

What is Cryptography Lifecycle Management and Why do I need it?

Sam Ross-Gower

Cryptography is an essential enabling technology for modern business: without it we would not be able to protect our sensitive data or carry out authentication. When perfectly implemented and maintained, cryptography provides security we can rely on. However, detailed errors in its usage can lead to total loss of protection, and our increasing reliance on cryptography means that these mistakes now carry significant financial and reputational risks.

READ ARTICLE ->

When Certificates Attack: Shadow Certificates

Jarred McGinnis

Shadow certificates are more likely than you think. It is as if the nails and screws used to build a house end up being what makes the house fall down. Briefly, shadow certificates refer to digital certificates that have been introduced by employees that the DevOps or SecOps teams are unaware of.

READ ARTICLE ->