Smalltalk › Squeak › Other › Squeak - Cryptography

Todays Meeting update

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Ron Teitelbaum

Todays Meeting update

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
[hidden email]
Squeak Cryptography Team Leader

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

cerebus-4

Re: Todays Meeting update

On 11/30/06, Ron Teitelbaum <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: 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 <[hidden email]> 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&id=165&Itemid=123
)

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

cerebus-4

Re: Re: Todays Meeting update

On 12/1/06, Kyle Hamilton <[hidden email]> 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
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Todays Meeting update

In reply to this post by Kyle Hamilton

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:[hidden email]]
> Sent: Friday, December 01, 2006 4:35 AM
> To: Cryptography Team Development List
> Cc: [hidden email]
> 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 <[hidden email]> 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&id=165&Itemid=123
> )
>
> -Kyle H

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Todays Meeting update

In reply to this post by cerebus-4

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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Cerebus
> Sent: Friday, December 01, 2006 12:01 AM
> To: [hidden email]; Cryptography Team Development List
> Subject: Re: [Cryptography Team] Todays Meeting update
>
> On 11/30/06, Ron Teitelbaum <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: Re: Todays Meeting update

In reply to this post by cerebus-4

On 12/1/06, Cerebus <[hidden email]> wrote:

> On 12/1/06, Kyle Hamilton <[hidden email]> 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/d5cfaedc804d8b27/3f0181d44571b601?lnk=gst&q=fips+validation+revoked&rnum=1#3f0181d44571b601

> > 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
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

cerebus-4

Re: Todays Meeting update

In reply to this post by Ron Teitelbaum

On 12/1/06, Ron Teitelbaum <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Todays Meeting update AND Eval Islands as Security Component

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:[hidden email]]
> Sent: Friday, December 01, 2006 10:31 AM
> To: [hidden email]; Cryptography Team Development List
> Subject: Re: [Cryptography Team] Todays Meeting update
>
> On 12/1/06, Ron Teitelbaum <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

cerebus-4

Re: Re: Todays Meeting update

In reply to this post by Kyle Hamilton

On 12/1/06, Kyle Hamilton <[hidden email]> 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
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: Todays Meeting update AND Eval Islands as Security Component

In reply to this post by Ron Teitelbaum

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 <[hidden email]> 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:[hidden email]]
> > Sent: Friday, December 01, 2006 10:31 AM
> > To: [hidden email]; Cryptography Team Development List
> > Subject: Re: [Cryptography Team] Todays Meeting update
> >
> > On 12/1/06, Ron Teitelbaum <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

--

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography