[dm-crypt] Cryptsetup, dmcrypt & FIPS140-2

[dm-crypt] Cryptsetup, dmcrypt & FIPS140-2

[Milan Broz]

Hi all,

from time to time someone asks about status of LUKS/dmcrypt and FIPS-140-2 [1].

Because just recently RHEL 6.2 completed this certification [2] and one module
is Full Disk Encryption module (based on cryptsetup/LUKS & dmcrypt) [3]
I would like to comment it here (for archive).

But first, I am no longer Red Hat employee and all comments below are related
to upstream, if you need more info about RHEL cert, please talk
to Red Hat support. Thanks.

However, all RHEL changes are upstream (as I implemented most of them).

Requirement for FIPS140-2 is mainly in US government and similar regulated sphere.
Certification requires exact system configuration (kernel in FIPS mode, compilation
with exact crypto library) and it is always applies only to exact hw configuration.
It requires many additional steps, described in documentation (security policy).

But most of requirements are fulfilled even outside of these environments,
(at least it applies to upstream cryptsetup).

IOW there is no fundamental problem for LUKS and dmcrypt in regard to FIPS140-2,
and there already exist fully validated system based on this technology.

Well, the better insight what FIPS is for is provided in [4] :-)

-- Abandon hope all ye who enter here ---

Low-level cryptsetup/dmcrypt FIPS implementation notes

- only LUKS format is covered by FIPS validation 
 (plain crypt is *not* FIPS compliant - key is directly derived from password)

- upstream default encryption modes corresponds to FIPS supported algorithms
  (PBKDF2 with SHA1, AES cipher, CBC mode with 128 or 256 bit key with ESSIV/sha256 or
  XTS mode with 256 or 512 bits key)
  (BTW validation info page is confusing, XTS is supported mode, only
   XTS with 192 bit key is not.)

-  LUKS/dmcrypt with default parameters is aligned to NIST SP 800-132 [5]
   "NIST Special Publication 800-132. Recommendation for Password-Based Key Derivation.
   Part 1: Storage Applications." (in FIPS mode, outside FIPS mode see note about RNG below)
   and NIST for XTS mode to NIST SP 800-38E [6]
   "Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality
   on Storage Devices"

(and perhaps more NIST docs I already forgot about :)

- the only supported FIPS library backend for cryptsetup is gcrypt for userspace
  and for dmcrypt obviously kernel crypto API

- cryptsetup must be compiled with --enable-fips switch

- all additional functionality is enabled only if cryptsetup detect that system is running
  in FIPS mode (simple check: /proc/sys/crypto/fips_enabled is 1)

  - it will use fipscheck library to checksum selfscheck to detect random binary
  corruption. (N.B. this is redundant to usual package consistency verification
  and does *not* prevent intentional tampering (fipscheck checksum is not signed).
  This requirement is perhaps just relict of FIPS hw self-check requirements
  which are applied to sw as well...)

  - Only FIPS certified RNG can be used in FIPS mode. Moreover, NIST SP 800-132
  requires that not only key is generated by FIPS RNG but also salt is generated
  by FIPS RNG.

  So in FIPS mode, gcrypt RNG is used to generate key and salt.
  Neither /dev/urandom nor /dev/random is used for crypto related things,
  it is not allowed.
    
  - All buffers with sensitive data are wiped after use (but this is normal).

If you need reference, please see source code and Fedora rpm source (spec) where
it is already properly configured.

Thanks,
Milan

References:
[1] http://en.wikipedia.org/wiki/FIPS_140-2
[2] http://www.redhat.com/about/news/press-archive/2013/4/red-hat-completes-fips-1402-certifications
[3] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm#1933
[4] http://permalink.gmane.org/gmane.comp.security.cryptography.randombit/3358
[5] http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
[6] http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf