1

I am trying to figure out a solution to a 'chicken and egg' issue which I have come across in a project I am working on for a new venture.

The systems in question are handing credit card data and as such the card numbers etc need to be stored encrypted in the database. In order to comply with PCI requirements we have the numbers encrypted with unique key pairs for each 'merchant', so if one merchant is compromised it shouldn't be possible to access another merchants card holder data.

This is fine when it comes to human interaction with the system, as the human can enter the passphrase to unlock the private key, and then decrypt the data, however when it comes to automated services which need to access the data (i.e. to process transactions at a later date) there is an issue with how best to provide the credentials to the service/daemon process.

A bit of background on the system:

  • card numbers are encrypted with asymmetric key pairs
  • the private key is passphrase protected
  • this passphrase is then encrypted with a 'master' key pair
  • the passphrase to unlock the master private key is then known by the operators granted permission (well, actually they a copy of it encrypted with their own key pair which they only know the passphrase to).
  • the daemon process will be run as its own user and group on a linux system.

For the daemon to be able to decrypt the data I was considering the following:

  • Setup a passphrase file similar to how .pgpass works
  • Store the file in the home directory for the daemon user
  • Set the permissions to 0600 for the file
  • Setup a file integrity monitoring system such as Tripwire to notify a security group (or similar) of any changes to the file or permissions.
  • Disable login for the daemon user, as it is used only for the process.

Given the above, I am wondering if this is sufficient. Obviously the weakness is with the system administrators - there are few of these (i.e. 2) trusted on the secure systems - given they can elevate their permissions (i.e. to root) and then change ownership on the files or the permissions to be able to read the passphrase - however once again this is likely something which can be mitigated with monitoring of checksum changes for files, FIM checksums etc.

So am I going about this the wrong way or are there other suggestions on how to handle this?

Matthew Savage
  • 3,794
  • 10
  • 43
  • 53

1 Answers1

2

Not sure how much help this will be as given your aim is compliance with PCI-DSS the person you need to convince is your QSA.

Most QSA companies are happy to work in a consultative capacity and help you find a suitable solution rather than working purely in an assessment capacity so get them involved early and work with them to get a solution they are happy to sign off as compliant.

It may be worth getting them to document why it is sufficient as well so that if you change QSA in the future you can take the reasoning with you in case the subject comes up again.

One thing they are likely to mention based on the above solution is split knowledge for key management. It sounds like a single administrator has all the knowledge needed to access keys where PCI (3.6.6) requires split knowledge and dual control for manual clear-text key-management procedures.

dfbpdave
  • 348
  • 1
  • 4
  • We discussed this with our QSA (which is probably the most valuable part of the relationship since the audit) and he suggested that we use one of our operator accounts (of which only the user knows the passphrase) to unlock the service accounts details. This is kind of like a nested russian doll setup but it seems to work and means we can easily rotate keys as required. – Matthew Savage Apr 11 '12 at 01:12