Not FIPS if app uses other crypto?
Locked
 
|
The following appears in the FIPS 140-2 Validation
presentation from Linux World Expo.
(oss-institute.org/OpenSSL/LWE_040406_BOF.pdf) Page 23: FIPS mode requirements: * The application must use only OpenSSL for all
cryptography. Where can I find this in the security policy? Are there any exceptions? What if “other
crypto” is also FIPS validated? What is the purpose of the requirement? |
Re: Not FIPS if app uses other crypto?
|
|
This should probably be clarified: The application must only use
FIPS-approved modules for all cryptography. However, most FIPS-approved modules cost a lot of money -- there are two that do not, but OpenSSL is the only one available for UNIX systems that does not, and it's the only one that can be distributed in source form. FIPS-approved modules, once put into FIPS mode (and thus running their internal consistency checks), will only operate with FIPS-approved algorithms. (Interestingly, AES-256 is NOT an approved algorithm, as AES only specifies 128 bits.) The modules must be used in compliance with their security policies. Key data (and entropy) needs to be overwritten in non-module memory as soon as possible. Various other issues exist as well. To simplify things, "All cryptography must be done using OpenSSL FIPS functions" is the easiest way to ensure that only FIPS-approved algorithms and modes are used. It's short, simple, and to the point. -Kyle H On 4/11/06, Lyon, Jay <[hidden email]> wrote: > > > > The following appears in the FIPS 140-2 Validation presentation from Linux > World Expo. (oss-institute.org/OpenSSL/LWE_040406_BOF.pdf) > > > > Page 23: FIPS mode requirements: > > * The application must use only OpenSSL for all cryptography. > > > > Where can I find this in the security policy? > > > > Are there any exceptions? What if "other crypto" is also FIPS validated? > > > > What is the purpose of the requirement? > > > > OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Re: Not FIPS if app uses other crypto?
|
|
It's my mistake, I believe. AES does specify 128, 192, and 256-bit
keylengths, but only 128-bit block lengths. (I misread something on the CSRC website.) (I'm copying this back to the list because it's something that I should clear up.) -Kyle H On 4/12/06, Wes Kussmaul <[hidden email]> wrote: > Kyle Hamilton wrote: > > > (Interestingly, AES-256 is NOT an approved algorithm, as > > AES only specifies 128 bits.) > > OK, now I'm confused. In John Walker's JavaScrypt (not to be confused > with javascript) description one reads: > > =================== > JavaScrypt's encryption facilities use the Advanced Encryption Standard > (AES) adopted by the United States as Federal Information Processing > Standard 197. AES supports key lengths of 128, 192, and 256 bits; > JavaScrypt uses 256 bit keys exclusively. > =================== > > Is Walker mistaken? > > > -- > Wes Kussmaul > CIO > The Village Group OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
|
|
In reply to this post by Lyon, Jay
Kyle, thanks for your response. If you don't mind answering one more
question, it will help clarify things for me. Assume a hypothetical crypto toolkit; OpenEXX has recently emerged and is a leader in a crypto technology that is useful for memory constrained devices. It has been recently FIPS validated using the same recompile model introduced by OpenSSL. Its security policy is similar to OpenSSL (they are modeled the same). These tools are philosophically in sync. My application, for example; ScatterData will benefit from both of these technologies and will have both tools in FIPS mode at the same time (overlapping threads, etc). Will the non-hypothetical OpenSSL be in a valid FIPS mode in this circumstance? Thanks... ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Re: Not FIPS if app uses other crypto?
|
|
On 4/12/06, Lyon, Jay <[hidden email]> wrote:
> Kyle, thanks for your response. If you don't mind answering one more > question, it will help clarify things for me. > > Assume a hypothetical crypto toolkit; OpenEXX has recently emerged and > is a leader in a crypto technology that is useful for memory constrained > devices. It has been recently FIPS validated using the same recompile > model introduced by OpenSSL. Its security policy is similar to OpenSSL > (they are modeled the same). These tools are philosophically in sync. > > My application, for example; ScatterData will benefit from both of these > technologies and will have both tools in FIPS mode at the same time > (overlapping threads, etc). Will the non-hypothetical OpenSSL be in a > valid FIPS mode in this circumstance? Please be aware that I am not a FIPS specialist, so I'm going to have to express my understanding; I hope that if I'm incorrect, someone with more knowledge will correct me. FIPS operates on a "security perimeter" concept -- that is, an individual cryptographic module is essentially a "black box" with a defined API. As long as cryptographically-significant state -- keys, entropy, initialization vectors, passphrases, ciphertext, plaintext -- are all maintained inside that security perimeter, then that module is in a valid FIPS mode. That said, however, two separate devices are two separate security perimeters. So, In order to move any data between FIPS devices, the application must first use the defined API of one of those devices to export that information out of that device's perimeter (in a manner compliant with that device's security policy), and then use the defined API of the other device to import that information into that other device's perimeter (in a manner compliant with that other device's security policy). In addition, keying material accepted from the user (passphrases and such) must be cleared from memory as soon as practical, and keys themselves are subject to the security modules' security policies. (Some modules require that keys be "non-exportable" if so marked, for example. This is especially true for modules that manage their own keystores, but may also be a concern in a hypothetical scenario such as the one you describe -- if that's the case, you will only be able to manipulate data encrypted with a given key in the module that created an manages that key's usage, even if the operation would be easier or quicker or even merely possible in the other module.) So, the answer to your question is "it depends on how you use them". -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Re: Not FIPS if app uses other crypto?
|
|
It seems to me that the question is this: can an application use two
FIPS-certified toolkits at the same time? For example, a FIPS certified device for doing private key operations, and FIPS software for doing symmetric key operations. The answer is yes. (There will be issues and difficulties, of course: sharing key material, for example, may be impossible.) Most applications using FIPS toolkits use hardware devices or binary-only libraries, where the API is not changeable. As an open source distribution, the caveat to "stay within the boundaries" by not using other than the FIPS API's is worth particular mention. /r$ -- SOA Appliances Application Integration Middleware ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
RE: Not FIPS if app uses other crypto?
|
|
In reply to this post by Lyon, Jay
I'm new to the OpenSSL/FIPS discussion and I am not familiar with
OpenSSL for FIPS but I do have some experience with FIPS certification. First of all I assume that we are talking about FIPS 140-2 [or 3 but that's not mandatory anywhere yet]. There are also FIPS publications on the cryptographic algorithm transforms and the NIST offers certifications that a particular implementation meets the standard. Those NIST certifications are necessary but by no means sufficient to get a FIPS 140 certification. As Kyle Hamilton mentioned in an earlier post FIPS 140 certifies a cryptographic module and a lot of effort goes in to guaranteeing that no secret passes over that boundary. If you are building a crypto board or chip then the boundary can be the board or chip. If you are using software then the CM boundary is going to be the box that contains your whole system. I am not familiar with what OpenSSL FIPS version offers but there are lots of things that could be helpful to gaining FIPS 140 certification. Examples are cryptographically signed and tested bootloading, certain self test capabilities and administrator authentication are some of the requirements. In short using OpenSSL may help in getting FIPS 140 but it is not the whole story by a long shot. Now perhaps someone familiar with Open SSL FIPS could explain what makes it FIPS. Regards, Hank Cohen Hifn > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Richard Salz > Sent: Wednesday, April 12, 2006 8:10 PM > To: [hidden email] > Subject: Re: Not FIPS if app uses other crypto? > > It seems to me that the question is this: can an application use two > FIPS-certified toolkits at the same time? For example, a > FIPS certified > device for doing private key operations, and FIPS software for doing > symmetric key operations. The answer is yes. (There will be > issues and > difficulties, of course: sharing key material, for example, may be > impossible.) > > Most applications using FIPS toolkits use hardware devices or > binary-only > libraries, where the API is not changeable. As an open source > distribution, the caveat to "stay within the boundaries" by not using > other than the FIPS API's is worth particular mention. > > /r$ > > -- > SOA Appliances > Application Integration Middleware > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
RE: Not FIPS if app uses other crypto?
|
|
> First of all I assume that we are talking about FIPS 140-2 [or 3 but
> that's not mandatory anywhere yet]. Mandatory? 140-3 isn't even issued yet. :) /r$ -- SOA Appliances Application Integration Middleware ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
RE: Not FIPS if app uses other crypto?
|
|
In reply to this post by Lyon, Jay
Right you are! My mistake.
I knew it was under development but no draft has been issued yet. Here's a new question. When OpenSSL got it's NIST algorithm certifications were they only for specific processors? I notice that the Open Source Software Institute certs were done on a HP 9000 whereas other certs using the OpenSSL library were done on PowerPC and Pentium. What other support for FIPS 140 are in the OpenSSL-fips library? (It is perfectly fine to say RTFM but kindness would dictate that you point me to the proper one.) Regards, Hank Cohen > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Richard Salz > Sent: Thursday, April 13, 2006 7:00 PM > To: [hidden email] > Cc: [hidden email]; [hidden email] > Subject: RE: Not FIPS if app uses other crypto? > > > First of all I assume that we are talking about FIPS 140-2 [or 3 but > > that's not mandatory anywhere yet]. > > Mandatory? 140-3 isn't even issued yet. :) > > /r$ > > -- > SOA Appliances > Application Integration Middleware > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Re: Not FIPS if app uses other crypto?
|
|
The security policy states that the fips-approved sources, when
compiled on a system that allows for verification that the compiled library has not been changed (via a fairly complex examination of process executable space), create a library that is FIPS 140-2 validated. I think that's probably what took so long. -Kyle H On 4/13/06, Hank Cohen <[hidden email]> wrote: > Right you are! My mistake. > I knew it was under development but no draft has been issued yet. > > Here's a new question. > When OpenSSL got it's NIST algorithm certifications were they only for > specific processors? I notice that the Open Source Software Institute > certs > were done on a HP 9000 whereas other certs using the OpenSSL library > were done on PowerPC and Pentium. > > What other support for FIPS 140 are in the OpenSSL-fips library? > (It is perfectly fine to say RTFM but kindness would dictate that you > point me to the proper one.) > > Regards, > Hank Cohen > > > > -----Original Message----- > > From: [hidden email] > > [mailto:[hidden email]] On Behalf Of Richard Salz > > Sent: Thursday, April 13, 2006 7:00 PM > > To: [hidden email] > > Cc: [hidden email]; [hidden email] > > Subject: RE: Not FIPS if app uses other crypto? > > > > > First of all I assume that we are talking about FIPS 140-2 [or 3 but > > > that's not mandatory anywhere yet]. > > > > Mandatory? 140-3 isn't even issued yet. :) > > > > /r$ > > > > -- > > SOA Appliances > > Application Integration Middleware > > > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List [hidden email] > > Automated List Manager [hidden email] > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Re: Not FIPS if app uses other crypto?
|
|
In reply to this post by Hank Cohen
On Thu, Apr 13, 2006, Hank Cohen wrote:
> Right you are! My mistake. > I knew it was under development but no draft has been issued yet. > > Here's a new question. > When OpenSSL got it's NIST algorithm certifications were they only for > specific processors? I notice that the Open Source Software Institute > certs > were done on a HP 9000 whereas other certs using the OpenSSL library > were done on PowerPC and Pentium. > Well in outline... As well as those specific platforms any platform where the FIPS module can be build from the unmodified validated source by strictly following the build procedure is covered. That is: ./config fips make make install Those instructions must work to the letter: no other options are permissible. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Re: Not FIPS if app uses other crypto?
|
|
There's no provision for --prefix= as an option?
-Kyle H On 4/14/06, Dr. Stephen Henson <[hidden email]> wrote: > On Thu, Apr 13, 2006, Hank Cohen wrote: > > > Right you are! My mistake. > > I knew it was under development but no draft has been issued yet. > > > > Here's a new question. > > When OpenSSL got it's NIST algorithm certifications were they only for > > specific processors? I notice that the Open Source Software Institute > > certs > > were done on a HP 9000 whereas other certs using the OpenSSL library > > were done on PowerPC and Pentium. > > > > Well in outline... > > As well as those specific platforms any platform where the FIPS module can be > build from the unmodified validated source by strictly following the build > procedure is covered. That is: > > ./config fips > make > make install > > Those instructions must work to the letter: no other options are permissible. > > Steve. > -- > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage > OpenSSL project core developer and freelance consultant. > Funding needed! Details on homepage. > Homepage: http://www.drh-consultancy.demon.co.uk > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Re: Not FIPS if app uses other crypto?
|
|
On Fri, Apr 14, 2006, Kyle Hamilton wrote:
> There's no provision for --prefix= as an option? > > No but that doesn't matter in practice... The "validated module" is the object file fipscanister.o. Once that and the associated hash files have been built and installed using the approved prodecure the validated source is no longer required and can be discarded. A second build of a later version of OpenSSL 0.9.7 can make use of it: the latest 0.9.7 snapshots do this automatically now and give a fatal error if the validated module can't be found. The second build can specify --prefix and any other options required. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
«
Return to OpenSSL - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |