Smalltalk › Squeak › Squeak - Dev

FW: Image Unique Identifier

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

27 messages Options

Ron Teitelbaum

FW: Image Unique Identifier

Sorry about the HTML.

-Ron

From: Ron Teitelbaum
Sent: Tuesday, August 22, 2006 4:09 PM

All,

I need a unique image identifier. Does anyone have any suggestions?

The identifier must be unique so that if someone copies an image to another
machine I get a new id. It must also be unique by instance, so that if two
images or the same image is launched multiple times I should get unique
identifiers. The id should be local and non transferable plus it should
never persist, since I would like to use this id to prevent movement between
images of objects like in spoon, magma, glorp, squeakELib, croquet, or any
other distributed objects scheme.

The id will be used first in my SSL implementation.

My first thought was to use Network Card NIC address + image PID. Are these
values available through squeak? Are they available across every platform?
(if they are an you know how to retrieve them please let me know) What I
dont like about these numbers is that they are public numbers. What would
really be cool is if the VM assigned a UUID every time it started stored in
a non accessible object so that we could only get a string back instead of a
full object that someone might be tempted to move from image to image.

Thank you everyone for your help and ideas. All suggestions are very much
welcomed! Feel free to contact me off list too.

Ron Teitelbaum

ATT00238.txt (2 bytes) Download Attachment

Colin Putney

Re: Image Unique Identifier

On Aug 22, 2006, at 4:13 PM, Ron Teitelbaum wrote:

> I need a unique image identifier. Does anyone have any suggestions?

Why not have a class that creates a UUID when the image comes up, and
destroys it on shutdown? That would satisfy your requirements for
uniqueness. If you need to be able to protect the identifier from
modification by untrusted code in the image, it gets a lot harder.
You might need a plugin for that.

Colin

Ramon Leon-5

RE: Image Unique Identifier

Speaking of UUID's, I have a need for something like a UUID, but shorter,
more human readable. I'd be fine with a UUID, but the biz folks don't like
em.

A buddy and I came up with the following...

(String streamContents: [:string |
(MD5 hashMessage: UUID new)
do: [:each | string nextPutAll: (each printStringBase: 36)]])
truncateTo: 16

It does an MD5 hash on a GUID, then takes the base36 string of each
resulting number, and chops the string to a length of 16. I'm just guessing
on the 16, might try it longer or shorter, hopefully shorter. Was wondering
if anyone had any comments about this, or an alternate approach?

Ron Teitelbaum

RE: Image Unique Identifier

In reply to this post by Colin Putney

I was worried that someone would transfer my object to another image before
it shut down with some distributed object framework; I wanted to prevent
that by having the image access some data outside the image itself. I
suppose that an external file containing a UUID would have the same effect,
but would add to support problems. It is a good thought.

Ron

> -----Original Message-----
> From: Colin Putney [mailto:[hidden email]]
> Sent: Tuesday, August 22, 2006 4:45 PM
> To: [hidden email]; The general-purpose Squeak developers list
> Subject: Re: Image Unique Identifier
>
>
> On Aug 22, 2006, at 4:13 PM, Ron Teitelbaum wrote:
>
> > I need a unique image identifier. Does anyone have any suggestions?
>
> Why not have a class that creates a UUID when the image comes up, and
> destroys it on shutdown? That would satisfy your requirements for
> uniqueness. If you need to be able to protect the identifier from
> modification by untrusted code in the image, it gets a lot harder.
> You might need a plugin for that.
>
> Colin

Ron Teitelbaum

RE: Image Unique Identifier

In reply to this post by Ramon Leon-5

Hi Ramon,

The thing to keep in mind about a UUID is that it is supposed to be unique.
By hashing the UUID you will distribute the number more widely depending on
the UUID implementation. The beginning bytes of the UUID are supposed to be
widely spread so I doubt that this makes much difference.

For example

