[PCI-DSS] 3.6.6 Split knowledge and establishment of dual control of cryptographic keys

[admin]

[PCI-DSS] 3.6.6 Split knowledge and establishment of dual control of cryptographic keys

3.6.6 Verify that key-management procedures are implemented to require split knowledge and dual control of keys (for example, requiring two or three people, each knowing only their own part of the key, to reconstruct the whole key).

[agentgreen]

Can someone shed a little more light into this requirement? I work for a collections agency, which utilizes PGP keys for encrypting data at rest and for transmitting card holder data back and forth from our clients.

Considering that the PGP software we use generates the encryption keys for us, does this control apply to us?

[agentgreen]

Originally Posted by agentgreen

Can someone shed a little more light into this requirement? I work for a collections agency, which utilizes PGP keys for encrypting data at rest and for transmitting card holder data back and forth from our clients.

Considering that the PGP software we use generates the encryption keys for us, does this control apply to us?

To go into more detail, is the split-knowledge and dual control in regards to the data used to CREATE the encryption key? Or is in regard to the use of the key itself. Meaning, does dual-control and split-knowledge mean that multiple parties have to be involved in decrypting the data? e.g my data processor encrypts and decrypts cardholder data every day using pgp. In order to do this, do 2 people need to know their half of the encryption passphrase in order to encrypt and decrypt?

[Roger Nebel]

In the case of PGP the full passphrase to open the private key should be split - no one person has the entire passphrase. If you feel the need to write it down, access to that written record, which should be on two pieces of paper separately sealed, should also be separated in some way - two keys, safe inside of safe, etc.

[agentgreen]

How is this feasible in an environment where many different data files are encrypted every day? It seems unreasonable that two different people would have to type in a pass phrase for every encrypted file.

Is there a real world example of how we can comply with this requirement? Is the only way to adopt a new encryption method for this type of work?

[Roger Nebel]

Generally once the two people type in the pass phrase to open the private key in PGP (and in GPG as well) the key stays available until you overtly change that. For example, in my PGP there are three options: Save my passphrase for the current Windows session only (i.e., until I log out), Save my passphrase for xx:yy:zz hr:min:sec, and Do not save my passphrase. Of course, if you have used different public/private keys for each object you would have to re-type the new passphrase for each new one but it would remain open based on the configurations above.

[Roger Nebel]

Originally Posted by agentgreen

To go into more detail, is the split-knowledge and dual control in regards to the data used to CREATE the encryption key? Or is in regard to the use of the key itself. Meaning, does dual-control and split-knowledge mean that multiple parties have to be involved in decrypting the data? e.g my data processor encrypts and decrypts cardholder data every day using pgp. In order to do this, do 2 people need to know their half of the encryption passphrase in order to encrypt and decrypt?

Both for key creation and for key use after that. PGP is generally best for discrete messaging, or to protect another key, and may be too cumbersome for data base record by record use. Look at SSL for example. It's a hybrid system - it uses public - private and a Diffie-Helman key exchange to negotiate a secret symmetric key for the actual link encryption because symmetric crypto is so much faster than the asymmetric public - private. Using that model you would use some public - private method to protect the symmetric keys used to protect the data records. So you have an encrypting key that is symmetric and a so-called key-encrypting-key or KEK, to provide confidentiality protection for the encrypting key. A real world example would be Bank ATMs which almost universally have a DES or 3DES key (AES in the really new ATMs) to encrypt the PIN between the ATM and the bank, and and a KEK to hide the PIN encrypting keys to prevent bad guys from intercepting and decoding the PINs. The KEK is highly protected in a piece of hardware called a Hardware Security Module (HSM). Both the KEK and the ATM require split knowledge of the keys - no one person knows the full KEK or any ATM key. PCI DSS key management is modeled on that idea.