<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 26/03/2015 22:29, Steve Marquess
wrote:<br>
</div>
<blockquote cite="mid:55147A4E.3060209@openssl.com" type="cite">
<pre wrap="">On 03/26/2015 01:41 PM, Jakob Bohm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 26/03/2015 16:56, Steve Marquess wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 03/26/2015 11:30 AM, John Foley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<tt>The point would be that the wrapper takes calls in the<br>
existing Linux kernel form and then implement each such<br>
call in terms of the functionality exposed by the<br>
existing OpenSSL FIPS blob. For instance if the Linux<br>
kernel has an API that sets up and performs AES CBC<br>
encryption, this would get mapped to OpenSSL FIPS blob<br>
calls that do AES CBC encryption. This is all<br>
facilitated by the existing ability of the Linux kernel<br>
to support multiple implementations of each needed<br>
primitive.</tt><tt><br>
</tt>
<blockquote cite="mid:55147A4E.3060209@openssl.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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").
</pre>
</blockquote>
<pre wrap="">
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, ...</pre>
</blockquote>
<tt>As the (unpatched upstream) kernel does not rely on the<br>
distribution above it, the platform would not include the<br>
user mode. This is similar to how a validation for running<br>
inside the core of a virtualization platform such as VMWare<br>
ESXi 5.1 or RedHat N.M libvirt/kvm does not include the<br>
guest OS in the platform for its validation.</tt><tt><br>
<br>
Of cause using the validation on a Vendor patched kernel<br>
such as "RedHat N.M patched Linux kernel 3.2" or "Debian 7.8<br>
patched Linux kernel 3.2" would obviously be a different<br>
platform than "kernel.org vanilla Linux kernel 3.2".<br>
</tt><br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>