FW: Image Unique Identifier
Locked
12
12
Re: FW: Image Unique Identifier
 
|
On Thu, Aug 24, 2006 at 12:56:26AM +0200, Lex Spoon wrote:
> 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. By no means guaranteed to be unique, but recent versions of the VM provide a sessionIdentifier for this purpose, which as you suggest could be combined with an IP address and/or process ID. The session identifier is currently used in the FilePlugin to help identify stale file handles, but the intent is to provide an identifier that more or less represents the current invocation of the VM along with the image that is was loaded from the image file. The value is obtained from Interpreter>>getThisSessionID. Have a look at the file plugin, or if you have OSProcess loaded, do "OSProcess accessor getSessionIdentifier" to find its current value. Using the Squeak sessionIdentifier combined with a process ID is probably a good combination, although for any practical implementation that is likely to occur in the next 20 years or so, the sessionIdentifier is probably sufficient. Better yet would be to just treat the Squeak session identifier as a hopefully-unique ByteArray of unknown length. Currently it will just happen to be an array of 4 bytes on a 32 bit machine, or 8 bytes on a 64 byte machine, but in some future Universe (sic) it might be be 128 bytes of impossibly obfuscated data. With respect to the original security question, the sessionIdentifier is visible in the image, hence inherently insecure. As others have pointed out, if you want an identifier that will not be visible to some other invocation of the image file, you simply cannot make it visible in the image at all. Dave p.s. "secure squeak" sounds like an oxymoron to me. |
RE: FW: Image Unique Identifier
|
|
Hi David,
Thank you that is very helpful. I was just looking at files because in my reading there were a lot of references about storing encrypted information in a file that has OS Access Control. I didn't see a way to change the security parameters of a file. Do we have that somewhere, is it planned. I want to be able to set the access rights for the file to be the currently logged in user only. As for your p.s. it amazes me that we haven't tried this yet. We have a huge amount of resources in very talented people, and in software, we have some very nice implementations of cryptography primitives. We will have SSL very soon. I suppose that protecting a SSL server is not really that difficult as long as a good firewall is used to protect it. I'm hoping to push us to implementing more and better security that is easy to use. What gets me is the concept of good enough security. Reading cryptography texts the concept comes up over and over. Aiming for completely secure implementations prevents any forward motion towards better security. I believe that we can provide security which is as good if not better then much of what I've seen. Will it be perfect? No, but will it be enough to rise to the standards of say NIST. Yes I believe it can. You would be surprised at what government agencies are currently using! I believe the average grade for using mandatory standards was a D! I'm hoping that my SSL (actually it is tls 1.2) implementation will encourage more people to participate in securing squeak! Thanks again for the suggestion. Ron Teitelbaum Squeak Cryptography Team Leader > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of David T. Lewis > Sent: Wednesday, August 23, 2006 10:34 PM > To: The general-purpose Squeak developers list > Subject: Re: FW: Image Unique Identifier > > On Thu, Aug 24, 2006 at 12:56:26AM +0200, Lex Spoon wrote: > > 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. > > By no means guaranteed to be unique, but recent versions of the VM > provide a sessionIdentifier for this purpose, which as you suggest > could be combined with an IP address and/or process ID. The session > identifier is currently used in the FilePlugin to help identify stale > file handles, but the intent is to provide an identifier that more or > less represents the current invocation of the VM along with the image > that is was loaded from the image file. > > The value is obtained from Interpreter>>getThisSessionID. Have > a look at the file plugin, or if you have OSProcess loaded, do > "OSProcess accessor getSessionIdentifier" to find its current value. > Using the Squeak sessionIdentifier combined with a process ID is > probably a good combination, although for any practical implementation > that is likely to occur in the next 20 years or so, the sessionIdentifier > is probably sufficient. > > Better yet would be to just treat the Squeak session identifier as > a hopefully-unique ByteArray of unknown length. Currently it will > just happen to be an array of 4 bytes on a 32 bit machine, or 8 > bytes on a 64 byte machine, but in some future Universe (sic) it > might be be 128 bytes of impossibly obfuscated data. > > With respect to the original security question, the sessionIdentifier > is visible in the image, hence inherently insecure. As others have > pointed out, if you want an identifier that will not be visible > to some other invocation of the image file, you simply cannot > make it visible in the image at all. > > Dave > > p.s. "secure squeak" sounds like an oxymoron to me. > > |
|
|
In reply to this post by timrowledge
On Wed, 23 Aug 2006 17:23:13 +0200, tim Rowledge wrote:
> On 23-Aug-06, at 12:14 AM, Klaus D. Witzel wrote: ... >> 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. Yes, that's the modern equivalent of it. How did someone say it: "back to the future", the B5000 is from the 195x's ;-) > 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. Sure, that's the right place. > It is essentially a writable control store that can be used for data as > well. Nice idea. /Klaus > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Satisfaction Guaranteed: We'll send you another copy if it fails. > > > > |
Re: FW: Image Unique Identifier
|
|
In reply to this post by Ron Teitelbaum
On Wed, Aug 23, 2006 at 11:38:51PM -0400, Ron Teitelbaum wrote:
> Hi David, > > Thank you that is very helpful. I was just looking at files because in my > reading there were a lot of references about storing encrypted information > in a file that has OS Access Control. I didn't see a way to change the > security parameters of a file. Do we have that somewhere, is it planned. I > want to be able to set the access rights for the file to be the currently > logged in user only. We do not have it, and it is not planned. File access control is very platform-specific, so it would be difficult to implement in a way that you could rely on for all platforms. Technically, it would be trivial to add a #primitiveChmod method to the OSProcessPlugin (there are lots of similar file system prims in OSPP, I just didn't happen to include chmod). But that immediately leads to to two problems. OSPP itself intruduces lots of security holes (precisely because it is designed to open up access to the operating system), and it is normally included only with Unix based VMs (it is available for Windows also, but you have to build your own VM and plugins to get it). If you are doing your own plugin to implement some security features, then you could borrow the relevant code from OSPP for a file system primitive, and adapt it to call chmod(). That would give you a more controlled implementation that might serve your needs. But overall I am inclined to think that relying on file system features will turn out to be more trouble than it is worth. Hope this helps, Dave |
Re: FW: Image Unique Identifier
|
|
David T. Lewis schrieb:
> On Wed, Aug 23, 2006 at 11:38:51PM -0400, Ron Teitelbaum wrote: >> Hi David, >> >> Thank you that is very helpful. I was just looking at files because in my >> reading there were a lot of references about storing encrypted information >> in a file that has OS Access Control. I didn't see a way to change the >> security parameters of a file. Do we have that somewhere, is it planned. I >> want to be able to set the access rights for the file to be the currently >> logged in user only. > > We do not have it, and it is not planned. File access control is very > platform-specific, so it would be difficult to implement in a way that you > could rely on for all platforms. Supposing this is is running on *ix - wouldn't a umask call in the start-up script be sufficient for that? - Bert - |
|
|
In reply to this post by Ron Teitelbaum
"Ron Teitelbaum" <[hidden email]> writes:
> 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. Maybe you should divide the problem into two halves? First solve the ID problem, then solve the cryptographic-key(s) problem. I have been talking about the ID part, for which the above seem to be just fine. It seems like an inescapable core of a remote object reference is going to include this kind of public material, just so that you can actually send your network packets to the right place. You can then add a secret part. For that, I do not have a firm suggestion, but you will certainly need to look into cryptography and into random number generators. I would be sure to check out what E does for sturdy references: http://www.erights.org/elang/concurrency/introducer.html By the way, if you are interested in Internet security in general, you should check out the "Y property" stuff. Start from http://www.yurl.net and follow the links. -Lex |
RE: FW: Image Unique Identifier
|
|
Hi Lex,
Very nice links, I will read through them carefully. Thank you! Ron Teitelbaum > From: Lex Spoon > Sent: Thursday, August 24, 2006 11:18 AM > > "Ron Teitelbaum" <[hidden email]> writes: > > 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. > > Maybe you should divide the problem into two halves? First solve the > ID problem, then solve the cryptographic-key(s) problem. I have been > talking about the ID part, for which the above seem to be just fine. > It seems like an inescapable core of a remote object reference is > going to include this kind of public material, just so that you can > actually send your network packets to the right place. > > You can then add a secret part. For that, I do not have a firm > suggestion, but you will certainly need to look into cryptography and > into random number generators. I would be sure to check out what E > does for sturdy references: > > http://www.erights.org/elang/concurrency/introducer.html > > > > By the way, if you are interested in Internet security in general, you > should check out the "Y property" stuff. Start from > http://www.yurl.net and follow the links. > > > -Lex > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |