Re: hiding global variables

yahalom wrote:
Alex wrote:
You didn't answer the main question: In what situation does your
hacker get access to the interpreter, in order to be able to ask [info
globals] ?

That's important, because you may be placing the security fence at the
wrong place.

we run our software with tclsh and we have packages. our software is
installed in many customers sites with workers that might have access
to the system. we hold sensitive data so we encrypt it. but those who
roam around the system might want to look at it. they can play with
tclsh and start investigating. the issue is even harder as we want the
key to be hidden from our own developers (only a security officer
should know it). This is the hardest one as they know the code. I know
this might be asking too much but pci regulations are about making it

I presume then you are operating a scheme whereby the user enters a password which is used to decrypt a public-key which is then used to decrypt the database?[*] That way, the program itself doesn't contain enough information to decrypt the data, until the password is entered. The problem then is where to store the password and decrypted key in memory so that it is safe from snooping. In general, this will be easier to achieve in C, where you can control memory more closely (e.g. overwriting the memory when you are done with it), and can avoid introspection. You still have to worry about people examining memory directly (or swap file), or somebody installing a keylogger, etc. But really, once someone has that level of access to the machine, any hope of security is gone.

[*] The scheme here is something like as follows:
1. Encrypt DB with private key
2. For each user, generate an individual key-file by encrypting the public key from (1) with their password.
3. User installs key-file with program (or, better: keeps it on a memory stick)
4. On startup, you enter user's password and use that to decrypt the key-file giving you the public key to allow you to decrypt the db.

Of course, this isn't foolproof -- the employee can still decrypt the key-file and get the public keys to the kingdom (and remember; most attacks are performed by rogue employees rather than external attackers). You can create variations: e.g. encrypt different areas of DB with different keys, giving a sort of capability-based system (if you have key X then you can access data Y). If you need better security, a much better approach is to store all your data on a central server which you can control access to much more rigorously. Ultimately, any solution which involves shipping both the data and the means to decrypt it to a client is inherently insecure (see the failure of DVD, DRM schemes and so on for the futility of this approach).

Finally -- if you are serious about security, you need to have a security review with someone who knows what they are talking about (I don't).

-- Neil