(1 to: 10) collect: [:i | UUID new] I get:
an UUID('48d374b0-b196-6a40-a15e-79a02a8dde89')
an UUID('48eacb8f-4564-d84f-a456-2856c5226b97')
an UUID('de67f9a4-4a42-cd44-bf79-8046366e6c9d')
an UUID('59edd53d-eb69-164b-b7f6-5e63d6284d12')
an UUID('fae32b90-49c8-ca46-a583-129e5a0fdc02')
an UUID('cc760f65-1732-3647-b632-9087256a85f1')
an UUID('6f23d070-a505-a240-addf-a749b02d6243')
an UUID('a620fe16-4701-3d4a-9aee-0b549057d855')
an UUID('154d299f-e2fe-3b42-bd3d-0fc4c3362db8')
an UUID('0cc33014-4f35-6f4e-b9de-4a005a3ceb00'))

Notice the first group of bytes are already well dispersed so there is no
benefit to the MD5.

Truncating to size 16 will remove some of the uniqueness of the UUID. Since
some of the goal of UUID was to disperse the values the likelihood of a
truncated UUID overlapping goes up as the number of objects increases but 16
bytes of 25 (which is what you would get with base 36) is close to the
uniqueness you get with UUID.

But notice the following:

A UUID new asInteger printStringBase: 36 returns a string that is 25 bytes
long for example: 'BGI8YR7NBJJTUOWIBQJU7E5TA' and if you take the first 16
you get only 16 bytes (one for each character). But if you store the UUID
asInteger guess what? The integer is only 16 bytes! So the right thing to
do if you have a budget of 16 bytes is to store the UUID as an integer
instead of as a string!

Hope that helps!

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
[hidden email]
Squeak Cryptography Team Leader

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Ramon Leon
> Sent: Tuesday, August 22, 2006 5:22 PM
> To: 'The general-purpose Squeak developers list'
> Subject: RE: Image Unique Identifier
>
> Speaking of UUID's, I have a need for something like a UUID, but shorter,
> more human readable. I'd be fine with a UUID, but the biz folks don't
> like
> em.
>
> A buddy and I came up with the following...
>
> (String streamContents: [:string |
> (MD5 hashMessage: UUID new)
> do: [:each | string nextPutAll: (each printStringBase: 36)]])
> truncateTo: 16
>
> It does an MD5 hash on a GUID, then takes the base36 string of each
> resulting number, and chops the string to a length of 16. I'm just
> guessing
> on the 16, might try it longer or shorter, hopefully shorter. Was
> wondering
> if anyone had any comments about this, or an alternate approach?
>
>

Colin Putney

Re: Image Unique Identifier

In reply to this post by Ron Teitelbaum

On Aug 22, 2006, at 5:27 PM, Ron Teitelbaum wrote:

> I was worried that someone would transfer my object to another
> image before
> it shut down with some distributed object framework; I wanted to
> prevent
> that by having the image access some data outside the image itself. I
> suppose that an external file containing a UUID would have the same
> effect,
> but would add to support problems. It is a good thought.

That's why I asked about trusted vs. untrusted code.

It seems like there are 3 levels of paranoia here:

Blasé: Do the simple thing, and if we find a situation where that
causes problems, fix them.

Cautious: Protect against accidentally transmitting the id by
accident as might happen with code that blindly reflects over the
entire system. Your remote string idea probably fits the bill here.

Tinfoil Hat: Protect against malicious code in the image actively
searching out and transmitting the id so as to defeat your security.
Tough to do in Smalltalk.

How paranoid are you?

Colin

Ramon Leon-5

RE: Image Unique Identifier

In reply to this post by Ron Teitelbaum

> Hi Ramon,
>
> The thing to keep in mind about a UUID is that it is supposed
> to be unique.
> By hashing the UUID you will distribute the number more
> widely depending on the UUID implementation. The beginning
> bytes of the UUID are supposed to be widely spread so I doubt
> that this makes much difference.
>
> For example
>
> (1 to: 10) collect: [:i | UUID new] I get:
> an UUID('48d374b0-b196-6a40-a15e-79a02a8dde89')
> an UUID('48eacb8f-4564-d84f-a456-2856c5226b97')
> an UUID('de67f9a4-4a42-cd44-bf79-8046366e6c9d')
> an UUID('59edd53d-eb69-164b-b7f6-5e63d6284d12')
> an UUID('fae32b90-49c8-ca46-a583-129e5a0fdc02')
> an UUID('cc760f65-1732-3647-b632-9087256a85f1')
> an UUID('6f23d070-a505-a240-addf-a749b02d6243')
> an UUID('a620fe16-4701-3d4a-9aee-0b549057d855')
> an UUID('154d299f-e2fe-3b42-bd3d-0fc4c3362db8')
> an UUID('0cc33014-4f35-6f4e-b9de-4a005a3ceb00'))
>
> Notice the first group of bytes are already well dispersed so
> there is no benefit to the MD5.

