Perhaps never a true guarantee, but level 4 HSMs are still impressive.
> The 4769 HSM has been verified to meet the FIPS 140-2 Level 4 requirements by protecting against attacks that include penetration of the secure module, side-channel attacks, and environmental failure protection (power or temperature manipulation). From the time of manufacture, the hardware is fully self-protecting. If tamper sensors detect a possible attack, all critical keys and other sensitive data are immediately destroyed and the HSM is rendered permanently inoperable. Note therefore that the 4769 HSM must be maintained at all times within the temperature, humidity, and barometric pressure ranges specified.
Reminds me of a Thales rack mount HSM the former security architect of CVS Caremark told me they deployed back in the 2000s. There were two of them in a dataceter used for a their transaction processing. One day, someone accidentally bumped into the rack where both HSMs were mounted, and they physically self-destructed, causing a major incident.
I did some work at a large saas company where HSM as a big part of what we did. In the early days, we paid for full HSMs that we managed and eventually had to make a decision on whether or not we would used managed HSM and HSM-like services like KMS across various cloud providers.
We did an analysis across all the HSM hardware vendors and found, unsurprisingly in hindsight, that all of these hardware vendors had all the same awful security practices as every other enterprise hardware vendor, and each had vulnerabilities that leaked private key material.
The conclusion was that cloud providers fronting managed HSM had more to lose than the hardware vendors did, and would be more likely to patch and address these kinds of issues.
What surprised me was my own reaction, I thought for sure managing our own HSM hardware had to be a better guarantee over the key material, but like many things, it turned out to be unscalable security theater.
If there were two HSMs then probably not. The reason why you buy two is to clone one into the other so that if one fails you can use the other. And then you hope and pray that the first one never, ever fails because the chances of successfully switching over to the second one and continuing operations as before are... slim.
For the higher levels, definitely. But even for just "we need FIPS" (which is always level 1) it's at least some form of guarantee in that anyone who gets it has proven that they're desperate enough for government contracts that they're willing to set fire to several hundred thousand dollars to prove it. So it's a guarantee, just not necessarily the one intended.
Huh, I don't know about the world of HSMs or crypto and their audits, but in FedRAMP SaaS, you absolutely have to run everything with FIPS mode enabled, there are strong guarantees that need to be in place and audited.
FedRAMP actually has a bunch of workarounds for the problems of FIPS.
In the "FedRAMP Policy for Cryptographic Module Selection and Use" (https://www.fedramp.gov/resources/documents/FedRAMP_Policy_f...), there are a ton of gems that make it clear that the FedRAMP folks are fed up with the CMVP process backlog. The most explicit is:
"FRR9: CSPs shall determine if updating to a newer version of the software, whether or not its cryptographic modules are FIPS validated, would eliminate the vulnerabilities; if it would, CSPs shall promptly update if that is feasible."
In layman’s terms that basically says if there’s a 0-day, patch first and we’ll worry about validation later.
You could say that’s “an issue” with literally every software package that has a support contract on earth. I can’t count how many times in my career we had to apply a patch release that wasn’t “officially ga” because of a zero day. That’s common sense, not a FIPS issue.
If our need to update fips certified packages out paces the ability to certify packages, that is absolutely a problem with the design of FIPs certifications.
So your choice inevitably boils down to running some ancient vulnerability-riddled version that's FIPS certified or running a recent less vulnerability-riddled version that's not certified. Most orgs that I've worked with keep running the vulnerable version because they have to be able to check the box that says "FIPS certified".
In reality FedRAMP has multiple variations, low, moderate, high, gives enough wiggle room to companies on what they can do when. Other good thing about government is that its quite flexible when needed. There is always exists a path to override a regulation if required.
If the requirement causes a massive security hole, the lawyers will probably tell you that knowingly allowing a security hole from a liability perspective is worse than turning off something an audit will flag.
Even on fedramp high, it’s possible to just be mistaken about configurations and still pass. I have been in the situation where I’m the guy answering all sorts of questions to the best of my ability to get the certification, then later discovered some of the claims made by developers were just not true and we had been out of compliance on a fedramp high datacenter for months. On accident.
I don't know about FedRAMP specifically, but I have gone through several procurements for federal agencies on the vendor side, and have never had any issues getting a FIPS waiver approved.
> That lag creates a perverse choice every vendor of validated modules eventually faces: ship the security fix now and fall off the validated list for a year or more, or keep shipping the validated build with the known flaw. Customers whose contracts require an active certificate are, in effect, paying the vendor to choose the second option.
That's what the blog post says about why/when FIPS is turned off, although I'm not sure I completely agree with this take. All forms of compliance in all industries (not just IT) is like this. Otherwise we get a lot of cowboy solutions.
This is why compliance does not operate in a silo. There's the baseline (when FIPS is on) and then there's the real world configuration that the business must carefully accept along with its own risks. This is why you have your own employees auditing and collaborating with everyone else involved in the decisions. That can often include the client wanting your services that depend on the HSMs. I'm not understanding what all the frustration is about unless some people have just never left their silo.
If your client is the government, then of course they're going to be very strict about FIPS. We're all at least in agreement that FIPS sucks because it moves at a glacial pace. There's a reason the phrase: "good enough for government work" means mediocre.
In my experience this is the core issue with security. It has to be a continuous process in reality but its hard to justify the cost and resource allocation. For this reason it ends up being a point in time function leaving gaps over the life cycle of the product.
The practical benefit of FIPS 140 is less that your crypto is better and more that your systems will fail to establish connections with anything not using FIPS mode, thus reducing your threat exposure. A silver lining to the overall unfortunate situation that is the FIPS CMVP.
> The practical benefit of FIPS 140 is less that your crypto is better and more that your systems will fail to establish connections with anything not using FIPS mode, thus reducing your threat exposure.
No, I don't think so.
If I'm running, say, a TLS listener (an HTTPS web server), there is no way for you to tell if I'm using a FIPS-validated implementation of the algorithms or not. I can be using a cipher suite that is allowed by FIPS, but that doesn't mean my implementation is FIPS-validated. It's not like there's a "FIPS validated and FIPS mode enabled" flag added to the TLS spec, and even if there was, there'd be nothing stopping me from setting it to true even when using a non-validated implementation.
Every customer wants FIPS 140-3 until the realize the performance hit. Then suddenly they don’t remember why they wanted it. Datasheet engineering FTW.
Perhaps never a true guarantee, but level 4 HSMs are still impressive.
> The 4769 HSM has been verified to meet the FIPS 140-2 Level 4 requirements by protecting against attacks that include penetration of the secure module, side-channel attacks, and environmental failure protection (power or temperature manipulation). From the time of manufacture, the hardware is fully self-protecting. If tamper sensors detect a possible attack, all critical keys and other sensitive data are immediately destroyed and the HSM is rendered permanently inoperable. Note therefore that the 4769 HSM must be maintained at all times within the temperature, humidity, and barometric pressure ranges specified.
https://public.dhe.ibm.com/security/cryptocards/pciecc4/docs...
Reminds me of a Thales rack mount HSM the former security architect of CVS Caremark told me they deployed back in the 2000s. There were two of them in a dataceter used for a their transaction processing. One day, someone accidentally bumped into the rack where both HSMs were mounted, and they physically self-destructed, causing a major incident.
I did some work at a large saas company where HSM as a big part of what we did. In the early days, we paid for full HSMs that we managed and eventually had to make a decision on whether or not we would used managed HSM and HSM-like services like KMS across various cloud providers.
We did an analysis across all the HSM hardware vendors and found, unsurprisingly in hindsight, that all of these hardware vendors had all the same awful security practices as every other enterprise hardware vendor, and each had vulnerabilities that leaked private key material.
The conclusion was that cloud providers fronting managed HSM had more to lose than the hardware vendors did, and would be more likely to patch and address these kinds of issues.
What surprised me was my own reaction, I thought for sure managing our own HSM hardware had to be a better guarantee over the key material, but like many things, it turned out to be unscalable security theater.
One hopes that there were recovery keys or equivalent in a fireproof safe offsite somewhere.
If there were two HSMs then probably not. The reason why you buy two is to clone one into the other so that if one fails you can use the other. And then you hope and pray that the first one never, ever fails because the chances of successfully switching over to the second one and continuing operations as before are... slim.
For the higher levels, definitely. But even for just "we need FIPS" (which is always level 1) it's at least some form of guarantee in that anyone who gets it has proven that they're desperate enough for government contracts that they're willing to set fire to several hundred thousand dollars to prove it. So it's a guarantee, just not necessarily the one intended.
Huh, I don't know about the world of HSMs or crypto and their audits, but in FedRAMP SaaS, you absolutely have to run everything with FIPS mode enabled, there are strong guarantees that need to be in place and audited.
FedRAMP actually has a bunch of workarounds for the problems of FIPS.
In the "FedRAMP Policy for Cryptographic Module Selection and Use" (https://www.fedramp.gov/resources/documents/FedRAMP_Policy_f...), there are a ton of gems that make it clear that the FedRAMP folks are fed up with the CMVP process backlog. The most explicit is:
"FRR9: CSPs shall determine if updating to a newer version of the software, whether or not its cryptographic modules are FIPS validated, would eliminate the vulnerabilities; if it would, CSPs shall promptly update if that is feasible."
How is that “a problem with FIPS?”
In layman’s terms that basically says if there’s a 0-day, patch first and we’ll worry about validation later.
You could say that’s “an issue” with literally every software package that has a support contract on earth. I can’t count how many times in my career we had to apply a patch release that wasn’t “officially ga” because of a zero day. That’s common sense, not a FIPS issue.
If our need to update fips certified packages out paces the ability to certify packages, that is absolutely a problem with the design of FIPs certifications.
+1, been all the way to fed ramp high and this is a huge part of the security theater that is fedramp.
The second best part is either getting really good at patching every single thing, or playing the POA&M game.
So your choice inevitably boils down to running some ancient vulnerability-riddled version that's FIPS certified or running a recent less vulnerability-riddled version that's not certified. Most orgs that I've worked with keep running the vulnerable version because they have to be able to check the box that says "FIPS certified".
In reality FedRAMP has multiple variations, low, moderate, high, gives enough wiggle room to companies on what they can do when. Other good thing about government is that its quite flexible when needed. There is always exists a path to override a regulation if required.
If the requirement causes a massive security hole, the lawyers will probably tell you that knowingly allowing a security hole from a liability perspective is worse than turning off something an audit will flag.
Even on fedramp high, it’s possible to just be mistaken about configurations and still pass. I have been in the situation where I’m the guy answering all sorts of questions to the best of my ability to get the certification, then later discovered some of the claims made by developers were just not true and we had been out of compliance on a fedramp high datacenter for months. On accident.
I don't know about FedRAMP specifically, but I have gone through several procurements for federal agencies on the vendor side, and have never had any issues getting a FIPS waiver approved.
> That lag creates a perverse choice every vendor of validated modules eventually faces: ship the security fix now and fall off the validated list for a year or more, or keep shipping the validated build with the known flaw. Customers whose contracts require an active certificate are, in effect, paying the vendor to choose the second option.
That's what the blog post says about why/when FIPS is turned off, although I'm not sure I completely agree with this take. All forms of compliance in all industries (not just IT) is like this. Otherwise we get a lot of cowboy solutions.
This is why compliance does not operate in a silo. There's the baseline (when FIPS is on) and then there's the real world configuration that the business must carefully accept along with its own risks. This is why you have your own employees auditing and collaborating with everyone else involved in the decisions. That can often include the client wanting your services that depend on the HSMs. I'm not understanding what all the frustration is about unless some people have just never left their silo.
If your client is the government, then of course they're going to be very strict about FIPS. We're all at least in agreement that FIPS sucks because it moves at a glacial pace. There's a reason the phrase: "good enough for government work" means mediocre.
> Track the lifecycle, not the purchase.
In my experience this is the core issue with security. It has to be a continuous process in reality but its hard to justify the cost and resource allocation. For this reason it ends up being a point in time function leaving gaps over the life cycle of the product.
The practical benefit of FIPS 140 is less that your crypto is better and more that your systems will fail to establish connections with anything not using FIPS mode, thus reducing your threat exposure. A silver lining to the overall unfortunate situation that is the FIPS CMVP.
> The practical benefit of FIPS 140 is less that your crypto is better and more that your systems will fail to establish connections with anything not using FIPS mode, thus reducing your threat exposure.
No, I don't think so.
If I'm running, say, a TLS listener (an HTTPS web server), there is no way for you to tell if I'm using a FIPS-validated implementation of the algorithms or not. I can be using a cipher suite that is allowed by FIPS, but that doesn't mean my implementation is FIPS-validated. It's not like there's a "FIPS validated and FIPS mode enabled" flag added to the TLS spec, and even if there was, there'd be nothing stopping me from setting it to true even when using a non-validated implementation.
There’s no automatic enforcement across most systems though. You can use a Thales HSM that’s configured in FIPS mode just fine from non-FIPS software.
Every customer wants FIPS 140-3 until the realize the performance hit. Then suddenly they don’t remember why they wanted it. Datasheet engineering FTW.
Why does the tone have to be ragebait? This is just a basic overview of what compliance looks like.
At this point, I'd rather be waterboarded than do any more compliance. Especially in this heat.
because for most use cases FIPS-140 have been waste of time for everyone involved
Presumably the prompt focused on the aspect described in the title, and the LLM obliged.
Government crypto governance seems to be written by people who think aerospace engineering is the epitome of diligence.
My friends in Christ, a aerodynamic object need only contend with 7 degrees of freedom, and occasional take-offs and landings.
[dead]