views:

228

answers:

4

Hi Guys,

I have been using the PHP mcrypt module for encrypting sensitive data at my company. This has been working well. However, I have been requested to create a new master password which should be able to decrypt any data. The problem is that this master password would have to be hardcoded in a script file. Please correct me if I am wrong but the only secure way seems to be to hardcode a public key in the script and use it to encrypt data while keep the private key secure and use it to decrypt only when needed.

mcrypt does not seem to have an implementation for such a scheme. Does anybody know of a library (PHP module or pure PHP) which would do this?

+2  A: 

There's a PECL extension for that. http://us2.php.net/manual/en/book.gnupg.php

You can also use gnupg command line tool from php, if it doesn't have to be very fast: http://devzone.zend.com/article/1265

I haven't tried either method.

David
A: 

Just to be sure of your requirement of this master password,

  1. Is it expected to be used only as a 'encrypt this' command that will 'seal' something
    which can then only be opened by someone knowing the private key in question? Or,
  2. Is it something you expect to open any encryption done in the enterprise?
    • I just want to be sure your phrasing is not to be interpreted in this second way
    • your phrase 'decrypt any data' sounds dangerous
      (and not-feasible/practical with asymmetric key encryption)


Update based on the comment.

  • You are planning for two copies of the data each encrypted with different keys
    • one copy is to be encrypted with the master public key
      • can be decrypted with anyone having the master private key
        the master private key must then be secured (public key is not critical)
    • the second copy is to be encrypted with the Rijndael 256 key
  • purpose is to allow the master to decrypt the data whenever required
    particularly, in the absence of the individual who encrypted it

This approach will work for, easy access of the data by the individual with the Rijndael key,
without need for intervention by the master private key owner.
And, when the master private key owner is trusted with the secrecy of the data.

Your scheme will need to update the master copy (deleting the older one and re-encrypting a new one) every time the user updates their copy.


However, if the user data is trusted with the master (as is clearly the case here),

  • an easier approach would be to issue the Rijndael key from the master
  • The master could keep it encrypted with the master-public key itself
  • The data can then be encrypted with just the issued Rijndael key
    • it will always be accessible with the master-private key
      which can open the user's Rijndael key

If the user needs to sign the data, that can be accomplished separately in the process.
It will save you from keeping double copies and maintaining them.


To sign the data, the user could have a a key pair generated by them.

  • Before encrypting the data with the Rijndael private-key
  • the master-public key encrypted with the user-private-key can be appended to it
  • the user-public key shared with the master (at least)
    will be sufficient to authenticate that the user has provided the data
  • In a worst-case scenario, if the user is unavailable and the key confirmation fails,
    the master may be trusted on the authenticity of the data -- which can still be decrypted
nik
Ok, here is the proposed scheme. All data entered by a user will be stored twice - once encrypted by the user's key (Rijndael 256) and once encrypted by the master public key - hardcoded in the script. The user will retrieve / edit this data at will. However, the sysadmin will also be able to retrieve this data at some later point using the master private key.
Crimson
It'd take a lot less cpu to just encrypt the users' keys with the master public key.
David
David is completely right. The proper way to solve this problem is to use the master public key to encrypt the ephemeral keys used to encrypt the documents. Even if asymmetric crypto is used then usually the documents are encrypted with a symmetric key first and only the symmetric key is encrypted with the asymmetric encryption scheme. Hence regardless of whether symmetric or asymmetric crypto is used there is usually a symmteric key that can be encrypted twice: once for the legitimate receiver and once for the key recovery.
Accipitridae
@Accipitridae, you are quite correct as is David. I got a bit lost in the thoughts about signing and added an unnecessary pair. Have fixed the answer and will remove the intermediate comment after David's since it was my misinterpretation.
nik
+1  A: 

I don't see how that would work. Any two-way encryption function is only going to decrypt when fed the specific password used to encrypt (unless you're the NSA and you put back doors in the algorithms). You can't have two passwords decrypt the same file (unless there are hash collisions, but that's not something you can make happen easily).

As far as storing your master password in the program, it would be much better to store it in a separate file the program reads in, so you can use tighter OS-level security on that file.

Keep in mind mcrypt is not public key cryptography. With public key cryptography, you might be able to do what you want, though. For instance, with PGP/GPG, you can encrypt a file such that three different users can decrypt it using their private keys, without knowing each other's private keys. So you can have a virtual user with the master password that can decrypt everything.

Another option would be to hold two copies of all encrypted data; one encrypted with the user's password, and one encrypted with the master password.

dj_segfault
Please see my comment to nik :)
Crimson
Also, can you please provide a link to an example of a GPG implementation / functionality which will allow two / three different users to decrypt the data without knowing each other's private keys?
Crimson
http://lists.gnupg.org/pipermail/gnupg-users/2003-September/020170.htmlhttp://fixunix.com/pgp/71286-using-gnupg-decrypt-message-sent-multiple-recipients.html
dj_segfault
+2  A: 

I suggest taking a look at the PHP OpenSSL bindings, and in particular the openssl_public_encrypt() function. You could indeed embed a master public key into the script, and have the script encrypt each user's AES key with this public key. Keep the corresponding master private key in the company safe.

Should you need the master decrypt function, you would pull the encrypted user key, decrypt it with the master private key and then decrypt the original data.

caf