Home


About OSF
 What We Do
 Who We Are
 Contact Info


Resources
 OpenSSL
 Download
 FIPS 140-2
 Testing
 Data Archives
 Export
 Mirrors


 
OpenSSL Software Foundation, Inc.

The FIPS 140-2 "Ransom Payment"

Last update 2015-06-26 ("SE" validation approved)

See latest status

1. Background

Change letter updates (in particular the addition of new platforms) to the widely used OpenSSL FIPS Object Module v2.0 FIPS 140-2 validated cryptographic module (certificate number #1747) have been banned since January 15, 2015. Details of this situation are documented here.

A possible, albeit confusing, workaround has been identified. That workaround is discussed here.

2. The "Alternative Scenario" 1A re-validation

The FIPS 140-2 Implementation Guidance document (IG), one of the canons of FIPS 140-2 scripture, was updated in 2013 to define two unusual new options for modification of existing validations1. One of those (Section G.8 subsection 1) allows for "re-branding" of an existing module:
Alternative Scenario 1A

If there are no modifications to a module and the new module is a re-branding of an already validated OEM module. The CST laboratory shall determine that the re-branded module is identical to the OEM module. The test report submission shall include a letter requesting the validation of the re-branded module and indicate the applicable documentation changes (e.g. Vendor name, address, POC information, versioning information, etc.) and an updated Security Policy reflecting the new re-branded module. The Security Policy shall be technically identical to the OEM module.

Many proprietary software vendors like to conceal the fact that they are using open source software, and such "re-brandings" are common, especially of the open source OpenSSL FIPS module which is particularly attractive for such use.2 Prior to advent of the Scenario 1A option, proprietary software vendors had to take the OpenSSL FIPS module software through an ostensibly independent validation which cost considerably more and took far longer.

3. A Workaround

Well, if other vendors with no connection to OpenSSL, and who have not contributed in any way to OpenSSL, can do "Scenario 1A" re-branding of the OpenSSL FIPS module, then why can't we? It took weeks to get clear answers to our queries, but we did eventually receive confirmation that we would not be prevented from obtaining a "Scenario 1A" re-validation of our own module, the OpenSSL FIPS Object Module v2.0 aka certificate #1747. We also received confirmation that we would be allowed (as are other vendors) to subsequently submit change letter updates to this new "re-branded" validation.

Since IG G.8 subsection 1 requires that the re-branded module have "no modifications" and be "identical" to the original module, we will use the openssl-fips-2.0.9.tar.gz module from the #1747 validation exactly as-is. The new module will be named "OpenSSL FIPS Object Module RE v2.0.9", with initial revision 2.0.94. The "RE" stands for "Ransom Edition". The original #1747 validation will implicitly become the "Original Edition" (OE). There will be frequent need to reference the original validation and the Scenario 1A derivatives; this will be confusing.

We're told this rebranded validation must omit all of the existing 101 platforms from Table 2. We will start with a single platform, one that had been submitted just as the #1747 change letter ban was first instituted and which has been in limbo in the meantime (this is the platform for Vendor "Y" referenced in the earlier "hostage issue" discussion).

Once the new re-validation is approved we can immediately submit change letter update requests for the other pending platforms (for Vendor "X") and for the new change letter sponsors who have elected to proceed with platform validation testing in the interim on an "at risk" basis.

4. The Ransom Payment

We can now put a price tag on the ransom payment to rescue our "hostage" platform sponsors: $9,250.5 Normally we'd bite the bullet for our clients on such extra costs. For instance, we paid for the change letter to remove Dual EC DRBG ourselves, but that was our own fault for implementing that abomination in the first place when we knew better. But, this time we have decided not to pay the ransom out of OSF funds, not just because it's a fair chunk of change for a small organization but also because despite the clear feedback we aren't convinced there won't be further obstacles in store.

Several prospective clients have indicated a willingness to pay some or all of the ransom. Note we won't be charging anything for our own efforts; we're only seeking to recover the actual ransom payment itself. We'll be proceeding as soon as we have finalized the appropriate commitment(s).

5. Partial Hostage Rescue, and Much Confusion

Once the new validation is approved, all 101 platforms for the original #1747 validation and all platforms for the new validation will be covered by one validation or the other. In the case of the initial revision of the new validation, which will share the same source distribution tarball with #1747, the same module is covered by both validations. So, a vendor or end user with applications running on platforms in the original list of 101 platforms for the #1747 validation, and also on platforms for the 2.0.9 revision of the new validation, can still use one module to cover all those platforms. Where it gets messy is when a 2.0.10 revision is introduced for the new validation (and that will happen rather quickly). Even though the 2.0.10 tarball will support all 101 of the old platforms, it will be missing the "magical pixie dust"6 of FIPS 140-2 validation goodness. The vendor/user will need to build a different binary FIPS module from the 2.0.9 tarball, and track use of the "right" FIPS module all the way to customer deployments in the field.

A specific example to illustrate this conundrum: Suppose Vendor Z sells a software product that runs on a wide variety of platforms, including FreeBSD 9.1, FreeBSD 9.3, FreeBSD 10.0, and FreeBSD 10.1. The same executable code runs on all four versions of FreeBSD, so the vendor need only ship one version of the product to all FreeBSD customers, at least where FIPS 140-2 isn't an issue. But, this product uses the "FIPS capable" OpenSSL which contains the OpenSSL FIPS module and for which a FIPS mode of operation can be enabled at runtime.

Since the FreeBSD 9.1 and FreeBSD 10.0 platforms are included in the #1747 validation (platforms #86/87, 94/95), and the FreeBSD 9.3 and FreeBSD 10.1 platforms are (we suppose) included in the new validation at revision 2.0.10, the same binary module can't be used for all four platforms. Instead, the vendor will have to build one module with the 2.0.9 source tarball common to both validations, and another with the 2.0.10 tarball for the new validation.

Note that different versions of operating systems are often added as platforms in some order other than ascending values of the version numbers; e.g. 9.1, 10.0, 9.3, and 10.1 in this example.

So, vendor Z has to supply two versions of its product and tell its customers that:

  • If they don't care about FIPS 140-2 use either product version for any FreeBSD platform.
  • For FIPS 140-2 use version "A" for FreeBSD 9.1 and 10.0 only
  • For FIPS 140-2 use version "B" for FreeBSD 9.3 and 10.1 only

Since the 2.0.10 tarball will have only platform portability changes not relevant to FreeBSD, both modules will run on all four platforms, but the vendor and end user now have to track this artifical distinction between the two colors (flavors?) of magical pixie dust. They're going to love that.

6. The Double Ransom Solution

After some thought we realized we could largely avoid some of these artifical distinctions and associated confusion with two "Scenario 1A" re-validations; one to remain forever at the original openssl-fips-2.0.9.tar.gz tarball shared with the original #1747 validation, and another to start with that 2.0.9 tarball but be modified as needed to accommodate new platforms.

The one that stays at the 2.0.9 tarball we'll call the "OpenSSL FIPS Object Module RE" (the "Ransom Edition").

The other "Scenario 1A" re-validation that will update the tarball we'll call the "OpenSSL FIPS Object Module SE" (the "Salvage Edition").

For convenience we'll refer to the original #1747 validation as "OE or the "Original Edition".

The next two sections discuss the implications of these two new "Scenario 1A" re-validations.

7. The Ransom Edition, a Doppelgänger Validation for Most Platforms

This validation will share the exact same source distribution tarball, and hence cryptographic module, with the #1747 validation. To put that another way, if someone builds a module from that tarball then you can't tell which validation it "belongs" to until it is installed on a specific platform. So for instance suppose you build a binary module that runs on both FreeBSD 9.1 and FreeBSD 9.3. When you copy that binary module to a FreeBSD 9.1 system you would then say "This product uses a cryptographic module with FIPS 140-2 validation certificate number #1747". Copy that exact same binary file to your FreeBSD 9.3 system and you'd then say "This product uses a cryptographic module with FIPS 140-2 validation certificate number #NNNN".

In practice vendors will probably elect to say in both cases "This product uses a cryptographic module with FIPS 140-2 validation number #1747 or #NNNN".

So, effectively the OE/RE validations constitute a single validation with two names and certificate numbers. Note the original fifteen "hostage" platforms remain available in their original form, along with all 101 original platforms plus all platforms subsequently added to the RE validation.

Easy mnemonic: this validation ransoms most of the hostages: the original fifteen platforms that were threatened along with all 101 of their fellows, plus the majority of new platforms.

8. The Salvage Edition, a Follow-On Validation for the Outlier Platforms

After nine separate change letter updates, most of which introduced multiple new platforms, the OE/RE validation supports a lot of platforms. But, there may still be need from time to time to add new platforms that require modifications to the source code (and in fact four such platforms were stalled in-process by the hostage issue). We can't modify the tarball for the RE validation without losing the original 101 validated platforms, so we will add such platforms to a separate new validation. Since a new binary module will need to be built anyway for such platforms, vendors and end users won't be forced to track arbitrary flavors of magical pixie dust for modules that would otherwise be interoperable across multiple platforms.

One important "pixie dust" caution should be noted, however: the SE validation tarball (2.0.10, 2.0.11, ..., etc.) can be used to create binary modules that will run on all platforms common to the three OE/RE/SE validations. But, those modules won't be FIPS 140-2 righteous on all such platforms (wrong flavor of pixie dust).

Easy mnemonic: this validation salvages the OE/RE validation for use with new platforms that cannot be added to the OE/RE tarball and validations.

9. Rules of Thumb

To use the OpenSSL FIPS Object Module, download both the 2.0.9 tarball7 and the most recent 2.0.N tarball.

If your platform of interest is listed for either the OE or RE validation, build using the 2.0.9 tarball. Otherwise if your platform is listed for the SE validation, build using the latest 2.0.N tarball.

When stating your FIPS 140-2 validation compliance, say:

This product uses a cryptographic module with FIPS 140-2 validation number #1747, #NNNN, or #MMMM"
where NNNN and MMMM are the validation certificate numbers for the RE and SE validations (TBD as those become available).

Note that while in most cases the latest revision of a software product is the best, that assumption does not apply to the OpenSSL FIPS module. Since we're generally not allowed to make any improvements, bug fixes, or vulnerability fixes to already validated modules the 2.0.N+1 revision is not better than 2.0.N in that regard; it just contains platform portability modifications to support some new platform(s).

In any context in which certificate numbers are not relevant, i.e. for those actually building, installing, or using the OpenSSL FIPS module, it will suffice to refer to the OpenSSL FIPS Object Module or OpenSSL FIPS module without the OE/RE/SE qualification, as those qualifications refer to the validation (the magical pixie dust) and not the modules themselves.

10. Current Status

Status updates for this developing situation will go here.

As of 2015-03-18 the accredited test lab has been engaged to submit the two new "1A re-brand" validations. The draft Security Policy documents can be found here (RE) and here (SE). Note those two documents differ by only six characters ( the six occurances of "RE" versus "SE"). These were generated from the original #1747 Security Policy by removing references to the original 101 platforms and past revisions, and changing the module name and date. So, this should be purely a rubber-stamp exercise; time will tell.

At this point we're secured commitments for only one of the ransom payments, so we're taking a bit of a gamble in the interests of the clients with change letter updates in process for the #1747 validation.

Update 2015-03-31: Our check to the accredited test lab for the $18,500 ransom payment has cleared. The test lab required that full payment in advance.

Update 2015-06-26: The "Salvage Edition" validation was approved on either June 24th or 25th depending on how one keeps score8. The SE validation has certificate number #2398. The "Ransom Edition" is still pending, although it was submitted together with the "Salvage Edition" and the paperwork differs by exactly six characters.


- Footnotes -

1 See Maintaining a FIPS 140-2 Certificate for an unusually readable discussion of validation modification options.

2 It's an open secret in the FIPS 140-2 community that a large majority of all Level 1 software validations are either the OpenSSL FIPS module renamed or a thin shell around OpenSSL code. Such "copycat" validations typically have names like "AcmeOS Secure Cryptographic Module 1.0". Some vendors go to a great deal of trouble to conceal the OpenSSL origins of "their" module (to the point of changing identifying literals in the C source code); others openly reference OpenSSL. This can be seen with a cursory search of the Security Policy documents on the NIST CMVP web site; closer study will reveal many more.

3 (placeholder to avoid renumbering footnotes)

4 We have to make this initial revision number "2.0.9" as the original modification contains that revision number both as a text string literal and in the binary format used with the function call API. Fortunately that is probably also the least confusing approach as the RE 2.0.9 module will be precisely bit-for-bit identical with the OE 2.0.9 module; they are the same module in all but name (and validation certificate number).

5 That consists of $4,250 for a CMPV "cost recovery fee", and $5,000 for the accredited test lab. The cost recovery fee is the same as for real validations (new software, new documentation). The test lab fee is quite reasonable considering their risk in dealing with this novel use of the Scenario 1A rebranding that appears to defeat the CMVP intentions in banning #1747 change letter updates (though unfortunately we have to pay it twice).

6 Software engineers and people with a practical technical background, especially those unfamiliar with FIPS 140-2 specifically or government certifications in general, often have a very hard time understanding why things like snail-mailed CD software distributions or building with specific command line parameters matter, when the end result is precisely the same. One of the most effective ways to explain such apparently nonsensical procedural requirements is to use the concept of "magical pixie dust"; e.g. the tarball on the snail-mailed CD has been sprinkled with FIPS 140-2 magical pixie dust whereas the bit-for-bit identical one they download from our web site hasn't.

7 Technically the "2.0.9 tarball" is actually two separate tarballs:

The "ecp" tarballs are an alternate form of the module that omits binary curve ECC; they are not widely used.

8 The entry for validation #2398 initially appeared on the 24th, but then disappeared again for reasons unknown. When it reappeared sometime late on the 24th or early on the 25th the link to the Security Policy was broken. The complete entry was not permanently in place until late morning EDT on the 25th.

2015-06-26
Noted approval of the SE validation
2015-03-18
2015-03-31
Noted payment of ransom
2015-03-18
Updates status to note new "1A re-brands" in progress
2015-03-12
Extensive additions to describe the double ransom solution
2015-03-06
Initial draft

This site Copyright © 2009-2016 OSF.