On Aug 22, 2006, at 6:51 PM, Ron Teitelbaum wrote:

> Hey Colin,
>
> Get out the tinfoil.
>
> The unique id is part of a key that protects security  
> certificates.  If the
> image is shut down, or is copied to another machine, we don't want  
> that
> image to have someone else certificate information.  Right now the  
> data is
> encrypted in memory so that there is no leakage of information from  
> the
> running image.  I generate a key to protect the data, but that key  
> currently
> lives on the certificate object.  That means that if the  
> certificate object
> were to be transferred to another machine they could use your  
> certificate.
> I want to make sure that doesn't happen, or to make sure that it  
> would be
> extremely difficult or impossible even for me (the guy writing to  
> the code)
> to get the information to work outside of the image that imported  
> it (and
> therefore had rights to the certificate in the first place).

I should have known better than to ask a crypto guy how paranoid he  
is. Sorry. Let me try again.

I was trying to ask where you want the boundary of trust to be.  
Clearly you have to trust the crypto code. You probably also have to  
trust the code it relies on. So lets say you have good test suite,  
and you can use Spoon to strip out all the code that SSL doesn't  
depend on. This, then, is what you *must* trust. Do a formal code  
review if you have to, but you can't run the crypto code without it.

But SSL by its self isn't useful for much. So I've got to be able to  
load other code into the image - a web server, say, or a mail  
program. The question is, do you want to implement this id in such a  
way that you don't have to trust that code?

So the three levels of trust I mentioned before would be:

1) just trust all the code in the image, anything else is impractical

2) trust the code not to reveal the id on purpose, but try to protect  
against accidents

3) don't trust the code

Colin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2687 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060822/8cb8684b/smime.bin