HSM in NIST Cryptographic Module Validation Program?

I see that “ISRG uses HSMs meeting FIPS 140-2 Level 3 (or higher) requirements”. Has the HSM been NIST Validated, e.g. is it in https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules/Search ?

If so, what is the certificate number / vendor name so that I can record that in my compliance documentation?

Thank you for a great product - I use several LetsEncrypt certs for my personal sites and am a (personal) contributor.

1 Like

Hi @openprivacy, nice to see you here.

My impression is that the details about the Let’s Encrypt hardware infrastructure are considered confidential. @josh, is there any information that you could share about this, or perhaps about the scope of the public audits in confirming that Let’s Encrypt uses appropriate cryptographic hardware? (I don’t know what the audits do or don’t assert in this regard.)

1 Like

Our HSMs are compliant with the Baseline Requirements specifications cited by @openprivacy. We do not disclose make and model information for hardware used to operate our CA.

Our audit documents can be found here:

https://letsencrypt.org/repository/

Hi Josh (and Schoen) - thanks for answering - but I need more.

I believe the CERTS are secure, but (unfortunately) in order to be able to use your LetsEncrypt CERTS for my Federal clients or even some of my state clients, the CERTS must also be compliant. To be compliant, your HSM must be enrolled in the NIST Cryptographic Module Validation Program.

Note that this does not diminish your security. For example, several clients use Comodo certs that have NIST approved Cert ID #2263 (search for certificate number 2263 at https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules/Search).

Are you planning to add NIST validation to your already impressive suite of certificate credentials? (As you are FIPS 140-2 Level 3, you may already have it.)

So I know every entity can have different compliance requirements and different interpretations of the same rules, but we currently have 12345 :slight_smile: certificates issued from our current intermediate

https://crt.sh/?identity=%.gov&iCAID=16418

plus 138 from the old intermediate

https://crt.sh/?Identity=%.gov&iCAID=7395

for various .gov domains representing a fairly wide variety of entities (though admittedly many of them are comparatively “techie” organizations like national laboratories, NASA, NOAA, and 18F). it seems like many government agencies have been able to find interpretations under which Let’s Encrypt certificates are already appropriate for their use.

1 Like

have other CAs disclosed this information?

Its not something i think they would and an audit by an authorised should be more than enouh

Otherwise let’s encrypt might not be for you

while it’s a great service and used by man people as schoen said it’s not always suitable for all use cases.

have other CAs disclosed this information?

In response to a direct query, Comodo support wrote:

We protect our private keys currently using HSMs from Utimaco and nCipher.
More specifically, the devices are:

nCipher nShield 500e F3 PCI-Express (NC4033E-500) FIPS 140-2 Cert #2640

Utimaco CryptoServer CSe100 PCIe FIPS 140-2 Cert #2263

If you are unable to provide similar info, we may still be able to use your CERTs, or as you correctly say: "it’s not always suitable for all use cases."

Thank you.

And I see you have a Canadian audit. Do you have a US audit?

I feel a bit awkward asking all these questions, as I personally trust LetsEncrypt infrastructure fully. But I work with some agencies that want to see an audit or other proof of a statement like: “ISRG uses HSMs meeting FIPS 140-2 Level 3 (or higher) requirements.”

I think this must be a misunderstanding.

The organization that manages/maintains WebTrust (which is the audit program criteria the root programs tend to want) is, in fact, the Chartered Professional Accountants of Canada.

The audit of ISRG/Lets Encrypt however covers their infrastructure and was covered by Schellman & Company, LLC, Certified Public Accountants of Tampa, FL (a part of the US).

As far as I’m aware there is no relevant US equivalent audit standard for CAs.

Even if ISRG/Lets Encrypt were willing to directly disclose exactly which hardware they ran for their HSM, upon what would you validate that assertion? A paid invoice? Even if you got that, there’s much more to evaluate… Like whether they use it despite it being in the rack.

That’s the point of the audits. You don’t get the full detail of what the auditors examined in detail, but you do get a statement from the auditors that they evaluated pursuant to the criteria and the management’s disclosures and their own examination and, in this case, found no exceptions to note.

Only posting this because it’s in the initial version of the CPS as of May 5, 2015, as published on the Let’s Encrypt repository… There’s a reference on page 80, section 7.1.3.

Who knows if that’s what they still use?

what would you validate that assertion...?

That's what many gov agencies rely on NIST as an auditor they trust. I'm not personally sure I'd trust NIST more then (say) the Canadian WebTrust, but I'm not the one making the rules. But I believe NIST re-certifies every two years, which is something.

I believe the point @mdhardeman was making is that even if a Let’s Encrypt employee said "yes, we indeed use ", you have nothing more to go on than their word that this is in fact what’s in active use.

Yes, that was the point I was trying to make, @jared.m.

NIST’s CMVP validates cryptographic modules to FIPS 140-2’s standards.

