Re: Inconsistent behavior between FIPS and non-FIPS AES
Steve, Thank you for the confirmation. It would be useful to put known issues & exceptions in the Users Guide, particularly for the FIPS validated versions, as they have such long cycles between when they will be revalidated. Thanks, -AJ - Original Message - From: Dr. Stephen Henson To: openssl-users@openssl.org Cc: Sent: Tuesday, October 16, 2012 11:35 AM Subject: Re: Inconsistent behavior between FIPS and non-FIPS AES On Tue, Oct 16, 2012, AJ wrote: > Any other comments on the actual issue here? > > I don't believe the inconsistency is the expected way the API should work. > It's a bug. The fix was applied to non-validated versions of OpenSSL but was too late to be included in the last validation. 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
Re: Inconsistent behavior between FIPS and non-FIPS AES
Any other comments on the actual issue here?
I don't believe the inconsistency is the expected way the API should work.
Thanks,
-AJ
- Original Message -
From: AJ
To: "openssl-users@openssl.org"
Cc:
Sent: Friday, October 12, 2012 7:14 PM
Subject: Re: Inconsistent behavior between FIPS and non-FIPS AES
Hi Jeff,
Thanks for the response ... all the return values are 1, including setting the
FIPS mode.
I had removed the checks in this stripped down example code to get to my point
and try to show the relevant portions, and minimize the code for someone to
look at.
-AJ
- Original Message -
From: Jeffrey Walton
To: openssl-users@openssl.org
Cc:
Sent: Friday, October 12, 2012 6:44 PM
Subject: Re: Inconsistent behavior between FIPS and non-FIPS AES
Hi aunt.jomamma,
You have ignored every return value. You should probably start by
checking all return values.
If you check all return values *and* assert all the checks, you will
have self debugging code. I find self debugging code the best code of
all, but I'm kind of lazy.
> 2) Is there purposely a difference in behavior between the FIPS and non-FIPS
> versions,...
Did FIPS_mode_set succeed? It returns 1 on success.
Jeff
On Fri, Oct 12, 2012 at 4:40 PM, AJ wrote:
> Hi,
>
> I've noticed an inconsistency between the behavior of AES_CTR in FIPS and
> non-FIPS modes.
> I am using openssl-1.0.1c and openssl-fips-2.0.
>
> The following code demonstrates the issue:
>
> 1 #include
> 2 #include
> 3 #include "openssl/evp.h"
> 4
> 5 #define MSG_SIZE 14
> 6 const unsigned char *key = (unsigned char *)"1234567890123456";
> 7 const unsigned char *iv = (unsigned char *)"0101010101010101";
> 8
> 9 int main(void) {
> 10
> 11 unsigned char in_1[MSG_SIZE];
> 12 unsigned char in_2[MSG_SIZE];
> 13 unsigned char out_1[MSG_SIZE];
> 14 unsigned char out_2[MSG_SIZE];
> 15 int out_len_1, out_len_2;
> 16
> 17 EVP_CIPHER_CTX ctx_1, ctx_2;
> 18
> 19 memset ( in_1, 0, MSG_SIZE );
> 20 memset ( in_2, 0, MSG_SIZE );
> 21
> 22 EVP_CIPHER_CTX_init( &ctx_1 );
> 23 EVP_EncryptInit( &ctx_1, EVP_aes_128_ctr(), key, iv );
> 24 EVP_EncryptUpdate( &ctx_1, out_1, &out_len_1, in_1, MSG_SIZE );
> 25 EVP_EncryptInit( &ctx_1, NULL, NULL, iv );
> 26 EVP_EncryptUpdate( &ctx_1, out_1, &out_len_1, in_1, MSG_SIZE );
> 27
> 28 FIPS_mode_set(1); /* Enable FIPS mode */
> 29
> 30 EVP_CIPHER_CTX_init( &ctx_2 );
> 31 EVP_EncryptInit( &ctx_2, EVP_aes_128_ctr(), key, iv );
> 32 EVP_EncryptUpdate( &ctx_2, out_2, &out_len_2, in_2, MSG_SIZE );
> 33 EVP_EncryptInit( &ctx_2, NULL, NULL, iv );
> 34 EVP_EncryptUpdate( &ctx_2, out_2, &out_len_2, in_2, MSG_SIZE );
> 35
> 36 if ( memcmp( out_1, out_2, MSG_SIZE ) == 0 ) {
> 37 printf("Buffers are equal.\n\n");
> 38 } else {
> 39 printf("Buffers are not equal.\n\n");
> 40 }
> 41
> 42 return 0;
> 43 }
>
> The reason for the difference outputs is that there is a difference in the
> EVP_EncryptInit code (lines 25 and 33) for the 2 modes.
>
> In the non-FIPS mode, line 25 will reset the ctx_1->num to zero. This is
> done in EVP_CipherInit_ex(), line 240:
> 239 case EVP_CIPH_CTR_MODE:
> 240 ctx->num = 0;
> 241 /* Don't reuse IV for CTR mode */
> 242 if(iv)
> 243 memcpy(ctx->iv, iv,
> EVP_CIPHER_CTX_iv_length(ctx));
> 244 break;
> 245
>
> However, in FIPS mode, the equivalent line does not reset ctx_2->num. This
> is from FIPS_cipherinit(), lines 210-215:
> 210 case EVP_CIPH_CTR_MODE:
> 211 /* Don't reuse IV for CTR mode */
> 212 if(iv)
> 213 memcpy(ctx->iv, iv,
> M_EVP_CIPHER_CTX_iv_length(ctx));
> 214 break;
> 215
>
>
> I can make my program work if I change line 33 from:
> EVP_EncryptInit( &ctx_2, NULL, NULL, iv );
> to:
> EVP_EncryptInit( &ctx_2, EVP_aes_128_ctr(), key, iv );
>
> This explicitly specifies the cipher and key again. From the docs, it
> appears that I should be able to set them to NULL and have it work, if they
> don't need to be updated, and that is how it works in the non-FIPS mode.
>
> Questions:
>
> 1)
Re: Inconsistent behavior between FIPS and non-FIPS AES
Hi Jeff,
Thanks for the response ... all the return values are 1, including setting the
FIPS mode.
I had removed the checks in this stripped down example code to get to my point
and try to show the relevant portions, and minimize the code for someone to
look at.
-AJ
- Original Message -
From: Jeffrey Walton
To: openssl-users@openssl.org
Cc:
Sent: Friday, October 12, 2012 6:44 PM
Subject: Re: Inconsistent behavior between FIPS and non-FIPS AES
Hi aunt.jomamma,
You have ignored every return value. You should probably start by
checking all return values.
If you check all return values *and* assert all the checks, you will
have self debugging code. I find self debugging code the best code of
all, but I'm kind of lazy.
> 2) Is there purposely a difference in behavior between the FIPS and non-FIPS
> versions,...
Did FIPS_mode_set succeed? It returns 1 on success.
Jeff
On Fri, Oct 12, 2012 at 4:40 PM, AJ wrote:
> Hi,
>
> I've noticed an inconsistency between the behavior of AES_CTR in FIPS and
> non-FIPS modes.
> I am using openssl-1.0.1c and openssl-fips-2.0.
>
> The following code demonstrates the issue:
>
> 1 #include
> 2 #include
> 3 #include "openssl/evp.h"
> 4
> 5 #define MSG_SIZE 14
> 6 const unsigned char *key = (unsigned char *)"1234567890123456";
> 7 const unsigned char *iv = (unsigned char *)"0101010101010101";
> 8
> 9 int main(void) {
> 10
> 11 unsigned char in_1[MSG_SIZE];
> 12 unsigned char in_2[MSG_SIZE];
> 13 unsigned char out_1[MSG_SIZE];
> 14 unsigned char out_2[MSG_SIZE];
> 15 int out_len_1, out_len_2;
> 16
> 17 EVP_CIPHER_CTX ctx_1, ctx_2;
> 18
> 19 memset ( in_1, 0, MSG_SIZE );
> 20 memset ( in_2, 0, MSG_SIZE );
> 21
> 22 EVP_CIPHER_CTX_init( &ctx_1 );
> 23 EVP_EncryptInit( &ctx_1, EVP_aes_128_ctr(), key, iv );
> 24 EVP_EncryptUpdate( &ctx_1, out_1, &out_len_1, in_1, MSG_SIZE );
> 25 EVP_EncryptInit( &ctx_1, NULL, NULL, iv );
> 26 EVP_EncryptUpdate( &ctx_1, out_1, &out_len_1, in_1, MSG_SIZE );
> 27
> 28 FIPS_mode_set(1); /* Enable FIPS mode */
> 29
> 30 EVP_CIPHER_CTX_init( &ctx_2 );
> 31 EVP_EncryptInit( &ctx_2, EVP_aes_128_ctr(), key, iv );
> 32 EVP_EncryptUpdate( &ctx_2, out_2, &out_len_2, in_2, MSG_SIZE );
> 33 EVP_EncryptInit( &ctx_2, NULL, NULL, iv );
> 34 EVP_EncryptUpdate( &ctx_2, out_2, &out_len_2, in_2, MSG_SIZE );
> 35
> 36 if ( memcmp( out_1, out_2, MSG_SIZE ) == 0 ) {
> 37 printf("Buffers are equal.\n\n");
> 38 } else {
> 39 printf("Buffers are not equal.\n\n");
> 40 }
> 41
> 42 return 0;
> 43 }
>
> The reason for the difference outputs is that there is a difference in the
> EVP_EncryptInit code (lines 25 and 33) for the 2 modes.
>
> In the non-FIPS mode, line 25 will reset the ctx_1->num to zero. This is
> done in EVP_CipherInit_ex(), line 240:
> 239 case EVP_CIPH_CTR_MODE:
> 240 ctx->num = 0;
> 241 /* Don't reuse IV for CTR mode */
> 242 if(iv)
> 243 memcpy(ctx->iv, iv,
> EVP_CIPHER_CTX_iv_length(ctx));
> 244 break;
> 245
>
> However, in FIPS mode, the equivalent line does not reset ctx_2->num. This
> is from FIPS_cipherinit(), lines 210-215:
> 210 case EVP_CIPH_CTR_MODE:
> 211 /* Don't reuse IV for CTR mode */
> 212 if(iv)
> 213 memcpy(ctx->iv, iv,
> M_EVP_CIPHER_CTX_iv_length(ctx));
> 214 break;
> 215
>
>
> I can make my program work if I change line 33 from:
> EVP_EncryptInit( &ctx_2, NULL, NULL, iv );
> to:
> EVP_EncryptInit( &ctx_2, EVP_aes_128_ctr(), key, iv );
>
> This explicitly specifies the cipher and key again. From the docs, it
> appears that I should be able to set them to NULL and have it work, if they
> don't need to be updated, and that is how it works in the non-FIPS mode.
>
> Questions:
>
> 1) Should I need to explicitly specifies the cipher and key again in
> EVP_EncryptInit(), if I am only updating the IV? (i.e. should I be able to
> put NULL for key and cipher).
> 2) Is there purposely a difference in behavior between the FIPS and non-FIPS
> versions, or is this a bug? My understanding was that they *should* work
> interchangeabl
Inconsistent behavior between FIPS and non-FIPS AES
Hi,
I've noticed an inconsistency between the behavior of AES_CTR in FIPS and
non-FIPS modes.
I am using openssl-1.0.1c and openssl-fips-2.0.
The following code demonstrates the issue:
1 #include
2 #include
3 #include "openssl/evp.h"
4
5 #define MSG_SIZE 14
6 const unsigned char *key = (unsigned char *)"1234567890123456";
7 const unsigned char *iv = (unsigned char *)"0101010101010101";
8
9 int main(void) {
10
11 unsigned char in_1[MSG_SIZE];
12 unsigned char in_2[MSG_SIZE];
13 unsigned char out_1[MSG_SIZE];
14 unsigned char out_2[MSG_SIZE];
15 int out_len_1, out_len_2;
16
17 EVP_CIPHER_CTX ctx_1, ctx_2;
18
19 memset ( in_1, 0, MSG_SIZE );
20 memset ( in_2, 0, MSG_SIZE );
21
22 EVP_CIPHER_CTX_init( &ctx_1 );
23 EVP_EncryptInit( &ctx_1, EVP_aes_128_ctr(), key, iv );
24 EVP_EncryptUpdate( &ctx_1, out_1, &out_len_1, in_1, MSG_SIZE );
25 EVP_EncryptInit( &ctx_1, NULL, NULL, iv );
26 EVP_EncryptUpdate( &ctx_1, out_1, &out_len_1, in_1, MSG_SIZE );
27
28 FIPS_mode_set(1); /* Enable FIPS mode */
29
30 EVP_CIPHER_CTX_init( &ctx_2 );
31 EVP_EncryptInit( &ctx_2, EVP_aes_128_ctr(), key, iv );
32 EVP_EncryptUpdate( &ctx_2, out_2, &out_len_2, in_2, MSG_SIZE );
33 EVP_EncryptInit( &ctx_2, NULL, NULL, iv );
34 EVP_EncryptUpdate( &ctx_2, out_2, &out_len_2, in_2, MSG_SIZE );
35
36 if ( memcmp( out_1, out_2, MSG_SIZE ) == 0 ) {
37 printf("Buffers are equal.\n\n");
38 } else {
39 printf("Buffers are not equal.\n\n");
40 }
41
42 return 0;
43 }
The reason for the difference outputs is that there is a difference in the
EVP_EncryptInit code (lines 25 and 33) for the 2 modes.
In the non-FIPS mode, line 25 will reset the ctx_1->num to zero. This is done
in EVP_CipherInit_ex(), line 240:
239 case EVP_CIPH_CTR_MODE:
240 ctx->num = 0;
241 /* Don't reuse IV for CTR mode */
242 if(iv)
243 memcpy(ctx->iv, iv,
EVP_CIPHER_CTX_iv_length(ctx));
244 break;
245
However, in FIPS mode, the equivalent line does not reset ctx_2->num. This is
from FIPS_cipherinit(), lines 210-215:
210 case EVP_CIPH_CTR_MODE:
211 /* Don't reuse IV for CTR mode */
212 if(iv)
213 memcpy(ctx->iv, iv,
M_EVP_CIPHER_CTX_iv_length(ctx));
214 break;
215
I can make my program work if I change line 33 from:
EVP_EncryptInit( &ctx_2, NULL, NULL, iv );
to:
EVP_EncryptInit( &ctx_2, EVP_aes_128_ctr(), key, iv );
This explicitly specifies the cipher and key again. From the docs, it appears
that I should be able to set them to NULL and have it work, if they don't need
to be updated, and that is how it works in the non-FIPS mode.
Questions:
1) Should I need to explicitly specifies the cipher and key again
in EVP_EncryptInit(), if I am only updating the IV? (i.e. should I be able to
put NULL for key and cipher).
2) Is there purposely a difference in behavior between the FIPS and non-FIPS
versions, or is this a bug? My understanding was that they *should* work
interchangeably.
Thanks,
AJ
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: FIPS 2.0: fipsld on cross-compile
Hi Steve, Thanks for all the help -- I think I've things sorted out now. Here are some of the issues I've had cross-compiling for Android. Just some feedback -- maybe they'll help someone running into the same. 1) Building as shared libraries is straightforward, but they give versioned libraries (i.e. libcrypto.so.1.0.0). Unfortunately, the Android packaging system only takes shared libraries ending with .so. And just changing the name doesn't work, as during the linking phase, other libraries use the internal library name which also has the version number. So, on loading the library, it thinks there is a mismatch. As we cannot modify the build (to maintain FIPS validation), there are only hacky-type solutions -- such as changing filename at runtime. As another user suggested, it would be helpful if version numbers could be put in front of the .so (i.e. libcrypto.1.0.0.so). 2) Building as static libraries requires using fipsld while linking to get the HMAC fingerprints. I originally wanted to just wrap the 2 static libraries into a one shared library with everything. I was using the -Wl,--whole-archive flags to get everything, which works fine using normal gcc. But with fipsld, it complains about multiple definitions (of items in fipscanister.o). You can specify --allow-multiple-definition to get past these warning, but then it will not get the right fingerprints. It will fail fingerprint test on FIPS_mode_set(1). 3) I modified my builds to accommodate building with static libraries. So I've now got the appropriate Makefile which calls to fipsld during linking into the JNI shared library. This works fine, but is some work, as the normal Android ndk-build system will not support things like defining CC. So you either need to hack the ndk-build files, or build it externally from the normal ndk-build system (as a prebuilt library). 4) In fipsld (line 116) calls "ar" to remove fipscanister.o. This is a native-host call, and fails on MacOS building for Android. [This does work fine on Linux building for Android however.] This really should be calling the cross-compile "ar", and not the host version. *** I can modify the fipsld script on MacOS to make this work, but will this invalidate the FIPS validation??? *** Thanks to you and others for all the hard work putting out this great tool. And a big thanks for all of the quick responses and support. Regards, AJ - Original Message - From: Dr. Stephen Henson To: openssl-users@openssl.org Cc: Sent: Friday, July 20, 2012 4:22 PM Subject: Re: FIPS 2.0: fipsld on cross-compile On Fri, Jul 20, 2012, AJ wrote: > OK, that worked -- built my library using fipsld. However, on running, I am > STILL getting fingerprint validation failure when calling FIPS_mode_set(1). > > 1552985864:error:2D06B06F:FIPS > routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:229: > > Any good ideas on how to debug why? > Do you get this error with the openssl utility entering FIPS mode using the commands I mentioned in a previous message? 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
Re: FIPS 2.0: fipsld on cross-compile
OK, that worked -- built my library using fipsld. However, on running, I am STILL getting fingerprint validation failure when calling FIPS_mode_set(1). 1552985864:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:229: Any good ideas on how to debug why? - Original Message - From: Dr. Stephen Henson To: openssl-users@openssl.org Cc: Sent: Friday, July 20, 2012 1:35 PM Subject: Re: FIPS 2.0: fipsld on cross-compile On Fri, Jul 20, 2012, AJ wrote: > 1) I am cross-compiling a static FIPS enabled OpenSSL library for Android > (using Linux host). > > I have generated the libssl.a and lib crypto.a. > I am trying to use the "fipsld" tool, as documented in Sec 5.3.1 in the User > Guide. > > However, I am running into the following error: > ../openssl-fips-2.0/fips/fipsld: line 137: > ../openssl-fips-2.0/fips/../fips/fips_premain_dso: cannot execute binary file > > > fips_premain_dso does not seem to be a linux executable (... nor does this > work when I try to link using MacOS cross-compile environment). > > > > Am I doing this right for cross-compile? > > If the fipsld script needs any modification, would this violate any FIPS > validation? > You need to set the FIPS_SIG environment variable to point to the incore script from the validated tarball. 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
FIPS 2.0: fipsld on cross-compile
1) I am cross-compiling a static FIPS enabled OpenSSL library for Android (using Linux host). I have generated the libssl.a and lib crypto.a. I am trying to use the "fipsld" tool, as documented in Sec 5.3.1 in the User Guide. However, I am running into the following error: ../openssl-fips-2.0/fips/fipsld: line 137: ../openssl-fips-2.0/fips/../fips/fips_premain_dso: cannot execute binary file fips_premain_dso does not seem to be a linux executable (... nor does this work when I try to link using MacOS cross-compile environment). Am I doing this right for cross-compile? If the fipsld script needs any modification, would this violate any FIPS validation? Thanks, AJ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS: Incore fingerprint check fails on Android?
Thanks Stephen! I still have the "multiple definitions" problem when trying to build on my Mac, but it works fine when I build in Linux. (Maybe something in my environment). However, now I run into a problem where my other library expects to link to the openssl libraries with version number: libssl.so.1.0.0 and lib crypto.so.1.0.0. The Android-NDK only handles prebuilt shared libraries which end with ".so" -- it won't package libraries with version numbers at the end of the filename. There doesn't appear to be a good (non-hacky) way of getting around that point, unless there is a way to get OpenSSL to build shared libraries without version numbers: http://stackoverflow.com/questions/11491065/linking-with-versioned-shared-library-android-ndk http://grokbase.com/t/gg/android-ndk/124n8n4rzn/sharedlib-dependency-mixed-mode-apk So the best option at this point would seem to going back to static build, and getting fipsld working for the android build. Unless I am missing something. Thanks, AJ - Original Message - From: Dr. Stephen Henson To: openssl-users@openssl.org Cc: Sent: Wednesday, July 18, 2012 6:55 PM Subject: Re: FIPS: Incore fingerprint check fails on Android? On Wed, Jul 18, 2012, AJ wrote: > This explains it -- thank you -- I was using a static library -- so I would > need to use fipsld, if I continue to use static. > > However, knowing this, I wanted to try with shared OpenSSL library instead, > but my build fails on "multiple definition" errors. > The only difference I made, was to add "shared" to the config line, when > building openssl-1.0.1c: > > ./config fips --with-fipslibdir=/usr/local/ssl/fips-2.0/lib/ shared > make depend > > make > > make install > > Don't use --with-fipslibdir instead use --with-fipsdir instead or you can set the FIPSDIR environment variable while building the validated module and the FIPS capable OpenSSL. So you'd instead do: ./config fips --with-fipsdir=/usr/local/ssl/fips-2.0 shared I just tried this with my setup and it worked OK. 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
Re: FIPS: Incore fingerprint check fails on Android?
This explains it -- thank you -- I was using a static library -- so I would need to use fipsld, if I continue to use static. However, knowing this, I wanted to try with shared OpenSSL library instead, but my build fails on "multiple definition" errors. The only difference I made, was to add "shared" to the config line, when building openssl-1.0.1c: ./config fips --with-fipslibdir=/usr/local/ssl/fips-2.0/lib/ shared make depend make make install Build log snippet: = if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \ (cd ..; make libcrypto.so.1.0.0); \ fi [ -z "libcrypto" ] || arm-linux-androideabi-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -march=armv7-a -mandroid -I/Users/richard/android-ndk-r8/platforms/android-14/arch-arm/usr/include -B/Users/richard/android-ndk-r8/platforms/android-14/arch-arm/usr/lib -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM -Iinclude \ -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \ /usr/local/ssl/fips-2.0/lib/fips_premain.c /usr/local/ssl/fips-2.0/lib/fipscanister.o \ libcrypto.a -ldl ar: fipscanister.o: not found in archive libcrypto.a(fipscanister.o): In function `fips_ec_gfp_simple_set_jprojective_coordinates_gfp': fips_canister.c:(.text+0x1b9ec): multiple definition of `fips_ec_gfp_simple_set_jprojective_coordinates_gfp' /usr/local/ssl/fips-2.0/lib//fipscanister.o:fips_canister.c:(.text+0x1b9ec): first defined here libcrypto.a(fipscanister.o): In function `fips_ec_point_set_affine_coordinates_gf2m': fips_canister.c:(.text+0x16448): multiple definition of `fips_ec_point_set_affine_coordinates_gf2m' /usr/local/ssl/fips-2.0/lib//fipscanister.o:fips_canister.c:(.text+0x16448): first defined here libcrypto.a(fipscanister.o): In function `FIPS_drbg_get_app_data': fips_canister.c:(.text+0x37f34): multiple definition of `FIPS_drbg_get_app_data' /usr/local/ssl/fips-2.0/lib//fipscanister.o:fips_canister.c:(.text+0x37f34): first defined here libcrypto.a(fipscanister.o): In function `fips_rsa_padding_add_none': fips_canister.c:(.text+0x283f8): multiple definition of `fips_rsa_padding_add_none' /usr/local/ssl/fips-2.0/lib//fipscanister.o:fips_canister.c:(.text+0x283f8): first defined here Any ideas? Thanks, AJ - Original Message - From: Dr. Stephen Henson To: openssl-users@openssl.org Cc: Sent: Wednesday, July 18, 2012 4:15 PM Subject: Re: FIPS: Incore fingerprint check fails on Android? On Wed, Jul 18, 2012, AJ wrote: > Its my application producing the error. > > I've been reading more... perhaps I need to get Android build to link via > fipsld to get the valid fingerprint? > > Does this sound right? Any tips? > How are you linking your application? If it is to the OpenSSL shared libraries then no further steps are needed as the fingerprint is embedded in the shared library. You should NOT use the fipsld utility to link. If you are linking against static libraries then you do need to make use of the fipsld utility. Check the OpenSSL utility can enter FIPS mode by doing something like this: OPENSSL_FIPS=1 openssl version -a OPENSSL_FIPS=1 openssl md5 somefile OPENSSL_FIPS=1 openssl sha1 somefile The md5 command should fail with an error message indicating that algorithm isn't allowed in FIPS mode. 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
Re: FIPS: Incore fingerprint check fails on Android?
I'm running on 4.0.4 and 2.3.4, with same results on both. - Original Message - From: Jeffrey Walton To: openssl-users@openssl.org Cc: Sent: Wednesday, July 18, 2012 2:27 PM Subject: Re: FIPS: Incore fingerprint check fails on Android? On Wed, Jul 18, 2012 at 11:15 AM, Aunt Jomamma wrote: > Sorry if this is duplicate, but I had an issue with the mailer, and not sure > if this went... > > I have successfully built openssl-fips-2.0 + openssl-1.0.1c for Android using > ndk-r8. > I am doing cross-compile on Mac OSX. > > However, I cannot pass FIPS_mode_set(1). > I get the following error: "FIPS > routines:FIPS_check_incore_fingerprint:fingerprint does not match" > > I am using the incore script provided from openssl-fips-2.0/util/incore. > > My setup is as follows: > > # Edit this to wherever you unpacked the NDK > export ANDROID_NDK=/home/android-ndk-r8 > > # Edit to wherever you put incore script > export FIPS_SIG=$PWD/openssl-fips-2.0/util/incore > > >PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin:$PATH; > export PATH > export MACHINE=armv7l > export RELEASE=2.6.32.GMU > export SYSTEM=android > export ARCH=arm > export CROSS_COMPILE="arm-linux-androideabi-" > export ANDROID_DEV="$ANDROID_NDK/platforms/android-14/arch-arm/usr" > export HOSTCC=gcc > > Any ideas why I cannot pass incore fingerprint validation? Do I need > anything special wrt incore on cross-compile? > What Android OS is being used on the device? Android 4.1 recently achieved full ASLR. ASLR might be the problem since randomizing shared objects and program load adresses is diametrically opposed to the FIPS check. A thread on recent platform security changes can be found at http://groups.google.com/group/android-security-discuss/browse_thread/thread/d585aa8062964673. Jeff __ 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
Re: FIPS: Incore fingerprint check fails on Android?
Its my application producing the error.
I've been reading more... perhaps I need to get Android build to link via
fipsld to get the valid fingerprint?
Does this sound right? Any tips?
Thanks.
"Dr. Stephen Henson" wrote:
>On Wed, Jul 18, 2012, Aunt Jomamma wrote:
>
>> Sorry if this is duplicate, but I had an issue with the mailer, and not sure
>> if this went...
>>
>> I have successfully built openssl-fips-2.0 + openssl-1.0.1c for Android
>> using ndk-r8.
>> I am doing cross-compile on Mac OSX.
>>
>> However, I cannot pass FIPS_mode_set(1).
>> I get the following error: "FIPS
>> routines:FIPS_check_incore_fingerprint:fingerprint does not match"
>>
>
>What is producing that error? Is it the openssl utility or an application
>you've developed?
>
>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
:��I"Ϯ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
