Image Unique Identifier

Ron Teitelbaum Ron at USMedRec.com
Wed Aug 23 16:39:30 UTC 2006


Klaus,  

Thank you for your reply!

I'm planning on supporting PKCS for non Microsoft platforms, and smartcards
which solves this problem (Just like the B5000 which I'd never heard of.
Wow that thing is a monster! :^)  

For my project it needs to be secure enough so that I can give away a
Smalltalk image from a web site to end users that have no idea about
security and will be using the image on and with the internet in some type
of runtime environment.  The people will be storing and sharing their
medical information.  The trick here is to make sure that the security is
strong enough that that information can not be hacked, that security
professionals looking at the product agree it is safe enough, and that
breaches are detectable and fixed quickly.

For an SSL server I guess the server is as strong as the DMZ setup around
it, for that I am less worried.

I went ahead and implemented a SmalltalkImageInstanceID.  It does a few
things.  It places a UUID on a class variable on startUp, removes it on shut
down.  I also implemented an accessor for the class variable with the same
name as the class variable that returns nil.  This makes it difficult to set
and read the class variable directly, but it's a minor hack.   The more I
think about it the more I agree that the key should not be in the image.  I
agree that it is safer in the VM how much safer, I'm not sure!

I am very interested in what you mean by: 

Having the Host OS implant the key on chip of the running executable.  I can
envision having a memory register hold the key but I don't know how to keep
other programs from accessing that key.  Nor can I imagine how to have the
vm access that key and present it to the image without encountering the same
problems as having the key generated in the image.  Could you elaborate
some, or suggest some additional reading?

Also could you explain more about what you mean by:

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

Given the requirements I'm sure you will agree that extra hardware like a
smartcard is not feasible for end users (but may be feasible for physicians
and hospitals).  

Getting access to a certificate stored on Microsoft's Store was much easier
then I thought it would be, now that I have access to it I have this need to
protect it.  It makes you wonder, if Microsoft couldn't secure the
certificate (other then with a box that comes up and says "Accessing your
private Key") then how is this supposed to be done! 

If you have suggestions I would very much appreciate learning from your
experience.

Thank you for your time!

Ron
 

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Klaus D. Witzel
> Sent: Wednesday, August 23, 2006 3:14 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Image Unique Identifier
> 
> 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