Ah, yea we were hashing it in hopes that it'd lessen the impact of trimming
it. I wasn't aware it was already dispersed.

>
> Truncating to size 16 will remove some of the uniqueness of
> the UUID. Since some of the goal of UUID was to disperse the
> values the likelihood of a truncated UUID overlapping goes up
> as the number of objects increases but 16 bytes of 25 (which
> is what you would get with base 36) is close to the
> uniqueness you get with UUID.
>

Any idea how close?

> But notice the following:
>
> A UUID new asInteger printStringBase: 36 returns a string
> that is 25 bytes long for example:
> 'BGI8YR7NBJJTUOWIBQJU7E5TA' and if you take the first 16 you
> get only 16 bytes (one for each character). But if you store
> the UUID asInteger guess what? The integer is only 16 bytes!
> So the right thing to do if you have a budget of 16 bytes is
> to store the UUID as an integer instead of as a string!

It's not about storage, I can store whatever I want, it's about a short
string representation for human use.

Ron Teitelbaum

RE: Image Unique Identifier

In reply to this post by Colin Putney

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

Ron

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Colin Putney
> Sent: Tuesday, August 22, 2006 5:52 PM
> To: [hidden email]
> Cc: 'The general-purpose Squeak developers list'
> Subject: Re: Image Unique Identifier
>
>
> On Aug 22, 2006, at 5:27 PM, Ron Teitelbaum wrote:
>
> > I was worried that someone would transfer my object to another
> > image before
> > it shut down with some distributed object framework; I wanted to
> > prevent
> > that by having the image access some data outside the image itself. I
> > suppose that an external file containing a UUID would have the same
> > effect,
> > but would add to support problems. It is a good thought.
>
> That's why I asked about trusted vs. untrusted code.
>
> It seems like there are 3 levels of paranoia here:
>
> Blasé: Do the simple thing, and if we find a situation where that
> causes problems, fix them.
>
> Cautious: Protect against accidentally transmitting the id by
> accident as might happen with code that blindly reflects over the
> entire system. Your remote string idea probably fits the bill here.
>
> Tinfoil Hat: Protect against malicious code in the image actively
> searching out and transmitting the id so as to defeat your security.
> Tough to do in Smalltalk.
>
> How paranoid are you?
>
> Colin

Ron Teitelbaum

RE: Image Unique Identifier

In reply to this post by Ramon Leon-5

> From: Ramon Leon
> Sent: Tuesday, August 22, 2006 6:10 PM
>
> > Hi Ramon,
> >
> > The thing to keep in mind about a UUID is that it is supposed
> > to be unique.
> > By hashing the UUID you will distribute the number more
> > widely depending on the UUID implementation. The beginning
> > bytes of the UUID are supposed to be widely spread so I doubt
> > that this makes much difference.
> >
> > For example
> >
> > (1 to: 10) collect: [:i | UUID new] I get:
> > an UUID('48d374b0-b196-6a40-a15e-79a02a8dde89')
> > an UUID('48eacb8f-4564-d84f-a456-2856c5226b97')
> > an UUID('de67f9a4-4a42-cd44-bf79-8046366e6c9d')
> > an UUID('59edd53d-eb69-164b-b7f6-5e63d6284d12')
> > an UUID('fae32b90-49c8-ca46-a583-129e5a0fdc02')
> > an UUID('cc760f65-1732-3647-b632-9087256a85f1')
> > an UUID('6f23d070-a505-a240-addf-a749b02d6243')
> > an UUID('a620fe16-4701-3d4a-9aee-0b549057d855')
> > an UUID('154d299f-e2fe-3b42-bd3d-0fc4c3362db8')
> > an UUID('0cc33014-4f35-6f4e-b9de-4a005a3ceb00'))
> >
> > Notice the first group of bytes are already well dispersed so
> > there is no benefit to the MD5.
>
> Ah, yea we were hashing it in hopes that it'd lessen the impact of
> trimming
> it. I wasn't aware it was already dispersed.
>
> >
> > Truncating to size 16 will remove some of the uniqueness of
> > the UUID. Since some of the goal of UUID was to disperse the
> > values the likelihood of a truncated UUID overlapping goes up
> > as the number of objects increases but 16 bytes of 25 (which
> > is what you would get with base 36) is close to the
> > uniqueness you get with UUID.
> >
>
> Any idea how close?

