Slashdot Mirror

Put an RSA-8192 signature using the 288 bit hash "SHA1|MD5" and PKCS-2 padding on the magnetic stripe. That would both contain the information on the front as well as sign the data as legitimate.

Only a secure black box (a la nCipher) at the state DMV would contain the private key. The public key would be given out publicly, especially card scanner manufacturers. The FBI or NSA could have a root certificate, and could countersign the public keys of each of the 50 states and other agencies issuing drivers' licenses.

We really need the federal government demanding a particular standard for the mag stripe system. Let the states design the fronts as they please, but at least make them all electronically readable. Don't build a central federal database with the information, as the public haaaaates that. Keep data storage the same, just make it possible to authenticate the data on the cards.

How much data can be stored on a mag stripe? Maybe you could fit a 10k image of the person on the mag stripe for a card reader to display. Like the other data, this would be hashed, identifying the photograph as authentic.

(Operator | in traditional cryptographic notation means "concatenate"; IE, attach the 128 bit MD5 hash to one of sides of the 160 bit SHA-1 hash to make a 288 bit hash function. SSH uses this. The MD5 algorithm has been shown insecure, as this output shows:

$ md5sum file1.dat file2.dat;sha1sum file1.dat file2.dat
a4c0d35c95a63a805915367dcfe6b751 *file1.dat
a4c0d35c95a63a805915367dcfe6b751 *file2.dat
2783c4ff4a3f20d25f2598a8b052b890c37dca c4 *file1.dat
3c35410823ef00b12d020981c1cf8564c0f89b cc *file2.dat
Click me for a site talking about this MD5 collision

SHA1 is also suspect. So combine the two for security. The fact that SHA1 and MD5 use opposite byte orders makes things even more secure.)

