[erlang-questions] OTP in FIPS mode ?

Fri May 1 10:01:13 CEST 2015

Hi,

When I was working on the FIPS branch the first step was switching to the
EVP-API. Interestingly, as Ingela pointed out, the EVP-API doesn't cover
all the functionality in OTP's crypto module. IIRC the public key
primitives were not available, but in that case even the low level OpenSSL
API seems to work in FIPS mode (which means those calls do end up in the
FIPS Object Module), so I left them as they are.

Besides the API-change I also:

   - Blocked non-compliant calls in FIPS mode before they would reach
   OpenSSL (so you get an Erlang error instead of killing your VM). This is a
   must have for any FIPS fork, but it was quite trivial to implement.
   - Modified the ssl code so it won't offer the disabled ciphers in FIPS
   mode. Interestingly, it's always been possible to query the list of
   supported algorithms from crypto, but most users of this application simply
   assumed their algorithms were always available. This is not a big change
   and would be very useful in FIPS mode, and you can just cherry-pick my
   commit (there may be conflicts with other OTP versions though, I'm not
   sure).
   - I found a couple of places where week crypto algorithms (or keys) were
   used. Mostly tests, but there was a dict somewhere with md5 hashes as keys.
   These had to be switched to something FIPS compliant. I think you can
   directly cherry-pick my commits, conflicts are not likely.
   - I also made a huge refactoring in the crypto NIF code that is not
   really necessary for FIPS support. From R16B to R16B-01 the crypto.erl API
   was refactored: originally there were different functions for e.g. md5,
   sha1 and so on, from R16B-01 there are generic hash/encrypt/... functions
   that take the algorithm's name as an argument. However, the change was only
   in the Erlang layer: the C code was still using the old per-algorithm
   functions and the Erlang code was translating the new API to the old API of
   the NIFs. But the EVP-API of OpenSSL is essentially the same as the new
   Erlang API, so I switched over the C code to this new design as well.
   I think this commit looks very frightening, because it changes a good
   portion of the C module. But it is not strictly speaking necessary for the
   FIPS support at all. And I am personally also happy that I could throw away
   800-1000 lines of C code. :)

Anyway, if you need FIPS mode, I would recommend you to fork OTP, take the
crypto application as it is from my branch and cherry-pick the commits to
non-crypto code on top of the OTP version of your choice. Rebasing my
changes of the crypto application to other OTP versions is not easy, you
would get a lot of conflicts*. But since 17.0 I think only a couple of new
algorithms were added to crypto, you can probably live without them in a
FIPS environment.

Cheers,
Daniel

* One of my colleagues at ESL ported the FIPS branch to a newer OTP release
(17.4 maybe?), but to be honest I forgot who did it, and I couldn't find
his repo between the many forks of OTP on github.

2015-04-23 15:52 GMT+02:00 Ingela Andin <ingela.andin@REDACTED>:

> Hi!
>
> This question is in the OTP 19 scope.  FIPS requires the use of the
> EVP-API which sounds interesting regardless of
> FIPS.  We see this as a possible first step, then we can consider if and
> what else we might want to do, to support or facilitate for others to
> support FIPS.  My current understanding is that using  only the  EVP-API
> functions we can not make the  crypto  API completely functional,  which
> will require at least some additions to the crypto API and perhaps
> OTP-techincal board considerations.
>
> Regards Ingela Erlang/OTP - Ericsson AB
>
> 2015-04-21 20:22 GMT+02:00 Drew Varner <drew.varner@REDACTED>:
>
>> Here’ s the discussion on a FIPS pull request that’s now closed:
>> https://github.com/erlang/otp/pull/377
>>
>> - Drew
>>
>>
>> On Apr 21, 2015, at 12:32 PM, Niclas Eklund <nick@REDACTED> wrote:
>>
>> Hi!
>>
>> IMHO I think that it would be good if FIPS could supported by OTP,
>> especially since the purpose of the FIPS standards are issued to ensure
>> computer security and interoperability. I've seen a question about this at
>> least once before on this list before -
>> http://erlang.org/pipermail/erlang-questions/2012-April/065902.html But
>> I don't know what became of it.
>>
>> Best regards,
>>
>> Nick
>>
>>
>> On 04/21/2015 03:48 PM, jonetsu wrote:
>>
>> Hello,
>>
>> We are using an Erlang-based middleware using OTP, ConfD, which
>> must now support FIPS mode.  Briefly, FIPS is a U.S. standard
>> that imposes a set of crypto parameters (ciphers, algorithms,
>> etc...).  FIPS-applications must use high-level OpenSSL
>> methods (The EVP set of methods) since the low-level functions
>> will make OpenSSL abort.  The application must also call
>> FIPS_mode_set(1) to enable this mode for a suitable OpenSSL build
>> that supports FIPS.
>>
>> OTP uses low-level OpenSSL functions.
>>
>> Initially I considered replacing, for instance, the AES_* uses in
>> crypto.c by their EVP equivalent, while keeping the interface to
>> Erlang intact.
>>
>> Now, looking at the extent of the FIPS modifications to the OTP
>> code done last year by Dániel Szoboszlay, who worked at Ericsson
>> and Erlang Solutions, I wonder about my naïve approach.
>>
>> Are anyone here familiar with this FIPS OTP port ?  Any comments
>> ? To anyone also familiar with ConfD: do you know of any effort
>> done in using this FIPS-enabled OTP code ?
>>
>> Thanks for any comments and suggestions !
>>
>> Regards.
>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150501/8050fdc8/attachment.htm>