Re: [openssl-users] 755413103 error on fingerprint match

[Brian Jost]

Update on this. Here is the log from my app. Any idea why my calculated sig
is 0...?

2016-08-03 11:47:49.988 App[32127:2253410] FIPS_mode_set failed: 755413103
2016-08-03 11:47:49.988 App[32127:2253410] Embedded sig:
7363808352b3d84a797c91df813afcb58bf924b4
2016-08-03 11:47:49.988 App[32127:2253410] Calculated sig:



Here is my code inside of my main.m files for my ios app

int mode = FIPS_mode(), ret = 0;

unsigned long err = 0;

if(mode == 0)

{

ret = FIPS_mode_set(1 /*on*/);

err = ERR_get_error();

}

else

{

ret = FIPS_mode_set(0 /*off*/);

err = ERR_get_error();

}

if(1 != ret)

NSLog(@"FIPS_mode_set failed: %lu", err);

NSMutableString* f1 = [NSMutableString stringWithCapacity:MAGIC_20*2 + 8];

for(unsigned int i = 0; i < MAGIC_20; i++)

[f1 appendFormat:@"%02x", FIPS_signature[i]];

NSLog(@"Embedded sig: %@", f1);

unsigned char calculated[20] = {};

unsigned int ret2 = FIPS_incore_fingerprint(calculated, sizeof(calculated));

if(ret2 != MAGIC_20)

{

// Failure - wipe it.

// Default is 0x00. We use 0xFF to differentiate

memset(calculated, 0xFF, sizeof(calculated));

}

NSMutableString* f2 = [NSMutableString stringWithCapacity:MAGIC_20*2 + 8];

for(unsigned int j = 0; j < MAGIC_20; j++)

[f2 appendFormat:@"%02x", calculated[j]];

NSLog(@"Calculated sig: %@", f2);

On Wed, Aug 3, 2016 at 10:39 AM, Brian Jost  wrote:

> I modified a script to get a FIPS compliant iOS library and am having
> issues with the fingerprint. I had to add a CPU adjustment to the
> incore_macho but I wouldn't think that would cause a FIPS fingerprint
> mismatch.
>
> https://gist.github.com/jostster/ebbc6925c668b632d8b185293080256c
>
> Does anyone have any thoughts how to overcome this error so that I can
> have a FIPS compliant iOS library for armv7, armv7s and arm64?
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 755413103 error on fingerprint match

[Brian Jost]

I modified a script to get a FIPS compliant iOS library and am having
issues with the fingerprint. I had to add a CPU adjustment to the
incore_macho but I wouldn't think that would cause a FIPS fingerprint
mismatch.

https://gist.github.com/jostster/ebbc6925c668b632d8b185293080256c

Does anyone have any thoughts how to overcome this error so that I can have
a FIPS compliant iOS library for armv7, armv7s and arm64?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS: using libcrypto.so ?

[jonetsu]

Thanks for the explanation.

> Just link against the library produced by the FIPS capable
> OpenSSL build.  If, for some reason, that only produced
> libcrypto.a, then you need to investigate why — perhaps you
> passed “no-shared” when running the config script?

The confusion came from trying to use methods such as FIPS_evp_sha1,
FIPS_evp_sha224, FIPS_evp_sha256.  As Steve replied yesterday, these should
not be used (is there any case in which they would ?) as the EVP_sha*
methods will automatically use the FIPS enabled ones when FIPS mode is
active.

For instance doing an 'objdump -T' on libcrypto.so.1.0.0 will show some
FIPS* methods, but not the sha* for instance.  Which now I see is a normal
thing since they are not to be used.

Thanks.




--
View this message in context: 
http://openssl.6102.n7.nabble.com/FIPS-using-libcrypto-so-tp67694p67705.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

Re: [openssl-users] FIPS: using libcrypto.so ?

[Thomas Francis, Jr.]

> On Aug 2, 2016, at 1:59 PM, jonetsu  wrote:
> 
> The current FIPS User Guide mentions:
> 
>  "3.3 Creation of Shared Libraries
> 
>  The FIPS Object Module is not directly usable as a shared
>  library, but it can be linked into an application that is a
>  shared library. A “FIPS compatible” OpenSSL distribution will
>  automatically incorporate an available FIPS Object Module into
>  the libcrypto shared library when built using the fips
>  option (see §4.2.3)."
> 
> Does the first sentence mean that there should be an intermediate, user
> created, .so that itself uses libcrypto.a ?

I think you’re confusing the FIPS Object Module with libcrypto.  You might also 
be confusing the libcrypto produced from your FIPS build, and the libcrypto 
produced by a FIPS capable OpenSSL.  The former is what you get when you 
compile the software found in, e.g., openssl-fips-2.0.11.tar.gz, while the 
latter is produced when you compile from a regular OpenSSL release (e.g. 
openssl-1.0.2g.tar.gz).  These are three different things.  The libcrypto from 
the FIPS build isn’t used in any of your link steps.

The FIPS Object Module may be (and on most systems is) compiled as a shared 
object (not a .so file, but a shared object).  Because it’s not a library, you 
can’t simply link it.  Some systems allow shared objects to be accessed via 
dlopen(), and the warning is to indicate that doing so is inappropriate, even 
when it’s possible.

Noting that you can link it into a shared executable or library indicates that 
if you have a shared library or executable that you want to link the FIPS 
Object Module into, that you may do so.  The usual way to do this is to link 
libcrypto.a (from a FIPS capable OpenSSL build) and use the fipsld script.  
Even if you don’t do it the usual way (e.g. you want to link only the FIPS 
Object Module), then you may, but you still have to follow all the rules laid 
out in the security policy (e.g. do everything the fipsld script is doing).  
This probably not what one wants to do.  It’s far more likely that one wants to 
use the FIPS capable OpenSSL shared library directly.  That’s what the second 
part is about...

> What does the second part mean ?  The FOM will be included in the shared
> library (assuming the libcrypto.so file) ?  If so, then why wouldn't it be
> available directly ?  A clarification in perhaps simpler terms over what
> seems to be an explanation in the User Guide would be much appreciated.

It means that when you create a FIPS capable OpenSSL, if you compiled libcrypto 
as a shared library, that libcrypto shared library will incorporate the FIPS 
Object Module, following the security policy.  This means that you can use that 
shared library as you would any other shared library, and still be able to 
enable FIPS mode.  This is what most people who want to use a shared library 
will want to do.

> In practical terms, is it possible for an application to link against a
> libcrypto.so that provides all needed FIPS symbols ?

In general, yes.  In practice, it depends.  Compiling a FIPS capable OpenSSL 
might not create a shared library on your system.  In that case, you must link 
libcrypto.a, and use the fipsld script (or equivalent) when you link it.  I 
think that the vast majority of systems will compile it as a shared library, 
though, without any intervention on your part.

> If it's not, can you
> give an example overview in which an application already using OpenSSL
> (libcrypto.so) but now supporting FIPS, can still use libcrypto.so with full
> FIPS support ?

Just link against the library produced by the FIPS capable OpenSSL build.  If, 
for some reason, that only produced libcrypto.a, then you need to investigate 
why — perhaps you passed “no-shared” when running the config script?

> Is the only answer to now have the application linked
> against libcrypto.a ?
> 
> Thanks !
> 
> 
> 
> 
> --
> View this message in context: 
> http://openssl.6102.n7.nabble.com/FIPS-using-libcrypto-so-tp67694.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