[ANN] Squeak Cryptography Certification Validation Officer

> 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 <[hidden email]> wrote:
> >
> > Krishna Sankar is joining our team as the new Squeak Cryptography
> > Certification Validation Officer.
> >
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] 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 <[hidden email]> wrote:
> > >
> > > Krishna Sankar is joining our team as the new Squeak Cryptography
> > > Certification Validation Officer.
> > >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> >
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > y
>
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry

> 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 <[hidden email]> wrote:
> > >
> > > Krishna Sankar is joining our team as the new Squeak Cryptography
> > > Certification Validation Officer.
> > >
> > _______________________________________________
> > 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
>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Kyle
> Hamilton
> Sent: Wednesday, October 11, 2006 10:49 PM
> To: [hidden email]; 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 <[hidden email]> 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 <[hidden email]> wrote:
> > > >
> > > > Krishna Sankar is joining our team as the new Squeak Cryptography
> > > > Certification Validation Officer.
> > > >
> > > _______________________________________________
> > > 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 H
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> 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: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Kyle
> > Hamilton
> > Sent: Wednesday, October 11, 2006 10:49 PM
> > To: [hidden email]; 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 <[hidden email]> 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

> -----Original Message-----
> From: Kyle Hamilton [mailto:[hidden email]]
> Sent: Thursday, October 12, 2006 4:36 PM
> To: [hidden email]; 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 <[hidden email]> 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: [hidden email]
> > > [mailto:[hidden email]] On Behalf Of
> Kyle
> > > Hamilton
> > > Sent: Wednesday, October 11, 2006 10:49 PM
> > > To: [hidden email]; 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 <[hidden email]> 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

>  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).