In general, Windows does a decent enough job with securing software keys in CAPI. Sure, you can open up Windows Explorer, browse to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and take a look at your private key files. These bare files, of course, are not exactly plain text. The RSA Machine Keys (which include private keys corresponding to software certificates), are encrypted using the Data Protection API (DPAPI).

The DPAPI encryption method is based on the use of a Master Key – a 512 bit random blob that is created using PKCS #5 Password-Based Key Derivation. This process takes the user’s account password, applies the SHA-1 hash algorithm, sends the hash plus a salt to the key derivation algorithm, and then iteratively calls another PKCS #5 function at least 4000 times to make brute-forcing the secret key even harder. Et Voila! Master Key.

The Master Key is then used to create session keys by generating 16 bits of random data, hashing that with the Master Key, optionally appending the result with entropy data and the user’s password, and passing that blob into a few CryptoAPI calls to derive a session key. This session key is used to encrypt the actual data.

Whew!

This process actually does a very good job of securing key files such that, if you got a copy of the key files as they exist on disk, you’d have a difficult time brute-forcing your way into the software key data. They’re basically useless unless you have an utterly stupefying amount of disposable processing power. However, for as strong as the key protection is, it’s just software.

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever”, said the old lady. “But it’s turtles all the way down!”
-Stephen Hawking, A Brief History of Time

That’s essentially what software keys are protected by – software, all the way down. Well, that’s not completely accurate. It’s software all the way down except for the mythical final turtle, which is our old friend, the password!

Now, I’m not suggesting that I know how to crack DPAPI, even if I do know a user’s password…that is, unless I have physical access to the device. Then all I’d need to do is log in, and Windows conveniently will take care of the rest, and allow me to use the keys however I see fit. (Un)fortunately, I don’t actually even need that to unlock a software key. All I need is a way of impersonating the user’s logon session, whether through remote desktop, exploiting Windows vulnerabilities, installing a rogue ActiveX control, or any number of countless ways to get a user to run some code.

So, how are we supposed to protect our private keys, then? Well, the simple and pretty inexpensive answer to that question, is Hardware Tokens. You can get a good FIPS-140 validated cryptography token for about $50-100, which will generate keys on the device, and the keys will never, ever be available to software (all cryptography operations are executed on the token). The tokens are tamper resistent (all memory is destroyed if the token is tampered with), and brute forcing won’t work, either (after a set number of failed logins, the token is locked and, optionally, all data is wiped). Now, this isn’t necessary for some applications, but if your encrypted data is worth more than $50 to you, why would you want to protect it with something as flimsy as a password?

Message Authentication Codes (MACs) are special pieces of data used to prove the authenticity and integrity of a message– to show that the message originated from a certain source and that it has not been modified. Consider a scenario in which Alice wants to send Bob an email. Upon receiving the email, Bob would like to be fairly certain that Alice was indeed the author and that the letter hasn’t been changed. When creating her email, Alice needs to have some technique that satisfies Bob’s concerns.

• First, she appends a secret word to the very end of the message. This secret word is only known by Alice and Bob.
• Next, she creates a unique “footprint” of her email by running it through a hash function (along with the secret appended at the end).
• Finally, she sends the original message (sans the secret word) to Bob. She also sends him the digest/hash/footprint.

When Bob gets the message:

• First he adds the secret word to the very end of the message (just like Alice did).
• Then he runs the message + secret through the exact same hash function that Alice did.
• Finally, he compares the resulting “footprint” with the one Alice sent him. If they match, the he can be confident that Alice sent it (since she’s the only other one who knows their secret) and that the message hasn’t been tampered with (since any change in the message would result in a different footprint).

This is almost identical to the way digital signatures work. However, MACs rely on a shared secret and, therefore, aren’t inherently based on public key theory. In addition, digital signatures are able to establish non-repudiation, which is not the case with MACs. In the above example, Bob could create an email from Alice to himself and Alice would not be able to prove she didn’t send it using just the MAC.

For this reason, MACs are most commonly used for inter-system communication. Webservers, specifically, make use of MACs to protect against cross-site request forgery (CSRF) attacks.

