Re: OpenSSL engine support in OpenSSL FIPS Object Module
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
Re: OpenSSL engine support in OpenSSL FIPS Object Module
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
Re: OpenSSL engine support in OpenSSL FIPS Object Module
Hi Kyle, Thanks a lot for detailed explaination, it helped me lots. Regards Jayalakshmi On Sun, Jul 6, 2014 at 2:44 AM, Kyle Hamilton aerow...@gmail.com 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 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
Re: OpenSSL engine support in OpenSSL FIPS Object Module
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.
OpenSSL engine support in OpenSSL FIPS Object Module
Hi All, We want to support a hardware accelerator on our device. We are using OpenSSL with OpenSSL FIPS Object module. I wanted to know if we can add engine support in OpenSSL FIPS Object module. I welcome all valuable inputs. Regards Jayalakshmi.
Re: OpenSSL engine support in OpenSSL FIPS Object Module
On 07/05/2014 02:09 AM, Jayalakshmi bhat wrote: Hi All, We want to support a hardware accelerator on our device. We are using OpenSSL with OpenSSL FIPS Object module. I wanted to know if we can add engine support in OpenSSL FIPS Object module. I welcome all valuable inputs. First, please don't cross post to both lists. The openssl-users list would suffice. You've more or less asked this question already. The OpenSSL FIPS Object Module source code is available under an open source license, so subject to the very liberal terms of that license you can hack that code to your hearts content. However... The FIPS 140-2 Level 1 validation of that module (certificate #1747) is a different thing entirely. The instant you touch the code that validation no longer applies. The code without the validation is worthless (it does nothing regular OpenSSL doesn't do better, faster, more securely). A new validation will be necessary. You will find such a validation a significant challenge even without the source code mods you contemplate. -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 marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL engine support in OpenSSL FIPS Object Module
On Sat, Jul 05, 2014, Jayalakshmi bhat wrote: Hi All, We want to support a hardware accelerator on our device. We are using OpenSSL with OpenSSL FIPS Object module. I wanted to know if we can add engine support in OpenSSL FIPS Object module. If you literally mean adding ENGINE support to the OpenSSL FIPS Object module then you can but it would IMHO be a pointless exercise. The ENGINE code was stripped out to keep the number of dependencies down in the module. If you mean add ENGINE support to the FIPS capable OpenSSL then you don't need to as ENGINE support is already there. I suggest you explain exactly what you want to do. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL engine support in OpenSSL FIPS Object Module
Hi Steve, 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. In my previous post related to TPM like how to deal with Non-FIPS compliant TPM chips, does it need any change in FIPS module size etc? 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. Both posts looks similar. I apologize I should have clearly mentioned these 2 posts are in different contexts. Thanks a lot. Regards Jayalakshmi On Sat, Jul 5, 2014 at 10:46 PM, Dr. Stephen Henson st...@openssl.org wrote: On Sat, Jul 05, 2014, Jayalakshmi bhat wrote: Hi All, We want to support a hardware accelerator on our device. We are using OpenSSL with OpenSSL FIPS Object module. I wanted to know if we can add engine support in OpenSSL FIPS Object module. If you literally mean adding ENGINE support to the OpenSSL FIPS Object module then you can but it would IMHO be a pointless exercise. The ENGINE code was stripped out to keep the number of dependencies down in the module. If you mean add ENGINE support to the FIPS capable OpenSSL then you don't need to as ENGINE support is already there. I suggest you explain exactly what you want to do. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
