Writing a interpreter extension

On 5/22/06, Kris L. [email protected] wrote:

Its an application that deals with highly sensitive data, I dont want
insiders to be able to write a bit of ruby and dump the data to
file/screen…

You are talking about two different things: hiding code (algorithms)
and hiding data. Hiding code is useless because if it can be executed
by a computer it can be cracked by a person. The millions of patches
on the Internet prove that even little known programs are cracked as
soon
as they appear. If your data is hidden by your code being hard to
understand, it will be visible very soon - binaries or not.

You can hide data by encrypting it though, and then giving the key to
only those who may see the data. Even so, the key can be found by
fast computers but hopefully it is long enough that the search will
take too long to be feasable. This means that all encrypted data
has an expiry date, as faster computers come around.

So: must the sensitive data be given to only some of the insiders by
your
program? Or must only some of the data be revealed to the insiders?
If you are trying to give people encrypted data that is only readable
by your program, I think that’s a lost cause.

Les

On May 22, 2006, at 9:44 AM, Kris L. wrote:

Mainly I want to be able to sell ruby/rails applications without
doing a
hosted only solution (like basecamp), if I was 37signals I would
want to
sell the application as you would desktop software…

The ruby obsufcator looks good but it may never work with Rails… it
doesn’t at the moment. :frowning:

It might, but we’ve never tried it.


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

Yes two things I am concerned with, I have also looked at Java and .NET
and they also have the same problems.

Hiding code is useless because if it can be executed
by a computer it can be cracked by a person.

I would not say useless, if you offer open source then you are asking
for trouble. If you take measures to obsfucate/encrypt the code the
skill level to get/change it increases. There is no such thing as
absolute security but…

Leslie V. wrote:

On 5/22/06, Kris L. [email protected] wrote:

Its an application that deals with highly sensitive data, I dont want
insiders to be able to write a bit of ruby and dump the data to
file/screen…

You are talking about two different things: hiding code (algorithms)
and hiding data. Hiding code is useless because if it can be executed
by a computer it can be cracked by a person. The millions of patches
on the Internet prove that even little known programs are cracked as
soon
as they appear. If your data is hidden by your code being hard to
understand, it will be visible very soon - binaries or not.

You can hide data by encrypting it though, and then giving the key to
only those who may see the data. Even so, the key can be found by
fast computers but hopefully it is long enough that the search will
take too long to be feasable. This means that all encrypted data
has an expiry date, as faster computers come around.

So: must the sensitive data be given to only some of the insiders by
your
program? Or must only some of the data be revealed to the insiders?
If you are trying to give people encrypted data that is only readable
by your program, I think that’s a lost cause.

Les

On May 22, 2006, at 9:44 AM, Kris L. wrote:

Mainly I want to be able to sell ruby/rails applications without
doing a
hosted only solution (like basecamp), if I was 37signals I would
want to
sell the application as you would desktop software…

The ruby obsufcator looks good but it may never work with Rails… it
doesn’t at the moment. :frowning:

Which obfuscator are you referring to? We’ve never even tried
obfuscating rails apps with ours, and neither have you. :stuck_out_tongue:


_why: zenspider’s most intense moments of solice are immediately
following the slaughter […]
_why: that topknot’s the only thing keeping a lid on the righteous anger
bricolage: yeah, that and his flagrant obsession with dvorak

On May 22, 2006, at 1:17 PM, Leslie V. wrote:

as they appear. If your data is hidden by your code being hard to
understand, it will be visible very soon - binaries or not.

How true is that? Bypassing a license key check is a LOT different
than reverse engineering a full binary (and being able to make sense
of it). I’m no black hat so I’m honestly asking here. I have no clue. :stuck_out_tongue:

Kris L. wrote:

Well there are several aspects to this, I want to protect the code from
being read, from being modified and from internal attacks.

I could use the file system permissions but its always vunrable to at
least one person. This normally would not be a problem but we are
dealing with sensative data.

