All,
We are very pleased to announce the addition of a new team member.
Krishna Sankar is joining our team as the new Squeak Cryptography Certification Validation Officer.
The goal of this position is to set a path for the cryptography team to ensure that the Squeak Cryptography code meets the FIPS common criteria http://niap.bahialab.com/cc-scheme/cc_docs/index.cfm which a first step on the path to FIPS certification.
Krishna has a distinguished security background, has worked with a number of government standards, has lead a workshop for Cisco on NIST PKI http://middleware.internet2.edu/pki04/ , is a lead author for Cisco Press WLAN Security book - http://www.ciscopress.com/authors/bio.asp?a=9ed11cfa-9067-4205-8110-76358f31 7825&rl=1 , and also contributes to OLPC. We are very excited to have Krishna join our efforts.
We are still searching for volunteers. I would like to encourage anyone that is even remotely interested in cryptography to join our efforts. This is the perfect time for you to join the group http://lists.squeakfoundation.org/mailman/listinfo/cryptography .
If you need cryptography in your applications, working on our common criteria validation effort will help you learn about cryptography and will teach you about the common criteria process so that you can apply what you learn to your own application. We are working to divide the tasks into manageable chunks so that individual developers can pick up a single piece and contribute. We are organizing the effort so that we can track, validate and get proper feedback as to our progress. We have no deadline, only a path to follow.
Please help me welcome Krishna Sankar,
Ron Teitelbaum Squeak Cryptography Team Leader President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com
Welcome, Krishna!
In the grand scheme of things, how can the integrity of the cryptographic component module be verifiably maintained in Squeak? Because of the NIST/FIPS requirement of a security boundary, the implementation must be an immutable "black box" -- put data in, get data out.
OpenSSL has a FIPS-validated component (no longer available for obtainment, but people who obtained it before it was made no-longer-available) that would operate in the context of an extension to the interpreter. [They're working on a follow-up validation for a to-be-made-available version of the library.] There is also at least one FIPS-validated, freely-available module available for Windows other than OpenSSL.
I bring this up only because I can't see how such a black box could be created (and its internal state verifiable at all times) unless it's not written within the Squeak environment itself. There isn't any means that I know of "sealing" classes and preventing data from being examined -- thus there isn't any means of enforcing a "black box" boundary the way that FIPS requires.
Any thoughts on the matter? Anyone?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Krishna Sankar is joining our team as the new Squeak Cryptography Certification Validation Officer.
Hi Kyle,
I discussed this with the certification lab that I spoke too. It is a very interesting question and one that we will need to address when it is time to do the actual certification. I know that the common criteria is less strict, and that is where we are focusing now. There are a number of ways that we can ensure that the code is not modifiable, including coding signing the VM, removing the compiler, crc checking the code before it runs, etc. I agree with you that this is going to be an interesting challenge, and it will be expensive process once we get to the point when we think we are secure the code and the VM and can pass the CC. But I also feel that having the certification would be a very good thing for Open Source in general, so it's a path worth going down. The lab thought that it would be difficult also but they believed it was possible. I planned to discuss this with the lab that worked with OpenSSL but after realizing how much work there was left to do before working with a lab, I figured it could wait. If they succeed then it makes it easier for us.
One of the tenants I've been working under is Good Enough Security. The idea is that if we try to build the perfect system we would find it a task that is so daunting that we would never try. If we try to make incremental improvements using the best information that we can find, working with the best possible people, and going through some of the certification processes, even if we don't succeed, we make Squeak better, and more secure, and more likely that businesses and developers will comfortably adopt Squeak.
My understanding of OpenSSL was that they had their certification but it was pulled, they are working to restore that certification now, and they have passed the lab stage and are waiting again for the government.
One of the other things to consider that I have mentioned already is that Microsoft CryptoAPI is FIPS certified. It is possible that we could attach to that and develop Squeak systems that are also certified, but I haven't read through the security policy document thoroughly enough to know how difficult that would be.
What other package where you thinking of?
Hope that helps!
Ron Teitelbaum Squeak Cryptography Team Leader
From: Kyle Hamilton Sent: Wednesday, October 11, 2006 6:05 PM
Welcome, Krishna!
In the grand scheme of things, how can the integrity of the cryptographic component module be verifiably maintained in Squeak? Because of the NIST/FIPS requirement of a security boundary, the implementation must be an immutable "black box" -- put data in, get data out.
OpenSSL has a FIPS-validated component (no longer available for obtainment, but people who obtained it before it was made no-longer-available) that would operate in the context of an extension to the interpreter. [They're working on a follow-up validation for a to-be-made-available version of the library.] There is also at least one FIPS-validated, freely-available module available for Windows other than OpenSSL.
I bring this up only because I can't see how such a black box could be created (and its internal state verifiable at all times) unless it's not written within the Squeak environment itself. There isn't any means that I know of "sealing" classes and preventing data from being examined -- thus there isn't any means of enforcing a "black box" boundary the way that FIPS requires.
Any thoughts on the matter? Anyone?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Krishna Sankar is joining our team as the new Squeak Cryptography Certification Validation Officer.
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Extending further, it depends on the Security Target and the TOE. If I am correct, the CC evaluation is for a (platform, function, version) tuple anyway. Like Ron points out, first we could bound the target configuration, by teeing off of a set of libraries that are already certified. We can then improve upon the base and have more ambitious plans.
I think one of the first tasks would be to put together the ST and ToE. The security claims we want to make also have a bearing on the current discussion. I haven't dug deeper into the profiles yet.
Cheers <k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Ron Teitelbaum Sent: Wednesday, October 11, 2006 4:54 PM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Re: [Newbies] [ANN] SqueakCryptographyCertification Validation Officer
Hi Kyle,
I discussed this with the certification lab that I spoke too. It is a very interesting question and one that we will need to address when it is time to do the actual certification. I know that the common criteria is less strict, and that is where we are focusing now. There are a number of ways that we can ensure that the code is not modifiable, including coding signing the VM, removing the compiler, crc checking the code before it runs, etc. I agree with you that this is going to be an interesting challenge, and it will be expensive process once we get to the point when we think we are secure the code and the VM and can pass the CC. But I also feel that having the certification would be a very good thing for Open Source in general, so it's a path worth going down. The lab thought that it would be difficult also but they believed it was possible. I planned to discuss this with the lab that worked with OpenSSL but after realizing how much work there was left to do before working with a lab, I figured it could wait. If they succeed then it makes it easier for us.
One of the tenants I've been working under is Good Enough Security. The idea is that if we try to build the perfect system we would find it a task that is so daunting that we would never try. If we try to make incremental improvements using the best information that we can find, working with the best possible people, and going through some of the certification processes, even if we don't succeed, we make Squeak better, and more secure, and more likely that businesses and developers will comfortably adopt Squeak.
My understanding of OpenSSL was that they had their certification but it was pulled, they are working to restore that certification now, and they have passed the lab stage and are waiting again for the government.
One of the other things to consider that I have mentioned already is that Microsoft CryptoAPI is FIPS certified. It is possible that we could attach to that and develop Squeak systems that are also certified, but I haven't read through the security policy document thoroughly enough to know how difficult that would be.
What other package where you thinking of?
Hope that helps!
Ron Teitelbaum Squeak Cryptography Team Leader
From: Kyle Hamilton Sent: Wednesday, October 11, 2006 6:05 PM
Welcome, Krishna!
In the grand scheme of things, how can the integrity of the cryptographic component module be verifiably maintained in Squeak? Because of the NIST/FIPS requirement of a security boundary, the implementation must be an immutable "black box" -- put data in, get data out.
OpenSSL has a FIPS-validated component (no longer available for obtainment, but people who obtained it before it was made no-longer-available) that would operate in the context of
an extension
to the interpreter. [They're working on a follow-up
validation for a
to-be-made-available version of the library.] There is
also at least
one FIPS-validated, freely-available module available for Windows other than OpenSSL.
I bring this up only because I can't see how such a black
box could be
created (and its internal state verifiable at all times)
unless it's
not written within the Squeak environment itself. There isn't any means that I know of "sealing" classes and preventing data
from being
examined -- thus there isn't any means of enforcing a "black box" boundary the way that FIPS requires.
Any thoughts on the matter? Anyone?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Krishna Sankar is joining our team as the new Squeak Cryptography Certification Validation Officer.
Cryptography mailing list Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
y
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
OpenSSL's situation is rather interesting. The OpenSSL FIPS 1.0 code is not available for procurement, but people/companies who already have copies are allowed to use it and it retains its validation. See http://oss-institute.org/index.php?option=content&task=view&id=166&a... for information (it was mistakenly listed as "revoked", but it is now properly marked as "not available": http://csrc.nist.gov/cryptval/140-1/1401val2006.htm , certificate number 642).
The other package that I'm thinking of (for Windows) is Crypto++, available at http://www.eskimo.com/~weidai/cryptlib.html . (Certificate numbers 343 and 562, since there are two different versions -- 343 refers to the VC++ 6.0 version, 562 refers to the VC++.Net version.)
I wonder... could the squeak VM have a public key which validates a signature on the crypto code whenever an object derived from that code is accessed? Or can the code be made immutable in the VM itself?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle,
I discussed this with the certification lab that I spoke too. It is a very interesting question and one that we will need to address when it is time to do the actual certification. I know that the common criteria is less strict, and that is where we are focusing now. There are a number of ways that we can ensure that the code is not modifiable, including coding signing the VM, removing the compiler, crc checking the code before it runs, etc. I agree with you that this is going to be an interesting challenge, and it will be expensive process once we get to the point when we think we are secure the code and the VM and can pass the CC. But I also feel that having the certification would be a very good thing for Open Source in general, so it's a path worth going down. The lab thought that it would be difficult also but they believed it was possible. I planned to discuss this with the lab that worked with OpenSSL but after realizing how much work there was left to do before working with a lab, I figured it could wait. If they succeed then it makes it easier for us.
One of the tenants I've been working under is Good Enough Security. The idea is that if we try to build the perfect system we would find it a task that is so daunting that we would never try. If we try to make incremental improvements using the best information that we can find, working with the best possible people, and going through some of the certification processes, even if we don't succeed, we make Squeak better, and more secure, and more likely that businesses and developers will comfortably adopt Squeak.
My understanding of OpenSSL was that they had their certification but it was pulled, they are working to restore that certification now, and they have passed the lab stage and are waiting again for the government.
One of the other things to consider that I have mentioned already is that Microsoft CryptoAPI is FIPS certified. It is possible that we could attach to that and develop Squeak systems that are also certified, but I haven't read through the security policy document thoroughly enough to know how difficult that would be.
What other package where you thinking of?
Hope that helps!
Ron Teitelbaum Squeak Cryptography Team Leader
From: Kyle Hamilton Sent: Wednesday, October 11, 2006 6:05 PM
Welcome, Krishna!
In the grand scheme of things, how can the integrity of the cryptographic component module be verifiably maintained in Squeak? Because of the NIST/FIPS requirement of a security boundary, the implementation must be an immutable "black box" -- put data in, get data out.
OpenSSL has a FIPS-validated component (no longer available for obtainment, but people who obtained it before it was made no-longer-available) that would operate in the context of an extension to the interpreter. [They're working on a follow-up validation for a to-be-made-available version of the library.] There is also at least one FIPS-validated, freely-available module available for Windows other than OpenSSL.
I bring this up only because I can't see how such a black box could be created (and its internal state verifiable at all times) unless it's not written within the Squeak environment itself. There isn't any means that I know of "sealing" classes and preventing data from being examined -- thus there isn't any means of enforcing a "black box" boundary the way that FIPS requires.
Any thoughts on the matter? Anyone?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Krishna Sankar is joining our team as the new Squeak Cryptography Certification Validation Officer.
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Hi Kyle and ALL,
First welcome to the team! I've been following OpenSSL and I really hope that they solve their problems and receive certification. We'll have to keep our eyes on it. From news reports it appears that vendors of cryptographic software are the cause of the suspension. The question now is how well the lab they are working with can make the case for certification against such powerful objections. I'm hoping since they have moved so far and since they have some corporate funding, they will succeed.
I'm looking at crypto++ thank you for the link. I noticed that their certification is level 1. When I was discussing this with the lab they were suggesting a level 2 certification:
The different levels within the standard provide different levels of security and in the higher levels, have different documentation requirements.
Level 1: The lowest level of security. No physical security mechanisms are required in the module beyond the requirement for production-grade equipment.
Level 2: Tamper evident physical security or pick resistant locks. Level 2 provides for role-based authentication. It allows software cryptography in multi-user timeshared systems when used in conjunction with a C2 or equivalent trusted operating system.
Level 3: Tamper resistant physical security. Level 3 provides for identity-based authentication.
Level 4: Physical security provides an envelope of protection around the cryptographic module. Also protects against fluctuations in the production environment.
They said that level 2 is the most common level for cryptographic software. I wonder how well the level 1 software is accepted, and how much easier it is to get? It is definitely something to consider. I think that OpenSSL is working towards level 2.
The major question here is the platform. IF we want to develop for binaries that are only for a windows platform, then we could skip the binaries altogether and just use CryptoAPI since it comes with the operating system and is also FIPS 140-2 certified (although I have not read the security policy to know how difficult building 140-2 certified code is).
If this team is interested in a Windows platform certification please speak up. If we want to go with windows as a first cut then let's decide to do that. My major concern is that most people will be looking to deploy the software as a server platform and will be looking for a *nix platform. Personally my interest IS Windows since my goal is to deploy secure clients not servers, but I don't want my personal needs to effect the group (especially without saying so specifically).
Again welcome to the group! Did you want to tell us about your experience and what you are looking to get from this group?
Ron Teitelbaum Cryptography Team Leader
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Kyle Hamilton Sent: Wednesday, October 11, 2006 10:49 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Re: [Newbies] [ANN] SqueakCryptographyCertification Validation Officer
OpenSSL's situation is rather interesting. The OpenSSL FIPS 1.0 code is not available for procurement, but people/companies who already have copies are allowed to use it and it retains its validation. See http://oss-institute.org/index.php?option=content&task=view&id=166&a... for information (it was mistakenly listed as "revoked", but it is now properly marked as "not available": http://csrc.nist.gov/cryptval/140-1/1401val2006.htm , certificate number 642).
The other package that I'm thinking of (for Windows) is Crypto++, available at http://www.eskimo.com/~weidai/cryptlib.html . (Certificate numbers 343 and 562, since there are two different versions -- 343 refers to the VC++ 6.0 version, 562 refers to the VC++.Net version.)
I wonder... could the squeak VM have a public key which validates a signature on the crypto code whenever an object derived from that code is accessed? Or can the code be made immutable in the VM itself?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle,
I discussed this with the certification lab that I spoke too. It is a
very
interesting question and one that we will need to address when it is
time to
do the actual certification. I know that the common criteria is less strict, and that is where we are focusing now. There are a number of
ways
that we can ensure that the code is not modifiable, including coding
signing
the VM, removing the compiler, crc checking the code before it runs,
etc. I
agree with you that this is going to be an interesting challenge, and it will be expensive process once we get to the point when we think we are secure the code and the VM and can pass the CC. But I also feel that
having
the certification would be a very good thing for Open Source in general,
so
it's a path worth going down. The lab thought that it would be
difficult
also but they believed it was possible. I planned to discuss this with
the
lab that worked with OpenSSL but after realizing how much work there was left to do before working with a lab, I figured it could wait. If they succeed then it makes it easier for us.
One of the tenants I've been working under is Good Enough Security. The idea is that if we try to build the perfect system we would find it a
task
that is so daunting that we would never try. If we try to make
incremental
improvements using the best information that we can find, working with
the
best possible people, and going through some of the certification
processes,
even if we don't succeed, we make Squeak better, and more secure, and
more
likely that businesses and developers will comfortably adopt Squeak.
My understanding of OpenSSL was that they had their certification but it
was
pulled, they are working to restore that certification now, and they
have
passed the lab stage and are waiting again for the government.
One of the other things to consider that I have mentioned already is
that
Microsoft CryptoAPI is FIPS certified. It is possible that we could
attach
to that and develop Squeak systems that are also certified, but I
haven't
read through the security policy document thoroughly enough to know how difficult that would be.
What other package where you thinking of?
Hope that helps!
Ron Teitelbaum Squeak Cryptography Team Leader
From: Kyle Hamilton Sent: Wednesday, October 11, 2006 6:05 PM
Welcome, Krishna!
In the grand scheme of things, how can the integrity of the cryptographic component module be verifiably maintained in Squeak? Because of the NIST/FIPS requirement of a security boundary, the implementation must be an immutable "black box" -- put data in, get data out.
OpenSSL has a FIPS-validated component (no longer available for obtainment, but people who obtained it before it was made no-longer-available) that would operate in the context of an extension to the interpreter. [They're working on a follow-up validation for a to-be-made-available version of the library.] There is also at least one FIPS-validated, freely-available module available for Windows other than OpenSSL.
I bring this up only because I can't see how such a black box could be created (and its internal state verifiable at all times) unless it's not written within the Squeak environment itself. There isn't any means that I know of "sealing" classes and preventing data from being examined -- thus there isn't any means of enforcing a "black box" boundary the way that FIPS requires.
Any thoughts on the matter? Anyone?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Krishna Sankar is joining our team as the new Squeak Cryptography Certification Validation Officer.
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-
bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
--
-Kyle H _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Hello, Ron and everyone!
I'll reply to your concerns in order; I just woke up, but talking about cryptography and implementation always gets me thinking more effectively. :)
I've been discussing the FIPS effort with the OpenSSL development team, when they have any time to work on it, and the issues with its being made "not available for procurement" are related to its security boundary and cryptographically-signed container. A very few functions that are security-related were not placed inside the signed container, and that raised concerns at the lab. (Considering that the container was created basically within the last 3 months of the validation effort, I can't say that I'm really surprised.)
However, and I cannot stress this enough, OpenSSL-FIPS 1.0 retains its validation for people who have already received the source, and can still be used to build valid binaries for customers.
To my understanding, the 1.1 effort is primarily an effort to more appropriately define and defend the security boundary.
Now, as for the level of validation: Please note that it's not "certification", it's "validation". When dealing with the US government, at least, they're very picky about their terminology. Certificates of validation are issued by NIST after an independent laboratory verifies that a given system operates the way that it is intended to, according to the NIST/FIPS testing plan.
As for the level: OpenSSL is also level 1. It don't believe it's possible for any pure-software system (specifically, "multi-chip standalone" system) to receive anything higher than a level 1 validation, because the communications between the chips can be tampered with. For a level 2 or higher validation I believe it is necessary to add tamper-resistance to the hardware. (I can't be sure, though, because the various links that supposedly mention what the requirements are no longer work. I'll have to go to a depository library and pull the appropriate documents; it'll probably be easier than finding them on the web. However, I did find this: http://niap.bahialab.com/pp/ci_manuals.cfm which may or may not be of use. Low Robustness Targets of Evaluation may include software, and require some action on the part of the IT staff at field implementation; Medium Robustness Targets of Evaluation require hardware.)
If you look at Certificate 405 at http://csrc.nist.gov/cryptval/140-1/1401val2004.htm#405 , you'll see that even Microsoft's kernel-mode FIPS.SYS driver is 140-2 level 1. Even though it supports role-based security, it doesn't exhibit tamper-evidence (it's possible to restore a backup and remove all traces of tampering).
Now, a note about FIPS 140-1 versus FIPS 140-2. 140-1 is no longer available for new validations nor product procurements, though products that use them may still be used. 140-2 is the current version of the FIPS that cryptographic modules must adhere to. The manuals for how a module is tested are on http://csrc.nist.gov/, as well as the functional requirements for startup and environment validation.
(Also, please note: Windows only achieves C2 certification when it's unplugged from the network. TCP/IP makes C2 compliance impossible, as there are covert channels within the protocol itself.)
For reference, what laboratory did you speak to that stated that level 2 is the most common that is worked toward by software? The requirements for level 2 cannot be met by software without the help of hardware.
We could certainly use the CryptoAPI on Windows, and in fact for PRNG cryptographic robustness we must (unless we want to build a new entropy-gathering system that we then pass through a FIPS-specified PRNG function). However, as a cross-platform project, I must point out that introducing platform specific code will only make things more difficult. (Then again, considering how difficult it is to build OpenSSL-FIPS on Windows, and the current impossibility of building it using standard Microsoft toolchains, we may need to create a platform-independent abstraction in any case.)
Anyway, hi! My name is Kyle Hamilton. I am a hobbyist security researcher who is attempting to build a general-purpose strongly-authenticable and strongly-encrypted peer-to-peer wireless networking system. I am envisioning emergency response crews (FEMA, EMTs, civilian emergency response crews, and police forces) and perhaps military combat units (as AES-256 has been specified by the NSA as being sufficient to protect "secret" classified data) utilizing this; this is why I am so interested in FIPS validation for my final design. I am a contributor to the RSA Labs Cryptography FAQ, and worked at Intel as a contractor on SSL acceleration in the mid 1990s. (One notable quote from my first interview there: "There is absolutely nothing on your resume to show that you have anywhere near the level of knowledge of cryptography that you have demonstrated today.")
What I want to get out of the Squeak project here is to make sure that strong cryptography is available to many more people than just those who spend the time working on it. I'm getting involved with a p2p authentication system design being developed for OpenSSL 0.9.7g in a software called RetroShare, and I think that since IPsec turned out to be a huge flop, it's probably time for application developers to take cryptographic implementation into their own hands.
-Kyle H
On 10/12/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle and ALL,
First welcome to the team! I've been following OpenSSL and I really hope that they solve their problems and receive certification. We'll have to keep our eyes on it. From news reports it appears that vendors of cryptographic software are the cause of the suspension. The question now is how well the lab they are working with can make the case for certification against such powerful objections. I'm hoping since they have moved so far and since they have some corporate funding, they will succeed.
I'm looking at crypto++ thank you for the link. I noticed that their certification is level 1. When I was discussing this with the lab they were suggesting a level 2 certification:
The different levels within the standard provide different levels of security and in the higher levels, have different documentation requirements.
Level 1: The lowest level of security. No physical security mechanisms are required in the module beyond the requirement for production-grade equipment.
Level 2: Tamper evident physical security or pick resistant locks. Level 2 provides for role-based authentication. It allows software cryptography in multi-user timeshared systems when used in conjunction with a C2 or equivalent trusted operating system.
Level 3: Tamper resistant physical security. Level 3 provides for identity-based authentication.
Level 4: Physical security provides an envelope of protection around the cryptographic module. Also protects against fluctuations in the production environment.
They said that level 2 is the most common level for cryptographic software. I wonder how well the level 1 software is accepted, and how much easier it is to get? It is definitely something to consider. I think that OpenSSL is working towards level 2.
The major question here is the platform. IF we want to develop for binaries that are only for a windows platform, then we could skip the binaries altogether and just use CryptoAPI since it comes with the operating system and is also FIPS 140-2 certified (although I have not read the security policy to know how difficult building 140-2 certified code is).
If this team is interested in a Windows platform certification please speak up. If we want to go with windows as a first cut then let's decide to do that. My major concern is that most people will be looking to deploy the software as a server platform and will be looking for a *nix platform. Personally my interest IS Windows since my goal is to deploy secure clients not servers, but I don't want my personal needs to effect the group (especially without saying so specifically).
Again welcome to the group! Did you want to tell us about your experience and what you are looking to get from this group?
Ron Teitelbaum Cryptography Team Leader
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Kyle Hamilton Sent: Wednesday, October 11, 2006 10:49 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Re: [Newbies] [ANN] SqueakCryptographyCertification Validation Officer
OpenSSL's situation is rather interesting. The OpenSSL FIPS 1.0 code is not available for procurement, but people/companies who already have copies are allowed to use it and it retains its validation. See http://oss-institute.org/index.php?option=content&task=view&id=166&a... for information (it was mistakenly listed as "revoked", but it is now properly marked as "not available": http://csrc.nist.gov/cryptval/140-1/1401val2006.htm , certificate number 642).
The other package that I'm thinking of (for Windows) is Crypto++, available at http://www.eskimo.com/~weidai/cryptlib.html . (Certificate numbers 343 and 562, since there are two different versions -- 343 refers to the VC++ 6.0 version, 562 refers to the VC++.Net version.)
I wonder... could the squeak VM have a public key which validates a signature on the crypto code whenever an object derived from that code is accessed? Or can the code be made immutable in the VM itself?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle,
I discussed this with the certification lab that I spoke too. It is a
very
interesting question and one that we will need to address when it is
time to
do the actual certification. I know that the common criteria is less strict, and that is where we are focusing now. There are a number of
ways
that we can ensure that the code is not modifiable, including coding
signing
the VM, removing the compiler, crc checking the code before it runs,
etc. I
agree with you that this is going to be an interesting challenge, and it will be expensive process once we get to the point when we think we are secure the code and the VM and can pass the CC. But I also feel that
having
the certification would be a very good thing for Open Source in general,
so
it's a path worth going down. The lab thought that it would be
difficult
also but they believed it was possible. I planned to discuss this with
the
lab that worked with OpenSSL but after realizing how much work there was left to do before working with a lab, I figured it could wait. If they succeed then it makes it easier for us.
One of the tenants I've been working under is Good Enough Security. The idea is that if we try to build the perfect system we would find it a
task
that is so daunting that we would never try. If we try to make
incremental
improvements using the best information that we can find, working with
the
best possible people, and going through some of the certification
processes,
even if we don't succeed, we make Squeak better, and more secure, and
more
likely that businesses and developers will comfortably adopt Squeak.
My understanding of OpenSSL was that they had their certification but it
was
pulled, they are working to restore that certification now, and they
have
passed the lab stage and are waiting again for the government.
One of the other things to consider that I have mentioned already is
that
Microsoft CryptoAPI is FIPS certified. It is possible that we could
attach
to that and develop Squeak systems that are also certified, but I
haven't
read through the security policy document thoroughly enough to know how difficult that would be.
What other package where you thinking of?
Hope that helps!
Ron Teitelbaum Squeak Cryptography Team Leader
From: Kyle Hamilton Sent: Wednesday, October 11, 2006 6:05 PM
Welcome, Krishna!
In the grand scheme of things, how can the integrity of the cryptographic component module be verifiably maintained in Squeak? Because of the NIST/FIPS requirement of a security boundary, the implementation must be an immutable "black box" -- put data in, get data out.
OpenSSL has a FIPS-validated component (no longer available for obtainment, but people who obtained it before it was made no-longer-available) that would operate in the context of an extension to the interpreter. [They're working on a follow-up validation for a to-be-made-available version of the library.] There is also at least one FIPS-validated, freely-available module available for Windows other than OpenSSL.
I bring this up only because I can't see how such a black box could be created (and its internal state verifiable at all times) unless it's not written within the Squeak environment itself. There isn't any means that I know of "sealing" classes and preventing data from being examined -- thus there isn't any means of enforcing a "black box" boundary the way that FIPS requires.
Any thoughts on the matter? Anyone?
-Kyle H
Hi Kyle,
Welcome again to the team. I am very happy to have you as part of our validation effort. I am looking forward to working with you to meet your goals and I'm very interested in learning more about what you are working on. I hope that we can all learn more about the validation process and that we can help teach others.
Here is a link to my original email after talking to the lab: http://lists.squeakfoundation.org/pipermail/cryptography/2006-July/000211.ht ml I spoke with J. Mark Braga of SAIC CMTL http://www.saic.com/infosec/cmtl/ they were very clear that 140-2 - level 2 validation is what most software systems work towards. There is a possibility that I misunderstood or that the -2 and level 2 got confused, but that seems unlikely since, as you said, 140-1 doesn't apply. I guess my understanding was that the security policy needed to include standards that must be followed for someone else to have a 140-2 level 2 validated system derived from our code. I also understood that we needed a reference implementation that exhibited these standards, but I figured we would set that up somewhere once we needed too. In order to support the physical requirement I figured we needed to say in our security policy that the server needed to be in a locked room with a lock pick resistant door, and those that have a key need to have clearance through a process that includes... I have no idea what to think about TCP/IP access and I guess if that completely invalidates level 2 then I can't imagine that most systems used comply with level 2 validation (unless TCP/IP in a secure WAN is acceptable).
We need more clarity around this issue, but it doesn't have to happen now, first things first. I'm sure there is a lot more we will learn as we go.
You goals for helping to increase the usage of cryptography fit very nicely with the stated goals of this team. Your p2p project opens up some very interesting questions as to security since it is the client that needs to be secured and the hardware is potentially in the hands of the attacker. I am also very interested in this question and I hope that we can spend some time discussing this, either in the group or off line.
Welcome to the team!
Ron Teitelbaum Squeak Cryptography Team Leader
-----Original Message----- From: Kyle Hamilton [mailto:aerowolf@gmail.com] Sent: Thursday, October 12, 2006 4:36 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] FIPS OpenSSL Crypto++ and CryptoAPI
Hello, Ron and everyone!
I'll reply to your concerns in order; I just woke up, but talking about cryptography and implementation always gets me thinking more effectively. :)
I've been discussing the FIPS effort with the OpenSSL development team, when they have any time to work on it, and the issues with its being made "not available for procurement" are related to its security boundary and cryptographically-signed container. A very few functions that are security-related were not placed inside the signed container, and that raised concerns at the lab. (Considering that the container was created basically within the last 3 months of the validation effort, I can't say that I'm really surprised.)
However, and I cannot stress this enough, OpenSSL-FIPS 1.0 retains its validation for people who have already received the source, and can still be used to build valid binaries for customers.
To my understanding, the 1.1 effort is primarily an effort to more appropriately define and defend the security boundary.
Now, as for the level of validation: Please note that it's not "certification", it's "validation". When dealing with the US government, at least, they're very picky about their terminology. Certificates of validation are issued by NIST after an independent laboratory verifies that a given system operates the way that it is intended to, according to the NIST/FIPS testing plan.
As for the level: OpenSSL is also level 1. It don't believe it's possible for any pure-software system (specifically, "multi-chip standalone" system) to receive anything higher than a level 1 validation, because the communications between the chips can be tampered with. For a level 2 or higher validation I believe it is necessary to add tamper-resistance to the hardware. (I can't be sure, though, because the various links that supposedly mention what the requirements are no longer work. I'll have to go to a depository library and pull the appropriate documents; it'll probably be easier than finding them on the web. However, I did find this: http://niap.bahialab.com/pp/ci_manuals.cfm which may or may not be of use. Low Robustness Targets of Evaluation may include software, and require some action on the part of the IT staff at field implementation; Medium Robustness Targets of Evaluation require hardware.)
If you look at Certificate 405 at http://csrc.nist.gov/cryptval/140-1/1401val2004.htm#405 , you'll see that even Microsoft's kernel-mode FIPS.SYS driver is 140-2 level 1. Even though it supports role-based security, it doesn't exhibit tamper-evidence (it's possible to restore a backup and remove all traces of tampering).
Now, a note about FIPS 140-1 versus FIPS 140-2. 140-1 is no longer available for new validations nor product procurements, though products that use them may still be used. 140-2 is the current version of the FIPS that cryptographic modules must adhere to. The manuals for how a module is tested are on http://csrc.nist.gov/, as well as the functional requirements for startup and environment validation.
(Also, please note: Windows only achieves C2 certification when it's unplugged from the network. TCP/IP makes C2 compliance impossible, as there are covert channels within the protocol itself.)
For reference, what laboratory did you speak to that stated that level 2 is the most common that is worked toward by software? The requirements for level 2 cannot be met by software without the help of hardware.
We could certainly use the CryptoAPI on Windows, and in fact for PRNG cryptographic robustness we must (unless we want to build a new entropy-gathering system that we then pass through a FIPS-specified PRNG function). However, as a cross-platform project, I must point out that introducing platform specific code will only make things more difficult. (Then again, considering how difficult it is to build OpenSSL-FIPS on Windows, and the current impossibility of building it using standard Microsoft toolchains, we may need to create a platform-independent abstraction in any case.)
Anyway, hi! My name is Kyle Hamilton. I am a hobbyist security researcher who is attempting to build a general-purpose strongly-authenticable and strongly-encrypted peer-to-peer wireless networking system. I am envisioning emergency response crews (FEMA, EMTs, civilian emergency response crews, and police forces) and perhaps military combat units (as AES-256 has been specified by the NSA as being sufficient to protect "secret" classified data) utilizing this; this is why I am so interested in FIPS validation for my final design. I am a contributor to the RSA Labs Cryptography FAQ, and worked at Intel as a contractor on SSL acceleration in the mid 1990s. (One notable quote from my first interview there: "There is absolutely nothing on your resume to show that you have anywhere near the level of knowledge of cryptography that you have demonstrated today.")
What I want to get out of the Squeak project here is to make sure that strong cryptography is available to many more people than just those who spend the time working on it. I'm getting involved with a p2p authentication system design being developed for OpenSSL 0.9.7g in a software called RetroShare, and I think that since IPsec turned out to be a huge flop, it's probably time for application developers to take cryptographic implementation into their own hands.
-Kyle H
On 10/12/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle and ALL,
First welcome to the team! I've been following OpenSSL and I really
hope
that they solve their problems and receive certification. We'll have to keep our eyes on it. From news reports it appears that vendors of cryptographic software are the cause of the suspension. The question
now is
how well the lab they are working with can make the case for
certification
against such powerful objections. I'm hoping since they have moved so
far
and since they have some corporate funding, they will succeed.
I'm looking at crypto++ thank you for the link. I noticed that their certification is level 1. When I was discussing this with the lab they
were
suggesting a level 2 certification:
The different levels within the standard provide different levels of security and in the higher levels, have different documentation requirements.
Level 1: The lowest level of security. No physical security mechanisms
are
required in the module beyond the requirement for production-grade equipment.
Level 2: Tamper evident physical security or pick resistant locks. Level
2
provides for role-based authentication. It allows software cryptography
in
multi-user timeshared systems when used in conjunction with a C2 or equivalent trusted operating system.
Level 3: Tamper resistant physical security. Level 3 provides for identity-based authentication.
Level 4: Physical security provides an envelope of protection around the cryptographic module. Also protects against fluctuations in the
production
environment.
They said that level 2 is the most common level for cryptographic
software.
I wonder how well the level 1 software is accepted, and how much easier
it
is to get? It is definitely something to consider. I think that
OpenSSL is
working towards level 2.
The major question here is the platform. IF we want to develop for
binaries
that are only for a windows platform, then we could skip the binaries altogether and just use CryptoAPI since it comes with the operating
system
and is also FIPS 140-2 certified (although I have not read the security policy to know how difficult building 140-2 certified code is).
If this team is interested in a Windows platform certification please
speak
up. If we want to go with windows as a first cut then let's decide to
do
that. My major concern is that most people will be looking to deploy
the
software as a server platform and will be looking for a *nix platform. Personally my interest IS Windows since my goal is to deploy secure
clients
not servers, but I don't want my personal needs to effect the group (especially without saying so specifically).
Again welcome to the group! Did you want to tell us about your
experience
and what you are looking to get from this group?
Ron Teitelbaum Cryptography Team Leader
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of
Kyle
Hamilton Sent: Wednesday, October 11, 2006 10:49 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Re: [Newbies] [ANN] SqueakCryptographyCertification Validation Officer
OpenSSL's situation is rather interesting. The OpenSSL FIPS 1.0 code is not available for procurement, but people/companies who already have copies are allowed to use it and it retains its validation. See http://oss-
institute.org/index.php?option=content&task=view&id=166&Itemid=
for information (it was mistakenly listed as "revoked", but it is now properly marked as "not available": http://csrc.nist.gov/cryptval/140-1/1401val2006.htm , certificate number 642).
The other package that I'm thinking of (for Windows) is Crypto++, available at http://www.eskimo.com/~weidai/cryptlib.html . (Certificate numbers 343 and 562, since there are two different versions -- 343 refers to the VC++ 6.0 version, 562 refers to the VC++.Net version.)
I wonder... could the squeak VM have a public key which validates a signature on the crypto code whenever an object derived from that code is accessed? Or can the code be made immutable in the VM itself?
-Kyle H
On 10/11/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle,
I discussed this with the certification lab that I spoke too. It is
a
very
interesting question and one that we will need to address when it is
time to
do the actual certification. I know that the common criteria is
less
strict, and that is where we are focusing now. There are a number
of
ways
that we can ensure that the code is not modifiable, including coding
signing
the VM, removing the compiler, crc checking the code before it runs,
etc. I
agree with you that this is going to be an interesting challenge,
and it
will be expensive process once we get to the point when we think we
are
secure the code and the VM and can pass the CC. But I also feel
that
having
the certification would be a very good thing for Open Source in
general,
so
it's a path worth going down. The lab thought that it would be
difficult
also but they believed it was possible. I planned to discuss this
with
the
lab that worked with OpenSSL but after realizing how much work there
was
left to do before working with a lab, I figured it could wait. If
they
succeed then it makes it easier for us.
One of the tenants I've been working under is Good Enough Security.
The
idea is that if we try to build the perfect system we would find it
a
task
that is so daunting that we would never try. If we try to make
incremental
improvements using the best information that we can find, working
with
the
best possible people, and going through some of the certification
processes,
even if we don't succeed, we make Squeak better, and more secure,
and
more
likely that businesses and developers will comfortably adopt Squeak.
My understanding of OpenSSL was that they had their certification
but it
was
pulled, they are working to restore that certification now, and they
have
passed the lab stage and are waiting again for the government.
One of the other things to consider that I have mentioned already is
that
Microsoft CryptoAPI is FIPS certified. It is possible that we could
attach
to that and develop Squeak systems that are also certified, but I
haven't
read through the security policy document thoroughly enough to know
how
difficult that would be.
What other package where you thinking of?
Hope that helps!
Ron Teitelbaum Squeak Cryptography Team Leader
From: Kyle Hamilton Sent: Wednesday, October 11, 2006 6:05 PM
Welcome, Krishna!
In the grand scheme of things, how can the integrity of the cryptographic component module be verifiably maintained in Squeak? Because of the NIST/FIPS requirement of a security boundary, the implementation must be an immutable "black box" -- put data in,
get
data out.
OpenSSL has a FIPS-validated component (no longer available for obtainment, but people who obtained it before it was made no-longer-available) that would operate in the context of an
extension
to the interpreter. [They're working on a follow-up validation
for a
to-be-made-available version of the library.] There is also at
least
one FIPS-validated, freely-available module available for Windows other than OpenSSL.
I bring this up only because I can't see how such a black box
could be
created (and its internal state verifiable at all times) unless
it's
not written within the Squeak environment itself. There isn't any means that I know of "sealing" classes and preventing data from
being
examined -- thus there isn't any means of enforcing a "black box" boundary the way that FIPS requires.
Any thoughts on the matter? Anyone?
-Kyle H
On 10/12/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle,
Welcome again to the team. I am very happy to have you as part of our validation effort. I am looking forward to working with you to meet your goals and I'm very interested in learning more about what you are working on. I hope that we can all learn more about the validation process and that we can help teach others.
I'll see what information I can get from other sources, obviously, but I'm quite certain we'll ALL get a lesson in government bureaucracy here. :P
Here is a link to my original email after talking to the lab: http://lists.squeakfoundation.org/pipermail/cryptography/2006-July/000211.ht ml I spoke with J. Mark Braga of SAIC CMTL http://www.saic.com/infosec/cmtl/ they were very clear that 140-2 - level 2 validation is what most software systems work towards. There is a possibility that I misunderstood or that the -2 and level 2 got confused, but that seems unlikely since, as you said, 140-1 doesn't apply.
It is entirely possible that what Mr. Braga was referring to was the fact that everything to be validated MUST comply with FIPS 140-2 (i.e., version 2), not version 1... simply because version 1 is no longer validatable. As I mentioned in an earlier mail, there is no software system which is validated to any level higher than level 1 (even Microsoft Windows Server 2003's FIPS.SYS kernel module -- and you can bet that if MS could have gotten a higher level of validation, they would have).
I guess my understanding was that the security policy needed to include standards that must be followed for someone else to have a 140-2 level 2 validated system derived from our code.
That is correct. This turns it from a "low-assurance" scenario to a "medium-assurance" scenario -- as long as the security policy states that there are implementation requirements necessary to get medium assurance, which become the responsibility of the IT staff which supports the system (which includes audit logs, tamper-evident tape to seal the machine from any hardware modification, appropriate security administration and privilege separation, and so on).
But, if the software that performs the encryption isn't validated to perform to level 1, then all the above procedures don't make the implementation FIPS-validatable.
I also understood that we needed a reference implementation that exhibited these standards, but I figured we would set that up somewhere once we needed too. In order to support the physical requirement I figured we needed to say in our security policy that the server needed to be in a locked room with a lock pick resistant door, and those that have a key need to have clearance through a process that includes... I have no idea what to think about TCP/IP access and I guess if that completely invalidates level 2 then I can't imagine that most systems used comply with level 2 validation (unless TCP/IP in a secure WAN is acceptable).
It doesn't necessarily invalidate level 2, but it makes it MUCH more difficult to validate, as all possible inputs need to be tested to ensure that the cryptographic boundary cannot be breached. I may be wrong about "no possible covert channel" being a requirement for level 2, but I'm fairly certain it's necessary for level 3.
We need more clarity around this issue, but it doesn't have to happen now, first things first. I'm sure there is a lot more we will learn as we go.
Aye. First, we need to figure out what we're going to use, and how we're going to use it.
You goals for helping to increase the usage of cryptography fit very nicely with the stated goals of this team. Your p2p project opens up some very interesting questions as to security since it is the client that needs to be secured and the hardware is potentially in the hands of the attacker. I am also very interested in this question and I hope that we can spend some time discussing this, either in the group or off line.
I'll gladly spend time discussing it (though it really may not belong here). There's an application called RapidShare, at http://www.lunamutt.com/ , that does at least part of what I want to do... but its key and identity management are very poor at best, and it has an unaudited web of trust implementation.
Welcome to the team!
Thanks! :)
I notice that you're from US Med Rec; it may also interest you that I'm attempting to build a set of specifications by which at the very least auditing can be implemented for any attempted access to a database. (In my case, I'm expanding the capabilities of a MUD software's database layer in order to more proactively find attempted violations of security policy, and I must use C to do it -- but it's my experience that implementation can be done in any language as long as the policy is specified and the appropriate methodologies are used during development.) This might have some good aspects for HIPAA compliance, if appropriately specified. (Access to and use of keys are also good candidates for this type of audit logging -- which brings it back into scope for purposes of this list. ;) )
-Kyle H
cryptography@lists.squeakfoundation.org
-
Krishna Sankar -
Kyle Hamilton -
Ron Teitelbaum