Image Unique Identifier
Klaus D. Witzel
klaus.witzel at cobss.com
Wed Aug 23 07:14:26 UTC 2006
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
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
> 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.
More information about the Squeak-dev