However, a common misconception with creating MACs is that any strong hash function alone is sufficient when creating an effective MAC. In reality, MAC-specific algorithms are designed to address some weakness with recklessly using block-level iterative hash functions (MD5, SHA, etc) concatenated to some shared secret. Specifically, the use of a Hash(message || secret) approach is susceptible to attack since someone could use information on known message/hash combinations to construct a new, working message/hash. By using a MAC-specific algorithm, such as HMAC or CMAC, these weaknesses can be mitigated or avoided altogether. So if you’re ever in a situation where you could benefit from a hastily-implemented MAC, be sure to consider both its strengths and weaknesses.

Today Slashdot had a story about how a news story about an Australian transportation plan was broken early by a newspaper. The transport minister said the access of this information was akin to the newspaper trying to “pick the lock off a secure office and take highly confidential documents”.  What was the brilliant security plan that was supposed to be protecting this information?  The information was all stored on an unpublished URL with no security or authentication in place.

We in the security industry call this “security by obscurity“.  And it is not security at all. (more…)

When companies create security policies designed to keep their information secure, they are often most focused upon the threat of an outsider.  Certain measures, like using secure protocols such as SSL and TLS, or using S/MIME encrypted email can help keep your information from being viewed by third parties when it is sent over untrusted networks.  Other measures, like performing hard disk encryption on your laptops help keep your information secure when a laptop is lost or stolen, or a hard drive is sold on eBay.  None of these measures will help in the scenario of a trusted insider getting access to over 1300 documents that they have no business having.

According to the complaint, Jhaveri admitted being employed by Bristol-Myers-Squibb as a Technical Operations Associate from November of 2007 until his termination on February 2, 2010. The complaint further alleges that during his employment, Jhaveri stole numerous trade secrets as part of a plan to establish a pharmaceutical firm in his native India which would compete with Bristol-Myers-Squibb in various markets around the world.

How do you protect against the insider threat?  It is one of the more complicated issues of information security and there are a lot of opinions on how to deal with it.  Certainly it has to start with understanding what information you have which needs to be protected, how damaging that information could be if it were to be lost/stolen, and then making some cost/benefit analysis decisions on the best ways to protect it.  Everything from a rights management services type of solution to a strong security event and information management (SEIM) system could be useful in preventing and detecting insider threats.

According to a new article on TechTarget, a study by the Ponemon Institute has revealed the cost of a data breach has increased once again, to $204 per compromised record. The study is available for download at http://www.encryptionreports.com/ after giving away some personal details.

The “Fifth Annual U.S. Cost of Data Breach Study,” funded in part by encryption vendor PGP Corp., determines the annual cost of the breach by establishing a company’s cost of lost business as a result of an incident; expenses incurred by notifying individuals and authorities of a breach; costs associated with legal fees and consulting firms and new investments made in technology and employee education.

In our down economy, it is interesting that the cost of data breaches have been rising for five years running.  If I were cynical, I might suggest that one of the reasons for the constantly increasing costs in this study is the partnership with PGP, who sells products designed to protect you in the case of a lost laptop or storage device.

That said, I’m not even sure that those items above can accurately represent the cost of data breaches, especially in certain environments.  The loss or damage of reputation caused by a data breach can be so devastating that the monetary cost can’t even be calculated.  If you don’t know what I’m talking about, what is the first thing that comes to your mind when I mention Heartland Payment Systems, TJX, or the Department of Veterans Affairs?  These organizations have suffered tremendously because of wide (and widely publicized) data breaches.  Imagine the firestorm of criticism if some of the most trusted companies were to suffer data breaches along the lines of Heartland’s breach?

In addition to the loss of reputation, what are other costs of data breaches that the Ponemon study doesn’t reveal? Let us know in the comments.

Dan Kaminsky posted on twitter the following:

http://eprint.iacr.org/2010/006.pdf Is it time to deprecate 1024bit RSA for, say, 1276bit? (2048 has perf issues.)

The link Dan provided is a research paper which reports the successful factorization of the 768-bit number from the original 2001 RSA challenge. I responded to him that NIST had already deprecated the use of 1024-bit RSA in the government, and it was time for industry to follow suit. Since I posted that, I’ve been surprised that a number of people don’t understand the upcoming changes in key lengths and algorithm strengths that have been mandated by NIST. So, this post offers some information about why I can confidently say the U.S. government has deprecated certain algorithms and key lengths.

(more…)

