On 7/6/2014 10:44 AM, Kyle Hamilton wrote:
On 7/5/2014 10:51 AM, Jayalakshmi bhat wrote:
Thanks a lot for the explanation. We have range of products that
provides network connectivity.
1. On these we would be using TPM to provide additional security.
2. On the products that are bit slow in software cryptographic
operation, we also would be using hardware acceleration chips, that
would do crypto operations.
I'm going to guess that you are grouping these into "class 1" (related
to the TPM) and "class 2" (related to offloading). Since you already
have a thread for "class 1", I'll only respond to your "class 2"
questions here.
For background, FIPS is basically a specific mode of operation for US
Federal agencies, and is targeted specifically to Federal procurement
mandates. In government systems which are actually required to use FIPS
mode, you are not allowed to use any crypto services (whether from
OpenSSL or from any other device) that don't use an approved FIPS mode
of operation. No other people actually *need* FIPS mode. (I tend to
use it whenever I can because it tends to reduce crypto container
information leakage, and also makes it more likely that the cryptography
is correct and interoperable.)
(In the case of OpenSSL, this actually wins you very little).
Let me try to approach this from a different angle.
LEGALLY:
If you have the luxury of having more than one FIPS validated "device"
available to you, you probably (ask a lawyer to be absolutely sure),
can use all of them together. However to claim FIPS compliance of the
resulting application, you must not do any cryptography outside those
"devices", and it must be impossible for the FIPS-mode variant of your
application to fall back to any non-validated implementations in case
of errors etc. Additionally you may or may not (really ask a lawyer)
be legally (not technically) required to treat any keys, passwords
etc. handed from one "device" to another AS IF those keys were traveling
over an insecure connection even though they never leave your process
address space on an EAL-whatever-level certified operating system on an
EAL-whatever-level certified computer.
TECHNICALLY:
If you want to combine the use of multiple FIPS validated "devices",
one of which happens to be the OpenSSL FIPS cannister, and another
one a piece of hardware accessed using an OpenSSL Engine, it is an
open technical question if the FIPS-enabled OpenSSL (which is legally
outside both "devices" and /can/ be changed) will correctly combine use
of the OpenSSL FIPS canister with the ENGINE for accessing the hardware
device, or if it will somehow fail to do so.
For instance I am unsure what happens if the ENGINE plugin for the
FIPS validated hardware device calls back to OpenSSL for cryptographic
operations outside the scope of that device (it might do that because
that piece of hardware is also used outside USGov and the ENGINE code
was written for that case). Will OpenSSL pass the calls to the FIPS
canister (if in FIPS mode) or use the non-validated software
implementations?
I am also unsure if the FIPS-enabled OpenSSL library allows use of
Engines when (runtime) configured in FIPS mode?
Finally /if/ it is legally required to go through additional
gymnastics when transporting parameters from one FIPS "device" to
another, I am unsure if the FIPS-enabled OpenSSL library will do so
when the transport is internal to OpenSSL and its ENGINE plugins.
To see the requirements of FIPS 140-2, I recommend you download the five
pieces of the specification itself from
http://csrc.nist.gov/publications/PubsFIPS.html . It is written in
bureaucratese, and you'll likely need several servings of alcohol to get
through it. You should also read FIPS 200, which describes the minimum
security requirements for federal information and the systems used to
process federal information. You'll probably want to budget several
servings of alcohol for this one, too. Once you read these, you'll have
a much stronger understanding of how incredibly foreign the US federal
government's policy on cryptography is to the rest of society.
And remember: for US federal procurement, these are law, and the law
cannot be ignored or violated just because it would make things faster
or easier. US government doesn't really care about how long it takes,
US government cares that it is done correctly.
-Kyle H
Both posts looks similar. I apologize I should have clearly mentioned
these 2 posts are in different contexts.
Thanks a lot.
Regards
Jayalakshmi
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
