5

I recently inherited an in-house built key storage system. The company stores credit card data in two database servers which are AES encrypted. The keys reside in a separate system that is located in its own DMZ. When a web server needs to encrypt some data, the key server is called via https and requests a key. It returns a key, and an encoded serial number. The app server stores the encrypted info and the serial number then discards the key. When data needs to be decrypted, the serial number is sent to the key server which returns the key that was used for that record.

The fellow that developed this did not use key pools. Every key is a unique random value. The key database is encrypted using a key generated by 2 passwords provided by 2 custodians. From what I am seeing, even if you got hold of the keys, you would have to be able to decode the serial numbers to be able to use them, and then each key would only be good for one record. He even wrote a php extension in c that has the encoding/decoding functions.

This seems to be a pretty good design. Anyone Have any experience with this type of thing that can give an opinion on this method and any possible holes or improvements.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
Pete Robbins
  • 51
  • 2
  • 3
    What's the threat model? What attacks/threats/failures is this trying to defend against? (Caveat: We probably can't give you a full security evaluation, as the exact risk management calculation is probably too specific to your particular situation.) – D.W. Nov 18 '12 at 22:50
  • 1
    This the method used to enrypt credit card data and store the keys. The idea was to use different keys for every peice of encyrpted data so if someone was able to get a hold of the keys, it would make very difficukt to get at the data since you wuld be going record by record. Our auditor cant decide wether this system meets pci or not. He is saying that because its an i house system, there is a bigger risk of comprimise from within. I'm not so sure about that. There are two key custodians that change their passwords every 90 days. Each of them are not involved in the it operations at all. Even –  Nov 19 '12 at 02:25
  • Is anyone else wondering what happens if the key server hardware dies? Also don't forget about physical security, if someone grabs the key server or any backups it looks like it's all over. – Inverted Llama Nov 22 '12 at 15:16

2 Answers2

3

On first glance, it appears to be ingenious and a double layer of security. On further thought, it is quite similar to tokenization of credit cards, with 1 pro and 1 con as opposed to tokenization:

  • pro - there are two layers of encryption in two separate systems
  • con - full credit card numbers, although encrypted, are still stored in the business system and the encryption is reversible.

Although the two custodian setup is a good mechanism, the keys to the kingdom are still the encryption key of the 'key database'. If they are compromised, the rest is just lookup and algorithms and ALL credit card numbers can escape.

Based on a preliminary analysis, I would venture that, on the whole, it is perhaps less secure to a tokenization system. A token cannot be reversed, it can only be looked up, and thus throttled, controlled from IP etc. A good tokenization system has other advantages like it can be outsourced, or the CC number can only be released to a third party like a payment processor, etc. and CC numbers, encrypted or clear, are never stored in a business system and may not even enter the business estate after having been exchanged for a token the first time.

Akber Choudhry
  • 809
  • 7
  • 12
1

Sounds over complicated and brittle - maintaining this is going to be a pain. How about this for a potential hole:

"the key server is called via https and requests a key"

If the https request to the key server is protected using a weak (e.g. self signed) certificate, the key exchange connection might be spoofed (e.g. by a MITM attack that returns a known key - easy decrypt stuff later when you know the key. It's quite possible since the key server is not public and maybe the creator didn't think to use a commercial CA, I wonder if the SSL server cert is properly verified at all....or if the key requester checks to see if a different key is received each time, it might easy to replay the inital message over and over....now I just need to crack one key! Oh well.

Anthony Palmer
  • 211
  • 1
  • 4