[openssl-users] FIPS Linux kernel documentation ?

[Steve Marquess]

On 03/26/2015 01:41 PM, Jakob Bohm wrote:
> On 26/03/2015 16:56, Steve Marquess wrote:
>> On 03/26/2015 11:30 AM, John Foley wrote:
>>> We looked at this very briefly a couple of years ago.  In theory, there
>>> may be a way to achieve the goal as a loadable kernel module (a.k.a.
>>> device driver).  The idea would be to have a kernel module that provides
>>> crypto support.  This kernel module would be the FIPS object module,
>>> with the FIPS boundary drawn around the kernel module.  This would be
>>> loaded at run time like any other device driver when FIPS mode needed to
>>> be enabled.
>>>
>>> There is likely some kernel work required to allow the ciphers in the
>>> kernel module to be injected into the crypto flow within the kernel.
>>> The other issue is getting the kernel to automatically run the FIPS
>>> integrity test on the module at load time.
>> We looked at it in quite a bit of detail about two years ago also, to
>> the point of developing a formal proposal for a prospective sponsor.
>>
>> Yes, a loadable module is the way to go. We had worked out how to do the
>> POST at module load (including an actual implementation).
>>
>> But, as with any open source based FIPS validation it would have been
>> expensive and risky, and the end result would still have been fossilized
>> code that would always be a painfully awkward fit in the Linux
>> ecosystem. We'd still consider tackling that, with financial
>> sponsorship, but we have no prospects for such.
>>
>> -Steve M.
>>
> Hypothetically speaking, would it be possible to use the
> OpenSSL FIPS module with an appropriate "outside the boundary"
> kernel module wrapper around it to form "yet another platform"
> for one of the validation numbers?

Possibly. The approach we tentatively settled on was to keep and
validate the existing kernel crypto code (non OpenSSL!) with the cruft
to satisfy FIPS 140-2 (the POST, and also the test suite software for
the algorithm testing). The hard part isn't the crypto code; it's
everything else. By keeping the existing interoperable crypto API we'd
get the most bank for the buck.

> Technically, the kernel module wrapper would interact with the
> same blob "API" that a FIPS-enabled OpenSSL uses, so there
> would be little or no change to FIPS module build and "security
> guide" for such additional kernel mode platforms.  "Inside the
> boundary" changes would be needed only to the extent that the
> FIPS blob makes direct system calls, since the kernel is not a
> normal POSIX-like environment when seen from a kernel mode
> module.

This could work if you weren't worried about compatibility with existing
kernel crypto usage. The current OpenSSL FIPS module code would still
need non-trivial massaging though.

> If the CMVP bureaucracy insists on a specific kernel version
> for the platform number, this should be one of the "Long Term
> Support" kernel releases to maximize longevity (assuming that
> regular OS patching within a version number is still accepted
> as "same platform").

Worse: it would need to be validated on every "Operational Environment"
(OE): meaning every Linux distribution: Debian N.M for every N and M,
Fedora N.M, Ubuntu N.M, CentOS N.M, ...

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc