Re: [openssl-users] FIPS mode restrictions and DES
Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto libraries to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu jone...@teksavvy.com wrote: Salz, Rich wrote As the old joke goes, if you have to ask, you can't afford it. Well, exploration can be free. I noticed that Strongswan uses a plug-in architecture for crypto that seemingly allows the use of OpenSSL instead of the kernel for crypto operations, for use under FIPS. Does anyone have an idea of the order of magnitude in performance loss this could be for IPSec, to use crypto from OpenSSL instead of the kernel ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto libraries to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu jone...@teksavvy.com wrote: Salz, Rich wrote As the old joke goes, if you have to ask, you can't afford it. Well, exploration can be free. I noticed that Strongswan uses a plug-in architecture for crypto that seemingly allows the use of OpenSSL instead of the kernel for crypto operations, for use under FIPS. Does anyone have an idea of the order of magnitude in performance loss this could be for IPSec, to use crypto from OpenSSL instead of the kernel ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: OpenSSL PKI Tutorial updated
In the Simple PKI example, step 5.4 View PKCS#7 bundle, the -in option points to ca directory, but the bundle was created in step 4.3 Create PKCS#7 bundle in the certs directory. I.e.: Step 4.3: openssl crl2pkcs7 -nocrl \ -certfile ca/signing-ca.crt \ -certfile ca/root-ca.crt \ -out certs/signing-ca-chain.p7c \ certs directory -outform der Step 5.4: openssl pkcs7 \ -in ca/signing-ca-chain.p7c \ ca directory -inform der \ -noout \ -text \ -print_certs So far though, this has been a helpful tutorial for a noob to PKI. Thanks! Kevin On Sun, Apr 21, 2013 at 5:56 AM, Stefan H. Holek ste...@epy.co.at wrote: Hi All! I have updated the OpenSSL PKI tutorial at readthedocs. The tutorial takes a novel approach without ever referring to openssl.cnf or CA.pl (yuck). You can find it here: https://pki-tutorial.readthedocs.org/ Thanks to everyone who has provided feedback for the first version. I heard your call for more verbosity! The first two examples now have much more detailed instructions, and I hope that by the third example you won't need instructions anymore. ;-) Cheers, Stefan -- Stefan H. Holek ste...@epy.co.at __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Any OpenSSL update when FIPS object module v2.0 is released?
When the validation is obtained for FIPS Object Module v2.0, and that version is officially released, will there also be an update to OpenSSL? Or are those two now independent as long as v1.0.1 is used with the FIPS module? Thanks, Kevin
Re: FIPS fingerprint in .data not .rodata
On Tue, Feb 21, 2012 at 1:11 PM, Andy Polyakov ap...@openssl.org wrote: Though in FIPS 2.0 there is new option that might work in this case. Besides switching to another compiler that is. Introduced to rectify situation with rodata segments not being position-independent on Win64, defining __fips_constseg might prove useful even in this situation. See if defining it in fips/fipssyms.h to __attribute__((section(.rodata))) makes it work. Keep in mind that me suggesting this doesn't make it validated. If it works, it still has to be separately validated by authorities. Ok, so I did this and added it to appropriate locations in fips_canister.c Right, you need the __attribute__ in question even for FIPS_rodata_[start|end]. I failed to mention this. Good catch. Well, this idea at first looked like it would do the trick, however, when the __attribute__((section(.rodata))) call makes a .rodata section, it isn't *the* .rodata section, it is just *a* .rodata section and in fact is made writeable, Well, then it's tough break, switch to another compiler. Of course one can name section something else, e.g. .rofips, and write a script that would set the read-only flag in fipscanister.o after it's linked. Or! It would be possible to modify incore to set the flag. I mean fipscanister.o can have .rofips that is not read-only, but it can become read-only in applications and shared lib in the process of embedding the signature. Well, whatever you do requires code change, so you have to validate it separately (change letter through opensslfoundation.com might be alternative)... Another option (but shoot it down if its bogus :-): I noticed that if I compile fipscanister.o without -fPIC, then the const variables do get placed in the (really readonly) .rodata section as desired. I thought maybe if I did that and went the static route - build libcrypto with no-shared and link libcrypto.a statically into my app - then maybe I would have a validate-able solution. I checked that the FIPS-bounded .text and .rodata regions are the same for the app and the fipscanister.o, and the app integrity test passes and fips mode gets enabled on the target. Per your comment below, FIPS_text_start (and end) also looks correct in the disassembled code: 0181ae34 FIPS_text_start: 181ae34: 3c 60 01 82 lis r3,386 (0x182) 181ae38: 38 63 ae 40 addir3,r3,-20928( - 0x51c0) 181ae3c: 4e 80 00 20 blr( = 0x181ae40) 0181ae40 FIPS_text_startX: 181ae40: 7c 08 02 a6 mflrr0 181ae44: 48 00 00 05 bl 181ae48 FIPS_text_startX+0x8 181ae48: 7c 68 02 a6 mflrr3 181ae4c: 7c 08 03 a6 mtlrr0 181ae50: 4e 80 00 20 blr I am expecting to have to do a change letter validation - just trying to minimize the necessary changes so that it will qualify for that option rather than a full-blown validation - which probably would not be viable for us. I assume that if a target can't support shared libraries properly then it is still ok to have the static alternative validated..? The assembler code looks correct for FIPS_text_startX returning its memory location. The question was if FIPS_text_start returns FIPS_text_startX's address [of its first instruction], *not* what does FIPS_text_startX return! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS fingerprint in .data not .rodata
On Tue, Feb 21, 2012 at 3:51 PM, Andy Polyakov ap...@openssl.org wrote: Another option (but shoot it down if its bogus :-): I noticed that if I compile fipscanister.o without -fPIC, then the const variables do get placed in the (really readonly) .rodata section as desired. I thought maybe if I did that and went the static route - build libcrypto with no-shared and link libcrypto.a statically into my app - then maybe I would have a validate-able solution. The prime reason for why FIPS 2.0 module is compiled with -fPIC is to make it versatile. Idea is to validate *single* fipscanister.o usable in either context, statically-linked application or dynamic library. Reasoning is that while it's plain inappropriate to use non-PIC code in dynamic library, linking PIC statically was proven to work on all tested platforms, therefore -fPIC. This naturally means that if you are positively not interested in unified/versatile fipscanister.o nothing prevents you from giving up on -fPIC and targeting statically-linked application only. I.e. introducing config-line without -fPIC through change letter is as validate-able as anything else. That is certainly sensible. But for my present needs, the static would be just fine - I really need something as a bridge to a newer OS/gcc version I'll be doing at a later point, and on which the -fPIC option will likely be supported better... I'll keep your last suggestion above in my back pocket though. Thanks for your insight and keeping me on a correct track. Per your comment below, FIPS_text_start (and end) also looks correct in the disassembled code: 0181ae34 FIPS_text_start: ... Yes, it looks proper. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS fingerprint in .data not .rodata
On Mon, Feb 20, 2012 at 5:18 AM, Andy Polyakov ap...@openssl.org wrote: Though in FIPS 2.0 there is new option that might work in this case. Besides switching to another compiler that is. Introduced to rectify situation with rodata segments not being position-independent on Win64, defining __fips_constseg might prove useful even in this situation. See if defining it in fips/fipssyms.h to __attribute__((section(.rodata))) makes it work. Keep in mind that me suggesting this doesn't make it validated. If it works, it still has to be separately validated by authorities. Ok, so I did this and added it to appropriate locations in fips_canister.c Right, you need the __attribute__ in question even for FIPS_rodata_[start|end]. I failed to mention this. Good catch. Well, this idea at first looked like it would do the trick, however, when the __attribute__((section(.rodata))) call makes a .rodata section, it isn't *the* .rodata section, it is just *a* .rodata section and in fact is made writeable, e.g., .file fips_aes_selftest.c gcc2_compiled.: .section .rodata,aw .type tests,@object tests: .byte 0 ... The objdump -h also shows for this section: 11 .rodata c724 018725d0 018725d0 000725d0 2**3 CONTENTS, ALLOC, LOAD, DATA so not READONLY. The assembler, which apparently recognizes .rodata for what it is, generates a warning about setting incorrect attributes for .rodata section. all with some #if's to try to limit the changes to my platform, and it seems to work. I say seems because it looks - to me - pretty much like it did before when I thought it was working, except that the .o file doesn't have a symbol per function. etc. So I don't know how to check if the sequestered code is located between the FIPS_text endpoints. I guess I can dump the fipscontainer.o symbols, and then dump the symbols in an executable that statically links it, and check that there has been no rearranging. I'm not sure how to check an executable that dynamically links libcrypto.so, since I do not have e.g., objdump or the like on the embedded target. But there ought to be cross-compile objdump you can run on the system you're cross-compiling on. How would you go about verifying this? So I did what I mentioned above, more or less following the idea in IncoreTutorial document, I don't know what IncoreTutorial document is. What is it? This is in the docs section for the previous validation. http://opensslfoundation.com/testing/validation-1.2/docs/ and could show that the symbols between FIPS_start/end are exactly the same in fipscontainer.o, libcrypto.so, and an app that statically links libcrypto.a. Same for FIPS_rodata_start/end. And it runs on the target. For the app the app symbols (and non-fipscanister crypto) are outside the sequestered area. I'm not sure what else to do to verify that it is correct now. Please suggest any additional tests I can do. The ultimate test is to run it under debugger and verify that value returned by FIPS_text_start is indeed pointer to first instruction of FIPS_text_startX. Set break point to FIPS_text_start, single-step till it returns, note the value in r3 register, 'disassemble FIPS_text_startX' and compare addresses. It's also possible to verify by examining disassembled code (objdump -d) and if necessary relocation tables (more than likely necessary in shared library case), but it's more complicated (specially in shared library case). The assembler code looks correct for FIPS_text_startX returning its memory location. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS fingerprint in .data not .rodata
On Sat, Feb 18, 2012 at 6:13 PM, Andy Polyakov ap...@openssl.org wrote: The key thing I realized is that the incore script that comes with the FIPS Object Module v2.0 tarball handles both native AND cross-compile scenarios. Even though FIPS 2.0 util/incore is capable of handling arbitrary ELF binary (native or not), it's not used in non-cross-compile/native cases, as there *are* configurations when it won't work. In other words above statement does no hold universally true and FIPS 2.0 util/incore script is supported and should be used only in cross-compile environments targeting ELF, moreover, not *any* environment, but in explicitly verified (see below). Thanks for clarifying that. I was being ELF-centric. After I had gotten the extra -f options from Harvey for this platform (BSD-powerpc), Using -f[data|function]-sections options is inappropriate as they undermine the idea of capturing fipscanister code and rodata between start/end symbols. It was bad advice/idea, do *not* use those options. Ok...so the original issue was that no .rodata section was being created, so no incore script (of any kind) worked. I had the impression that there needed to be a read-only data section to protect certain data. So what would you suggest I try - what has been done with other compilers that do this? I can't (don't want to?) believe this just dead-ends with no solution. I learned a lot of interesting things along the way, so aside from time spent and the bruised forehead, everything is good. I'm not convinced that it is:-) Just because it appears working it doesn't necessarily mean it's doing the right thing. Every cross-compiler has to be explicitly verified, which is why there is no generic one-size-fits-all support for cross-compiling. Ok, I get that - but the criteria needed to achieve explicit verification for a given cross-compilation scenario is not clear to me. I have now had to add one line to config, Configure, and fips_canister.c in the FIPS module to get it to work on my target. Oh well. Keep in mind that it will be counted as validated only as long as you don't change it. Yes, I am aware of that - I realize the changes mandated additional testing. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS fingerprint in .data not .rodata
On Sun, Feb 19, 2012 at 11:52 AM, Andy Polyakov ap...@openssl.org wrote: After I had gotten the extra -f options from Harvey for this platform (BSD-powerpc), Using -f[data|function]-sections options is inappropriate as they undermine the idea of capturing fipscanister code and rodata between start/end symbols. It was bad advice/idea, do *not* use those options. Ok...so the original issue was that no .rodata section was being created, so no incore script (of any kind) worked. I had the impression that there needed to be a read-only data section to protect certain data. This is correct impression, but it doesn't make -fdata-sections appropriate. So what would you suggest I try - what has been done with other compilers that do this? Well, it says what has been done [in the single case encountered by then] in User Guide 1.2: users are advised to *use another compiler*, in other words nothing. I can't (don't want to?) believe this just dead-ends with no solution. But you can/do accept that compiler has to be ANSI C-compliant in order to compile OpenSSL. Indeed, I don't hear you complaining about OpenSSL being impossible to compile with KR C. In other words it's perfectly reasonable to impose some requirements on compiler, isn't it? And so just like compiler is required to be ANSI C to compile OpenSSL at all, it's required to discriminate read-only data (by placing it to dedicated segment) to compile FIPS module in particular. If your compiler doesn't meet the minimal requirement, tough break, but that's the way it is. Though in FIPS 2.0 there is new option that might work in this case. Besides switching to another compiler that is. Introduced to rectify situation with rodata segments not being position-independent on Win64, defining __fips_constseg might prove useful even in this situation. See if defining it in fips/fipssyms.h to __attribute__((section(.rodata))) makes it work. Keep in mind that me suggesting this doesn't make it validated. If it works, it still has to be separately validated by authorities. Ok, so I did this and added it to appropriate locations in fips_canister.c all with some #if's to try to limit the changes to my platform, and it seems to work. I say seems because it looks - to me - pretty much like it did before when I thought it was working, except that the .o file doesn't have a symbol per function. etc. So I don't know how to check if the sequestered code is located between the FIPS_text endpoints. I guess I can dump the fipscontainer.o symbols, and then dump the symbols in an executable that statically links it, and check that there has been no rearranging. I'm not sure how to check an executable that dynamically links libcrypto.so, since I do not have e.g., objdump or the like on the embedded target. How would you go about verifying this? I learned a lot of interesting things along the way, so aside from time spent and the bruised forehead, everything is good. I'm not convinced that it is:-) Just because it appears working it doesn't necessarily mean it's doing the right thing. Every cross-compiler has to be explicitly verified, which is why there is no generic one-size-fits-all support for cross-compiling. Ok, I get that - but the criteria needed to achieve explicit verification for a given cross-compilation scenario is not clear to me. Criteria is very simple (and is not specific to cross-compile case(*)): machine instructions comprising FIPS module has to reside between addresses returned by FIPS_text_start and FIPS_text_end. Similar applies to constant data, but it's the code segment that can tricky. Question here is how do you know that current implementation of FIPS_text_[start|end] actually does that on arbitrary platform? And the answer is you don't. You don't know if FIPS_text_start returns address on a machine instruction to start with, nor that linker doesn't rearrange code(**) in such manner that machine instructions end up outside the addresses in question. It was fortunate that current implementation worked on cross-compiler platforms we've looked at so far(***), but we can/may *not* assume that it holds universally true and provide one-size-fits-all support for cross-compiling. Admittedly it's very likely that current implementation would work even on platform in question, but it can't be established without verifying. (*) What is specific to cross-compile case is that addresses returned by FIPS_text_[start|end] has be those of instructions constituting FIPS_text_[start|end]X. (**) Which is the very reason why -f*-segments options are inappropriate, they [are documented to] facilitate rearranging of code/data at linker stage. (***) It worked because ld -r merged .text segments without changing their order and that FIPS_text_[start|end] did return addresses of machine instructions. __ OpenSSL
Re: FIPS fingerprint in .data not .rodata
On Sun, Feb 19, 2012 at 3:50 PM, Kevin Fowler kevpfow...@gmail.com wrote: On Sun, Feb 19, 2012 at 11:52 AM, Andy Polyakov ap...@openssl.org wrote: After I had gotten the extra -f options from Harvey for this platform (BSD-powerpc), Using -f[data|function]-sections options is inappropriate as they undermine the idea of capturing fipscanister code and rodata between start/end symbols. It was bad advice/idea, do *not* use those options. Ok...so the original issue was that no .rodata section was being created, so no incore script (of any kind) worked. I had the impression that there needed to be a read-only data section to protect certain data. This is correct impression, but it doesn't make -fdata-sections appropriate. So what would you suggest I try - what has been done with other compilers that do this? Well, it says what has been done [in the single case encountered by then] in User Guide 1.2: users are advised to *use another compiler*, in other words nothing. I can't (don't want to?) believe this just dead-ends with no solution. But you can/do accept that compiler has to be ANSI C-compliant in order to compile OpenSSL. Indeed, I don't hear you complaining about OpenSSL being impossible to compile with KR C. In other words it's perfectly reasonable to impose some requirements on compiler, isn't it? And so just like compiler is required to be ANSI C to compile OpenSSL at all, it's required to discriminate read-only data (by placing it to dedicated segment) to compile FIPS module in particular. If your compiler doesn't meet the minimal requirement, tough break, but that's the way it is. Though in FIPS 2.0 there is new option that might work in this case. Besides switching to another compiler that is. Introduced to rectify situation with rodata segments not being position-independent on Win64, defining __fips_constseg might prove useful even in this situation. See if defining it in fips/fipssyms.h to __attribute__((section(.rodata))) makes it work. Keep in mind that me suggesting this doesn't make it validated. If it works, it still has to be separately validated by authorities. Ok, so I did this and added it to appropriate locations in fips_canister.c all with some #if's to try to limit the changes to my platform, and it seems to work. I say seems because it looks - to me - pretty much like it did before when I thought it was working, except that the .o file doesn't have a symbol per function. etc. So I don't know how to check if the sequestered code is located between the FIPS_text endpoints. I guess I can dump the fipscontainer.o symbols, and then dump the symbols in an executable that statically links it, and check that there has been no rearranging. I'm not sure how to check an executable that dynamically links libcrypto.so, since I do not have e.g., objdump or the like on the embedded target. How would you go about verifying this? So I did what I mentioned above, more or less following the idea in IncoreTutorial document, and could show that the symbols between FIPS_start/end are exactly the same in fipscontainer.o, libcrypto.so, and an app that statically links libcrypto.a. Same for FIPS_rodata_start/end. And it runs on the target. For the app the app symbols (and non-fipscanister crypto) are outside the sequestered area. I'm not sure what else to do to verify that it is correct now. Please suggest any additional tests I can do. Thanks again for your guidance. Kevin I learned a lot of interesting things along the way, so aside from time spent and the bruised forehead, everything is good. I'm not convinced that it is:-) Just because it appears working it doesn't necessarily mean it's doing the right thing. Every cross-compiler has to be explicitly verified, which is why there is no generic one-size-fits-all support for cross-compiling. Ok, I get that - but the criteria needed to achieve explicit verification for a given cross-compilation scenario is not clear to me. Criteria is very simple (and is not specific to cross-compile case(*)): machine instructions comprising FIPS module has to reside between addresses returned by FIPS_text_start and FIPS_text_end. Similar applies to constant data, but it's the code segment that can tricky. Question here is how do you know that current implementation of FIPS_text_[start|end] actually does that on arbitrary platform? And the answer is you don't. You don't know if FIPS_text_start returns address on a machine instruction to start with, nor that linker doesn't rearrange code(**) in such manner that machine instructions end up outside the addresses in question. It was fortunate that current implementation worked on cross-compiler platforms we've looked at so far(***), but we can/may *not* assume that it holds universally true and provide one-size-fits-all support for cross-compiling. Admittedly it's very likely that current implementation
Re: FIPS fingerprint in .data not .rodata
On Fri, Feb 17, 2012 at 10:25 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Fri, Feb 17, 2012, Kevin Fowler wrote: Thanks Harvey, This seems to have worked as far as getting the .rodata section used. This is what I see now: 001b5740 g O .rodata0010 FIPS_rodata_start 001b5750 l O .rodata0011 FIPS_hmac_key 001b57bc g O .rodata0036 FIPS_bn_version 001c1e08 g O .rodata0010 FIPS_rodata_end 001fb1cc g O .data 0014 FIPS_signature My problem now is that when I build an executable (I'm using the simple hmac.c example in the user guide, with the Makefile modified to use a shared library) that uses the shared libcrypto.so, and run it on my target, it just spits out a hash value, no matter what options I give it. For example: # ./hmac 334286d0c4ca79f97921fa782c7269e972e0a420 Before I used the suggested -f options, this app at least worked for non-fips and gave me an error when enabling fips mode. Now I don't understand what it is doing, but I think it is trying to tell me something!! I've tried messing around with different INCORE_ADJUST values, but that does not seem to make any difference. I don't really understand how incore2 is supposed to work: it calculates a lot of stuff and dumps out values but never appears to modify the executable or library. I've also tried static linking of libcrypto.a into the executable - same result. You need to use the fipsld script to link the target. It obtains the signature and embeds it. You need to set FIPS_SIG environment variable to point to the incore script. Steve. Yes, I was doing that, but I was getting the procedure for the older FIPS/OpenSSL version mixed up with the one for the new FIPS/OpenSSL version. The key thing I realized is that the incore script that comes with the FIPS Object Module v2.0 tarball handles both native AND cross-compile scenarios. I had thought for cross-compiling we needed to replace it with the incore2 script on the website (like I think incore.gz was needed with the previous FIPS release..?). After I had gotten the extra -f options from Harvey for this platform (BSD-powerpc), I kept trying to get it to work with the incore2 script, but didn't really know what to do with it. I ended up embedding the signature by-hand by running a test app on my target, getting the hash it spat out, and then rebuilding the libcrypto.so with -DHASH_SHA1_SIG set to that hash. Then, while solving the what should INCODE_ADJUST be for my platform issue, the answer I figured out helped me to see that the FIPS_text_startX/endX symbols used by the latest incore script for v2.0 solves the whole problem for cross-compiled binaries and embeds the correct signature in the correct location without all the by-hand stuff. I rebuilt the whole thing pointing FIPS_SIG to the correct incore script, with the necessary compiler options from Harvey for this platform/compiler, and then everything worked fine automatically. I learned a lot of interesting things along the way, so aside from time spent and the bruised forehead, everything is good. I have now had to add one line to config, Configure, and fips_canister.c in the FIPS module to get it to work on my target. Oh well. Kevin -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS fingerprint in .data not .rodata
Thanks Harvey,
This seems to have worked as far as getting the .rodata section used. This
is what I see now:
001b5740 g O .rodata0010 FIPS_rodata_start
001b5750 l O .rodata0011 FIPS_hmac_key
001b57bc g O .rodata0036 FIPS_bn_version
001c1e08 g O .rodata0010 FIPS_rodata_end
001fb1cc g O .data 0014 FIPS_signature
My problem now is that when I build an executable (I'm using the simple
hmac.c example in the user guide, with the Makefile modified to use a
shared library) that uses the shared libcrypto.so, and run it on my target,
it just spits out a hash value, no matter what options I give it. For
example:
# ./hmac
334286d0c4ca79f97921fa782c7269e972e0a420
Before I used the suggested -f options, this app at least worked for
non-fips and gave me an error when enabling fips mode. Now I don't
understand what it is doing, but I think it is trying to tell me something!!
I've tried messing around with different INCORE_ADJUST values, but that
does not seem to make any difference. I don't really understand how incore2
is supposed to work: it calculates a lot of stuff and dumps out values but
never appears to modify the executable or library.
I've also tried static linking of libcrypto.a into the executable - same
result.
Help appreciated!
Kevin
On Thu, Feb 16, 2012 at 4:47 PM, Harvey Shepherd
harvey.sheph...@aviatnet.com wrote:
Hi Kevin,
I encountered this problem when compiling the 1.2.3 FIPS object module
some time ago, with exactly the same compiler. After some experimentation I
managed to get it to embed the fingerprint correctly using the following
compiler options:
-fno-common -fdata-sections -ffunction-sections
I also needed to change the INCORE_ADJUST setting to an 8 byte offset for
my processor as follows:
diff --git a/current/appfs/openssl-fips/incore
b/current/appfs/openssl-fips/incore
index 07df989..61f68b9
100755 (executable)
--- a/current/appfs/openssl-fips/incore
+++ b/current/appfs/openssl-fips/incore
@@ -6,6 +6,7 @@
DEBUG=
+CROSS_COMPILE=ppc_8xx-
OBJCOPY=${CROSS_COMPILE}objcopy
OBJDUMP=${CROSS_COMPILE}objdump
@@ -58,6 +59,7 @@ if [ -z $INCORE_ADJUST ]; then
elf64-x86-64) INCORE_ADJUST=4;;
#elf32-littlearm|elf32-little|elf32-bigarm) INCORE_ADJUST=-36;;
elf32-littlearm|elf32-little|elf32-bigarm) INCORE_ADJUST=-8;;
+elf32-powerpc) INCORE_ADJUST=8;;
esac
fi
I'm not really an expert in this area, but it worked for me, so give it a
try.
Regards,
Harvey
I am building a cross-compiled FIPS-capable libcrypto.so with the 1.0.1beta
OpenSSL and 2.0 FIPS Object Module.
The build is being done on a linux (CentOS) host for a PowerPC target
running
netbsd 1.6.2 (yes, I know, its old).
gcc being used:
$ ${CROSS_COMPILE}gcc -v
gcc version 2.95.3 20010315 (release) (NetBSD nb3)
(yes, I know, also old)
I can successfully build fipscontainer.o, and then build fips_algvs, which
runs successfuly on the target system. This made me think that the
fingerprint was working correctly...
Later (when building libcrypto.so) I realized I was using the native
incore
script instead of the cross-compile incore script. I switched to the
cross-compile incore script, but that failed to embed a fingerprint in
the (FIPS-capable) libcrypto.so.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
fips-capable libcrypto.so build in netbsd
Using FIPS module and FIPS capable OpenSSL (2.0/1.0.1) on a NetBSD platform. I build FIPS module by hand to follow the build instructions, and copy it into a tips sub-directory in openssl directory. I would like to build the libcrypto.so library as part of the NetBSD cross-compile build (i.e., launched from src/lib/libcrypto/Makefile), so it can be built as needed for different processors. NetBSD uses its own makefile approach using perl scripts to launch builds, and using generic src/share/mk/bsd.*.mk makefiles. I was thinking I could modify only the lib/libcrypto/Makefile file and leave the generic makefiles alone, but am struggling with the final linking step rules using fipsld. Has anyone else done this in NetBSD builds? Alternatively, I could also build the library by hand and coax the main build into just installing libcrypto.so instead of building it. Suggestions welcome! I've searched but cannot find any sign of anyone coping with similar issues. Kevin
FIPS/OpenSSL include directories
When I build the FIPS module and install, it populates a fips-2.0/include/openssl directory with a set of header files. When I build the FIPS-capable OpenSSL library libcrypto, it has the fips-2.0 include director in its CFLAGS, but at the end. Since the FIPS include directory has a subset of the files in the usual include/openssl directory, and since the FIPS include directory comes last in CFLAGS, it seems that the FIPS include files are never used. So, I don't see why it is even listed in CFLAGS. E.g, powerpc--netbsd-gcc -I.. -I../.. -I../modes -I../asn1 -I../evp* -I../../include * -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -O3 -fomit-frame-pointer -Wall *-I/usr/local/ssl/fips-2.0/include* -c -o i_cbc.o i_cbc.c But my real question is, when writing an application that uses the FIPS-capable libcrypto, should that application pick up the header files in the usual include/openssl directory, or the header files in the fips-2.0/include/openssl directory? While some files are identical, a few have differences. Is this a benign issue when using the FIPS-capable libcrypto, even when FIPS mode is enabled? I.e., once I have the library, do I ever need the fips-2.0/include/openssl versions? Thanks, Kevin
Re: FIPS/OpenSSL include directories
I'm asking here about the header files with the same name in both directories. I see that there are three fips-specific header files in the fips-2.0 include directory - which I would guess is what is getting picked up by the last -I in CFLAGS... On Sun, Jan 29, 2012 at 2:19 PM, Kevin Fowler kevpfow...@gmail.com wrote: When I build the FIPS module and install, it populates a fips-2.0/include/openssl directory with a set of header files. When I build the FIPS-capable OpenSSL library libcrypto, it has the fips-2.0 include director in its CFLAGS, but at the end. Since the FIPS include directory has a subset of the files in the usual include/openssl directory, and since the FIPS include directory comes last in CFLAGS, it seems that the FIPS include files are never used. So, I don't see why it is even listed in CFLAGS. E.g, powerpc--netbsd-gcc -I.. -I../.. -I../modes -I../asn1 -I../evp* -I../../include * -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -O3 -fomit-frame-pointer -Wall *-I/usr/local/ssl/fips-2.0/include* -c -o i_cbc.o i_cbc.c But my real question is, when writing an application that uses the FIPS-capable libcrypto, should that application pick up the header files in the usual include/openssl directory, or the header files in the fips-2.0/include/openssl directory? While some files are identical, a few have differences. Is this a benign issue when using the FIPS-capable libcrypto, even when FIPS mode is enabled? I.e., once I have the library, do I ever need the fips-2.0/include/openssl versions? Thanks, Kevin
FIPS cross-compile: issue with location of system include files
I think I know the answer to this but I'm hoping I am wrong. I am building the FIPS Object Module v2.0 (a recent snapshot) on an x86-linux2 host for an embedded PowerPC target running NetBSD. There is a well-established and intricate build process already in place for the product, and I am trying to build the FIPS module outside of that process but using the same cross-compiler. That existing build process puts the system include files in a special directory, which is passed to gcc with a -I. When I build the FIPS module, there are several environment variables that can be set in order to get the cross-compile to work, except for the location of those system include files(?). My question is whether I am missing something - i.e., an environment variable - that I can set to indicate the location of that directory, without impacting the (future) validated status of the module. Or is there a simpler solution I am overlooking? If not, I expect I will need to modify the Makefile, and thus invalidate the module... Kevin
Re: FIPS cross-compile: issue with location of system include files
I copied all the system header files from their special home into the location the powerpc--netbsd-gcc was looking for them, and then I could do the ./config no-asm; make successfully. I am thinking that is a legal approach for building the FIPS Object Module. If so, I answered my own question... Kevin On Wed, Nov 30, 2011 at 12:01 PM, Kevin Fowler kevpfow...@gmail.com wrote: I think I know the answer to this but I'm hoping I am wrong. I am building the FIPS Object Module v2.0 (a recent snapshot) on an x86-linux2 host for an embedded PowerPC target running NetBSD. There is a well-established and intricate build process already in place for the product, and I am trying to build the FIPS module outside of that process but using the same cross-compiler. That existing build process puts the system include files in a special directory, which is passed to gcc with a -I. When I build the FIPS module, there are several environment variables that can be set in order to get the cross-compile to work, except for the location of those system include files(?). My question is whether I am missing something - i.e., an environment variable - that I can set to indicate the location of that directory, without impacting the (future) validated status of the module. Or is there a simpler solution I am overlooking? If not, I expect I will need to modify the Makefile, and thus invalidate the module... Kevin
B_ENDIAN for powerpc on fips/openssl
I noticed that for the FIPS Object module for ./config no-asm the endian flag is removed from CFLAGS. But in openssl, this is not the case. So, e.g. for linux-ppc, openssl build has -DB_ENDIAN flag, but fips build has no such flag. I'm guessing that the powerpc gcc may default to big-endian, so this may not be an issue. But, since it appeared inconsistent I thought I'd mention it. Thanks, Kevin
Re: understanding fipsld usage
Thanks Steve, I have a follow-up below - just checking I have it straight. On Mon, Nov 21, 2011 at 10:11 AM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Nov 18, 2011, Kevin Fowler wrote: Let me first say I have read the User Guide and Security Policy repeatedly, as well as the Incore Tutorial, looked through this users group, and read anything else I could find - so I'm not being lazy, although my questions may be pedestrian... Please correct any misunderstandings along the way. I understand that when fipscanister.o is built, its SHA1 digest is calculated and saved. Then when an application links to fipscanister.o, fipsld is used, which checks that the SHA1 is correct, and then calculates the digest for the application and rebuilds it with that digest embedded. Then, when the application is run and calls FIPS_mode_set(), the digest is calculated and checked against the embedded value. I think that openssl itself is an example of an application built with the fipscanister.o, is that correct? It depends on what you mean by openssl and the build options. If you are performing a shared library build then fipscanister.o is embedded in the libcrypto shared library. For a static build every application including the openssl utility statically includes fipscanister.o Ok, so: - if I do a shared build of OpenSSL (./config fips shared), then the libcrypto.so that is produced contains the FIPS Object Module, and fipsld will have embedded the digest in that library. - if I do a static build of OpenSSL (.config tips), then the libcrypto.a that is produced does not contain the FIPS Object Module. Later linking to an application will require fipscanister.o, -L lcrypto, and the use of fipsld to embed the digest in the application. An example of this is the hello application in the Incore Tutorial document. When OpenSSL is built, it produces, among other things, the libcrypto.a static library, which contains what was sequestered in fipscanister.o.Is that correct? Now I have a big application to build, and it will have the FIPS-capable OpenSSL in it. When I do the build, I think the instructions say that the SHA1 digest has to be re-calculated on this application, and that value embedded where the previous standalone value was. Is that correct? Is my application pulling in the FIPS stuff by linking in the libcrypto.a? If my application is just too large and complex, do I pretty much need to go with the shared library, and avoid the part where the digest is recalculated/re-embedded in the application itself? If you're library links against the OpenSSL shared library you don't need to bother with any of this as the fingerprint is embedded in that shared library by the build process. If you want to statically link against OpenSSL you do need to address this. If you're using a Unix like system then making some minor adjustments to the final linking to use fipsld and set a few environement variables is sufficient. If you want to integrate this with some IDE or you are using Windows with an IDE then this is a bit trickier and you might need to develop your own procedure following the security policy requirements. 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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
understanding fipsld usage
Let me first say I have read the User Guide and Security Policy repeatedly, as well as the Incore Tutorial, looked through this users group, and read anything else I could find - so I'm not being lazy, although my questions may be pedestrian... Please correct any misunderstandings along the way. I understand that when fipscanister.o is built, its SHA1 digest is calculated and saved. Then when an application links to fipscanister.o, fipsld is used, which checks that the SHA1 is correct, and then calculates the digest for the application and rebuilds it with that digest embedded. Then, when the application is run and calls FIPS_mode_set(), the digest is calculated and checked against the embedded value. I think that openssl itself is an example of an application built with the fipscanister.o, is that correct? When OpenSSL is built, it produces, among other things, the libcrypto.a static library, which contains what was sequestered in fipscanister.o.Is that correct? Now I have a big application to build, and it will have the FIPS-capable OpenSSL in it. When I do the build, I think the instructions say that the SHA1 digest has to be re-calculated on this application, and that value embedded where the previous standalone value was. Is that correct? Is my application pulling in the FIPS stuff by linking in the libcrypto.a? If my application is just too large and complex, do I pretty much need to go with the shared library, and avoid the part where the digest is recalculated/re-embedded in the application itself? Thanks Kevin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
make test fails for FIPS-capable OpenSSL build
Hi, I successfully built the FIPS 2.0 module (2010), its tests passed, and it was installed correctly in /usr/local/ssl/fips-2.0. I then build openssl 1.0.1 (2010): ./config fips shared make which all seems to go ok Then I do: make test and eventually get this error: ... Testing key generation with NIST Binary-Curve B-571 ok cat base64 aes-128-cbc 3086473868:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180: bad decrypt 3086592652:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180: 3086592652:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:535: ./p ./p.aes-128-cbc.clear differ: byte 1, line 1 make[1]: *** [test_enc] Error 1 It appears that EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag is not getting set, but I'm not familiar enough yet with the code to understand what I may be doing wrong. I have OPENSSL_FIPS set to 1 in my environment. I am building/running on CentOS 5.6. Thanks, Kevin
Re: make test fails for FIPS-capable OpenSSL build
Thank you - that was my problem On Tue, Nov 15, 2011 at 9:43 AM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Nov 14, 2011, Kevin Fowler wrote: Hi, I successfully built the FIPS 2.0 module (2010), its tests passed, and it was installed correctly in /usr/local/ssl/fips-2.0. I then build openssl 1.0.1 (2010): ./config fips shared make which all seems to go ok Then I do: make test and eventually get this error: ... Testing key generation with NIST Binary-Curve B-571 ok cat base64 aes-128-cbc 3086473868:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180: bad decrypt 3086592652:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180: 3086592652:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:535: ./p ./p.aes-128-cbc.clear differ: byte 1, line 1 make[1]: *** [test_enc] Error 1 It appears that EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag is not getting set, but I'm not familiar enough yet with the code to understand what I may be doing wrong. I have OPENSSL_FIPS set to 1 in my environment. I am building/running on CentOS 5.6. Don't set OPENSSL_FIPS=1 before calling make test as not all the tests work in FIPS mode. The tests will swicth to FIPS mode themselves if this is being tested. Though currently only a TLS test does this. 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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
make test fails for FIPS-capable OpenSSL build
Hi, I successfully built the FIPS 2.0 module (2010), its tests passed, and it was installed correctly in /usr/local/ssl/fips-2.0. I then build openssl 1.0.1 (2010): ./config fips shared make which all seems to go ok Then I do: make test and eventually get this error: ... Testing key generation with NIST Binary-Curve B-571 ok cat base64 aes-128-cbc 3086473868:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180: bad decrypt 3086592652:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180: 3086592652:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:535: ./p ./p.aes-128-cbc.clear differ: byte 1, line 1 make[1]: *** [test_enc] Error 1 It appears that EVP_MD_CTX_FLAG_NON_FIPS_ALLOW flag is not getting set, but I'm not familiar enough yet with the code to understand what I may be doing wrong. I have OPENSSL_FIPS set to 1 in my environment. I am building/running on CentOS 5.6. Thanks, Kevin
