Re: [openssl-users] FIPS: Common method executed in case of error

2015-03-12 Thread jonetsu


 From: Dr. Stephen Henson st...@openssl.org 
 Date: 03/10/15 20:04 

 I mean you could add a callback to FIPS_mode_set using
 FIPS_post_set_callback: see the fips_test_suite.c application
 for an example. The supplied callback is called during each
 POST, continuous RNG and pairwise consistency checks. The op
 value is set to FIPS_POST_FAIL if any test fails.

This is basically what was also suggested by Henrik in a related
thread recently, which I understood being implemented in an
application.  The variation here would be that the callback is
part of the library, located in FIPS_mode_set() in o_fips.c, with
the callback itself being defined elsewhere in the same file.

A potentially useful case for some applications that do not need
to be further modified would be for the library to automatically
know that it has to run in FIPS mode.  Eg. to automatically call
FIPS_mode_set() at load time, based on a env. var. or some other
external sign.




___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[openssl-users] FIPS: Common method executed in case of error

2015-03-10 Thread jonetsu
Hello,

  Is there a method that is always in the path of execution when a crypto error 
occurs ?  The reason for asking is that I would like to very slightly modify 
the OpenSSL FIPS version so that it will write a file in tmpfs when an error 
occurs.  That place will be observed by another app using inotify.  Granted, 
modifying OpenSSL FIPS will void its FIPS certification.  But then, the whole 
unit will be validated.  Having a single place to modify would be quite an 
extraordinary thing.  I have asked recently about a related topic and got some 
replies regarding the modification of applications, although modifying the 
library would provide a single package to modify.  Steve has replied that 
indeed the validation will be lost - I wonder if that would have any impact on 
the total validation costs for a whole unit, OS and apps ?  Would a 
non-modified FIPS OpenSSL library reduce the
validation costs ?

Any comments and suggestions welcomed, regards.



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] FIPS: Common method executed in case of error

2015-03-10 Thread jonetsu


 From: Steve Marquess marqu...@openssl.com 
 Date: 03/10/15 08:56 

Hello,

  Thanks for your reply.

 You're talking about a Level 2 validation (or higher)? You most
 definitely do *not* want to include the OS or applications in the
 cryptographic module boundary for Level 1.

It's a level 2.  The behaviour of the unit as a whole is
validated.  As an example amongst many, there will be no Linux
console prompt available in FIPS mode.

 I think you're going to be shocked at the cost (in time and money) to
 validate a hacked OpenSSL FIPS module, compared to using it as-is or a
 change letter update.

That brings a question.  I'm currently using 1.0.1k with the 2.0
FIPS module for development purposes.  This may seem a bit blunt,
but, is it possible at all to use 1.0.1k to benefit from the FIPS
validation ?  Based on recent comments I would think not.  Going
back to a pre-heartbleed version ?  Is there any way to benefit
from the gained OpenSSL FIPS validation at all ?

 That's because the CMVP has introduced a number of new
 requirements since the current FIPS module was validated (in
 2012), and any new validation will now need to satisfy
 those.

Again, is there any benefit to be gained from using a once
validated OpenSSL FIPS ?  What would be the bugs fixed/ security
updates trade-off ?

 That means not only non-trivial code hacks unrelated to yours,
 but also a new paper shuffle for the arm waving (DTR)
 components of the validation process.  The cost of the latter
 dwarfs the former; which is why we have not attempted a new
 validation ourselves.

Hmmm... If this goes through, would it be possible for OpenSSL to
benefit from any validation our unit can get ?

 But, that cost could be dwarfed in turn by that of a Level 2 or 3
 validation of a turnkey system including OS and apps.

Thanks again for your comments, much appreciated.

Regards.







___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] FIPS: Common method executed in case of error

2015-03-10 Thread Steve Marquess
On 03/10/2015 08:20 AM, jonetsu wrote:
 ...
 Steve has replied that indeed the validation will be lost - I wonder
 if that would have any impact on the total validation costs for a
 whole unit, OS and apps ? 

You're talking about a Level 2 validation (or higher)? You most
definitely do *not* want to include the OS or applications in the
cryptographic module boundary for Level 1.

 Would a non-modified FIPS OpenSSL library
 reduce the validation costs ?

I think you're going to be shocked at the cost (in time and money) to
validate a hacked OpenSSL FIPS module, compared to using it as-is or a
change letter update. That's because the CMVP has introduced a number
of new requirements since the current FIPS module was validated (in
2012), and any new validation will now need to satisfy those. That means
not only non-trivial code hacks unrelated to yours, but also a new paper
shuffle for the arm waving (DTR) components of the validation process.
The cost of the latter dwarfs the former; which is why we have not
attempted a new validation ourselves.

