[swift-server-dev] FIPS certification

Drew Crawford drew at sealedabstract.com
Thu Feb 16 18:05:59 CST 2017


Not to start a large bikeshed, but I was surprised by the following statement in the README:

A final motivation in using native libraries is that vendors often go through security certification processes for their own modules and therefore users can get this certification for free. In particular, many use cases that involve government or enterprise data or users, require FIPS 104 compliance or validation. FIPS is a US Government (NIST) cryptographic standard and is a requirement by most government agencies and many enterprises. The process of getting certified is hard, expensive and time consuming and is only done by vendors and large organizations.
This is, as I understand it, the sole argument presented for choosing OpenSSL in the Linux implementation.

First, a clarifying question: are the references to "FIPS 104" in this document actually "FIPS 140"? [0]  I am not aware of a "FIPS 104", and google suggests it is a typo [1].

To provide some (possibly biased) background knowledge for the discussion:

* Until recently, the FIPS 140 standard mandated conforming cryptographic libraries make available the DUAL_EC_DRBG cipher with certain unexplained magic numbers.
* The New York Times reports that DUAL_EC_DRBG is actually an NSA backdoor based on information they received from Edward Snowden.  [2]
* While NIST did not remove this algorithm from FIPS 140 until 2014, the backdoor was widely suspected among security experts as early as 2007.  [3]
* Reuters reports that the NSA paid $10m to a security firm to ensure this backdoored algorithm was the default on various products. [4]
* Separately, OpenSSL's implementation and testing of this algorithm is so poor that it did not even work, accidentally "prevent[ing] all use of the Dual EC DRBG algorithm" [5]
* The "hard, expensive, and time consuming" FIPS validation process never discovered this bug.  Upstream says "Not only the original validation (#1747) but many subsequent validations and platforms have successfully passed the [FIPS] algorithm tests several hundred times now. That's a lot of fail... Frankly the FIPS 140-2 validation testing isn't very useful for catching 'real world' problems." [5]
* Because of the enormous expense of re-verifying a one-line patch, OpenSSL did not fix this bug, in part because the FIPS "process forbids modifications of any kind (even to address severe vulnerabilities) without the substantial time and expense of formal retesting and review"  [5]
* Stephen Marquess, OpenSSL maintainer, who implemented some of the FIPS code in question, is "on record as stating that FIPS 140-2 validated software is necessarily less secure than its equivalent unvalidated implementation" [7]

With that background, some questions:

0.  Can we name any specific Swift users with FIPS requirements?  Are those users incapable of taking the their own steps to address their requirements?
1.  Regardless of what enterprises require, does anyone believe that FIPS 140 or NIST standards in general actually improve security, or is less than actively harmful?  That argument is conspicuously absent from a security proposal.
2.  If there were some "certification X" that was required by enterprises but was known to introduce security vulnerabilities for long periods, how bad would things have to be before we told those enterprises to take a hike, and how is that hypothetical distinct from the present situation?
3.  Will Swift use OpenSSL in "FIPS mode" (FIPS_mode_set) ?  By default?  As an option?  At all?  What percentage of users do we expect to actually use the FIPS module?  I am of the impression the vast majority of even OpenSSL users do not use FIPS.
4.  Have we considered the performance impact of FIPS?  According to various benchmarks [6], OpenSSL in FIPS mode is several orders of magnitude slower than otherwise across effectively all workloads.
5.  Is Swift or related projects themselves seeking FIPS certification?  What is Swift's policy with respect to exposing "mandated" algorithms to userspace if they are widely expected to contain backdoors or vulnerabilities?
6.  What is Swift's policy with respect to responding to vulnerabilities in dependent FIPS-certified modules, when that code cannot be changed without losing the FIPS certification?
7.  Why is OpenSSL preferred to other FIPS-validated libraries such as NSS?

Thanks in advance for what is hopefully a productive discussion,

Drew

[0] http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[1] http://www.vm.ibm.com/related/tcpip/pm93363.html
[2] https://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?src=twrhp&_r=0
[3] https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html
[4]  http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220
[5]  http://marc.info/?l=openssl-announce&m=138747119822324&w=2
[6] https://wiki.openwrt.org/doc/howto/benchmark.openssl
[7] http://veridicalsystems.com/blog/secure-or-compliant-pick-one/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170216/39bd5a2b/attachment.html>


More information about the swift-server-dev mailing list