>From wikipedia:

The number of theoretically possible UUIDs is therefore 256 raisedTo: 16 or
about 3.4 × 10 raisedTo: 38. This means that during a 10 billion year
lifetime of the Earth, about 1 trillion UUIDs have to be created every
nanosecond to exhaust the number of UUIDs.

So I would say depending on the distribution, if it is evenly spread through
all bytes then the answer to your question is 16/25 (roughly 3/5) of the
above statement.

I understand the original implementation of UUID used information from the
computer but people said this was a bad thing since data created from a
computer could be traced back to that computer. I don't see that in this
UUID and I'm not sure of our implementation. If it is based on SHA then the
distribution should be very close to random meaning 3/5th's. If it is the
old UUID where the distribution was wider on the beginning bits then I'd say
you have a larger amount of uniqueness in the first 16 of 25 bits, although
guaranteed uniqueness came from the computer id so who knows.

>
> > But notice the following:
> >
> > A UUID new asInteger printStringBase: 36 returns a string
> > that is 25 bytes long for example:
> > 'BGI8YR7NBJJTUOWIBQJU7E5TA' and if you take the first 16 you
> > get only 16 bytes (one for each character). But if you store
> > the UUID asInteger guess what? The integer is only 16 bytes!
> > So the right thing to do if you have a budget of 16 bytes is
> > to store the UUID as an integer instead of as a string!
>
> It's not about storage, I can store whatever I want, it's about a short
> string representation for human use.
>

Does your implementation share resources, like a single database? If so a
human readable record number could use a db sequence starting at 1. Those
are the most human readable numbers. Or consider bar codes of the 16 bit
number instead!

Overall I don't see 'BGI8YR7NBJJTUOWI' being much more readable then
'0cc33014-4f35-6f4e-b9de-4a005a3ceb00'. I like 123632 better!

Happy coding!

Ron Teitelbaum

johnmci

Re: Image Unique Identifier

Ok, well first the squeak VM returns a UUID if that support is in the
VM to fetch it from the host operating system
If it is not found then we generate a type of UUID based on the
squeak random number generator with a reset very N usages.
However I can't speak for how random that would be, since I don't
believe it's considered a cryptographic level random number generator.

For platforms that support getting the UUID from the host operating
system the system *might* have done a one-way hash on
the UUID. How valid is that? You would have to get the vendors to
admit what they are doing.

On 22-Aug-06, at 4:14 PM, Ron Teitelbaum wrote:

> I understand the original implementation of UUID used information
> from the
> computer but people said this was a bad thing since data created
> from a
> computer could be traced back to that computer. I don't see that
> in this
> UUID and I'm not sure of our implementation. If it is based on SHA
> then the
> distribution should be very close to random meaning 3/5th's. If it
> is the
> old UUID where the distribution was wider on the beginning bits
> then I'd say
> you have a larger amount of uniqueness in the first 16 of 25 bits,
> although
> guaranteed uniqueness came from the computer id so who knows.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Colin Putney

Re: Image Unique Identifier

In reply to this post by Ron Teitelbaum

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

smime.p7s (3K) Download Attachment

ccrraaiigg

re: Image Unique Identifier

In reply to this post by Ron Teitelbaum

Hi Ron--

For what it's worth, there are random-number servers on the net. I
like randomnumbers.org, since it uses a quantum process (photons through
a semi-transmissive mirror). Or you could buy the PCI card they use[1]
and run such a server yourself.

-C

[1] http://www.idquantique.com/products/quantis.htm

--
Craig Latta
http://netjam.org/resume

