Re: protecting perl script source

["Jim McGarvey" <mcga0031 () umn edu>]

I'm not sure what solutions were already proposed but here's my take on the
question.  You want to protect a script running on a server from being
stolen, and that script needs to access the Internet when running.  You
specify that the server running the script needs to boot unattended, which
is problematic, because that eliminates a common option for a useful
cryptographic solution.

If you cannot accept a solution that requires an operator to manually enter
a decryption key or passphrase (at the console or remotely), should a reboot
of the server be required, then all that can be done is security vigilance,
as you mentioned, and possibly network/application architecture and computer
architecture enhancements, which I'll describe below.  Any other
cryptographic solutions would be "security through obscurity" as others have
mentioned.

But if you are willing to have your script stop running briefly after the
server boots, while waiting for an operator to locally or remotely provide
a passphrase, then you can limit your exposure by only having the decrypted
script in memory.

So here are the best (theoretical) solutions you have available to you:

1. *Encrypt the File with a Manually Entered Passphrase.*  This would be
similar to how most SSL enabled web servers allow you to optionally encrypt
your SSL private keys with a passphrase, which you need to supply on
start-up to decrypt the keys.  The downside is that the program will not
automatically start on boot, since it requires a passphrase.

Protects Against:
a. Server compromises that do not or cannot dump the memory where the
decrypted script resides.
b. Someone walking away with the server or hard drive, provided they do not
know the passphrase.

Fails Against:
a. Attack that first compromises the system, avoids Intrusion Detection
Systems (IDS) such as tripwire, reboots the system, and then intercepts the
passphrase as the operator enters it to get the program going again.
b. Attack that dumps the memory where the decrypted script resides.

Rating: 5/10 for effectiveness of security, 5/10 for ease of implementation


2. *Modify Network/Application Architecture.*  Instead of one firewall and
one server, break the application into two parts, and have two firewalls and
two servers, connected in this order: Internet = external-firewall =
dmz-server = internal-firewall = internal-server.  This assumes that it is
possible to modify the architecture of your application such that the secret
parts of it reside on the better-protected internal-server, which accesses
data gathered by the dmz-server through the internal-firewall.  The
internal-firewall would only allow connections through a sanitized protocol
originating from the internal server.  The external-firewall would be more
lenient to accommodate whatever connectivity to the Internet is necessary
for the application to function.  The internal-application would tell the
dmz-application what to do and what data to get, while keeping the secrets
of the application on the better-protected internal server.

Protects Against:
a. Attacks that cannot compromise both servers through an extremely limiting
internal-firewall.

Fails Against:
a. Attacks that compromise both servers, even through an extremely limiting
internal-firewall.
b. Someone walking away with the server or hard drive. (Note: Combining 1
and 2 would prevent someone from walking away with the server or hard
drive from getting the secret script in decrypted form.)

Rating: 6/10 for effectiveness of security, 4/10 for ease of implementation


3. *Modify Computer Architecture.*  If indeed this imaginary script is worth
millions of dollars, then perhaps it would be worth the time and expense to
move the sensitive code into some kind of tamper-proof package that
integrates with the server and performs any sensitive computations.  Like a
smart card, but tamper-proof in that the code stored inside cannot be
accessed physically or programmatically, it can only be written and run on
an internal processor.  This sounds theoretical to me, but I've heard that
there are such commercially available "tamper-proof" packages available,
though I'm told the engineers who make them usually devise some way of
bypassing the tamper-proofing while testing the products.  If anyone can
tell me if there is such a product available, and point me toward further
information, that would be interesting to read about.

Protects Against:
a. Server compromises and black-bag attacks

Fails Against:
a. Implementations with packages that are not really "tamper-proof"
b. Someone who can open the tamper-proof package without it self-erasing,
and read the memory.  (Note: this risk could be mitigated by requiring
manual entry of a passphrase for decryption as in #1 above)

Rating: 8/10 for effectiveness, 0.1/10 for ease of implementation


ready for criticism... fire away!
-Jim


At 11:58 AM 1/24/2003 -0700, you wrote:
> Hi. Let's assume someone wrote a perl script that figured out how to make a
> lot of money on the stock market, but that they wanted to protect the
script
> because if others began using it, it would diminish its returns. The new
> millionaire would want to protect her creation, but it has to run on a
> computer with access to the internet. She puts it on a box which she tries
> to keep patched, it's behind a firewall, and only root has access to the
> scripts. The scripts need to run unattended, and the system needs to boot
> unattended. She fears two things: a remote root vulnerability, and that
> someone would physically walk off with the box.
>
> My impression is that under these conditions, besides vigilance, limiting
> running processes, working on physical security, keeping up on patches,
> possibly some sort of IDS -- there really isn't anything she can do to
> protect the source. If it's booting unattended, and running scripts
> unattended there's no sort of crypto strategy that could protect either
> against an intruder with root access or physical access to the hard drive.
>
> What do you think?
> John