We can make the encrypt key in the interpreter hard to find, not
impossible, but much more secure than having open source code.

Google for the phrase “security through obscurity” (STO).

Are you in the US? What is your native language?

Hal

On Tue, May 23, 2006 at 06:26:42AM +0900, Kris L. wrote:

Yes two things I am concerned with, I have also looked at Java and .NET
and they also have the same problems.

Because this is a general problem, not depending on language.

Hiding code is useless because if it can be executed
by a computer it can be cracked by a person.

True. You could store it in “safe” hardware, a smartcard for example.

I would not say useless, if you offer open source then you are asking
for trouble. If you take measures to obsfucate/encrypt the code the
skill level to get/change it increases. There is no such thing as
absolute security but…

Enryption is hard. You will implement a useless scheme privatly. Doing
this any other way than open source, under peer review, will lead to a
trivially breakable system. Sorry if this seems harsh.

So: must the sensitive data be given to only some of the insiders by
your
program? Or must only some of the data be revealed to the insiders?
If you are trying to give people encrypted data that is only readable
by your program, I think that’s a lost cause.

Very true. Except you stuff that data and the processing program
into “safe” hardware, and only communicate unclassified results from
that to your rails app.

Lastly, if that data is really “highly sensitive”, it is also highly
valuable, and obfuscation won’t keep the bad boys away. If it ain’t
valueable, don’t bother with obfuscation, because your time is of
value too.

Jürgen

Hal F. wrote:

Google for the phrase “security through obscurity” (STO).
There’s a useful difference between full security and a picket fence.
Sure, a picket fence is easy to get over, but you know you’re
trespassing (and legally have shown intent) when you do.

Google for the phrase “security through obscurity” (STO).

I know what this is. But I’m getting no helpful suggestions on this.
There seems to be a load of resistance to doing anything secure or
commerical in ruby. And yes its a general problem with all interpreted
languages except Coldfusion which I think allows you to encrypt source.
PHP goes part way with obsfucation.

The general feeling I get is it can’t be done… Does anyone have any
suggestions how to secure ruby (or other) code.

Kris L. wrote:

suggestions how to secure ruby (or other) code.

Oh, anything can be done… but is it worth it, and have you really
accomplished anything?

That’s the source of the resistance you perceive. Most of us don’t
want or need what you describe.

I venture to say there are numerous people here who might put in
some hours and achieve what you want. But the people who really
understand cryptography (and I am not one) will not spend their
time on an STO scheme.

As for coding… Most people are motivated only two ways to write code:

  1. They’re paid
  2. The project seems cool to them

You’re not paying (are you?) and people aren’t convinced this is cool.

Actually I remember someone making an obfuscator of some kind 3-4
years ago… I played with it awhile and couldn’t break it. Others
could, though. Or I could given a few hours.

The best suggestion yet was to keep the code off the client machine
and make a web service. That is relatively secure.

Hal

I know what this is. But I’m getting no helpful suggestions on this.

You’re getting plenty of helpful suggestions: it makes no sense to go
to great lengths to encrypt code and expect it to be secure.

If you want to keep casual eyes away from your code, the very first
answer to your question:

On 5/19/06, Eric H. [email protected] wrote:
Override require.

was spot on. Implementing any sort of obfuscation in your own
require will keep 99% of the audience out of your code.

If, on the other hand, you want to securely keep the other 1% who are
determined in one way or the other to get at your code out, you can’t
do it in software.

Keeping your sensitive data encrypted on the other hand can be done
in software and with proper encryption, there is no need to obscure
the encryption routine, only the keys you’re using (granted, you need
to find a secure way of destributing encryption passwords to users).
You could use the openssl ruby library to do the encryption, for
example. Openssl, by the way, is open source, yet quiete a few banks
trust it to protect their homebanking sites.

The general feeling I get is it can’t be done… Does anyone have any
suggestions how to secure ruby (or other) code.

