PrimeKey has now completed the process to obtain our second Common Criteria certification for the EJBCA Enterprise software. Since our first Common Criteria certification in 2012, global requirements have gone through a lot of changes. The software we have certified is EJBCA Enterprise, our enterprise certification authority software which is used worldwide to issue billions of certificates. EJBCA is also available as an open-source community software version by the name of EJBCA Community, albeit not as a Common Criteria certified version. Certifying against a Collaborative Protection Profile this time was a new learning experience with less testing by us, but more rigorous independent testing by the testing laboratory.
Common Criteria Updates
Since our last blog post about Common Criteria, things have moved on steadily. Common Criteria is evolving and updating, just as everything else. The big updates are improvements, but as usual updates can also cause confusion. In the PKI space, the biggest changes related to Common Criteria are that:
- The old CIMC protection profile is being phased out and no longer accepted by some schemes.
- Schemes are not accepting generic evaluations on a specific EAL level any longer, but requiring conformance to a specified protection profile.
- And as reported earlier, new non-EAL based (cPP) certifications are continuing to evolve.
A conclusion of the above is that if you want to certify a PKI today, the relevant Protection Profile is the “Protection Profile for Certification Authorities, v2.1”.
The reasons to certify our products have not changed much over the years:
- Public tenders, world-wide, often either requires or gives advantage to common criteria certified products.
- The digital signature law in certain countries mandates certified software.
- It helps overall trust in our products having a certified testing laboratory evaluate our products in a strict and well-defined process.
- From a marketing and branding perspective, a Common Criteria certification is beneficial – both to the PrimeKey and EJBCA brand. Performing an audit, such as eIDAS or WebTrust, may be easier with a certified product. Although the audit standards do not require product certification, some of the audit requirements can be more easily audited based on the accompanying certification documentation.
- New and improved Protection Profile and Testing
The new Protection Profile for Certification Authorities, which is used for our latest certification contains very strict, PKI specific testing. Although we have our own automated and manual test suites, having an independent evaluator perform their own uniquely designed testing is beneficial. The evaluators’ tests are based on detailed test requirements in the protection profile, and look closely into cryptographic security aspects. This gives us higher assurance that the PKI functionality works as expected, both functionality and in regards to the security aspects.
As product certifications and audits are complex topics, which not everyone (including PKI experts) can be expected to be experts in, we continue to get many questions based on misunderstandings. Some common misunderstandings are:
- A certified software is guaranteed to be secure. This is simply not so. As evidence by history, not even the most rigorously tested products are free from security issues. Software today is so complex there is no formal method to ensure there are no vulnerabilities. In addition, completely new attack vectors, and vulnerabilities in relying on components (even the underlying hardware), are discovered continuously.
- That only a certified version of a product should be used. For a complex software product, this is not the case. Common Criteria is a very long process and newer, better and more secure versions of the software are becoming available at all times. A user should not wait years for a security update to become certified before upgrading to the updated, secure version. The certified version can be seen as the trusted base, on where updates are applied.
- A certification vs an audit. A certification, such as Common Criteria or FIPS, is done on the software and you can procure a certified product (as the trusted base). An audit is performed on the deployment, and the processes of usage, of a system and has to be done by a qualified auditor on the final installed system, operated by the end user. Examples of audits related to PKI systems are ETSI eIDAS audits and WebTrust.
- A procurement certification requirement specified as “Common Criteria certified”. As mentioned above, generic Common Criteria certifications are not performed, and would not be very useful as it does not say anything about the applicability of the software in a PKI system. Certifications are performed strictly conformant to a Protection Profile. Procurement requirement should be specified with the desired protection profiles, which can be one or several, but not “or equivalent”. Procurement must be done in accordance with procurement laws of course, not limiting the market to too few vendors.
Not our only certified product
The Common Criteria certification of EJBCA is not the only certification our products go through. Our hardware security product, the PrimeKey SEE, has been certified at FIPS 140-2 Level 3. A good example of how certifications can be used on top of each other is what the certification D-Trust has done on the Web-Dienst product that needs to run on the PrimeKey SEE Platform, as specified in the D-Trust Security Target document.
Learn more about EJBCA Enterprise