Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 4 down vote favorite

I've inherited the task of self-auditing an e-commerce system for compliance with the PCI-DSS.

We are storing the PAN in our database in encrypted form using 256 bit AES algorithm to do the encryption. Key generation occurs within the application and is derived from a password set by the user. The password is read at application initialisation from a config. file. The encryption system used is provided by jasypt PBE methods.

I'm unclear how such a system should be managed for PCI-DSS compliance.

Q1: Should the password above be considered to be the "key encrypting key"?

Q2: Is PCI-DSS requirement 3.6.6 "If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control (for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key)." relevant in this case and if so how could this be implemented?

I'm concerned about the need for compliance to 3.6.6 affecting our rapid development iteration and deployment cycle.

share|improve this question

1 Answer

up vote 2 down vote

Q1. no, the password from which the key is generated (btw how is this done? PBKDF?) is not the KEK. The key you use to encrypt the password stored in the config file, that is the KEK. What do you mean, the password is not encrypted?

Q2. Not exactly.
If you implement a KEK to protect the key-generating password, then the KEK needs to be managed. Who can access the KEK, who can change it? That is where the split knowledge / dual control needs to come into play. For example, depending on your system, perhaps when it comes up two people need to manually enter (their part of) the KEK, to allow it to decrypt the key-generating password. Or perhaps you focus on the "dual control" part, where one has the OS-level password to enable local access to the config file, and one has the physical key to enter the room (assuming the config file can only be modifed locally, of course).

Of course, I am not a QSA, most importantly I am not your QSA - consult with him/her to verify your solution before implementing it.

share|improve this answer
i don't my questions states "the password is not encrypted", did you mean something else? – user15411 Oct 26 '12 at 11:16
I'm still unsure how key management would work in practice given the following scenario: application is deployed to production, application reads password used for key generation from config file on local fs (bitbucket.org/tednaleid/grails-jasypt/wiki/Home). In this scenario how can i implement dual control of the key? Whatever (code or human) deploys the application would also be able to access the password in the config file. – user15411 Oct 26 '12 at 12:07
Where did you say the password is not encrypted? In any event, it should be, storing this unencrypted is effectively like storing your encryption key unprotected. Not good. – AviD♦ Oct 26 '12 at 13:46
The dual control could be applied on the key-encrypting key, not on the (key-generating) password. In other words, you need a mechanism to protect and encrypt the password, and dualcontrol the key to that. This should be a one-time / service-startup thing, the point would be that noone can get to the EK by himself. – AviD♦ Oct 26 '12 at 13:48
Probably i wasn't clear in my original question. Password based encryption has been implemented so that the key used to encrypt the database field only ever resides in the application memory. The password/passphrase does not allow decryption of the dtabase field by itself. Therefore we do not disclose a plain-text encryption key, making dual-control a none issue. Do you agree with this statement? Thanks for your time with this! – user15411 Oct 26 '12 at 13:59
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.