But, that cost could be dwarfed in turn by that of a Level 2 or 3
validation of a turnkey system including OS and apps.

-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
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] FIPS: Common method executed in case of error

2015-03-10 Thread Dr. Stephen Henson
On Tue, Mar 10, 2015, jonetsu wrote:

 Hello,
 
   Is there a method that is always in the path of execution when a crypto
 error occurs ?  The reason for asking is that I would like to very slightly
 modify the OpenSSL FIPS version so that it will write a file in tmpfs when
 an error occurs.  That place will be observed by another app using inotify. 
 Granted, modifying OpenSSL FIPS will void its FIPS certification.  But then,
 the whole unit will be validated.  Having a single place to modify would be
 quite an extraordinary thing.  I have asked recently about a related topic
 and got some replies regarding the modification of applications, although
 modifying the library would provide a single package to modify.  Steve has
 replied that indeed the validation will be lost - I wonder if that would
 have any impact on the total validation costs for a whole unit, OS and apps
 ?  Would a non-modified FIPS OpenSSL library reduce the validation costs ?
 
 Any comments and suggestions welcomed, regards.
 

Although you cannot modify the FIPS module itself without voiding the
validation you *can* change the FIPS capable OpenSSL.

You might (for example) change FIPS_mode_set() to always add a callback
which logs any errors.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] FIPS: Common method executed in case of error

2015-03-10 Thread jonetsu


 Is there a method that is always in the path of execution when a crypto error 
 occurs ?  

It looks like fips_set_selftest_fail() would be a likely candidate where to 
create an empty file on a tmpfs in order to let the OS know about the error.

Comments and suggestions welcomed.  Based on your experience with FIPS 
validation process, and many customers/sponsors, do you think that having a 
ever so slightly modified OpenSSL FIPS code would increase validation costs for 
a whole unit (OS and apps) ?  Recently Steve, I think, has mentioned that the 
cost for an initial OpenSSL FIPS validation was well into the 6 numbers.  Would 
this type of figure be added to a project if OpenSSL FIPS is modified ?  I 
think the labs could go with a diff and see how simple the modification is.

Regards.



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] FIPS: Common method executed in case of error

2015-03-10 Thread jonetsu


 From: Dr. Stephen Henson st...@openssl.org 
 Date: 03/10/15 10:21 

 Although you cannot modify the FIPS module itself without voiding the
 validation you *can* change the FIPS capable OpenSSL.

 You might (for example) change FIPS_mode_set() to always add a callback
 which logs any errors.

I see.  So this would actually enable benefiting (saving
validation costs) from an intact recent OpenSSL 1.0.1k with all
security fixes.

FIPS_mode_set() is very straightforward to patch although it
would only catch startup errors.  Not the eventual errors from
tests that are executed before each crypto use.  And not the
continuous RNG tests.

Within the scope of OpenSSL itself, there is a
fips_cipher_abort() that is called for each algo.  That macro
could perhaps be a good place.  Although it would still not catch
continuous RNG test failures.

Regards.






___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] FIPS: Common method executed in case of error

2015-03-10 Thread Dr. Stephen Henson
On Tue, Mar 10, 2015, jonetsu wrote:

 
 
  From: Dr. Stephen Henson st...@openssl.org 
  Date: 03/10/15 10:21 
 
  Although you cannot modify the FIPS module itself without voiding the
  validation you *can* change the FIPS capable OpenSSL.
 
  You might (for example) change FIPS_mode_set() to always add a callback
  which logs any errors.
 
 I see.  So this would actually enable benefiting (saving
 validation costs) from an intact recent OpenSSL 1.0.1k with all
 security fixes.
 

Only the FIPS module is validated: the FIPS capable OpenSSL uses it.

So you can modify (within reason) the FIPS capable OpenSSL without affecting
the validation . So you can use OpenSSL 1.0.1l or 1.0.2 with the FIPS module.

 FIPS_mode_set() is very straightforward to patch although it
 would only catch startup errors.  Not the eventual errors from
 tests that are executed before each crypto use.  And not the
 continuous RNG tests.
 

I mean you could add a callback to FIPS_mode_set using FIPS_post_set_callback:
see the fips_test_suite.c application for an example. The supplied callback is
called during each POST, continuous RNG and pairwise consistency checks. The
op value is set to FIPS_POST_FAIL if any test fails.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users