<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>Besides the API-change I also:</div><div><ul><li>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.</li><li>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).</li><li>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.</li><li>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.<br>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. :)</li></ul><div>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.</div></div><div><br></div><div>Cheers,</div><div>Daniel</div><div><br></div><div>* 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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-23 15:52 GMT+02:00 Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi!<br><br></div>This question is in the OTP 19 scope.   FIPS requires the use of the EVP-API which sounds interesting regardless of <br></div>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.<br></div></div><div><br></div>Regards Ingela Erlang/OTP - Ericsson AB</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-04-21 20:22 GMT+02:00 Drew Varner <span dir="ltr"><<a href="mailto:drew.varner@redops.org" target="_blank">drew.varner@redops.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Here’ s the discussion on a FIPS pull request that’s now closed: <a href="https://github.com/erlang/otp/pull/377" target="_blank">https://github.com/erlang/otp/pull/377</a><span><font color="#888888"><div><br></div></font></span><div><span><font color="#888888">- Drew</font></span><div><div><br><div><br></div><div><div><blockquote type="cite"><div>On Apr 21, 2015, at 12:32 PM, Niclas Eklund <<a href="mailto:nick@tail-f.com" target="_blank">nick@tail-f.com</a>> wrote:</div><br><div>Hi!<br><br>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 - <a href="http://erlang.org/pipermail/erlang-questions/2012-April/065902.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2012-April/065902.html</a> But I don't know what became of it.<br><br>Best regards,<br><br>Nick<br><br><br>On 04/21/2015 03:48 PM, jonetsu wrote:<br><blockquote type="cite">Hello,<br><br>We are using an Erlang-based middleware using OTP, ConfD, which<br>must now support FIPS mode.  Briefly, FIPS is a U.S. standard<br>that imposes a set of crypto parameters (ciphers, algorithms,<br>etc...).  FIPS-applications must use high-level OpenSSL<br>methods (The EVP set of methods) since the low-level functions<br>will make OpenSSL abort.  The application must also call<br>FIPS_mode_set(1) to enable this mode for a suitable OpenSSL build<br>that supports FIPS.<br><br>OTP uses low-level OpenSSL functions.<br><br>Initially I considered replacing, for instance, the AES_* uses in<br>crypto.c by their EVP equivalent, while keeping the interface to<br>Erlang intact.<br><br>Now, looking at the extent of the FIPS modifications to the OTP<br>code done last year by Dániel Szoboszlay, who worked at Ericsson<br>and Erlang Solutions, I wonder about my naïve approach.<br><br>Are anyone here familiar with this FIPS OTP port ?  Any comments<br>? To anyone also familiar with ConfD: do you know of any effort<br>done in using this FIPS-enabled OTP code ?<br><br>Thanks for any comments and suggestions !<br><br>Regards.<br><br><br><br><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div></blockquote></div><br></div></div></div></div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>