Nobody is denying that it can be done to some extent. You can keep out
casual attackers by implementing some trivial protection (rot13,
obfuscation, loading your code from a zip file …) or even keep out
professionals with some resources to invest by executing in tamper
proof hardware. But you seem to want something in between, and are
convinced the only way to do it is to compile your encryption key in
C.
-tim

Hal F. wrote:

Kris L. wrote:

suggestions how to secure ruby (or other) code.

Oh, anything can be done… but is it worth it, and have you really
accomplished anything?

It would be a layer of protection that would at least prevent casual
attacks.

That’s the source of the resistance you perceive. Most of us don’t
want or need what you describe.

Because you dont want it you resist its development…

I venture to say there are numerous people here who might put in
some hours and achieve what you want. But the people who really
understand cryptography (and I am not one) will not spend their
time on an STO scheme.

As for coding… Most people are motivated only two ways to write code:

  1. They’re paid
  2. The project seems cool to them

You’re not paying (are you?) and people aren’t convinced this is cool.

I’m not asking anyone else to do it.

Actually I remember someone making an obfuscator of some kind 3-4
years ago… I played with it awhile and couldn’t break it. Others
could, though. Or I could given a few hours.

The best suggestion yet was to keep the code off the client machine
and make a web service. That is relatively secure.

But that makes huge limits on profit. My feeling is web software can’t
be sold like desktop software is. Either boxed or a pre-installed
server.

Hal

Leslie V. wrote:

On 5/23/06, Ryan D. [email protected] wrote:

by a computer it can be cracked by a person. The millions of patches
on the Internet prove that even little known programs are cracked
as soon
as they appear. If your data is hidden by your code being hard to
understand, it will be visible very soon - binaries or not.

How true is that? Bypassing a license key check is a LOT different
than reverse engineering a full binary (and being able to make sense
of it). I’m no black hat so I’m honestly asking here. I have no clue. :stuck_out_tongue:

What I’m saying is that bypassing a license key check in a binary and
bypassing a license key check in source are both very easy. Source is
obviously easier but a binary is usually also trivially easy - just
get a debugger and set some break-points, search for some strings,
some API calls… it rarely takes more than 30 minutes.

Only for programmers. A key can be found, but it can’t be reversed to
source.

In the face of a bit of investigation entire file formats and
protocols are open for all to see - just look at the drop-in
replacements for Exchange, the many programs that can read and write
MS Word documents, the NTFS support on Linux. Protocols have been
decoded and servers hacked without having the source OR the binaries
but just by looking at the comms. With a binary, things are very easy.

Seriously: your program is visible, your strength needs to lie somewhere
else.

Les

On 5/23/06, Ryan D. [email protected] wrote:

by a computer it can be cracked by a person. The millions of patches
on the Internet prove that even little known programs are cracked
as soon
as they appear. If your data is hidden by your code being hard to
understand, it will be visible very soon - binaries or not.

How true is that? Bypassing a license key check is a LOT different
than reverse engineering a full binary (and being able to make sense
of it). I’m no black hat so I’m honestly asking here. I have no clue. :stuck_out_tongue:

What I’m saying is that bypassing a license key check in a binary and
bypassing a license key check in source are both very easy. Source is
obviously easier but a binary is usually also trivially easy - just
get a debugger and set some break-points, search for some strings,
some API calls… it rarely takes more than 30 minutes.

In the face of a bit of investigation entire file formats and
protocols are open for all to see - just look at the drop-in
replacements for Exchange, the many programs that can read and write
MS Word documents, the NTFS support on Linux. Protocols have been
decoded and servers hacked without having the source OR the binaries
but just by looking at the comms. With a binary, things are very easy.

Seriously: your program is visible, your strength needs to lie somewhere
else.

Les

Tim B. wrote:

I know what this is. But I’m getting no helpful suggestions on this.

