Hi Jakob, Thank you very much for detailed and helpful explanation.
Regards Jayalakshmi On Sun, Jul 6, 2014 at 9:32 PM, Jakob Bohm <jb-open...@wisemo.com> wrote: > 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 >
