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 this post I wanted to know to support an hardware accelerator that > supports FIPS enabled algorithms implemented apart from supporting the > hardware from OpenSSL side, do we need to make changes in FIPS module > as well. If I understand you correctly, you wish to alter the FIPS canister to offload time-consuming operations to hardware acceleration. If this understanding is correct, I must regretfully inform you that it cannot legitimately be done. Oh, sure, you can technically do it -- but it would be a modification of the "black box", and require a new validation. (I don't believe that such an implementation could in fact be validated, though I could be wrong. I am not an expert. But even if it can be, it cannot be validated with a private-label validation and would cost upwards of $200,000 to validate.) Remember, the FIPS canister *as written* is the only way to legitimately have FIPS mode from OpenSSL. Once FIPS mode is set, only cryptographic operations which are provided by the FIPS canister can be performed, and only by the unmodified code within the FIPS canister. It cannot be offloaded, because the FIPS canister cannot be modified to perform the offloading. Also, by offloading, you change the boundaries of the cryptographic provider to include additional, unverified, and quite possibly incorrect functionality. 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
smime.p7s
Description: S/MIME Cryptographic Signature