On the low cost side, there are instances of low performance, constrained resource environments which hold current FIPS 140-2 Level 3 overall certificates in the well below $5.00 category. One such example would be NXP’s JCOP OS environment (a JavaCard runtime and library set) running on P60 series NXP smart card ICs. On the high side, you have high performance HSMs and realtime encrypting high speed proprietary network interfaces costing $10s to $100s of thousands.

What FIPS 140-2 attempts to illustrate is that there are devices which MAY be utilized to achieve certain security aims if utilized appropriately.

NIST’s CMVP certificates cover equipment and configurations thereof. It does not cover use cases. It does not cover process as pertains to field operation of the equipment and appropriateness of use case of particular instances of the equipment.

I don’t understand (or accept legitimacy of) a regulatory environment in which a written statement from the CA just claiming without evidence that they utilized HSM model #xyz with certificate number ABC would ever be accepted by anyone as proof or security of compliance of any useful form.

NIST’s CMVP is about auditing products for whether there exists a way to use them securely pursuant to the goals and standards of FIPS 140-2. Blessing an entire model of a product has (thankfully) little to do with auditing or certifying a certificate authority.

A certificate authority’s audits are designed to (theoretically) ensure that a infrastructure and process in this particular per-CA instance are in keeping with standards and conventions that allow for trust in the CA’s cryptographic assertions.

Technically, a CA could load a copy of their keys – while also just using OpenSSL on a Linux box internet connected with root password of root – into a $5.00 smart card, claim in writing “We utilize SmartcardHSM for our key management” and not even be telling a lie, as long as they’re not claiming that they exclusively use the certified product.

Or a CA might say “We have a Mfg A Model B HSM with cert #123.” Nevermind that it just sits in the rack eating power, completely unused in any material sense.

I suspect the original author and his clients’ interests would be best served by consulting the various contracting agencies’ compliance officers to ensure that whatever the needs – reasonable or not – are met.

As an aside, I have to ask… If you’re service provider to a government client, why would you ever try to use a free CA (or for that matter a free anything) in serving said client? Milk them dry, everyone else does. If you use a pay-for CA you get to resell that certificate and make money on markup.

Just a (cynical) thought.

1 Like

Good points all, until the last.

Yes, everyone else does. But my company is working to transform government – and transform government contracting – by providing quality FLOSS solutions to agencies (Education, Health, etc.) that are providing useful services to under-served communities. And we often find ourselves in fixed price contracts where additional cost directly affects our bottom line. In this case, standard certs would run multiple thousand dollars and, well, if we can connect them to solutions like LetsEncrypt, I believe that would be … transformative.

Oh, and I have been in contact with the compliance officers (aka Authorizing Officials). Originally, they demanded NIST CVMP-registered CAs. This has been a great conversation - thanks all! - as now that those certs are up for renewal I have additional arguments with which to educate the AOs to see that LetsEncrypt’s claim to FIPS 140-2 is as good as anyone else’s – if not better.

2 Likes

this is generally why you don’t reveal some things

https://www.cvedetails.com/vulnerability-list/vendor_id-665/Ncipher.html

https://www.cvedetails.com/vulnerability-list/vendor_id-5819/Utimaco-Safeware.html

remembering these are public disclosures

@ahaw021 point taken, though security by obscurity is not my favorite tack. Openness and transparency foster more secure systems, IMO.

1 Like

You may find this quotation from The HTTPS-Only Standard - Certificates useful:

More specifically, if you are trying to establish to others in your agency that Let's Encrypt's HSMs have been validated, I would refer them to the Baseline Requirements, section 6.2.7, where we state:

You can rely on that statement because we are annually audited for compliance with the Baseline Requirements; you can see the audits at Policy and Legal Repository - Let's Encrypt.

You may also be interested in the amendments to the Subscriber Agreement for government use: https://letsencrypt.org/documents/LE-USG-SA-Amendment-Sept-22-2015.pdf and https://letsencrypt.org/documents/LE-US-State-Local-SA-Amendment-Dec-28-2016.pdf.

If you have any trouble convincing your agency, I'd recommend getting in touch with 18F, which has done a great job in the past explaining why various types of commercial and non-profit public CAs are suitable for government use.

2 Likes

Thank you for these links which are very helpful.

We’ve made the decision to pursue the use of LetsEncrypt certificates for our federal client. To manage additional risk of short-lived CERTs, we’ll be setting up a monitor that will raise an alarm should a ticket not get properly renewed on time. And if such an alarm went off, I’d look first to see if some new SELinux policy was preventing delivery.

I wonder if there are others here with experience installing on RHEL7 w/ SELinux in full enforcing mode. The install instructions make no mention of SELinux, so perhaps it just works, but in my experience that’s not always the case.

I haven’t seen anyone discuss use of Certbot under SELinux. If you wind up needing any workarounds, please post here or file a documentation PR so others can benefit from your work! Thanks,

Jacob