from the deployment of 65,000 smart cards (let's see, at $50 a piece, that comes to....?)

Smart cards are much cheaper than $50 each. For development work I get them (for this device) for under $10 each in quantities of 10 and that's expensive. In large quantities they are available for a few dollars each. I'm sure MS buys them in quantities to ensure some sort of discount is applied.

Let me start out by reminding the audience I am not a security expert.

Understood - this isn't personal, just a few points which I though were unclear or misstated.

TCPA adds a few elements to this security scheme [...] longer keys (some keys are 160 bits, most are 2048 bits)

I would assume that the 128 and 160-bit keys are keys for some symmetric cipher, and the 2048 bit keys are RSA keys. It is wrong to suggest that key length correlates to strength without taking the algorithm into account, and even then practicality limits the usefulness of longer and longer keys. 128 bits is probably safe enough, and though I'd be happy to use a 160 or 256 bit key in a symmetric cipher, longer than that gets silly: at 128 bits you're already never going to see the key brute forced.

The benefits of 2048 bit RSA keys come not from strength through length, but from the fact that they belong to a different class of algorithm, which allows you to do very different things with them.

This enables the denial of access to data if rogue software, such as a virus, is introduced into a platform, because such introduction necessarily changes the software state of the platform.

I have yet to be convinced that this is true of data in the general sense and malware. All real world software contains bugs, some of which can be exploited to subvert the system. No amount of hardware trickery can stop this being true, the best you can hope for is to contain the spread of corruption by compartmentalizing the system. If you only have one compartment, or only one compartment you really care about, which I suspect will be the case for the majority of systems, then containing malicious code to that compartment provides little benefit. Even if you care about other compartments, the premise of containment assumes no bugs in the boundaries between neighbouring compartments.

In all likelihood you can make things prohibitively difficult for individuals to do something against the policy of the creator of the platform/application, even with their own property, but you can't make the guarantee that the platform is immune from malware.

Can open-source software make use of TCPA? Yes.

This is not necessarily useful. Anyone may well be able to implement TCPA features, just as anyone can implement an SSH client. Without access to the necessary keys, you can still be prevented from accessing particular data or functionality, just as your own SSH client won't allow you to login to any extra servers. With open access to the keys, you've lost any security guarantees that rested on them. This makes the exercise somewhat pointless in many cases.

While somebody could write a DRM application using the TPM, they could also write one without it.

DRM without hardware support can never be secure. At some point the data being protected has to be decrypted, and since the DRM implementation doesn't have the secure platform guarantee the TPM provides, it can't be sure there isn't something out there waiting to extract the data. It's even relatively easy to directly subvert the software, but subverting secure hardware is very much more difficult. This is significant because the R in DRM is not directly tied to law - it can be used to enforce policy that extends beyond the data owner's rights, by restricting rights that the end user does have.

Non-DRM applications can be developed under TCPA. The example I thought of is an improved VPN for companies that are super-paranoid about their data (think about it ... 2048 bit keys, no hash load on the system CPU, ability to tie accessibility to a unique platform).

This can of course be done without TCPA. You could easily push the crypto into the NIC. nCipher make a variety of crypto hardware accelerators for networking, storage and other uses, which don't impact the architecture of the whole of the rest of the system.

could this be used in SSL acceleration cards to improve the effiency of the SSL 'processor'

Unlikely in presently deployed accelerator cards, since AFAIK most (Rainbow CryptoSwift and nCipher) are based on custom hardware chips (FPGA and the likes) which do mainly RSA key setup which is the really slow part of establishing a SSL session. I believe several of the cards do not even do any symmetric (i.e. RC4, 3DES) acceleration because it isn't worth it.

First, instead of faking up a general purpose computer as a crypto box, you are much better off getting a FIPS 140 rated hardware crypto device. They may cost a bit more up-front (although they are becoming cheaper), but dedicated devices have a lot of advantages. They are designed for security from the ground-up, and you don't have to worry about the "weekly" patch. They usually perform cryptography much faster (think SSL accelerators), and have better protection against insider attacks too.

Second, you need to break down the data access requirements. Carefully look the functions that need to be performed. Many times when you think you might need access to the data, you really can get by with something else (for example as mentioned in another thread, you can create a cryptographic hash of CC info, and compare it with a stored hash).

Most importantly, the design should not require the crypto box to decrypt the data. It does not matter how safe the crypto box keeps your keys, if the hacker can decrypt the data by hijacking an existing decryption script. So long as the crypto box can't decrypt data, the hacker could have complete control of the machine and still have no way to get the protected information. You can see this also protects against insider attacks too.

A logical questions is how do you actually use the credit card info, if the crypto box encrypts it right away, and has no way to decrypt it? The basic technique is to allow the box to make limited "translations". For example, incoming data is translated from SSL to a database key. Another transaction translates the data from encryption under a database key into a switch key. If someone absolutely has to see the data in the clear, make them use a smartcard; and have the crypto box translate the data into a format that only that specific smart card can decrypt.

You can see why you have to be so careful about knowing what functions need data access. Actually, I'm leaving a lot of things out, but here are a couple more considerations. Be very careful with the allowed translations, since you don't want to allow the attacker to translate the protection into a usable or weak format. Also don't forget about auditing all of these transactions (a Visa requirement).

I'd recommend starting by looking at crypto box vendors. A traditional way is to get a crypto box that either already supports this type of application (protecting CC info is a common problem), or to arrange for custom commands (also see Atalla, Thales, and Eracom). There is a relatively new concept of running ordinary programs on a secure box (such as nCipher). I'm kind of skeptical of this approach, since designing a logical secure interface can be fairly difficult. I recommend using PKCS#11 based boxes only with great care, since the protocol has some significant logical security problems, and is probably not the right type of tool for this issue.

Check out this whitepaper from CyberSource that describes a good solution for your problem. I'd add to this approach that you should use a keyed hash, and a hardware encryption device for both hashes and encryption/decryption so the keys are not readily available to someone with a login on the machine. I'd recommend Ncipher. Finally, use Tripwire or some such thing to monitor the machines for unauthorized programs that might gain access to both the database and the crypto HW.

You might want to consider hardware based crypto like nCipher. This way you do the key storage and en/decrypt functionality in (supposedly) tamper resistant hardware. HOWEVER, if someone hacks your system and is able to access/copy your code and get the right privileges to talk to the nCipher box you are screwed anyway. But it would certainly raise the bar ...

Umm... if you're screaming for crypto coprocessors, then why don't you buy something like the nCipher nFast? PCI or external SCSI...

> For example in the UK it is actually illegal to do encryption in hardware You mean like the nCipher device which performs RSA and DH operations in hardware? Produced in Cambridge (not the one in MA)? A little more care required before you post inaccurate stuff like that It is not illegal to perform encryption in hardware, software or via two packs of playing cards in the UK. Much to the security services' annoyance.

In the end, it's nothing that spectacular: it's about identifying public and and unencrypted secret key data in a stream of bits with lots of other data. Although it seems as if nobody has thought about this kind of attack before, other forms of attack, based on additional characteristics of the key (for example, that it is contained in an OpenPGP packet), were certainly known, and it is quite likely that systems designed to be immune against this kind of attack (i.e., by employing tamper-proof hardware or storing critical key material on a strongly protected separate server) will resist the new (old) one as well.

Of course, only few people in the modern e-commerce world care about security on their sites, so some media attention, although a bit late and a bit exaggerated, is always a good thing.

"In this paper we consider the problem of efficiently locating cryptographics keys hidden in gigabytes of data, such as the complete file system of a typical PC. We describe efficient algebraic attacks which can locate secret RSA keys in long bit strings, and more general statistical attacks which can find arbitrary cryptographic keys embedded in large programs. These techniques can be used to apply lunchtime attacks on signature keys used by financial institutes, or to defeat authentication type mechanisms in software packages."

Now we actually now what this is about. As far as I am concerned, the interesting application would be if No Such Agency sifted communications channels of a planet to find the keys. They can afford to do it if it's computationally cheap enough.

First of all, as everyone else has pointed out, is a cracker has access the filesystem where you store your keys, you have more important security concerns.

Second of all, this was reported almost a year and a half ago (Sept 22, 1998)

http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pdf

The "attack", detailed in:

http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pdf

appears to be a better search algorithm for finding keys in already-compromised media. Anyone relying on a strange filename or a full disk to hide their RSA keys now has even more need to worry :)

This is not a new "break", it just make security-through-obscurity even less obscure/secure.

The vulnability described is a way to scan memory and finding a private key in the middle of it. Since most servers, even the NT ones :-), have strict security on who can run and who can access memory this would be no problem for most of the server.

The major problem I see is the virtual servers that hold many sites into a single machine. Every site owner have access to run programs in the machine, if those sites are not properly secured one site owner could be able to exploit some known hole to be able to scan memory is search for other site owner's keys.

--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"

Could be useful in other areas too, like embedded hidden compressed code.

Read this article for more.

This was reported by Nicko van Someren at the
Crypto'98 rump session.
Markus Kuhn was cited in a news-posting I read, and he mentioned the ncipher, who apparantly used this trick before to get their strong encryption (hardware!) into the windows api. One of their founders is said Nicko van Someren.

There are a few operations that are much faster in silicon than in software, like modular exponentiation. See the nFast hardware for example of a good way to accelerate crypto.