[dm-crypt] LUKS encryption standards

[dm-crypt] LUKS encryption standards

[Bennett, Justin]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3095 bytes --]

Re: [dm-crypt] LUKS encryption standards

[Sven Eschenberg]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] EXTERNAL: Re: LUKS encryption standards

[Bennett, Justin]

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@saout.de [mailto:dm-crypt-bounces@saout.de] On Behalf Of Sven Eschenberg
Sent: Wednesday, February 29, 2012 2:09 PM
To: dm-crypt@saout.de
Subject: EXTERNAL: Re: [dm-crypt] 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>


_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] EXTERNAL: Re: LUKS encryption standards

[Sven Eschenberg]

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@saout.de [mailto:dm-crypt-bounces@saout.de] On
> Behalf Of Sven Eschenberg
> Sent: Wednesday, February 29, 2012 2:09 PM
> To: dm-crypt@saout.de
> Subject: EXTERNAL: Re: [dm-crypt] 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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] EXTERNAL: Re: LUKS encryption standards

[Bennett, Justin]

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@saout.de [mailto:dm-crypt-bounces@saout.de] On Behalf Of Sven Eschenberg
Sent: Wednesday, February 29, 2012 5:41 PM
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] 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@saout.de [mailto:dm-crypt-bounces@saout.de] On
> Behalf Of Sven Eschenberg
> Sent: Wednesday, February 29, 2012 2:09 PM
> To: dm-crypt@saout.de
> Subject: EXTERNAL: Re: [dm-crypt] 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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>


_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] LUKS encryption standards

[Milan Broz]

On 02/29/2012 05:23 PM, Bennett, Justin wrote:
> 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).

Hi,

As you already found, RHEL5 has no FIPS certified module for disk
volume encryption.

For RHEL6, there is such module in validation process
(based on LUKS/cryptsetup/dm-crypt).

But anyway, this is really question for Red Hat support channel.

> 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.

Also check modules in process page.

Milan

Re: [dm-crypt] EXTERNAL: Re: LUKS encryption standards

[Bennett, Justin]

Milan,

Thanks for your response.  I don't think we'll be able to jump to RHEL 6, unfortunately.  

It sounds like you believe that the Redhat support we have would be able to help me come up with something that is FIPS certified, is that correct?  If so, I can definitely start working with them (I'm not used to having support available, so I hadn't even though of it).

Justin

-----Original Message-----
From: Milan Broz [mailto:mbroz@redhat.com] 
Sent: Wednesday, February 29, 2012 2:24 PM
To: Bennett, Justin
Cc: dm-crypt@saout.de
Subject: EXTERNAL: Re: [dm-crypt] LUKS encryption standards

On 02/29/2012 05:23 PM, Bennett, Justin wrote:
> 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).

Hi,

As you already found, RHEL5 has no FIPS certified module for disk
volume encryption.

For RHEL6, there is such module in validation process
(based on LUKS/cryptsetup/dm-crypt).

But anyway, this is really question for Red Hat support channel.

> 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.

Also check modules in process page.

Milan