OK I have two answers for you.  

My goal eventually is to lock down the image altogether in a run time
environment by reviewing the VM and all entry points, signing the image,
removing the compiler and other ways to add code, and checking all methods
have not changed before they are executed.  In this way we can trust that
the code was not tampered with after the image is signed by the delivering
party.  

That would be 3) don't trust the code
With the modification of don't trust the code that hasn't be reviewed and
signed.  If we have that level of review then if the implementation uses a
distributed objects mechanism the developers could guard against leakage.  

For now I would like people to start using my SSL implementation, (when it
is completed) without the worry of having someone come in and snatch their
certificate information.  I'm trying now to protect the information as much
as possible for developers that are terribly security minded by not leaving
the private key unencrypted in the running image. 

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

Ron


> -----Original Message-----
> From: Colin Putney [mailto:cputney at wiresong.ca]
> Sent: Tuesday, August 22, 2006 7:24 PM
> To: Ron at USMedRec.com; The general-purpose Squeak developers list
> Subject: Re: Image Unique Identifier
> 
> 
> 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