Image Unique Identifier

Klaus D. Witzel klaus.witzel at cobss.com
Wed Aug 23 07:14:26 UTC 2006


Hi Ron,

on Wed, 23 Aug 2006 02:26:06 +0200, you wrote:

> The major issue for me is not finding a random key, I'm ok with that, my
> worry is how to protect that key inside the image, or how to append image
> instance information to that key so that only the running image can  
> retrieve information encrypted with that key.

Having worked for supersecurity-hyperparanoid www.nato.int in their data  
centres for some years, I think that I have some background knowledge  
which can protect that key inside the image.

The short story is, to not have the key passed to the image (i.e. during  
startup) and to not generate the key within the image (i.e. between  
startup and shutdown and/or snapshot).

The protection mechanism is to not allow to take a copy of the running  
executable (means: VM) and also to not swap the executable out of real  
(chip) memory, that means: the executable is never written back onto disk  
again. Buy a B5000 (or a modern successor) and its hardware and OS already  
does that for you ;-)

The get-it-going is to have some party (like the Squeak host OS) to  
implant a (new, unique) key, at the time it loads the VM's executable,  
into the (chip) memory of the loaded executable (you can patch linux for  
that, or else [again] go buy a B5000 ;-). So the key was not on disk in  
the past and will not be on disk in the future. The key can be accessed  
only by calling the VM and the VM will automagically destroy it when  
unwinding the process' expression stack (and when returning to a calling  
method, which is the more frequent case). Lots of details skipped here for  
the sake of brevity (like: the oop of the key cannot be stored in a  
non-context object).

If the part which implants the key in the executable is too heavy a  
change, have the VM generate a key during startup. Of course this is  
weaker than the above (all other details skipped here).

No other change is necessary. You're even free to deploy the compiler, no  
problem (perhaps except when you discuss that with paranoids ;-)

> Basically I'm afraid of Spoon!  If you can copy my objects and move them,
> then I need to protect against that by making sure decryption is  
> dependent
> on something unique to the instance of the running image.

This is the easier part: when doing any form of i/o (for example:  
networking, display, file r/w) the VM just has to guarantee that the key  
is not on the expression stack. This implies that the key is currently not  
in the image. Done.

/Klaus

> Ron




More information about the Squeak-dev mailing list