Re: crypting ruby source

On Tue, Apr 16, 2002 at 09:23:02AM +0900, [e-mail] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In article <[e-mail]>,
> Jim Freeze  <[e-mail]> 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...
~