Re: protecting perl script source

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

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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
script
>because if others began using it, it would diminish its returns. The new
Received on Thu Jan 30 14:11:03 2003