Hi All,
I had a very nice meeting with someone that was responsible for CC and FIPS at Mozilla.
I left the meeting with a better understanding of what we need to do. Here are my notes:
FIPS 140-2 was originally developed as a hardware specification. Many of the requirements for FIPS 140-2 software validation still resemble a hardware implementation. The basics of 140-2 are:
1) Module validation: Do the modules do what they are supposed to do. There are a number of other validations for specific algorithms that we may want to do. 2) FIPS Mode of Operation: Which requires that a user authenticate to the module before it performs any operations. This is like a smartcard or some such hardware implementation. The Trusted Computing Base would also do a self check on startUp. 3) low level / high level algorithm separation: Make sure that the algorithms are properly separated with in the OSI levels. 4) Since we are software and potentially multiuser we would need FIPS 140-2 level 2 validation.
The most difficult part of FIPS is the security document.
We may want to review openSSL and integrate that or NSS into squeak for people that have to have an FIPS validated system. This would remove our need to be validated, and shift our job to interpreting and implementing external modules properly.
OpenSSL solved the problem of code isolation, since they allow both separate lib calls and imbedding the library into your application, by setting up a chain of custody which defines how to verify the code has not changed from Authors to end users. This doesn't seem to prevent malware from changing bytes but this may not be required for FIPS validation. We should look more closely at OpenSSL's documentation.
Documentation of all modules is also needed.
Common Criteria.
It seems to me that there is little use for us to proceed with CC. CC is more like a system evaluation. They even call it a system evaluation. The evaluation has different levels we would probably want 2 or 3 but in order to have something to validate we would actually need to write a system.
An example of something that would be validated is an Operating System. The operating system requires user authentication, Access control like ACL's, resource partitioning ... In this example if the user is required to enter a password and the operating system says it needs n letters, can only be entered 3 times before being inactivated, and needs to be changed montly. Then this would be part of the Protection Profile that is already written for operating systems. If there is no current Protection Profile for your system you can either write you own, and submit it for consideration of all systems like yours or you can write a Security Target Document which explains just what your system is doing. Plus there are the controls over the development environment and library.
This "what" your system is doing is what would be evaluated. We may want to review the Java CC evaluation but it seems to me that we do not have standard authentication, acl's ... We may want to write some of those pieces for people to use, but until we have them we should probably be focusing on FIPS 140-2. I'm sorry I didn't understand the distinction earlier.
Also CC validation runs around US$200K. FIPS can be between US$40K - US$100K
I'm told that if we want to do CC then we should look into foreign labs since CC is international and a validation from say the EU would be valid in the US. Apparently Oracle saved a bundle doing this.
So I'm scheduling a follow up meeting with someone else that I was introduced too that does is working with a lab to do FIPS Validation for NSS. My interest is in how we can get enough of a direction to get things moving on our own, suggestions on selecting a lab, and what we can expect. There is nothing like practical experience. I'm considering forming our own Foundation and doing some fundraising to cover our costs, so we will need to show longevity and commitment to encourage investment. Until that time we need to make sure we are on the right path.
Comments are welcome,
Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com Squeak Cryptography Team Leader
On 11/30/06, Ron Teitelbaum Ron@usmedrec.com wrote:
We may want to review openSSL and integrate that or NSS into squeak for people that have to have an FIPS validated system. This would remove our need to be validated, and shift our job to interpreting and implementing external modules properly.
Personally I prefer NSS over OpenSSL. OpenSSL's FIPS status is still sorta in question (Why does the cryptval list still say "Not Available"?). NSS has better certificate management features. In addition, I've found it easier to get RedHat to address bugs & features in NSS than it is to get active OpenSSL developers fired up to fix things.
It seems to me that there is little use for us to proceed with CC. CC is more like a system evaluation. They even call it a system evaluation. The evaluation has different levels we would probably want 2 or 3 but in order to have something to validate we would actually need to write a system.
You get EAL2 just for showing up at the meetings is what I hear. :)
I'm told that if we want to do CC then we should look into foreign labs since CC is international and a validation from say the EU would be valid in the US. Apparently Oracle saved a bundle doing this.
I'm given to understand that the US CC evaluators are backed up into the next decade as well. CC validation takes forever. It takes longer to get a PP approved (SLOSPP-MR took years, frex.).
-- Tim
First, please allow me to apologize for my absence from this list. I have been ill, and am still not quite up to full strength; however, I have been following the discussions as best as I've been able.
My comments are interspersed with the quote below.
On 11/30/06, Cerebus cerebus2@gmail.com wrote:
We may want to review openSSL and integrate that or NSS into squeak for people that have to have an FIPS validated system. This would remove our need to be validated, and shift our job to interpreting and implementing external modules properly.
Personally I prefer NSS over OpenSSL. OpenSSL's FIPS status is still sorta in question (Why does the cryptval list still say "Not Available"?). NSS has better certificate management features. In addition, I've found it easier to get RedHat to address bugs & features in NSS than it is to get active OpenSSL developers fired up to fix things.
Funny, I've found the opposite. (And I'm on the mailing lists for both, as well as the commit lists.) This doesn't necessarily mean that your experience is invalid.
As for the "Why does the cryptval list say that OpenSSL is "Not Available"?" question, it's a slightly complex answer but it's important to understand what happened, how, why, and what the direction is.
First off, OpenSSL is the first FIPS-validated module that can be distributed as source code, and compiled by the end user. For every other module (including NSS), in order to say "FIPS-validated", one must use the precise binary libraries that the developer produced, and that the laboratories ran their tests against.
As you can probably imagine, things got confused. There were endless arguments, debates, and discussion between the developers, the labs, and NIST. It took about 5 times as much money as the Open Source Software Institute (http://oss-institute.org/) had originally raised, and two and a half years, to shepherd through the validation process.
Now, I'm going to quote directly from the Computer Security Resource Center's Cryptographic Validation (http://csrc.nist.gov/cryptval/ ) web site:
...begin quote... If a validation certificate is marked not available, the module is no longer available for procurement from the vendor identified on the certificate, but may still be retained and used to demonstrate compliance to FIPS 140-1 or FIPS 140-2.
If a validation certificate is marked as revoked, the module validation is no longer valid and may not be referenced to demonstrate compliance to FIPS 140-1 or FIPS 140-2. ...end quote...
As of right now (2006-12-01 09:03:30 GMT -- December 01, 2006 at 2:03:30 AM Mountain Standard Time), this is what certificate 642 (OpenSSL's certificate of validation) states:
...begin quote... OpenSSL FIPS Object Module (Source Content Version: OpenSSLfips1.0.tar.gz; Resultant Compiled Software Version: 1.0)
(Not Available)
(When built, installed, protected and initialized as specified in the provided Security Policy. Appendix B of the provided Security Policy specifies the complete set of source files of this module. There shall be no additions, deletions or alterations of this set as used during module build. All source files shall be verified as specified in Appendix B of the provided Security Policy. Installation, protection, and initialization shall be completed as specified in Appendix C of the provided Security Policy. Any deviation from specified verification, protection, installation and initialization procedures will result in a non FIPS 140-2 compliant module.)
Validated to FIPS 140-2 ...end quote...
This states "Not Available", not "Revoked", which is an entirely different beast.
I have a copy of the OpenSSL FIPS-1.0 code, which I obtained before the certification was changed to "Not Available". This means that I am able to use it to demonstrate compliance in any binary software that I originate, even now -- I have procured it, and the "cannot be procured" applies to integrators, not end users. However, anyone who did not have the software as of the date it was marked "Not Available" cannot use it to demonstrate compliance.
The reason for this is because there is a small amount of cryptographic code which resides outside the "security boundary" -- i.e., the HMAC-digitally-signed binary library which is generated at OpenSSL-FIPS's compilation time. (There is a message from Dr. Stephen N. Henson in the openssl-dev mailing list archives which I can find and point you to, dating from either the end of July or sometime in the entire month of August, which goes into more detail.)
(As an aside, OpenSSL validated to Level 1 -- "Multi-chip standalone". Please see http://csrc.nist.gov/cryptval/140-1/140val-all.htm#642 for full and up-to-the-minute information. It is literally impossible for a module in a general-purpose computing system to get anything more than a Level 1 validation, simply because general-purpose OSes have debugging capability which can examine the contents of memory owned by another process or library. A Level 2 validation shows resistance to such attacks.)
So, let's look at the circumstances surrounding this series of events:
1) A completely new approach to FIPS-validated module distribution (source code, instead of binary code or hardware). 1a) A lack of composite understanding by the lab 1b) A lack of composite understanding by the developers 1c) A lack of composite understanding by NIST
2) A fairly large US-government sponsor for the validation (which sponsored the validation so that it could save procurement budget money). 2a) The Department of Defense Medical Logistics Standard Support program
3) A large development community which was completely shut out of any ability to make any suggestions, modifications, or evaluations of the code as it was going through the validation process.
It is amazing, frankly, that it got validated in the first place. However, now that everyone involved has an understanding of what the process entails and the bugs present in the FIPS-validated code (it doesn't compile on HP/UX-64 [or any 64-bit platform that I'm aware of], and it's an absolute bitch to get it to compile and run in a FIPS-validated configuration on Win32 since the supported configuration relies on an open-source toolchain which does not integrate well with Microsoft's toolchain), the FIPS-1.1 validation should go more smoothly.
In this case, Open Source's strengths were hobbled by administrivia and bureaucratic "flaming hoops" that got smaller and smaller (and thus got harder and harder to jump through without getting singed) that prevented those strengths from coming into play.
I'm told that if we want to do CC then we should look into foreign labs since CC is international and a validation from say the EU would be valid in the US. Apparently Oracle saved a bundle doing this.
I'm given to understand that the US CC evaluators are backed up into the next decade as well. CC validation takes forever. It takes longer to get a PP approved (SLOSPP-MR took years, frex.).
It doesn't surprise me. Validations take a long time.
FWIW, the FIPS validation laboratory that the OSS Institute used was Domus IT Security Laboratory, of Ottawa, Ontario, Canada. (This from http://www.oss-institute.org/index.php?option=com_content&task=view&... )
-Kyle H
On 12/1/06, Kyle Hamilton aerowolf@gmail.com wrote:
Funny, I've found the opposite. (And I'm on the mailing lists for both, as well as the commit lists.) This doesn't necessarily mean that your experience is invalid.
It helps that I work for a company that manages an FFRDC supporting a large PKI. My sponsor has RedHat under a couple of different contracts that make them, shall we say, amiable to suggestion from such a source as I. :)
I have a copy of the OpenSSL FIPS-1.0 code, which I obtained before the certification was changed to "Not Available". This means that I am able to use it to demonstrate compliance in any binary software that I originate, even now -- I have procured it, and the "cannot be procured" applies to integrators, not end users. However, anyone who did not have the software as of the date it was marked "Not Available" cannot use it to demonstrate compliance.
I think this is compelling reason enough to drive implementations toward NSS. Great information though, and I appreciate the insights.
The reason for this is because there is a small amount of cryptographic code which resides outside the "security boundary" -- i.e., the HMAC-digitally-signed binary library which is generated at OpenSSL-FIPS's compilation time. (There is a message from Dr. Stephen N. Henson in the openssl-dev mailing list archives which I can find and point you to, dating from either the end of July or sometime in the entire month of August, which goes into more detail.)
Please, if only to satisfy my own curiosity.
It is literally impossible for a module in a general-purpose computing system to get anything more than a Level 1 validation, simply because general-purpose OSes have debugging capability which can examine the contents of memory owned by another process or library. A Level 2 validation shows resistance to such attacks.)
I see from the pre-val list that RedHat/Sun have a newer version of NSS (I can't recall which version) in pending review (i.e., testing is done & it has a recommendation) for both level 2 and level 1. Is there something different that NSS has done that OpenSSL did not, aside from the validation of source vs. validation of object?
-- Tim
On 12/1/06, Cerebus cerebus2@gmail.com wrote:
On 12/1/06, Kyle Hamilton aerowolf@gmail.com wrote:
I have a copy of the OpenSSL FIPS-1.0 code, which I obtained before the certification was changed to "Not Available". This means that I am able to use it to demonstrate compliance in any binary software that I originate, even now -- I have procured it, and the "cannot be procured" applies to integrators, not end users. However, anyone who did not have the software as of the date it was marked "Not Available" cannot use it to demonstrate compliance.
I think this is compelling reason enough to drive implementations toward NSS. Great information though, and I appreciate the insights.
As Ron has suggested, we can use a platform-native library to do the actual work, integrating new primitives to call it. I suggest OpenSSL because there's much less "we can't do this" that I get from the openssl-dev list than the dev-tech-crypto list. However, NSS is a valid suggestion as well. In that case, though, we're limited to the platforms which have been validated with it.
The reason for this is because there is a small amount of cryptographic code which resides outside the "security boundary" -- i.e., the HMAC-digitally-signed binary library which is generated at OpenSSL-FIPS's compilation time. (There is a message from Dr. Stephen N. Henson in the openssl-dev mailing list archives which I can find and point you to, dating from either the end of July or sometime in the entire month of August, which goes into more detail.)
Please, if only to satisfy my own curiosity.
My apologies, it was by Steve Marquess at the OSS Institute: http://groups.google.com/group/mailing.openssl.dev/browse_thread/thread/d5cf...
It is literally impossible for a module in a general-purpose computing system to get anything more than a Level 1 validation, simply because general-purpose OSes have debugging capability which can examine the contents of memory owned by another process or library. A Level 2 validation shows resistance to such attacks.)
I see from the pre-val list that RedHat/Sun have a newer version of NSS (I can't recall which version) in pending review (i.e., testing is done & it has a recommendation) for both level 2 and level 1. Is there something different that NSS has done that OpenSSL did not, aside from the validation of source vs. validation of object?
This I don't know. I'm not a member of the FIPS administration/development list. However, as RedHat is one of the sponsors for it, perhaps you could find out from their support team? (I would like to know, actually. I'm looking at the 140-2 document, describing what would be necessary -- "locks or tamper evidence" is the part that software-only systems cannot do.)
However, there are other aspects that could be implemented, including "role-based or identity-based operator authentication".
"Secure installation and generation" is what OpenSSL does; "Secure Distribution" is not available in the source code form as far as I can tell.
Though, also important to note: Level 1 is for a single operator. Level 2 is for multiple operators. As it stands, Squeak is a single-operator system (there's no authentication except what the underlying OS imposes, and that only for access to OS-level objects). It would take a major reengineering of the underlying design philosophy of Smalltalk to change that property.
-Kyle H
On 12/1/06, Kyle Hamilton aerowolf@gmail.com wrote:
I see from the pre-val list that RedHat/Sun have a newer version of NSS (I can't recall which version) in pending review (i.e., testing is done & it has a recommendation) for both level 2 and level 1. Is there something different that NSS has done that OpenSSL did not, aside from the validation of source vs. validation of object?
This I don't know. I'm not a member of the FIPS administration/development list. However, as RedHat is one of the sponsors for it, perhaps you could find out from their support team? (I would like to know, actually. I'm looking at the 140-2 document, describing what would be necessary -- "locks or tamper evidence" is the part that software-only systems cannot do.)
RedHat tells me:
NSS 3.11.4 is what's currently being evaluated. The level 2 eval is on trusted platforms (Trusted Solaris and a Trusted Linux built on RHEL4).
-- Tim
Hi Kyle,
I hope you are feeling better and are back to 100% soon, thank you for your summary of the OpenSSL validation.
Ron
-----Original Message----- From: Kyle Hamilton [mailto:aerowolf@gmail.com] Sent: Friday, December 01, 2006 4:35 AM To: Cryptography Team Development List Cc: Ron@usmedrec.com Subject: Re: [Cryptography Team] Todays Meeting update
First, please allow me to apologize for my absence from this list. I have been ill, and am still not quite up to full strength; however, I have been following the discussions as best as I've been able.
My comments are interspersed with the quote below.
On 11/30/06, Cerebus cerebus2@gmail.com wrote:
We may want to review openSSL and integrate that or NSS into squeak
for
people that have to have an FIPS validated system. This would remove
our
need to be validated, and shift our job to interpreting and
implementing
external modules properly.
Personally I prefer NSS over OpenSSL. OpenSSL's FIPS status is still sorta in question (Why does the cryptval list still say "Not Available"?). NSS has better certificate management features. In addition, I've found it easier to get RedHat to address bugs & features in NSS than it is to get active OpenSSL developers fired up to fix things.
Funny, I've found the opposite. (And I'm on the mailing lists for both, as well as the commit lists.) This doesn't necessarily mean that your experience is invalid.
As for the "Why does the cryptval list say that OpenSSL is "Not Available"?" question, it's a slightly complex answer but it's important to understand what happened, how, why, and what the direction is.
First off, OpenSSL is the first FIPS-validated module that can be distributed as source code, and compiled by the end user. For every other module (including NSS), in order to say "FIPS-validated", one must use the precise binary libraries that the developer produced, and that the laboratories ran their tests against.
As you can probably imagine, things got confused. There were endless arguments, debates, and discussion between the developers, the labs, and NIST. It took about 5 times as much money as the Open Source Software Institute (http://oss-institute.org/) had originally raised, and two and a half years, to shepherd through the validation process.
Now, I'm going to quote directly from the Computer Security Resource Center's Cryptographic Validation (http://csrc.nist.gov/cryptval/ ) web site:
...begin quote... If a validation certificate is marked not available, the module is no longer available for procurement from the vendor identified on the certificate, but may still be retained and used to demonstrate compliance to FIPS 140-1 or FIPS 140-2.
If a validation certificate is marked as revoked, the module validation is no longer valid and may not be referenced to demonstrate compliance to FIPS 140-1 or FIPS 140-2. ...end quote...
As of right now (2006-12-01 09:03:30 GMT -- December 01, 2006 at 2:03:30 AM Mountain Standard Time), this is what certificate 642 (OpenSSL's certificate of validation) states:
...begin quote... OpenSSL FIPS Object Module (Source Content Version: OpenSSLfips1.0.tar.gz; Resultant Compiled Software Version: 1.0)
(Not Available)
(When built, installed, protected and initialized as specified in the provided Security Policy. Appendix B of the provided Security Policy specifies the complete set of source files of this module. There shall be no additions, deletions or alterations of this set as used during module build. All source files shall be verified as specified in Appendix B of the provided Security Policy. Installation, protection, and initialization shall be completed as specified in Appendix C of the provided Security Policy. Any deviation from specified verification, protection, installation and initialization procedures will result in a non FIPS 140-2 compliant module.)
Validated to FIPS 140-2 ...end quote...
This states "Not Available", not "Revoked", which is an entirely different beast.
I have a copy of the OpenSSL FIPS-1.0 code, which I obtained before the certification was changed to "Not Available". This means that I am able to use it to demonstrate compliance in any binary software that I originate, even now -- I have procured it, and the "cannot be procured" applies to integrators, not end users. However, anyone who did not have the software as of the date it was marked "Not Available" cannot use it to demonstrate compliance.
The reason for this is because there is a small amount of cryptographic code which resides outside the "security boundary" -- i.e., the HMAC-digitally-signed binary library which is generated at OpenSSL-FIPS's compilation time. (There is a message from Dr. Stephen N. Henson in the openssl-dev mailing list archives which I can find and point you to, dating from either the end of July or sometime in the entire month of August, which goes into more detail.)
(As an aside, OpenSSL validated to Level 1 -- "Multi-chip standalone". Please see http://csrc.nist.gov/cryptval/140-1/140val-all.htm#642 for full and up-to-the-minute information. It is literally impossible for a module in a general-purpose computing system to get anything more than a Level 1 validation, simply because general-purpose OSes have debugging capability which can examine the contents of memory owned by another process or library. A Level 2 validation shows resistance to such attacks.)
So, let's look at the circumstances surrounding this series of events:
- A completely new approach to FIPS-validated module distribution
(source code, instead of binary code or hardware). 1a) A lack of composite understanding by the lab 1b) A lack of composite understanding by the developers 1c) A lack of composite understanding by NIST
- A fairly large US-government sponsor for the validation (which
sponsored the validation so that it could save procurement budget money). 2a) The Department of Defense Medical Logistics Standard Support program
- A large development community which was completely shut out of any
ability to make any suggestions, modifications, or evaluations of the code as it was going through the validation process.
It is amazing, frankly, that it got validated in the first place. However, now that everyone involved has an understanding of what the process entails and the bugs present in the FIPS-validated code (it doesn't compile on HP/UX-64 [or any 64-bit platform that I'm aware of], and it's an absolute bitch to get it to compile and run in a FIPS-validated configuration on Win32 since the supported configuration relies on an open-source toolchain which does not integrate well with Microsoft's toolchain), the FIPS-1.1 validation should go more smoothly.
In this case, Open Source's strengths were hobbled by administrivia and bureaucratic "flaming hoops" that got smaller and smaller (and thus got harder and harder to jump through without getting singed) that prevented those strengths from coming into play.
I'm told that if we want to do CC then we should look into foreign
labs
since CC is international and a validation from say the EU would be
valid in
the US. Apparently Oracle saved a bundle doing this.
I'm given to understand that the US CC evaluators are backed up into the next decade as well. CC validation takes forever. It takes longer to get a PP approved (SLOSPP-MR took years, frex.).
It doesn't surprise me. Validations take a long time.
FWIW, the FIPS validation laboratory that the OSS Institute used was Domus IT Security Laboratory, of Ottawa, Ontario, Canada. (This from http://www.oss- institute.org/index.php?option=com_content&task=view&id=165&Itemid=123 )
-Kyle H
Tim could you explain this in more detail?
You get EAL2 just for showing up at the meetings is what I hear. :)
Thanks,
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Cerebus Sent: Friday, December 01, 2006 12:01 AM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Todays Meeting update
On 11/30/06, Ron Teitelbaum Ron@usmedrec.com wrote:
We may want to review openSSL and integrate that or NSS into squeak for people that have to have an FIPS validated system. This would remove
our
need to be validated, and shift our job to interpreting and implementing external modules properly.
Personally I prefer NSS over OpenSSL. OpenSSL's FIPS status is still sorta in question (Why does the cryptval list still say "Not Available"?). NSS has better certificate management features. In addition, I've found it easier to get RedHat to address bugs & features in NSS than it is to get active OpenSSL developers fired up to fix things.
It seems to me that there is little use for us to proceed with CC. CC
is
more like a system evaluation. They even call it a system evaluation.
The
evaluation has different levels we would probably want 2 or 3 but in
order
to have something to validate we would actually need to write a system.
You get EAL2 just for showing up at the meetings is what I hear. :)
I'm told that if we want to do CC then we should look into foreign labs since CC is international and a validation from say the EU would be
valid in
the US. Apparently Oracle saved a bundle doing this.
I'm given to understand that the US CC evaluators are backed up into the next decade as well. CC validation takes forever. It takes longer to get a PP approved (SLOSPP-MR took years, frex.).
-- Tim _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
On 12/1/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Tim could you explain this in more detail?
You get EAL2 just for showing up at the meetings is what I hear. :)
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
""" EAL2: Structurally Tested
EAL2 requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time. EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems """
Basically, EAL2 says "It works and there's at least some evidence provided that it was designed," i.e., the developer showed up at the meetings. EAL1 says "It works but nobody showed it works on purpose," i.e., the developer didn't show any design documentation, or didn't have any design documents to show.
EAL3 and 4 are where the stringency takes hold.
-- Tim
Thanks Tim,
Based on that, if we design and distribute security components for Squeak and we want to be CC evaluated we should at a minimum shoot for level 3. We should revisit this when we have standard security components to offer.
All,
Would anything within Islands meet the criteria for a security component and be eligible for, or be contained in any existing security target, or protection profile? (Again my apologies for not being able to review it)
Ron
-----Original Message----- From: Cerebus [mailto:cerebus2@gmail.com] Sent: Friday, December 01, 2006 10:31 AM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Todays Meeting update
On 12/1/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Tim could you explain this in more detail?
You get EAL2 just for showing up at the meetings is what I hear. :)
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
""" EAL2: Structurally Tested
EAL2 requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time. EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems """
Basically, EAL2 says "It works and there's at least some evidence provided that it was designed," i.e., the developer showed up at the meetings. EAL1 says "It works but nobody showed it works on purpose," i.e., the developer didn't show any design documentation, or didn't have any design documents to show.
EAL3 and 4 are where the stringency takes hold.
-- Tim
If I'm understanding Mark Miller's thesis properly, it seems to be possible to look at Islands as performing the same set of operations that X.509 "Proxy Certificates" perform -- basically, as a user, you delegate permission to run on your behalf to the objects that you interact with, and they in turn grant permission to the objects they call to perform a limited set of functions for them, and so on. From the computer's point of view, you're the trust anchor (after your identity and authorization are validated from a trust anchor like a CA) for everything that it does on your behalf.
After your identity and authorization are validated, the system then evaluates the ability for code running on your behalf to perform certain operations based on what you are authorized to do.
FIPS 140-2 Level 2 requires EAL 2, not EAL 3. I think that EAL 3 is a better target to shoot for than EAL 2, though. (EAL 2 is a single-user environment.)
-Kyle H
On 12/1/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Thanks Tim,
Based on that, if we design and distribute security components for Squeak and we want to be CC evaluated we should at a minimum shoot for level 3. We should revisit this when we have standard security components to offer.
All,
Would anything within Islands meet the criteria for a security component and be eligible for, or be contained in any existing security target, or protection profile? (Again my apologies for not being able to review it)
Ron
-----Original Message----- From: Cerebus [mailto:cerebus2@gmail.com] Sent: Friday, December 01, 2006 10:31 AM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Todays Meeting update
On 12/1/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Tim could you explain this in more detail?
You get EAL2 just for showing up at the meetings is what I hear. :)
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
""" EAL2: Structurally Tested
EAL2 requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time. EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems """
Basically, EAL2 says "It works and there's at least some evidence provided that it was designed," i.e., the developer showed up at the meetings. EAL1 says "It works but nobody showed it works on purpose," i.e., the developer didn't show any design documentation, or didn't have any design documents to show.
EAL3 and 4 are where the stringency takes hold.
-- Tim
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
cryptography@lists.squeakfoundation.org
-
Cerebus -
Kyle Hamilton -
Ron Teitelbaum