Sven, Again, thanks for taking the time to provide such a great answer. After I emailed I did more research and looking over some of the other certifications I would tend to agree with your points regarding the pointless nature of the FIPS certification. As an aside, your email address is from Germany, is the government there hung up on pointless certifications like these? It would be so nice to see a move toward a more open approach where standards and specifications for cryptographic soundness are developed and then employed across the board, as opposed to the vague certifications that leave everything open for debate/discussion and invite many organizations to design and implement their own solutions to the problem. Thanks again, Justin -----Original Message----- From: dm-crypt-bounces@xxxxxxxx [mailto:dm-crypt-bounces@xxxxxxxx] On Behalf Of Sven Eschenberg Sent: Wednesday, February 29, 2012 5:41 PM To: dm-crypt@xxxxxxxx Subject: Re: EXTERNAL: Re: LUKS encryption standards Hi Justin, If RHEL gets a FIPS Certification, the certificate will explicitly name the mode of operation etc. If you look at some of the certificates/validations (There is one for an F-Prot Kernel Module or something like that which I looked at) there will be listed, which hash methods/functions etc. took place in the certification process and which didn't. >From a plain technical POV (I only briefly looked at the FIPS-140 docs) you'd have to make sure to use SHA as hashing, and AES (or possibly 3DES if I saw it right) as cipher. Most of the docs on allowed functions refer to other resources, so there would be some reading up to clarify this. I could not find (as example) any indication on the desired mode of operation that needs to be chosen, maybe FIPS really leaves this question open. What I am trying to say: dm-crypt (using the provided modules) can provide the necessary cipher, hashing, HMAC functions that are acceptable. Same holds probably true for Mode of Operation. Oh and the RNG source can be chosen too, of course, thus it is easy to use any acceptable (P)RNG from FIPS-140 --- Now from a security point of view: FIPS is not a standard, it is a certification and revenue program. Basicly certain ciphers etc. need to be supported (and none else when if FIPS mode) then some tests are conducted and the module gets certified ... and what exactly does this prove? The certification takes place at a certain point in time, everything after that point in time is not covered, from what I read. Since it's the very nature of OSS, that everyone can change and thus tamper it, it is hard to get certified, then again, certified products currently listed can be easily tampered with (esp. at the manufacturer) and they would still be FIPS certified, and the whole (specific) certification process (for a certain module) and the product's (tech.) documenatation is not readily available for peer review... I could not find any signatures in the certificate/validation document for the module (in question) to check that no one tampered with it, since it was 'certified'. That's just one of several scenarios that seem to be neglected by the whole procedure. Just a sidenote, why you might be lucky with a commercial distribution like RHEL getting certified and why it is (IMHO) pointless afterall. Regards -Sven On Wed, February 29, 2012 20:51, Bennett, Justin wrote: > Sven, > > Understood. The physical and key mgmt portions of the FIPS-140-2 are taken > care of in our existing implementation, I am strictly looking for a > comparable encryption module that I can use in place of the product we had > been using. > > That said, if I install RHEL 5.5 and choose to encrypt the disk, am I > doing everything necessary or is there more setup that needs to be done to > make sure that I am using the appropriate encryption methodologies? The > previous response from Milan on this issue seemed to indicate that the > module included in RHEL 5 was not FIPS-140-2 compliant but the one > included in RHEL 6 is... > > Thank you very much for your help, > Justin > > -----Original Message----- > From: dm-crypt-bounces@xxxxxxxx [mailto:dm-crypt-bounces@xxxxxxxx] On > Behalf Of Sven Eschenberg > Sent: Wednesday, February 29, 2012 2:09 PM > To: dm-crypt@xxxxxxxx > Subject: EXTERNAL: Re: LUKS encryption standards > > Hi there, > > From a technical POV LUKS easily can achieve everything demanded by > FIPS-140-2 for the technical stuff. > > That being said: > > One Major thing about 140-2 considers physical device security (tampering > detection) which naturally is outside of LUKS' scope. Further, you'D > probably need a certification, to really conform to FIPS-140-2. > > The Key management Part etc. is (again) completely outside of LUKS' scope, > it's a question fo procedure. > > Concerning the actual encryption algorithm, Hashign Methods etc. LUKS can > achieve everything FIPS-140-2 demands, as long as you choose wisely. > > So, in general, everything from FIPS-140-2 that is limited to the area of > implemenation (software), LUKS can generally achieve, but that's just a > rather small part of what your customer is asking for, as far as I can > tell. > > Regards > > -Sven > > > > On Wed, February 29, 2012 17:23, Bennett, Justin wrote: >> Hello all, >> >> At my work, we have a requirement from our customer to provide total >> hard >> drive encryption on pieces of our system that are considered mobile >> (laptops, for instance). Previously, we have been using a commercial >> product to achieve this, but that product has since been discontinued in >> favor of a hardware based product that the company is now using. >> >> I'd like to use the LUKS-based encryption that is available during the >> installation of RHEL 5 (the OS we'll be using going forward) but I need >> to >> know some specific information regarding the encryption standards that >> are >> met by LUKS. Specifically, the customer requires that the encryption >> meet >> the standards set forth by the United States Dept. of Commerce in >> FIPS-140-2 (http://en.wikipedia.org/wiki/FIPS_140-2). >> >> I'm wondering if someone can tell me whether the current cryptsetup or >> dm-crypt offerings support this or not. I tried looking through a list >> of >> validated cryptographic modules kept by the NIST, but I didn't have any >> luck. >> >> Any help you can offer would be greatly appreciated. >> >> Thank you, >> Justin Bennett >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt >> > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
