I had a call today from someone who was experiencing an issue centered around SSL. While the subject of this post has absolutely nothing to do with that call, it did make me remember another article I wrote about FIPS 140-2. I never polished it up for publication and decided that today would be a good day to bring it out from hiding. For any of you going through issues with FIPS 140-2 compliance, perhaps it will shed some light to your path.
For those of you who don’t know what FIPS 140-2 is or how it might influence your overall wellbeing, go ahead and run for your lives. It’s not something you want to have in your life as a general rule.
The below diatribe was written by me while configuring an IBM HTTP Server instance (basically Apache Server) to be FIPS 140-2 compliant. Based on my experience, I have a feeling that several of the SSL implementations in the world don’t meet FIPS when it comes to negotiated ciphers and encapsulating RSA key strength. Maybe this is going too deep, but FIPS is definitely very specific once you really start to understand it.
Introduction to FIPS 140-2
FIPS 140-2 is a rather dull document. At first glance, it appears to not reference SSL or even software design. How on earth it applies to an Apache SSL configuration is beyond me. Indeed, with sections devoted to physical security of “cryptographic modules” people might be led to think this doesn’t apply to them. This is what I thought; however, closer examination and careful reading of additional FIPS (Federal Information Processing Standard) and NIST (National Institute of Standards and Technology) publications started making the picture much clearer. Let’s start with a simple statement in FIPS 140-2, Section 1.1.
Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic module (e.g., at least one Approved algorithm or Approved security function shall be used).
We can’t even read Section 1 without being bombarded by FIPS jargon. After reading through Section 1, a few things are obvious. FIPS 140-2 offers four different security levels. Each one builds on the previous. Since this is one of the basic requirements to be FIPS 140-2 compliant, it might be worth a closer look. So where can we find information about an “approved algorithm” or an “approved security function”? Well, it appears that the term “approved algorithm” isn’t the one for which we should be looking. Believe it or not, an “approved algorithm” is a subset of the “approved security functions”. Let’s do a search on “approved security function” and see what we find. Bingo, FIPS 140-2, Section 2.1.
Approved security function: for this standard, a security function (e.g., cryptographic algorithm, cryptographic key management technique, or authentication technique) that is either
a) specified in an Approved standard,
b) adopted in an Approved standard and specified either in an appendix of the Approved standard or in a document referenced by the Approved standard, or
c) specified in the list of Approved security functions.
So we’re left with more questions. Where’s that “list of Approved security functions”? Further searching brings us to FIPS 140-2, Section 4.1.
A cryptographic module shall implement at least one Approved security function used in an Approved mode of operation. […] (Approved security functions are listed in Annex A to this standard.)
Ah, now we’re getting somewhere. Let’s take a detour from FIPS 140-2 and move into its first of four annexes. FIPS 140-2, Annex A is pretty straightforward if you understand what you’re reading. In the end, the following methods are the only approved cryptographic functions under FIPS 140-2.
- Symmetric Key: AES, TDEA, and EES
- Asymmetric Key: DSS (DSA, RSA, and ECDSA)
That’s a pretty narrow list. On top of that, only three of those are commonly tossed around: AES, TDEA (also know as Triple DES), and RSA. Let’s take a closer look at RSA and TDEA.
RSA is usage is defined in FIPS 186-2. Per that document, RSA is approved and detailed in ANSI X9.31. I don’t have any questions about RSA really (at the moment) so I’m not going to bother with an ANSI document. The fact that we’ve left the FIPS/NIST world and gone to an ANSI document at least makes me feel a little closer to reality.
TDEA is described in NIST SP800-67 (ooh, a “special publication”, this has my interest perked). Per NIST SP800-67’s forward,
With the withdrawal of the FIPS 46-3 standard:
1. Triple DES (i.e., TDEA), as specified in ANSI X9.52, Keying Options 1 and 2, is recognized as the only FIPS approved DES algorithm.
That’s nice. I’m not even sure what a keying option is, but I know that we can only use option numbers 1 and 2. That’s the government for you: restrict first, explain later. Reading on, NIST SP800-67, Section 2 states that
The DEA cryptographic engine is used by TDEA to cryptographically protect blocks of data consisting of 64 bits under the control of a 64-bit key. Subsequent processing of the protected data is accomplished using the same key as was used to protect the data. Each 64-bit key shall contain 56 bits that are randomly generated and used directly by the algorithm as key bits.
So each key is 56-bits wide. This is easily understood. Now we continue to NIST SP800-67, Section 3.2.
This recommendation specifies the following keying options for a TDEA key bundle (Key1, Key2, Key3)
1. Keying Option 1: Key1, Key2 and Key3 are independent keys (i.e., Key1 ≠ Key2 ≠ Key3 ≠ Key1);
2. Keying Option 2: K1 and K2 are independent keys (i.e., Key1 ≠ Key2), and Key3 = Key1.
Now it’s all making sense. TDEA supports three 56-bit keys. As a result, there are three configurations, or “keying options”, for the keys. According to this, the only approved TDEA modes of operation are 2TDEA (112-bits, 80 bits real security) and 3TDEA (168-bit, 112 bits real security). (Real security values are from NIST SP800-57, Section 5.6.1.) This makes it very clear (crystal in fact) that 56-bit DES encryption is not encryption in the eyes of FIPS 140-2. Speaking of FIPS 140-2, it’s about time to get back to that document.
This teaches me one important thing regarding Apache SSL configurations: I must limit the number of negotiable ciphers to this FIPS 140-2 approved list. In the end, I find I’m only going to be offering three ciphers: 3TDEA, AES-128, and AES-256. I configure my server to match these and now I’m at least partially compliant.
Further investigation of FIPS 140-2 brings us to Section 4.3.3.
Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role.
I don’t know what that means to you, but to me it means that the server on which keys reside needs to be secure. We can’t have just anyone logging into this server and compromising the keys. Wow, I didn’t know FIPS 140-2 covered server security!
Further reading in Section 4.3.3 yields more information about the breadth of FIPS 140-2.
The strength of the authentication mechanism shall conform to the following specifications:
- For each attempt to use the authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur (e.g., guessing a password or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods).
This was another “wow” moment for me. Here’s proof that FIPS 140-2 requires passwords of each operator and keystore be secure. Don’t trust my math, but I think a simple eight character password exceeds these requirements. Still, FIPS 140-2 requires password complexity? That’s a new one for me.
As far as my Apache SSL implementation goes, I’m compliant here. I just need to make sure that I don’t compromise security with bad administrative practices and I’m good to go.
Let’s read Section 4.7 of FIPS 140-2. There are several good nuggets in this one.
Cryptographic keys and CSPs encrypted using a non-Approved algorithm or proprietary algorithm or method are considered in plaintext form, within the scope of this standard.
There goes the idea of using “custom” or “in-house” encryption. Many people argue this is “more secure” since it’s not based on a method that is public knowledge. Obviously the government doesn’t fall into the classification of “many people.”
Public keys shall be protected within the cryptographic module against unauthorized modification and substitution.
Let’s keep this on in the back of our minds for later. I take this to mean that we need to protect our RSA keys in an acceptable manner (i.e. permissions, passwords, etc.).
Documentation shall specify all cryptographic keys, cryptographic key components, and CSPs employed by a cryptographic module.
You mean that FIPS 140-2 is telling me how to document my system? The answer to that rhetorical question is a resounding “YES!”
Key Exchange (or Encapsulating DES/AES Keys with RSA)
Deeper into FIPS 140-2 we proceed.
If key establishment methods are employed by a cryptographic module, only Approved key establishment methods shall be used. Approved key establishment methods are listed in Annex D to this standard.
If a key transport method is used, the cryptographic key being transported shall meet the key entry/output requirements of Section 4.7.4.
All encrypted secret and private keys, entered into or output from a cryptographic module and used in an Approved mode of operation, shall be encrypted using an Approved algorithm. Public keys may be entered into or output from a cryptographic module in plaintext form.
Documentation shall specify the key entry and output methods employed by a cryptographic module.
The common method used for “key transport” is RSA public key encryption (at least with SSL and TLS). Basically, if we’re transmitting an AES or DES key across the wire, we need to encrypt the key. FIPS 140-2 Annex D specifies that NIST SP800-56B provides insight into using Integer Factorization Cryptography (IFC…RSA fits into this) as a key establishment technique. Reading through NIST SP800-56B is pretty dry since it tells us a lot of things we already know about RSA. There is one important point in Section 6.1 that is a good argument against self-signed RSA certificates.
Public keys shall be protected from unauthorized modification. This is often accomplished by using public key certificates that have been signed by a Certification Authority (CA).
Let’s move back into FIPS 140-2 and continue reading. We’ll finish up with Section 4.7.5.
Cryptographic keys stored within a cryptographic module shall be stored either in plaintext form or encrypted form. Plaintext secret and private keys shall not be accessible from outside the cryptographic module to unauthorized operators.
Documentation shall specify the key storage methods employed by a cryptographic module.
These sections really help with my Apache SSL configuration. I know that using SSL or TLS is OK since RSA is approved for use in DES/AES key encapsulation. Furthermore, as long as my RSA private key is not open to the public I don’t have to encrypt it. I do have it encrypted using a Java keystore but I’m not sure what kind of encryption that uses (RC4 would be my guess). As long as I protect the location in which it is stored, I don’t have anything to worry about.
A Revisit to Section 4.7.3
I skipped a critical paragraph of FIPS 140-2, Section 4.7.3 earlier. I did this intentionally so we could revisit it now.
Compromising the security of the key establishment method (e.g., compromising the security of the algorithm used for key establishment) shall require at least as many operations as determining the value of the cryptographic key being transported or agreed upon.
This one is really important. This is saying that the underlying symmetric key (DES, AES) used in a secure connection (SSL, TLS) must be encrypted by a public key (RSA) of equal or greater bit strength. Unfortunately, the “bit strength” of an RSA key is not the same as its “bit length”. In other words, a 4096-bit RSA key does not provide 4096 bits of strength. So how do we know what strength a particular RSA bit length provides? NIST SP800-57, Section 5.6.1 provides the answers. Table 2 of this publication clearly illustrates the security required by an IFC method (RSA) to transport symmetric keys used by TDEA and AES. The common length of 1024 bits for RSA keys only provides 80-bits of strength. This is sufficient to protect a 2TDEA (112-bit DES) key but nothing more. 2TDEA is FIPS compliant but it is rapidly losing its credibility as secure. According to FIPS 140-2 IG, Section 7.5, page 63, 2TDEA should only be used through 2010. RSA with a 1024 bit key should not be used after 2010 either. When I check my calendar, it looks like 2010 is over in just eleven more days!
Are you using a 1024-bit RSA key? If so, it’s not FIPS 140-2 compliant regardless of the underlying cipher negotiation!
Here are the algorithms that FIPS 140-2 allows per Annex A and the RSA bit length needed to provide enough strength for encapsulation. Keep in mind the RSA length is the minimum required.
- 2TDEA (112-bit DES) – RSA key length of 1024 bits – overall security strength of 80 bits
- 3TDEA (168-bit DES) – RSA key length of 2048 bits – overall security strength of 112 bits
- AES-128 – RSA key length of 3072 bits – overall security strength of 128 bits
- AES-256 – RSA key length of 15360 bits – overall security strength of 256 bits
This section of FIPS 140-2 is critical to understand. Having AES-256 encryption is all but useless if you’re using a 1024-bit RSA certificate to secure it. The standard is clear here if you take time to read it. I’m honestly not sure that very many implementations meet these requirements.
For my Apache SSL implementation I have already decided I will be using 3TDEA, AES-128, and AES-256 ciphers. I’m working with a limitation imposed by IBM’s HTTP Server 6.0.2 of a maximum RSA key length of 4096 bits. I can relax in the knowledge that this RSA key can secure 3TDEA and AES-128 without any problem. While the key can’t protect AES-256 with sufficient strength, I can argue that is a risk imposed by the software with which I am working. Besides, 4096 bit RSA shows an end-of-life at 2030 (per FIPS 140-2 IG, Section 7.5). Hopefully IBM will have the 4096 bit limitation resolved by then.
A Note on Web Browsers
I have been unable to get Internet Explorer 6 or 7 on Windows XP to connect using AES encryption. It’s only a matter of time before TDEA is called into question as a credible encryption schema (in my opinion). FIPS 140-2 IG, Section 7.5 says 3TDEA will be good only through 2030. I’m not sure we can rest assured that this won’t change before 2030. This might be a reason for corporations to investigate alternate browsers (i.e. Firefox, Chrome) or upgrading to Vista or Windows 7 (I believe AES is supported on those operating systems).
And yes, I know of at least one good sized company that just upgraded to IE 7. And this same company is still running Windows XP on almost all workstations. Why they aren’t at least using something like Firefox or Chrome to help promote security is beyond me; but, a lot of things seem to be beyond me!
A lot of things other than FIPS 140-2. No, that one I feel I have a pretty good grasp on now. Hopefully after reading this, you do as well.