Re: Anybody successful enabling FIPS mode in wince kernel mode DLL ?
On 5/29/2013 7:29 AM, Abhijit Ray Chaudhury wrote: HI , Anybody successfully enabled FIPS mode in wince as kernel mode dll ? I Have faced following problem when giving baseaddress 0xC000 to link.exe : = link.exe won't accept baseaddr 2GB, even with /LARGEADDRESSAWARE flag. link.exe accepts baseaddr 2GB with /DRIVER flag, but it adds a section called INIT, fro which current msincore script generates wrong sha1 and fingerprinting fails upon running it. == I have not done this myself, but two options seem obvious: A: Use an alternate rebasing tool or linker (assuming this can get past the FIPS procedural restrictions), without the artificial 2GB limitation. The ReBaseImage Win32 function can do this (it just needs a wrapper that calls it), and its source code was previously published as a Win32 sample (in the NT 3.5 SDK), though that sample may not know about all the ARM relocation types. There is also a chance that a different build of LINK.EXE does not have the 2GB limitation. B: Look for a way to make the hashing base independent, such that a DLL will pass its startup check even if relocated at load time, this is much more robust, but I am not sure if the FIPS team had the foresight to implement this (On all modular platforms that I know, DLLs and kernel modules are never guaranteed a specific load address, and this is made worse if ASLR is enabled). 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_VERIFY_PEER and self-signed certificates
Hello Dave, Once again, thanks for your help. I performed a test yesterday with the instruction SSL_CTX_use_certificate_file(tx,path_to_file, SSL_FILETYPE_PEM); replaced by SSL_CTX_load_verify_locations(ctx, path_to_file, NULL); Where path_to_file points to my file server.crt. The function returns 1 so, I expect my certificate to be properly initialised. But, whn I perform the connect, I get an error. The corresponding error message is : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed After the connect failed, the function SSL_get_peer_certificate(ssl) returns NULL and the function SSL_get_verify_result(ssl) returns 18 (X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT), which is exactly the same problem as before. My server is also printing an error message: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Regards, Brice 2013/5/28 Dave Thompson dthomp...@prinpay.com: From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Monday, 27 May, 2013 23:45 You are right, I am using a self-signed certificate for use by my server. In fact, I do not perform client authentication in my application : only the server shall be authentified by ssl. The client is authentified by another mechanism. Here are how I generate my RSA key and my certificate: openssl genrsa -des -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -days 2 -in server.csr -signkey server.key -out server.crt Asides: you could combine those: req -new -newkey rsa:2048 replaces genrsa req -new -x509 replaces x509 -signkey but the way you have it works. Also, 54+ years is a pretty long period! The only file that I transmit to my client is server.crt. Good. I think that all those files are OK because, on the server side, once everything is initialised, the command SSL_CTX_check_private_key is happy with it. In order to initialise the truststore of my client, I copy the server.crt file somewhere, and I execute the following command : SSL_CTX_use_certificate_file(ctx,path_to_file, SSL_FILETYPE_PEM); Bad. That attempts to use the cert as the *client's* cert, which has no effect because you didn't give the client the privatekey, and rightly (the client shouldn't have the server's privatekey, and you say you don't want ssl-level client-auth anyway). Do I have to generate another file ? Or do I have to perform another configuration in my client ? There are two standard ways to set up a truststore for openssl lib, in your case the client's truststore to trust the server. SSL_CTX_load_verify_locations (ctx, fileornull, pathornull) tells openssl to use the (selfsigned root and/or EE) certs concatenated in one PEM file named by fileornull if not null, and/or stored in individual PEM files using the subjecthash for link or name in directory pathornull if not null. SSL_CTX_set_default_verify_paths (ctx) does something similar but using environment-variable settings or compiled default values for the file and/or path, usually systemwide places (for all apps on the system) something like /etc/openssl/cert.pem and /etc/openssl/certdir . Most of the commandline utilities allow you to specify -CAfile and/or -CApath for the first way, or default to the second way. Since you have one cert in one PEM file, the fileornull (CAfile) approach is simplest. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-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
Re: SSL_VERIFY_PEER and self-signed certificates
Hello, Just a little hint: Your questions would be much clear if you state, at each step, which end of the connection each thing applies to, like at what end did you call SSL_CTX_load_verify_locations, at what end did you get which error messages etc. I suspect this may be the cause of some confusion here. On 5/29/2013 9:14 AM, Brice André wrote: Hello Dave, Once again, thanks for your help. I performed a test yesterday with the instruction SSL_CTX_use_certificate_file(tx,path_to_file, SSL_FILETYPE_PEM); replaced by SSL_CTX_load_verify_locations(ctx, path_to_file, NULL); Where path_to_file points to my file server.crt. The function returns 1 so, I expect my certificate to be properly initialised. But, whn I perform the connect, I get an error. The corresponding error message is : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed After the connect failed, the function SSL_get_peer_certificate(ssl) returns NULL and the function SSL_get_verify_result(ssl) returns 18 (X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT), which is exactly the same problem as before. My server is also printing an error message: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Regards, Brice 2013/5/28 Dave Thompson dthomp...@prinpay.com: From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Monday, 27 May, 2013 23:45 You are right, I am using a self-signed certificate for use by my server. In fact, I do not perform client authentication in my application : only the server shall be authentified by ssl. The client is authentified by another mechanism. Here are how I generate my RSA key and my certificate: openssl genrsa -des -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -days 2 -in server.csr -signkey server.key -out server.crt Asides: you could combine those: req -new -newkey rsa:2048 replaces genrsa req -new -x509 replaces x509 -signkey but the way you have it works. Also, 54+ years is a pretty long period! The only file that I transmit to my client is server.crt. Good. I think that all those files are OK because, on the server side, once everything is initialised, the command SSL_CTX_check_private_key is happy with it. In order to initialise the truststore of my client, I copy the server.crt file somewhere, and I execute the following command : SSL_CTX_use_certificate_file(ctx,path_to_file, SSL_FILETYPE_PEM); Bad. That attempts to use the cert as the *client's* cert, which has no effect because you didn't give the client the privatekey, and rightly (the client shouldn't have the server's privatekey, and you say you don't want ssl-level client-auth anyway). Do I have to generate another file ? Or do I have to perform another configuration in my client ? There are two standard ways to set up a truststore for openssl lib, in your case the client's truststore to trust the server. SSL_CTX_load_verify_locations (ctx, fileornull, pathornull) tells openssl to use the (selfsigned root and/or EE) certs concatenated in one PEM file named by fileornull if not null, and/or stored in individual PEM files using the subjecthash for link or name in directory pathornull if not null. SSL_CTX_set_default_verify_paths (ctx) does something similar but using environment-variable settings or compiled default values for the file and/or path, usually systemwide places (for all apps on the system) something like /etc/openssl/cert.pem and /etc/openssl/certdir . Most of the commandline utilities allow you to specify -CAfile and/or -CApath for the first way, or default to the second way. Since you have one cert in one PEM file, the fileornull (CAfile) approach is simplest. 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
Dear openssl group, could you solve this issue regarding mod_ssl? Michele Masè On Thu, May 23, 2013 at 10:11 AM, Michele Mase' michele.m...@gmail.com wrote: Okay, openssl works, but mod_ssl doesn't. Is this a real problem? Instead try hacking mod_ssl code ... Could I ask for a bug/improvement so that mod_ssl could finally work? Michele MAsè On Thu, May 23, 2013 at 1:22 AM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' Sent: Tuesday, 21 May, 2013 04:16 I was wrong! Does it work with client=Firefox using client certs under both CAs? I would expect at least one to fail. Note that s_server -verify doesn't *require* client cert, it only *allows* it; how did you check Firefox is actually using your client cert(s)? I've tested it with both smart card I went back and set up a (modified) test and ... I was wrong! The lookup as such does use the canonical DN and returns only one, sometimes the wrong one. But I didn't realize X509_STORE_get1_issuer hiddenly caches *all* the matches and tries them, and (given you have AKI) *does* select the correct one. So actually your earlier tries should have worked, or at least not failed for this reason. The certificates you attached are CA roots and have no AKI. snip pardon, my mistake, I forgot to send the clients certs :( As attachment, there are the client certificates I used. And those do indeed have AKI (correctly matching the roots). I don't know what exclusive mode means here. virtualhost1 has the ca's bundle made with all certificates + ca1 (for smart card1) virtualhost2 has the ca's bundle made with all certificates + ca2, (for smart card2); the or (exclusive) means you can try virtualhost1 with smart card1 or virtualhost2 with scard2 Okay. RFC3280 - is it correct? snip 4.1.2.4 about case-insensitive and space-insignificant Actually, 3280 has been superseded by 5280, which has more complicated rules to handle internationalization using Unicode and IDN, but for this simple (ASCII) case boils down to the same thing. But, as above and contrary to what I said before, openssl *should* work for this case after all, which means you don't need the CA to change, which is probably good. (I think it's still confusing to people to have almost-identical DNs, but since most people won't even know how to look at a certificate, that's less of a problem.) s_server.out is the output of the openssl s_server command. The only error this shows is that one client cert (and card) -- I assume client2006.pem -- is rejected for cert expired. Which it is; the notAfter is Oct 12 23:59:59 2011 GMT. In order to convince the ca's supplier to change the old scard I should: 1) Show him the rfc 2) Inform all scard users to stop using the old scard 3) Give all scard users the new scard Are there some better argumentations to persuade the sa's supplier? If it were necessary I'd say probably yes, but as above I don't think it's necessary. Try using cards (certs) that are under the old 2006 root but NOT expired, and (now) I'll bet they do work. Sorry for the unnecessary alarm and confusion. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-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
Re: SSL_VERIFY_PEER and self-signed certificates
Hello Jakob, All commands described in my mail are executed from the client. I only try to perform server authentication by certificate, and my problem is that the client is not able to perform this authentication. I think that my server code is ok (but I may be wrong). On the server side, the private key and certificate are initialised as follows: SSL_CTX_use_PrivateKey_file(ctx, server.key, SSL_FILETYPE_PEM) SSL_CTX_use_certificate_file(ctx, server.crt, SSL_FILETYPE_PEM) All commands return proper exit code and I added the following call to check if everything is properly initialised : SSL_CTX_check_private_key(ctx) And it also returns proper exit code. Regards, Brice 2013/5/29 Jakob Bohm jb-open...@wisemo.com: Hello, Just a little hint: Your questions would be much clear if you state, at each step, which end of the connection each thing applies to, like at what end did you call SSL_CTX_load_verify_locations, at what end did you get which error messages etc. I suspect this may be the cause of some confusion here. On 5/29/2013 9:14 AM, Brice André wrote: Hello Dave, Once again, thanks for your help. I performed a test yesterday with the instruction SSL_CTX_use_certificate_file(tx,path_to_file, SSL_FILETYPE_PEM); replaced by SSL_CTX_load_verify_locations(ctx, path_to_file, NULL); Where path_to_file points to my file server.crt. The function returns 1 so, I expect my certificate to be properly initialised. But, whn I perform the connect, I get an error. The corresponding error message is : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed After the connect failed, the function SSL_get_peer_certificate(ssl) returns NULL and the function SSL_get_verify_result(ssl) returns 18 (X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT), which is exactly the same problem as before. My server is also printing an error message: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Regards, Brice 2013/5/28 Dave Thompson dthomp...@prinpay.com: From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Monday, 27 May, 2013 23:45 You are right, I am using a self-signed certificate for use by my server. In fact, I do not perform client authentication in my application : only the server shall be authentified by ssl. The client is authentified by another mechanism. Here are how I generate my RSA key and my certificate: openssl genrsa -des -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -days 2 -in server.csr -signkey server.key -out server.crt Asides: you could combine those: req -new -newkey rsa:2048 replaces genrsa req -new -x509 replaces x509 -signkey but the way you have it works. Also, 54+ years is a pretty long period! The only file that I transmit to my client is server.crt. Good. I think that all those files are OK because, on the server side, once everything is initialised, the command SSL_CTX_check_private_key is happy with it. In order to initialise the truststore of my client, I copy the server.crt file somewhere, and I execute the following command : SSL_CTX_use_certificate_file(ctx,path_to_file, SSL_FILETYPE_PEM); Bad. That attempts to use the cert as the *client's* cert, which has no effect because you didn't give the client the privatekey, and rightly (the client shouldn't have the server's privatekey, and you say you don't want ssl-level client-auth anyway). Do I have to generate another file ? Or do I have to perform another configuration in my client ? There are two standard ways to set up a truststore for openssl lib, in your case the client's truststore to trust the server. SSL_CTX_load_verify_locations (ctx, fileornull, pathornull) tells openssl to use the (selfsigned root and/or EE) certs concatenated in one PEM file named by fileornull if not null, and/or stored in individual PEM files using the subjecthash for link or name in directory pathornull if not null. SSL_CTX_set_default_verify_paths (ctx) does something similar but using environment-variable settings or compiled default values for the file and/or path, usually systemwide places (for all apps on the system) something like /etc/openssl/cert.pem and /etc/openssl/certdir . Most of the commandline utilities allow you to specify -CAfile and/or -CApath for the first way, or default to the second way. Since you have one cert in one PEM file, the fileornull (CAfile) approach is simplest. 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: Question about FIPS Enabled OPENSSL in WINCE platform
Hi Steve, Thanks a lot for you clarification. The user guide states : = The Microsoft Windows mobile operating systems are among the most challenging platform for the FIPS Object Module, due to the wide variation among individual system configurations. Representative Build These instructions are necessarily only representative of one specific configuration and may require substantial modification for specific Windows CE or EC platforms. Typically a version of Visual Studio will be used. In this representative example the following environment variables are defined in a .BAT file, setenv-wince6.bat: @set FIPS_SIG=perl /opensslfips2.0/util/msincore = It also states: The standard OpenSSL build with the fips option will use a base address for libeay32.dll of 0xFB0 by default. In the event of a clash with another dynamically loaded library which will trigger runtime relocation of libeay32.dll, the integrity check will fail with the error FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED A base address conflict can be resolved by shuffling the other DLLs or re-compiling OpenSSL with an alternative base address specified with the --with-baseaddr= option. == This procedure is perfectly valid for user mode dll but for kernel mode dll if we try --with-baseaddr=0xc08a ( 3GB) , the build will fail. Though link.exe prohibits the use of base address 3GB, editbin.exe enables us to follow user guide completely by allowing base address to be defined 3GB. EditBin.exe can only modify binary and cannot link. So I have defined set FIPS_SIG=perl mymsincore.pl and in mymsincore.pl I call editbin.exe allowing us follow the effect of --with-baseaddr=0xc08a, then call normal msincore script (which is in effect doing the exact same thing stated in user guide). This produces binary which can set FIPS mode properly. Now my question is since I have followed following clause: - ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... Is the libeay32.dll thus produced a FIPS140-2 validated module. Thanks in advance, -Abhijit On Tue, May 28, 2013 at 8:28 PM, Steve Marquess marqu...@opensslfoundation.com wrote: On 05/28/2013 09:28 AM, Abhijit Ray Chaudhury wrote: Hi, We have an application running in WINCE Kernel address space as a DLL. We require to have it compiled against FIPS enabled openSSL. ... To get around the problem we have added following line in msincore script, all the build procedure and files remains exactly same as in source distribution. == system(editbin /nologo /rebase:base=0xc08a @ARGV[$#ARGV] @ARGV[$#ARGV].rel); == Please let me know : a If the libeay32.dll thus produced will still be FIPS 140-2 validated module ? The answer to that question is prominently featured on the NIST CMVP web site, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747: ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... and is also clearly stated in the Security Policy document (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf) -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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Signature of EVP_DigestVerifyFinal()
Dear all I'm a total OpenSSL newbie, so please be kind. While writing my C++ program, I stumbled over the somewhat strange signature of EVP_DigestVerifyFinal: int EVP_DigestVerifyFinal(EVP_MD_CTX *ctx, unsigned char *sig, size_t siglen); I'm pretty sure that the second argument (sig) should actually be of type const unsigned char*. I come to this conclusion since the EVP_DigestVerifyFinal() function only calls EVP_PKEY_verify() and the EVP_MD_CTX::pctx::pmeth::verifyctx function pointer which is set via EVP_PKEY_meth_set_verifyctx(). Both of those functions take a const unsigned char* argument, so there is simply no point in having the sig argument to EVP_DigestVerifyFinal being modifiable. Am I missing something here? I tried googling for this, but nothing useful turned up. Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS Enabled OPENSSL in WINCE platform
On 05/29/2013 05:40 AM, Abhijit Ray Chaudhury wrote: Hi Steve, Thanks a lot for you clarification. The user guide states : ... Now my question is since I have followed following clause: - ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... Is the libeay32.dll thus produced a FIPS140-2 validated module. Did you modify the tarball? Yes. Is modifying the tarball allowed? No. I didn't write that statement that appears so prominently on the NIST CMVP web site, but I can't think of a way to state it more clearly. You're confusing two different things: the requirements for claiming FIPS 140-2 validation, and getting the code to run. Most definitely not the same thing. -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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Signature of EVP_DigestVerifyFinal()
Dear all I'm a total OpenSSL newbie, so please be kind. While writing my C++ program, I stumbled over the somewhat strange signature of EVP_DigestVerifyFinal: int EVP_DigestVerifyFinal(EVP_MD_CTX *ctx, unsigned char *sig, size_t siglen); I'm pretty sure that the second argument (sig) should actually be of type const unsigned char*. I come to this conclusion since the EVP_DigestVerifyFinal() function only calls EVP_PKEY_verify() and the EVP_MD_CTX::pctx::pmeth::verifyctx function pointer which is set via EVP_PKEY_meth_set_verifyctx(). Both of those functions take a const unsigned char* argument, so there is simply no point in having the sig argument to EVP_DigestVerifyFinal being modifiable. Am I missing something here? I tried googling for this, but nothing useful turned up. Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ssl_connect fails Windows Non-blocking
OpenSSL latest version I use. This is the bad sequence, client and server are already connected at TCP level: Client -- ssl_connect returns WANT_READ, so I've wait for next select/WSAEventSelect --- SSLv2/v3 read server hello A Server -- ssl_accept returns WANT_READ, same wait --- SSLv3 read client certificate A Client -- READ event arrives, call again ssl_connect which now returns -1 (error:0005:lib(0):func(0):DH lib) Server -- WRITE event arrives and must wait READ event, however Client disconnects Sometimes it connects well, with this sequence: Client -- ssl_connect returns WANT_READ, so I've wait for next select/WSAEventSelect --- SSLv2/v3 read server hello A Server -- ssl_accept returns WANT_READ, same wait --- SSLv3 read client certificate A Client -- READ event arrives Client -- call again ssl_connect returns -1 (error:0002:lib(0):func(0):system lib) == wants more READ --- SSLv3 read server session ticket A Server -- WRITE event arrives Server -- READ event arrives Server -- call again ssl_accept returns succesfully Client -- READ event arrives Client -- call ssl_connect returns succesfully Any ideas? Thanks in advance. -- View this message in context: http://openssl.6102.n7.nabble.com/ssl-connect-fails-Windows-Non-blocking-tp45348.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
3DES functions in FIPS mode
Hi Are the functions in include/openssl/des.h available in FIPS mode? I am using OpenSSL 1.0.1c. I need to use 3DES in my code. I do not see a EVP wrapper for it. Please let me know if have I missed seeing 3DES wrappers in EVP. Thanks Rahul
Re: 3DES functions in FIPS mode
On 5/29/2013 3:30 PM, Rahul Godbole wrote: Hi Are the functions in include/openssl/des.h available in FIPS mode? I am using OpenSSL 1.0.1c. I need to use 3DES in my code. I do not see a EVP wrapper for it. Please let me know if have I missed seeing 3DES wrappers in EVP. EVP_des_ede (for 112 bit two key 3DES) EVP_des_ede3 (for 168 bit three key 3DES) (Each name comes in variants for the different modes of operation) They are all in evp.h Another issue, to which I do not know the answer, is if the FIPS module includes 3DES (formal name TDEA) or not, since the whole point of FIPS mode is to artificially restrict OpenSSL to algorithms which are currently approved for use inside the US Government. 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS Enabled OPENSSL in WINCE platform
Steve, Apologies if I got you confused. I am writing below what I did : === 1. downloaded openssl-fips-2.0.3. 2. exported variables as dictated by user guide and suited for my build enviroment. exported FIPS_SIG=perl mymsincore.pl (I have written mymsincore.pl which calls editbin.exe, that gives the desired base address, followed by msincore script came with openssl-fips) 3. ms\do_ms gave me fipscanister.lib 4. built wcecompat library as stated in user guide. 5. compiled openssl as mentioned in user guide. = Note that, NONE of the files in openssl-fips-2.0.3 tarball was modified. The only trick I had to use to follow the user guide is the environment variable refers to mymsincore.pl which calls msincore script came with openssl-fips. I guess I am supposed to adapt the environment variable according to my need. kindly let me know if I have created FIPS 140-2 validated binary. Thanks in advance , -Abhijit On Wed, May 29, 2013 at 5:37 PM, Steve Marquess marqu...@opensslfoundation.com wrote: On 05/29/2013 05:40 AM, Abhijit Ray Chaudhury wrote: Hi Steve, Thanks a lot for you clarification. The user guide states : ... Now my question is since I have followed following clause: - ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... Is the libeay32.dll thus produced a FIPS140-2 validated module. Did you modify the tarball? Yes. Is modifying the tarball allowed? No. I didn't write that statement that appears so prominently on the NIST CMVP web site, but I can't think of a way to state it more clearly. You're confusing two different things: the requirements for claiming FIPS 140-2 validation, and getting the code to run. Most definitely not the same thing. -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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS Enabled OPENSSL in WINCE platform
On 05/29/2013 11:34 AM, Abhijit Ray Chaudhury wrote: Steve, Apologies if I got you confused. I am writing below what I did : === 1. downloaded openssl-fips-2.0.3. 2. exported variables as dictated by user guide and suited for my build enviroment. exported FIPS_SIG=perl mymsincore.pl (I have written mymsincore.pl which calls editbin.exe, that gives the desired base address, followed by msincore script came with openssl-fips) 3. ms\do_ms gave me fipscanister.lib 4. built wcecompat library as stated in user guide. 5. compiled openssl as mentioned in user guide. = Note that, NONE of the files in openssl-fips-2.0.3 tarball was modified. Ah, good. A colleague who was paying better attention than I also pointed that out. Even though it sounds silly, you can't modify *any* files in the workarea created by unpacking the source distribution tarball. So in particular you can't modify the file ./openssl-fips-2.0.3/util/msincore, even though that file isn't actually used in the generation of the FIPS module proper. You can't for instance even modify the file ./openssl-fips-2.0.3/README.FIPS; the CMVP was especially adamant on that point when we did the very first validations, which is why I (over)emphasize it. The only trick I had to use to follow the user guide is the environment variable refers to mymsincore.pl which calls msincore script came with openssl-fips. I guess I am supposed to adapt the environment variable according to my need. kindly let me know if I have created FIPS 140-2 validated binary. Ok, if you created the FIPS module (the fipscanister.lib and technically also the fipscanister.lib.sha1, fips_premain.c, fips_premain.c.sha1 files) *exactly* as documented in the Security Policy and without *any* modification of the ./openssl-fips-2.0.3/ workarea, *then* you have a FIPS module you can claim as FIPS 140-2 validated. Having achieved that your question is really about limitations on the subsequent process used to link that validated FIPS module into an executable application. Here the restrictions are far less severe; you have only two responsibilities: 1) Verify the digests of the FIPS module (fipscanister.o, fips_premain.c) against the *.sha1 files. 2) Set the integrity test digest. The msincore utility does that in your situation. Different incore utilities are used for other cross-compiled platforms. Note the CMVP does not (to our knowledge) impose any specific requirement on the incore utility. While it can be very dangerous to presume an understanding of their thought processes, as they see FIPS 140-2 validation from a very different perspective than the typical software developer/engineer, I believe it goes something like this: The integrity digest is verified at runtime as part of the mandated POST (Power Up Self Test, a key FIPS 140-2 concept). The code that performs that check is carefully and formally reviewed and tested. That integrity test consists of calculating a HMAC-SHA1 digest of the TXT and RODATA segments of the FIPS module as mapped in live memory, and comparing it against a known value embedded in the module. The incore utility (in this case) stores that known value. No formal testing is required for that utility because for given any fixed string of bits (i.e. the TXT+RODATA segments) there is only one possible correct value for the HMAC-SHA1 digest. If an untested and defective incore utility stores an incorrect value then the POST will fail, therefore only the latter need be formally tested. BTW I have drafted a page in our new wiki: http://wiki.openssl.org/index.php/FIPS_Build_Guidelines that will hopefully over time expand into a useful resource for your class of question. It's a tricky topic. -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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EVP_DecryptUpdate
Hello, Can I use the same input and output buffer in calls to EVP_DecryptUpdate and the EVP_DecryptUpdate_final_ex functions? The padding is on by default. And my application will always feed 8k chunks in the update and the final calls? Is it safe to then do the decrypt in place?
RE: SSL_VERIFY_PEER and self-signed certificates
From: owner-openssl-us...@openssl.org On Behalf Of Brice André Sent: Wednesday, 29 May, 2013 03:14 I performed a test yesterday with the instruction SSL_CTX_use_certificate_file(tx,path_to_file, SSL_FILETYPE_PEM); replaced by SSL_CTX_load_verify_locations(ctx, path_to_file, NULL); Where path_to_file points to my file server.crt. The function returns 1 so, I expect my certificate to be properly initialised. To be exact, the client's trustore containing your cert. One possible problem here: _load_verify_ accepts a sequence of (PEM) certs, including zero, skipping any invalid format(s). Make sure the client's file is/contains an exact copy of the server's certfile, at least the lines from dash-BEGIN to dash-END, including eol (either NL or CRLF okay) after each line (including the dash-END line) and body lines not longer than 76 characters. If you copied the content by cut-and-paste or sending in an email or something like that, these sometimes go wrong. If you transferred the file using FTP or SCP or similar, they shouldn't. (FTP mode A may convert but not add/delete/move eols, and that is okay.) But, whn I perform the connect, I get an error. The corresponding error message is : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed After the connect failed, the function SSL_get_peer_certificate(ssl) returns NULL and the function SSL_get_verify_result(ssl) returns 18 (X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT), which is exactly the same problem as before. It should work and does for me, as long as the client CAfile is exactly the (selfsigned) cert the server is using; and you don't have KeyUsage excluding certSign, but that gives a different error. If it isn't damaged per above and you have commandline on the client try openssl s_client -connect host:port -CAfile same.server.crt.file and see what it says for Verify return code at the end of SSL-session (note s_client unlike a real app will proceed even if verify error). My server is also printing an error message: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca That's consistent; if the client decides the server cert is bad, the client aborts the handshake with an alert like that. (The exact alert may vary SSL vs TLS, but always some alert.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PKCS12 keystore creation failing in fips mode
We are trying to create pkcs12 keystore in FIPS mode using OpenSSL 1.0.1 and it fails with the following error 9uo8bYe2YpDmqEgC[root@vos-i/usr/local/platform/bin/openssl pkcs12 -export -in tomcat.pem -inkey ../keys/tomcat_priv.pem -out tomcat.keystore Enter Export Password: Verifying - Enter Export Password: 4151633544:error:060A60A3:digital envelope routines:FIPS_CIPHERINIT:disabled for fips:fips_enc.c:142: 4151633544:error:06074078:digital envelope routines:EVP_PBE_CipherInit:keygen failure:evp_pbe.c:205: 4151633544:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error:p12_decr.c:83: 4151633544:error:2306C067:PKCS12 routines:PKCS12_item_i2d_encrypt:encrypt error:p12_decr.c:175: 4151633544:error:23073067:PKCS12 routines:PKCS12_pack_p7encdata:encrypt error:p12_add.c:202: The same command works in FIPS mode. So I have the following questions 1. Is there a way to work around issue and still be able to create pkcs12 format keystore in FIPS mode. 2. This command worked in earlier version of openssl like 0.9.8l in FIPS mode. What has changed in 1.0.1 That it has stopped working in FIPS mode. Any pointers will be appreciated. Thanks, Anamitra __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS12 keystore creation failing in fips mode
On Wed, May 29, 2013, Anamitra Dutta Majumdar (anmajumd) wrote: We are trying to create pkcs12 keystore in FIPS mode using OpenSSL 1.0.1 and it fails with the following error 9uo8bYe2YpDmqEgC[root@vos-i/usr/local/platform/bin/openssl pkcs12 -export -in tomcat.pem -inkey ../keys/tomcat_priv.pem -out tomcat.keystore Enter Export Password: Verifying - Enter Export Password: 4151633544:error:060A60A3:digital envelope routines:FIPS_CIPHERINIT:disabled for fips:fips_enc.c:142: 4151633544:error:06074078:digital envelope routines:EVP_PBE_CipherInit:keygen failure:evp_pbe.c:205: 4151633544:error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error:p12_decr.c:83: 4151633544:error:2306C067:PKCS12 routines:PKCS12_item_i2d_encrypt:encrypt error:p12_decr.c:175: 4151633544:error:23073067:PKCS12 routines:PKCS12_pack_p7encdata:encrypt error:p12_add.c:202: The same command works in FIPS mode. So I have the following questions 1. Is there a way to work around issue and still be able to create pkcs12 format keystore in FIPS mode. 2. This command worked in earlier version of openssl like 0.9.8l in FIPS mode. What has changed in 1.0.1 That it has stopped working in FIPS mode. Any pointers will be appreciated. That's a bug in 1.0.1 in that it tries to use an unapproved algorithm in FIPS mode. Workaround: use the -descert option. 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
