Configuring trusted keys and certificates (PCI-DSS)

PCI-DSS 3 requires that in-scope devices, like cash register computers or payment processing servers, accept only trusted certificates. Specifically, it states:

Protect Cardholder Data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
4.1(b) Are only trusted keys and/or certificates accepted?

Sensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted. Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection.

So, how do you do this in Windows?

First, view the certificates of all payment processing services and document the trusted root certificate. Add to this list of trusted root certificates those that are required for Microsoft Windows to function. (This list is documented here: http://support2.microsoft.com/?id=293781). Create one master list of all certificates that should be accepted.

Second, open the local computer’s certificate store. (Control Panel > All Tasks > Administrative Tools > Manage computer certificates.) Under Trusted Root Certification Authorities, expand Certificates. Delete all certificate authorities not on the previously created master list.

Third, configure the computer’s Web browser to not allow the user to continue to Websites with untrusted certificates. This setting varies from browser to browser. In Internet Explorer, the settings are in Local Security Policy under:

Windows Components\Internet Explorer\Internet Control Panel
Prevent ignoring certificate errors

Windows Components\Internet Explorer\Internet Control Panel\Advanced Page
Turn on warn about certificate address mismatch
Check for server certificate revocation

The computer will now accept only those certificates accepted for business purposes. Any invalid certificates will stop the transaction and not allow the user to inadvertently continue. This configuration reduces the likelihood of Man-in-the-middle (MITM) attacks, signed malware, and other attacks against certificate infrastructure. In addition, the computer’s configuration is now in compliance with PCI-DSS 3’s 4.1.b requirement.

Some additional thoughts:

• When making configuration changes, always snapshot or backup the computer first
• PowerShell can be used to export the root certificates to disk
• Fully test the changes before putting the above recommendations into production
• Use group policy to deploy the settings to multiple domain computers

The question is back in the news: is using encryption a sign you are criminal?

In May of 2005, a Minnesota court filed a ruling that upheld a conviction in part based on the presence of encryption software (State v. Levie). The chilling sentence in the filing was: “We find that evidence of appellant’s internet use and the existence of an encryption program on his computer was at least somewhat relevant to the state’s case against him.” This was but one in a chain of legal cases involving cryptography. In fact, the software in question in the Levie case has, almost from its inception, been the subject of legal scrutiny. Yet the ruling set off a firestorm in part because it appeared to imply that encryption by itself was indicative of criminal activity.

The view was reinforced by Bruce Schneier, a prominent InfoSec analyst and cryptographer. “An appeals court in Minnesota has ruled that the presence of encryption software on a computer may be viewed as evidence of criminal intent.” As sometimes happens on the Internet, the resulting discussion involved many who did not read the ruling and many more who employed fallacy of extension arguments. For example, one commentator responded “Next I suppose they’ll consider finding a knife in your kitchen is ‘evidence’ on criminal intent to commit some gruesome attack on an innocent bystander.”

The actual ruling was significantly more balanced than it appeared from Schneier’s summary. When placed into context, it is clear that the presence of cryptography along with the existence of searches related to the crime were introduced to demonstrate the Levie’s state of mind. It was only in relation to the primary crime that they, in fact, became admissible. Other writers were quick to point this out. “The court did not hold that encryption is a signal of criminal activity. All it did was say that in one case, where a crucial witness testified about the presence of a computer file on a computer, that the presence of encryption software on the computer in early 2003 was “at least somewhat relevant” to the question of whether the defendant was a skilled computer user who had intentionally removed any traces of that file from the hard drive. (Kerr, 2005)”

The concern remained, however, that the ruling would be interpreted and used in future cases. This concern was best voiced by Jennifer Granick; the “hacker lawyer” and director of Stanford Law School’s Center for Internet and Society. Granick repeated Kerr’s argument that the ruling suggested the presence of encryption software simply shows the defendant could have destroyed the evidence. She then repeated the argument that was most concerning: the ruling could demonstrate that encryption “suggests a consciousness of guilt.” That is, why encrypt if you have nothing to hide? While Granick is careful to say that both interpretations are valid, the primary concern should not be “what this opinion says or doesn’t say, but how it could be used by courts looking at this issue in the future.”

Where do we stand some today? The legal opinions are still a mixed bag. Because encryption is such a wide field, let us take another example that deals with PGP. A federal judge ruled in 2007 that a decryption passphrase was protected under the Fifth Amendment (United States v. Boucher). This was celebrated at the time but the celebrations were short lived. In February of 2009, the court reversed its decision. At its heart was the definition of a PGP passphrase: was it speech or was it a key? The original ruling came down on the side of speech and thereby protected the passphrase. The reversal saw the passphrase like a key or combination, which prior rulings had established are unprotected by the Fifth Amendment.

A person can be legally required to open a safe and reveal incriminating documents or books. Likewise, according to States v. Boucher, a person can now be required to decrypt a folder to review digital documents. The issue is whether the presence of encrypting software or, for that matter, illicit digital materials is relevant to prosecution.

While this topic has not been specifically taken up in law journals, the related topic of suspicious materials has been covered in depth. See, for example, Swiss Cheese That’s All Hole: How Using Reading Material To Prove Criminal Intent Threatens The Propensity Rule (Murphy, May 2008). Murphy details the legal precedence and evidentiary rules that allow for reading materials to be used by the prosecution. Such materials can be submitted if they are relevant in demonstrating the defendant’s mental state or aptitudes. But books cannot be used to demonstrate motive or intent. By itself, a book cannot be used to demonstrate a defendant had the inclination towards criminal acts (this is the propensity rule).

The same legal structures likely apply to digital materials. In State v. Levie, illicit web searches were relevant to Levie’s mental state at the time of the crime. The presence of PGP was relevant to Levie’s ability to obfuscate or remove digital evidence. Yet neither the web searches nor PGP were used to demonstrate his propensity to perform the criminal act. The digital materials, just like written materials would have been, were not used to define motive or intent. That proof was from the primary evidence: an eye witness testimony. People can continue to safely use PGP and other encryption technologies. The propensity rule prevents these from being admitted as evidence of criminal intent.

Hashing functions such as MD5 are susceptible to collisions. That is, someone can take two documents and tailor them such that the resulting MD5 hashes are identical. One group showed this particularly well by hashing documents that shows who will win the US election. The group made twelve PDF documents all have the same MD5 fingerprint.

Predicting the winner of the 2008 US Presidential Elections using a Sony PlayStation 3

http://www.win.tue.nl/hashclash/Nostradamus/

Consider SSL. The web client and web server exchange keys and establish an encrypted tunnel, which they then use to communicate over. The person sees the reassuring padlock and begins entering sensitive information such as credit cards and passwords.

Of course, the person could be sending quite a bit more thru that tunnel and no one in the middle would be the wiser. This makes it difficult to protect incoming and outgoing traffic against threats such as drive-by downloads and data leakage. The question becomes how to read the SSL traffic as it crosses our Internet gateways.

I have been looking at Microsoft’s ISA server quite a bit recently. One feature they offer is SSL bridging. Now the web client negotiates an SSL tunnel with the ISA server. The ISA server then negotiates a separate tunnel between itself and the web server. Then ISA proxies web requests between these two tunnels. The web traffic is unencrypted on ISA itself and therefore can be monitored.

Of course, this means that people cannot trust their sensitive information is actually confidential. But, I am sure someone will say, we trust our network administrators. True, yet consider this: Akamai also does SSL bridging on a massive scale. This company handles web traffic for a third or more of all Internet sites. If you are hitting Akamai during an SSL session, someone at Akamai is reading your unencrypted information.