Dual Control & Split Knowledge
September 3rd, 2006 by pinsecurity Posted in Encryption, PCI DSS, PCI PIN, Payment ApplicationsI recently wrote about the issue of key management, and I felt that one particular aspect of this deserved more attention - dual control and split knowledge. Once again, this is a requirement that is shared by all of the PCI standards, but is often poorly understood.
The principle behind dual control and split knowledge can be expressed easily enough - no one person should have access to any information, device, or function, that allows them to determine the key that is being protected more quickly than through the best attack known for that algorithm. Ideally, this means a brute force search of the entire key space.
This principle can be expressed in another way: The determination of any part of the key must require the collusion between at least two trusted individuals. Any feasible method to violate this axiom means that the principles of dual control and split knowledge are not being upheld.
This principle is enforced by requiring both dual control, and split knowledge. That is, at least two people are required to ‘reconstruct’ the key, and they each must have a physical thing (thereby providing dual control), and they each must have some information that is required (thereby providing split knowledge).
These requirements can be easily misunderstood, so to make things clearer, here are some examples of systems where dual control and split knowledge are not upheld:
* Splitting a 128 bit key ‘in half’ to form two 64 bit parts. As each part contains half the plaintext bits of the original key, one of the two custodians can determine the key by exhausting the other half - which requires only 2^64 operations, instead of the 2^128 which is required for the entire key space.
* Storing key components on two ’smartcards’ (or other cryptographic tokens), and not requiring any further authentication by the users to use these components. Here the smartcards give you dual control, but with no passwords required for their use, there is no split knowledge enforced.
* Storing a key enciphered under another key that can be re-constructed with one or more passphrases. This type of system provides split knowledge, but not dual control (there is no physical item to ensure that all parties must be present).
* Storing a key on a single smartcard (or cryptographic token) that requires one or more passphrases to access. This comes close, but with only one smartcard required, it does not meet the requirements of dual control.
Now, it is perhaps important to clarify here that dual control and split knowledge is only required to access the plaintext key. The use of a key to encipher or decipher data, or access to a key that is enciphered under another key (which is ultimately maintained under dual control and split knowledge) does not require such control.
If you have encryption keys appearing in the clear in a PCs DRAM, the principles of dual control and split knowledge are difficult to maintain. Very, very, difficult. It’s not impossible - but it’s difficult.
Have I mentioned how hard it is?
The good news is that you only have to maintain a single master key under this control, and all other keys can be enciphered under it. For example, if you have a (potentially huge) database of card details and you want to have a unique key per entry, maintaining all of these keys under dual control and split knowledge would be a practical impossibility. However, if you have a single master key (lets call it Kmaster), you can generate a new key for each entry based on the result of the encipherment of the (entry) primary key with Kmaster.
Put algebraically, if we call the entry encryption key to be generated Kentry, we have:
Kentry = eKmaster(primary key for the database entry)
As each primary key must be unique per entry for the database to work, this will generate a unique key for each entry. As no-one knows Kmaster, they cannot know Kentry - even though they can know the information that is used to generate it (ie the primary key of the database). Of course, the key that is generated should also not appear as plaintext in the PCs DRAM, but it can be deleted as soon as it has been used.
Similar systems can be used to generate unique keys for physical devices, based on serial numbers, or device IDs.
Dual control and split knowledge is not difficult to achieve, but it is easy to get wrong. However, its importance cannot be overstated. Who knows your keys?
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
11 Responses to “Dual Control & Split Knowledge”
By Nick on Oct 4, 2006
Thanks for this article - it helped me understand split knowledge…
By Gaby on Oct 13, 2006
Thanks for this article, too - interesting reading.
But: You give quite a number of examples for solutions where dualcontrol & splitknowledge are actually not fulfilled.
I am wondering how a feasible solution should look like in a real-world-environment (e.g. webserver, webapp, backend db eg. Oracle, all hosted on more-or-less ordinary SUN hardware), in particular if you take high-availability requirements into account, i.e. no human interaction possible at a re-start of the servers?
Could you give an example for a solution that will perfectly comply to the PCI requirement concerning dualcontrol & split knowledge as outlined in your article?
Thanks!
Gaby
By Tim Holman on Dec 5, 2006
Dual control does not require the use of something physical. Multiple authentication would suffice, that is, it takes 2+ administrators to log into the keystore in order to access what’s inside. This alone should suffice - and split knowledge isn’t really relevant as as administrators have already typed in something that they only know (password) to access the keystore.
Thoughts?
By PINSecurity on Dec 5, 2006
Tim, you are correct in saying that dual control does not require the use of something physical - passwords are fine, as long as more than one password is required, and each password is unique. However, the use of a ‘keystore’ does not provide split knowledge; once the custodians have logged in, either one has access to the entire plaintext of the stored keys. This violates the principles of split knowledge, which requires that no one person can determine with certainty any single bit of the key.
To expand upon your example, if you have a secure ‘keystore’ that can be logged into using two (or more) passwords, then it would be OK if the keys could be exported as full length components for each password holder. This is similar to how master keys are exported from the HSMs used in banks - except they are usually printed on tamper evident envelopes so that no-one even sees the plaintext of the components until they are needed to restore a key.
By Andreas on Dec 8, 2006
One simple question: Is it in compliance with the dual control and split knowledge principles to keep the decryption key in a PCs DRAM after the key was combined in accordance with split knowledge and dual control?
Thanks.
Andreas
By Tim Holman on Dec 8, 2006
If you have a keystore that doesn’t allow extraction of keys, then split knowledge shouldn’t apply. Is there any reason why a keystore administrator should ever have access to plaintext keys? Other than to import keys from an external source, of course, but then the split-knowledge component in turn must apply to that other source.
Keeping the decryption key in RAM is fine, as long as nobody can access it. We’re excluding applications. Presumably, if an application meets PABP, then it’s going to be looking after things in RAM, and not allow users to access this memory space.
True, you could in theory run something that caused a core dump of memory into a file, from which you could wade your way through and eventually find the key, but there are other points of PCI regarding application/system security that should ensure that people can’t just hack/log into your system and do this. For example, if you have a UNIX server that’s patched to the hilt, with central auditing, integrity monitoring, anti-virus and access control enabled, then the risk of it being compromised to the point of someone being able to initiate a core dump is very, very small.
By G2w on May 23, 2007
Did the comment on this Blog from Gaby above ever get a response? I would also be interested in a PCI compliant encryption key management architecture using only normal web server/ app server/ db server components. Some don’t have financial resources for HSM etc.
Thanks,
By datasecurity on May 23, 2007
G2w and Gaby,
I’ll leave it up to our resident PinSecurity expert who wrote this post to provide a technical answer, but let me try the big-picture answer.
Remember that when you are attempting to meet compliance you need to understand the intent of the requirement, which in this case is to “render the cardholder data unreadable”. We are given several options for this from truncation and hashing to encryption and tokenization.
Now how do we accomplish this when choosing the option of encryption? We say that we do this with:
* strong encryption algorithms and proper key length
* proper encryption key rotation
* secure encryption key storage
Once you are able to contextualize the concept of split-knowledge and dual-control as a sub-requirement of encryption and that of rendering the data unreadable, we can then begin to understand the primary goal.
If, in whatever manner we store the data, we are able to render it unreadable in a secure and proper manner then we are meeting the intent of the requirement. If you can meet the intent of the requirement then you can be compliant. This of course is contingent on the pivotal test of: “are you doing it securely?” To answer this, I’ll need to call upon the expertise of our resident encryption expert.
I hope this helps, even a little.
By Clint Lawson on Jul 11, 2007
Does anyone have any thoughts on the use of the IBM Cryptographic Coprocessor (AKA Crypto-Card) being used for encryption of CC data and being certified PCI Compliant? I am concerned that the Administrator on the as400 box will be able to decrypt information with out having to have another person present. I am also concerned with key management issues of the crypto-card. Has anyone known of any Tier-1 PCI certifications using this solution?
Thanks,
Clint Lawson
By e.ganba on Sep 9, 2009
Unfortunately I still do not see the way to implement key split. I will try to give a concrete example of my problem.
Let’s say I have a credit card PAN that I want to encrypt before storing into my database.
To generate a key I will ask two different persons for theirs entries. Let’s say first person enters AAAA and second BBBB. Now I will build my key based on these entries by for example first crypting one with another or even with third my entry. However at the end I will have a single key (let’s say XXXXYYYYZZZZ), which I will keep in secret and will use to encipher the PAN before storing to the database.
Now to decipher the PAN I will need to tell my application to use the same key (XXXXYYYYZZZZ).
And in the same way I will be able to decrypt the encrypted PAN with that salt.
Question is how to hide the generated salt from anybody including myself and make available only to my application?
Thanks