From cbc937f1c16964669a6d4865aeda2fcdeef9df0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?D=C3=A1niel=20Szoboszlay?= Provides information about the FIPS operating status of
+ crypto and the underlying OpenSSL library. If crypto was built
+ with FIPS support this can be either In FIPS mode all non-FIPS compliant algorithms are
+ disabled and throw exception The current crypto implementation uses nifs to interface OpenSSLs crypto library
- and requires OpenSSL package version 0.9.8 or higher. The current crypto implementation uses nifs to interface
+ OpenSSLs crypto library and requires OpenSSL package
+ version 0.9.8 or higher. FIPS mode support requires at least
+ version 1.0.1 and a FIPS capable OpenSSL installation. Source releases of OpenSSL can be downloaded from the The following configuration parameters are defined for the
+ crypto application. See Specifies whether to run crypto in FIPS mode. This setting
+ will take effect when the nif module is loaded. If FIPS mode
+ is requested but not available at run time the nif module and
+ thus the crypto module will fail to load. This mechanism
+ prevents the accidental use of non-validated algorithms. application(3)
+ OpenSSL can be built to provide FIPS 140-2 validated
+ cryptographic services. It is not the OpenSSL application that is
+ validated, but a special software component called the OpenSSL
+ FIPS Object Module. However applications do not use this Object
+ Module directly, but through the regular API of the OpenSSL
+ library. The crypto application supports using OpenSSL in FIPS mode. In
+ this scenario only the validated algorithms provided by the Object
+ Module are accessible, other algorithms usually available in
+ OpenSSL (like md5) or implemented in the Erlang code (like SRP)
+ are disabled. Build or install the FIPS Object Module and a FIPS enabled
+ OpenSSL library. You should read and precisely follow the instructions of
+ the It is very easy to build a working OpenSSL FIPS
+ Object Module and library from the source. However it does
+ not qualify as FIPS 140-2 validated if the numerous
+ restrictions in the Security Policy are not properly
+ followed. Configure and build Erlang/OTP with FIPS support: If Set the The best place is in the Entering and leaving FIPS mode on a node already running crypto
+ is not supported. The reason is that OpenSSL is designed to
+ prevent an application requesting FIPS mode to end up accidentally
+ running in non-FIPS mode. If entering FIPS mode fails (e.g. the
+ Object Module is not found or is compromised) any subsequent use
+ of the OpenSSL API would terminate the emulator. An on-the-fly FIPS mode change would thus have to be performed
+ in a critical section protected from any concurrently running
+ crypto operations. Furthermore in case of failure all crypto calls
+ would have to be disabled from the Erlang or nif code. This would
+ be too much effort put into this not too important feature. The Erlang API of the crypto application is identical
+ regardless of building with or without FIPS support. However the
+ nif code internally uses a different OpenSSL API. This means that the context (an opaque type) returned from
+ streaming crypto functions ( In FIPS mode non-validated algorithms are disabled. This may
+ cause some unexpected problems in application relying on
+ crypto. Do not try to work around these problems by using
+ alternative implementations of the missing algorithms! An
+ application can only claim to be using a FIPS 140-2 validated
+ cryptographic module if it uses it exclusively for every
+ cryptographic operation. Although public key algorithms are supported in FIPS mode
+ they can only be used with secure key sizes. The Security Policy
+ requires the following minimum values:
+ The Erlang API allows using arbitrary curve parameters, but
+ in FIPS mode only those allowed by the Security Policy shall be
+ used. Md5 is a popular choice as a hash function, but it is not
+ secure enough to be validated. Try to use sha instead wherever
+ possible. For exceptional, non-cryptographic use cases one may consider
+ switching to As md5 is not available in FIPS mode it is only possible to
+ use certificates that were signed using sha hashing. When
+ validating an entire certificate chain all certificates
+ (including the root CA's) must comply with this rule. For similar dependency on the md5 and des algorithms most
+ encrypted private keys in PEM format do not work
+ either. However, the PBES2 encryption scheme allows the use of
+ stronger FIPS verified algorithms which is a viable
+ alternative. It is only possible to use All SSL and TLS versions prior to TLS 1.2 use a combination
+ of md5 and sha1 hashes in the handshake for various purposes: OpenSSL handles these corner cases in FIPS mode, however the
+ Erlang crypto and ssl applications are not prepared for them and
+ therefore you are limited to TLS 1.2 in FIPS mode. On the other hand it worth mentioning that at least all
+ cipher suites that would rely on non-validated algorithms are
+ automatically disabled in FIPS mode. Certificates using weak (md5) digests may also cause
+ problems in TLS. Although TLS 1.2 has an extension for
+ specifying which type of signatures are accepted, and in FIPS
+ mode the ssl application will use it properly, most TLS
+ implementations ignore this extension and simply send whatever
+ certificates they were configured with.
+
+
+$ cd $ERL_TOP
+$ ./otp_build configure --enable-fips
+...
+checking for FIPS_mode_set... yes
+...
+$ make
+
+
+
+