Ron Teitelbaum

RE: Image Unique Identifier

In reply to this post by Colin Putney

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:[hidden email]]
> Sent: Tuesday, August 22, 2006 7:24 PM
> To: [hidden email]; 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

Ramon Leon-5

RE: Image Unique Identifier

In reply to this post by Ron Teitelbaum

> Does your implementation share resources, like a single
> database? If so a human readable record number could use a
> db sequence starting at 1. Those are the most human readable
> numbers. Or consider bar codes of the 16 bit number instead!

Yes, but I'm doing this to avoid having to do exactly that, a sequenced
number that has to be managed, and looks like a sequence. The string needs
to appear kinda random, and since I'm doing the front end in Squeak, I don't
want to be dependent on the database, which involves a web service call due
to squeak poor support for SqlServer.

> Overall I don't see 'BGI8YR7NBJJTUOWI' being much more
> readable then '0cc33014-4f35-6f4e-b9de-4a005a3ceb00'.

Neither do I, but my boss does, so I'm happy to use the first 16 digits off
a base 36 UUID.

>
> Happy coding!
>
> Ron Teitelbaum

Thanks, appreciate the help.

Ron Teitelbaum

RE: Image Unique Identifier

In reply to this post by ccrraaiigg

Hi Craig,

We have an implemntation of SecureRandom which I am very comfortable with.
It uses TripleDES to achieve a random distribution which should be very
close to random noise. Chris worked on it based on the suggestions from
Bruce Schneier in "Practical Cryptography".

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.

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.

Ron

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Craig Latta
> Sent: Tuesday, August 22, 2006 7:32 PM
> To: [hidden email]
> Subject: re: Image Unique Identifier
>
>
> Hi Ron--
>
> For what it's worth, there are random-number servers on the net. I
> like randomnumbers.org, since it uses a quantum process (photons through
> a semi-transmissive mirror). Or you could buy the PCI card they use[1]
> and run such a server yourself.
>
>
> -C
>
> [1] http://www.idquantique.com/products/quantis.htm
>
> --
> Craig Latta
> http://netjam.org/resume
>
>
>

Klaus D. Witzel

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

timrowledge

Re: Image Unique Identifier

On 23-Aug-06, at 12:14 AM, Klaus D. Witzel wrote:

>
> 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 nearest hardware equivalent that I know of would be the latest
ARM designs; they have a software controlled chunk on on-cpu memory
that is cache-speed and never reflected on any if the package pins.
Thus you could load the routine to generate the uuid into this
memory, execute entirely in there with no shadow of the intermediate
results ever being visible, and then store the result and and testing
routine in there. Of course, I would want to install crucial parts of
the VM in this memory space as well.

It is essentially a writable control store that can be used for data
as well. Nice idea.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Satisfaction Guaranteed: We'll send you another copy if it fails.

Ron Teitelbaum

RE: Image Unique Identifier

In reply to this post by Klaus D. Witzel

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: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Klaus D. Witzel
> Sent: Wednesday, August 23, 2006 3:14 AM
> To: [hidden email]
> 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
>
>

Lex Spoon

Re: FW: Image Unique Identifier

In reply to this post by Ron Teitelbaum

"Ron Teitelbaum" <[hidden email]> writes:
> I need a unique image identifier. Does anyone have any suggestions?
>
> The identifier must be unique so that if someone copies an image to another
> machine I get a new id. It must also be unique by instance, so that if two
> images or the same image is launched multiple times I should get unique
> identifiers. The id should be local and non transferable plus it should
> never persist, since I would like to use this id to prevent movement between
> images of objects like in spoon, magma, glorp, squeakELib, croquet, or any
> other distributed objects scheme.

UUID's are a sort of perpetual motion machine for computer science.
They are nice to have, but none of them work, despite the large number
of designs that are tantalizingly close. It is better to talk about
plain old identifiers, ID's. They are never universally unique, so
the first U should go; they are always *somewhat* unique, and so the
second U is redundent. It's just about identifiers.

The "universally" part seems possible for some people, so let me dwell
on it a minute. One problem is, if you have no restrictions on the
execution environment, then you can have no grounds for ensuring
uniqueness, either. Anything that you might be using for uniqueness,
might get duplicated if people are running your code on a virtual
machine such as VMWare.