It’s been talked about in the past about how important it is to become PCI DSS compliant. For some industries it’s an absolute must. Without it, they can’t conduct business. We’ve covered some of the latest updates to PCI as well. One of the most overlooked aspects of becoming PCI DSS compliant though is actually maintaining compliance. Instead, most simply rush out to meet the requirements in order to meet the auditor deadline. Instead, we should be looking at what needs to be done on a continual basis. It’s the down time after the audit where most data breaches occur. The following list, which was put together by Dr. Anton Chuvakin, will outline the areas that require some form of upkeep.

(more…)

As a recent slashdot article points out, Amazon has honestly admitted that it is impossible to attain PCI Level 1 compliance on an application built on their EC2 (computing) and S3 (storage) services.

It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3, but you cannot achieve level 1 compliance. And you have to provide the appropriate encryption mechanisms and key management processes. If you have a data breach, you automatically need to become level 1 compliant which requires on-site auditing; that is something we cannot extend to our customers.

We wrote a short whitepaper covering a brief security overview of cloud computing, and this is one of the topics we have been concerned about.  I’m currently en route to perform an on-site assessment of a service provider for a customer of ours.  This type of assessment provides my customer a great deal of confidence that they can trust their business partner.  If the provider of cloud services either won’t let you (or your auditor) visit their data centers, or can’t tell you which one to visit (because your data is unpredictably stored in many different locations), then it is impossible to get the same level of confidence that your data is being stored and protected.

Cloud computing isn’t for everything. It’s not going to be a good fit when you need compliance with PCI or similar standards, or your security policies require on-site assessments. Kudos to Amazon for admitting that.

Questions about the trustworthiness of electronic voting machines have been in the news a lot over the last few years. Plenty of people acknowledge the potential for abuse of these machines, and discussions of how they can be used to swing elections are pretty common. A trait that these discussions share are hypothetical scenarios or instances where an attacker would need to have some kind of esoteric/insider knowledge about the hardware and/or software running the machine to mount an effective attack.

However, I recently came across a video detailing a real attack against a real voting machine, carried out by real engineers, using real tools and data, and showing very real results.

The Sequoia AVC Advantage, a pretty old piece of electronic voting equipment, was broken pretty badly by hardware reverse engineering and return-oriented programming. The following video shows how it was done by a team of computer scientists and engineers from the University of California, San Diego, the University of Michigan, and Princeton University:

More about the attack details here.

What’s really interesting is the ease in which they were able to get a voting machine to play with in the first place. They didn’t steal one or bribe a government worker. Instead, they bought 5 of them… online… from a government surplus auction for less than $20 a pop. Craziness… especially considering some states still use these same machine models. A few months later and these guys have a well-structured attack that can swing the vote any way they want.

This just goes to show how thin the line is between hypothetical voting machine attacks carried out by insiders with special knowledge and real voting machine attacks carried out by smart people with a couple of dollars and some spare time on their hands.

Overnight, the Clear Registered Traveler Program ceased operation.  I do travel by air 5-10 times per year, and had considered the program to speed my visits through airports.  There were three main reasons why I didn’t, and I wonder if they are reasons why they have had to cease operation.

1. There weren’t Clear lanes at every airport I travel to; the only way this system could be cost effective for me would be if it worked everywhere.
2. As mentioned at the Consumerist, the Clear lanes just provide shorter lines; you still were subject to all the security checkpoint hassles.
3. My home airport, Dulles International, opened the Black Diamond lanes: basically the same as Clear without the fee.

In addition to the $199/year charge, enrolling in Clear required presentation of two IDs, your social security number, and the capture of your fingerprints and retinal scan. Clear lost (and found) a laptop last year, and although their privacy policy (pdf) indicates that all personal information is always stored and transmitted encrypted, it doesn’t indicate what algorithm is used or how key management is performed. (Remember, ROT13 is an encryption algorithm…)  Biometrics are the only identification factor that you can’t have revoked and reissued, so giving mine up to both a private company and the Transportation Security Administration to save perhaps 15 minutes didn’t seem like a good idea.

The privacy policy also indicates that personal information is removed from their system automatically after 90 days if you are no longer a Clear member. It is not yet clear if the cessation of operation that occurred overnight will trigger this data removal event. It is also not clear if the TSA ever gives up your data which Clear shares.  All told, if I had been a Clear member, I would seriously examine tools for detecting and preventing identity theft for a while.