From: Jim Freeze Date: 2002-04-16T23:55:50+09:00 Subject: Re: crypting ruby source On Tue, Apr 16, 2002 at 09:23:02AM +0900, bbense+comp.lang.ruby.Apr.15.02@telemark.stanford.edu wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > In article <20020415125925.A90269@freeze.org>, > Jim Freeze wrote: > >On Mon, Apr 15, 2002 at 11:28:53PM +0900, Mark Probert wrote: > >> > =- Security through obscurity never works in the long run. If > your algorithm can't be public, it can't be secure. Yes, thanks for mentioning that. I'm sure it is public knowledge among this group but worth repeating. Security through obscurity is not real security. We call it raising the bar. However, for the original posters needs, 'real' security is not absolutely needed. Let me say that I am not aware of any way to protect 'live' data in a computer if the computer is in the hands of the cracker. Once it is decrypted for use, AND the cracker has access to the hardware, all bets are off. The preconditions for this problem, from my understanding, are some client using the software on their machine. It is desired to protect text source files as they sit on disk. Running C programs are assumed to be opaque (more on this later). The value of the data to the individual employee is not worth the effort to break into. The program usually offers up the data. The value to the user is the way the program interacts with the data. The need for security of program and data for the seller is to prevent copying. And although their is no real security, the bar is high enough that the effort exceeds the value. The solution I propose is to encrypt the files with a known secure algorithm. This makes the files secure as they sit on the hardrive. The key is transfereed with a known public key exchange algorthm. So far so good. The weakness is that the cracker has access to the computer. (Let me say that I have implemented this algorithm for a wide publishing distrubution system and it works fine. The users do not have the expertise nor the desire to attempt to extract keys from a running program. In addition, the real value is not the data nor the program, but the combination of the two). My proposition to raise the bar a bit was to have the key transferred into a running C program instead of into a running ruby program. > >I think this is a good idea for some situations, especially > >as you mention above for storing data. > >And, I can't imagine this being too terribly difficult to implement. > > =- It is extremely difficult to implement in any meaningful > way. At best you get security through obscurity, which may > be enough for some uses, but at best you are just fooling > yourself. If this was easy to implement, record companies > would be doing it today. Ah, you missed the point. I don't think the record company scenario is equivalent. I'm not sure many customers would appreciate having to call the record company for an access key every time they inserted a CD. > >If I was implementing this I would do it as follows: > > 1. Write a controller in c. Granted, this is the weak part > > of the system, but unless there is internal cooperation from the > > ruby parser and encrypting of the AST's, then, as far as code > > is concerned, the security if through obscurity. > > > > 2. Write a special require module (in c) that decrypts its source. > > > > 3. Use the c controller to load the encrypted ruby code, decrypt > > the require'd modules and run as normal. > > > >Again, the reason for the c controller is so that it is not trivial > >to insert a watch point to read the code after it is un-encrypted. > > =- This is trivial for any unix hacker to get around. Root can > read the memory of any process and I only have to find a break > point somewhere in the interpeter to stop the code while the > strings are still in memory. > I think I referred to this in the original post. I certainly referred to this in this post. :) Yes, you are right. All bets are off as soon as the cracker has access to the computer. In other words, if the computer is not secured, neither is your data (in a live program). > >Now, how does one get the encryption key to the controller program. > >The nice part of ruby is that it would not be difficult to write a > >challenge-response system as part of the controller so a customer > >may gain access to their program and data. > > =- This system won't stop even the mildly dedicated, and it will > piss off your customers. Managing keys in a secure fashion is > much harder than you are making it out to be. If the key to > decrypt the data is on the machine that runs the program, I > can read the src. > I disagree. The system proposed has been implemented in another context and has not had a successful cracker. My observations are that most people without a technical degree have a hard enough time distinguishing the difference between the monitor and the computer let alone find an access point inside a running program to spy on decrypted data. The 'mildly' dedicated comment is interesting as well. There has to be some compelling reason to break the system. In the above system, the cracker could get the original key and expose the ruby code, but they would have to write a hack that another user would have to install to unlock access to the data in the origanal program. A lot of effort for no value add. > =- Booker C. Bense > Cheers -- Jim Freeze If only I had something clever to say for my comment... ~