To address just one example, consider using a random number generator
from the network. First, you can never really know that two images
are really calling the same generator server. The Internet is a
mysterious thing when you factor in firewalls, caches, and emulation.
Further, if you somehow do know you are calling the same server, why
not save yourself the headaches and have the server hand out plain old
sequential ID numbers?

Okay, enough bashing of UUID's. For your problem, here are two
possible avenues for (non-universally unique) ID's to use.

1. An IP plus a process ID (which might be an IP port number) plus an
image-wide unique number. Such an ID is unique relative to a
particular IP network, but of course can be duplicated--just think
about all the computers in the world with address 192.168.1.1.

2. You might want to use something like http URL's, with a hostname
and a list of strings as the identifier.

These are just ideas, though. In the end, you need to spend some time
thinking about the more specific problem. Internet email's
Message-ID's are a farce, but POP's UIDL's are simple and work. The
difference is that Message-ID's pretended to be universally unique,
while UIDL's are only unique relative to a particular mail server.

-Lex

Ron Teitelbaum

RE: FW: Image Unique Identifier

Hey Lex,

Thank you for your response. I had considered IP Address, computer name,
NIC address and PID. But when I thought more about it I thought they were
too public. I then considered adding the startup time of the image but it
was only accurate within a second and I figured it is possible that two
images would be started in the same second and that information could be
leaked out, so it wasn't good enough. I would feel very comfortable with a
UUID if that UUID could be protected by the VM since in order to retrieve
information from an image an attacker would have to find the UUID for an
image. Duplication of the id does not make this any easier.

Thanks again!

Ron

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Lex Spoon
> Sent: Wednesday, August 23, 2006 6:56 PM
> To: [hidden email]
> Subject: Re: FW: Image Unique Identifier
>
> "Ron Teitelbaum" <[hidden email]> writes:
> > I need a unique image identifier. Does anyone have any suggestions?
> >
> > The identifier must be unique so that if someone copies an image to
> another
> > machine I get a new id. It must also be unique by instance, so that if
> two
> > images or the same image is launched multiple times I should get unique
> > identifiers. The id should be local and non transferable plus it
> should
> > never persist, since I would like to use this id to prevent movement
> between
> > images of objects like in spoon, magma, glorp, squeakELib, croquet, or
> any
> > other distributed objects scheme.
>
>
> UUID's are a sort of perpetual motion machine for computer science.
> They are nice to have, but none of them work, despite the large number
> of designs that are tantalizingly close. It is better to talk about
> plain old identifiers, ID's. They are never universally unique, so
> the first U should go; they are always *somewhat* unique, and so the
> second U is redundent. It's just about identifiers.
>
> The "universally" part seems possible for some people, so let me dwell
> on it a minute. One problem is, if you have no restrictions on the
> execution environment, then you can have no grounds for ensuring
> uniqueness, either. Anything that you might be using for uniqueness,
> might get duplicated if people are running your code on a virtual
> machine such as VMWare.
>
> To address just one example, consider using a random number generator
> from the network. First, you can never really know that two images
> are really calling the same generator server. The Internet is a
> mysterious thing when you factor in firewalls, caches, and emulation.
> Further, if you somehow do know you are calling the same server, why
> not save yourself the headaches and have the server hand out plain old
> sequential ID numbers?
>
>
> Okay, enough bashing of UUID's. For your problem, here are two
> possible avenues for (non-universally unique) ID's to use.
>
> 1. An IP plus a process ID (which might be an IP port number) plus an
> image-wide unique number. Such an ID is unique relative to a
> particular IP network, but of course can be duplicated--just think
> about all the computers in the world with address 192.168.1.1.
>
> 2. You might want to use something like http URL's, with a hostname
> and a list of strings as the identifier.
>
>
> These are just ideas, though. In the end, you need to spend some time
> thinking about the more specific problem. Internet email's
> Message-ID's are a farce, but POP's UIDL's are simple and work. The
> difference is that Message-ID's pretended to be universally unique,
> while UIDL's are only unique relative to a particular mail server.
>
> -Lex
>
>
>