You’re getting plenty of helpful suggestions: it makes no sense to go
to great lengths to encrypt code and expect it to be secure.

But it is more secure than open source.

If you want to keep casual eyes away from your code, the very first
answer to your question:

On 5/19/06, Eric H. [email protected] wrote:
Override require.

was spot on. Implementing any sort of obfuscation in your own
require will keep 99% of the audience out of your code.

Agreed. It is something I am looking at.

If, on the other hand, you want to securely keep the other 1% who are
determined in one way or the other to get at your code out, you can’t
do it in software.

Keeping your sensitive data encrypted on the other hand can be done
in software and with proper encryption, there is no need to obscure
the encryption routine, only the keys you’re using (granted, you need
to find a secure way of destributing encryption passwords to users).
You could use the openssl ruby library to do the encryption, for
example. Openssl, by the way, is open source, yet quiete a few banks
trust it to protect their homebanking sites.

How do those banks prevent the keys being found by their own staff or
server admins?

The general feeling I get is it can’t be done… Does anyone have any
suggestions how to secure ruby (or other) code.

Nobody is denying that it can be done to some extent. You can keep out
casual attackers by implementing some trivial protection (rot13,
obfuscation, loading your code from a zip file …) or even keep out
professionals with some resources to invest by executing in tamper
proof hardware. But you seem to want something in between, and are
convinced the only way to do it is to compile your encryption key in
C.
-tim

On 5/23/06, Kris [email protected] wrote:

Keeping your sensitive data encrypted on the other hand can be done
in software and with proper encryption, there is no need to obscure
the encryption routine, only the keys you’re using (granted, you need
to find a secure way of destributing encryption passwords to users).
You could use the openssl ruby library to do the encryption, for
example. Openssl, by the way, is open source, yet quiete a few banks
trust it to protect their homebanking sites.

How do those banks prevent the keys being found by their own staff or
server admins?

I’m no expert, but I know encryption keys aren’t present in the source
code of the program. Wheter a given encryption program is secure or
not doesn’t have anything to do with wheter it is open source or not.
A lot of encryption protocols involve keys generated on the spot from
other information, for example.

How do those banks prevent the keys being found by their own staff or
server admins?

That’s a different problem, typically solved by using secure hardware.
The point is, only the key needs to be secret, not the implementation.

-tim

Kris wrote:

Tim B. wrote:

I know what this is. But I’m getting no helpful suggestions on this.

You’re getting plenty of helpful suggestions: it makes no sense to go
to great lengths to encrypt code and expect it to be secure.

But it is more secure than open source.
Careful with your terminology. It’s more obscure than unencrypted
source. It’s not more secure than open source.

Tim B. wrote:

How do those banks prevent the keys being found by their own staff or
server admins?

That’s a different problem, typically solved by using secure hardware.
The point is, only the key needs to be secret, not the implementation.

-tim

Agreed, but how do you hide the key from people with access to the
server?

Bira wrote:

On 5/23/06, Kris [email protected] wrote:

Keeping your sensitive data encrypted on the other hand can be done
in software and with proper encryption, there is no need to obscure
the encryption routine, only the keys you’re using (granted, you need
to find a secure way of destributing encryption passwords to users).
You could use the openssl ruby library to do the encryption, for
example. Openssl, by the way, is open source, yet quiete a few banks
trust it to protect their homebanking sites.

How do those banks prevent the keys being found by their own staff or
server admins?

I’m no expert, but I know encryption keys aren’t present in the source
code of the program. Wheter a given encryption program is secure or
not doesn’t have anything to do with wheter it is open source or not.
A lot of encryption protocols involve keys generated on the spot from
other information, for example.

An open source project compiled (open at design time) and software that
has interpreted open source (open at run time) are different. And
interpreted is less secure than compiled. Not much more secure in
skilled hands, but even so. Its easier to write anti-tamper with
compiled. Or better still as suggested using hardware.