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
SSL passphare expiration
Hello List, I am encrypting a file using open SSL, but the password which is created should be expired after 1 year or 2 year what ever we configure. It there anything password expiry concept in openssl? Thanks -- Regards Jeshwanth Kumar N K Bangalore, India __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL passphare expiration
> I am encrypting a file using open SSL, but the password which is created > should be expired after 1 year or 2 year what ever we configure. It there > anything password expiry concept in openssl? Ah, licensing? :) No, password expiration is not supported. You could sign the file with a certificate that has an expiration period and check the signature. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Certificate problem
I'm having a problem with generating certificates and I'm wondering if anybody has any suggestions on where to look. I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? I realize that actually attaching the certa might be helpful but I do not have them handy as I write this. Please let me know if that might help somebody help me figure this out. Thanks! Chad. __ 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 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 Lis
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 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 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, Pa
