Slashdot Mirror

Considering the recent USENIX talk on exploiting most mainstream IKE implementations via a Bleichenbacher attack, this seems most probable. Related paper: https://www.ei.rub.de/media/nd...

Since this is coming from the US military, it's pretty much useless, unless you are the US military.
Everyone else won't touch it with a two mile pole, due to the 100% guarantee of there being back doors in there and that being then entire point of this program.
(Cue the US military sock puppets trying their cheap dated memes on me. Sorry, "conspiracy", "tin foil hat", and similar thought-terminating straw man arguments do not work anymore since Snowden. I have seen TAOs happen in real life, and know about dopant-level hardware trojans you freedom-hating anti-democratic fascist fucks.)

Most manufacturers outside of the German cars are using systems developed by KeeLoq, so a vulnerability in that would impact a large number of vehicles. Parts of the encryption method have been attacked by researchers, with papers like How To Steal Cars. Some of these papers point out that the exact security mechanisms used by manufacturers on top of KeyLoq's hardware are not public, so turning the theoretical hacks into a working device is still hard even with these issues identified. Based on that FAQ, KeeLoq itself seems secure against anything but very knowledgeable attackers with significant resources--they're quoting months of work to find a real-world vulnerability. However, we can't be sure that a specific implementation of the security approach wasn't weakened by a manufacturer mistake. I wouldn't place a large bet on that though. Someone like a car manufacturer wants to be able to say they passed the risk to someone expert in this area. If they start customizing things to add back doors, they're going to lose any ability to blame KeeLoq if there's a nasty vulnerability.

One problem I have read about on Android is that some 3rd party apps and even shovel-ware put on the phone by vendors is weak. Basically I could install a totally legit text messaging app and another app could invoke it to send messages on its behalf. So from a user standpoint, I approve the text messaging app to send SMS (legit) and later I install Uno. It could wait some random period of time and then start sending messages. This is actually preferred for the malware creators because then it also has another variable as when it would work (say its dependent on a carrier branded dialer, or some other 3rd party app).

http://www.ei.rub.de/media/trust/veroeffentlichungen/2010/11/13/DDSW2010_Privilege_Escalation_Attacks_on_Android.pdf
(Sorry, PDF)
This has a pretty good explanation of the problem, and honestly I'm not sure if this could also work on an iOS device. (Can apps on iOS invoke another app?)

Here's the actual paper: http://www.nds.rub.de/research/publications/breaking-xml-encryption/

You should find a pdf of the paper here: http://www.nds.rub.de/research/publications/breaking-xml-encryption/

http://www.emsec.rub.de/media/crypto/veroeffentlichungen/2011/10/10/desfire_2011_extended_1.pdf

Nice idea to go for encryption, but it turns out that the most popular keyless lock system was hacked just a couple of days ago...

MD5 collision attacks aren't really new, although this is a powerful example. An equally meaningful example of a collision attack on the algorithm, in the form of two different PostScript files with the same MD5 hash, was provided at least two years ago (IIRC).

The key to understanding the limits of this demonstration's significance is to realize that a collision attack is quite different from a prefix attack. These researchers were able to create a pair of executables having the same hash value by specially constructing them as such; crafting a new executable to match a specific hash value corresponding to some other party's executable is vastly more difficult to achieve.

So while this demonstrates MD5 to be useless for uses where the purported signatory is to be included in our threat analysis -- as has already been demonstrated to us by other researchers -- the algorithm is still relatively safe if our only goal is to ensure that a given executable almost certainly came from a specific party (rather than showing that it is a specific executable from said party). In other words, one could conceivably use MD5 to verify that the Ubuntu packages on that FTP server were in fact produced by Canonical. So no, demonstration does not mark MD5 as completely useless for code signing; the most common applications of code signing are entirely unconcerned with collisions in the hash function.

In conclusion: the title is terribly misleading, or possibly just misinformed. Boo! Hiss!

No, unfortunately this is incorrect. bzip2 probably will ignore data after the end of the stream, plus it has future usage blocks that are likely ignored. OOo also has areas that are ignored by the editor. (I'm generalizing, I didn't check either program, but many - can I say most? - programs have such areas.)

Using those areas you can add whatever padding data you need to "fix" the hash after adding your fake data.

Recording the file length makes it harder, true. But if you are the one generating the hash you can pre-padd the data to give you a space later for this manipulation.

Have a look: http://www.cits.rub.de/MD5Collisions/ the page has links to two postscript files with identical MD5's. Quite different content though.

Even still, there have been cases where two obviously different files share the same MD5 hash: http://www.cits.rub.de/MD5Collisions/

If it's non-acedemic (sic) to crack an MD5 hash, please tell me the plaintext for this: f6540dee6b248c863bb90fcaa784fef9

The term "plaintext" has no meaning for cryptographic hashes. The point of the attack is, if you had some text that hashed to say, f6540dee6b248c863bb90fcaa784fef9, I could, with even less work than I initially gathered, generate another set of data, saying something completely different, which also hashes to the same value. This has severe implications in the field of digital signatures, as the way most digital signature algorithms work is as follows:

1. Generate the hash of the document to be signed.
2. Encrypt the hash using the signer's private key.
3. The encrypted hash is the document's digital signature.

Now, if I wanted to verify the signed document:

1. Generate the hash of the document to be signed.
2. Decrypt the digital signature using the signer's public key.
3. Compare the computed hash with the hash recovered by decrypting the digital signature. If they match, the document is supposed to be authentic.

See the central role that hash functions play in this scheme? Now, if I'm able to generate collisions for the hash with a feasible amount of work, then given any digital signature you make using MD5 as the base hash I can create another document that might say something quite different, and attach the digital signature of the initial document to it, and it will look to anyone who cares as though you signed it. Of course, the document might look slightly strange to a person looking at it, but if the signature were used as part of a more complex cryptographic protocol, where only a computer ever really sees it, or if it's a document in a complicated file format (e.g. PostScript) that provides some leeway to add arbitrary data that is ignored by the viewer, then we might be in a spot of serious trouble. These collisions for MD5 are not just harmless, theoretical curiosities as you seem to think, as the page on X.509 certs and the PostScript examples illustrate.

The fact that collisions can be computed also destroys the non-repudiation characteristic of digital signatures. If this is important for your application, continued use of a weak hash function like MD5 is certainly out of the question, as the ability to generate collisions gives the alleged sender of a signed document a valid excuse to plausibly deny that she ever sent it. This of course makes MD5 digital signatures worthless from a legal standpoint.

Fortunately most people and began phasing out the use of MD5 for these and similar applications over the past several years, as it was already long suspected to harbor significant weaknesses. Now, we're hearing similar news about SHA-1 as what we heard about MD5 since roughly 1996, when cryptographers began recommending that alternative algorithms be used. Now, we're hearing the same thing again about SHA-1, and I think it would be wise to heed the advice again and start migrating to better hash functions as soon as possible.

They have been found, in theory, to not be as collision-proof as previously thought, but noone has yet found a way to take one block of data and modify it such that it would have an identical hash signature as the original.

>I think it's actually very hard, in practice, to determine whether or not losing that property renders a particular system more vulnerable to attack.

It is computationally feasible, now, to build collding X.509 certificates.

It is possible, in some common environments and with a little cleverness, to Create two documents which are both human-readable and meaningful and which have the same MD5 hash.

Those are attacks which a collision-resistant hash function is supposed to prevent.

A collision-resistant hash function which has been shown not to be collision-resistant is broken. As of today, there's no published way for someone to start with a file you created and match its MD5 with a document they created. But in the case where an attacker can generate both files (say, the new $MUSTHAVE binary that gets signed by the repository and the separate binary with the same MD5 that contains a Trojan) MD5 has lost its usefulness.

Those TPM chips have a (hardware) random number generator and hash accelerator...

Maybe speed up your encrypted volumes ?
Faster WEP/WPA cracking for the wardrivers ?

If you have the lib and the driver and your OS is free, you could use it for *your* purposes

Linux driver for the Infineon TPM: http://www.prosec.rub.de/tpm/index.html

The mainstream Linux kernel has had a driver for infineon trusted platform modules since 2.6.12. I didn't even know any motherboards had shipped with those chips (have any?). User libraries and kernel patches were available well before 2.6.12. Linux has supported kernel-level encryption for ages, and is also on the forefront of technologies like mandatory access control. Not to mention how easy it would be to write a kernel module to implement one's own preferred flavor of DRM.

In short, Linux is an excellent operating system to implement DRM on. Low user interest and even lower vendor interest are the main problems, not the kernel.

That being said, I think that all DRM is inherently flawed without some serious hardware support, and that it will probably always be crackable on a general purpose computer with any operating system, simply due to the fact that the unencrypted data must be available on the machine at some point. I concur with your 3 day estimate.

If we could craft a collision block that contained a specified string at a specified position, that would be another issue altogether.

You can. You just can't make it based on an existing document, but you can create two files containing any specified content with the same hash. That means you have to make someone trust the first file and then abuse it using the second file. If you can maange to be subtle about it, well... For example, if you can create a source patch to an OSS project which makes one "sane" fix, and a few odd whitespace changes, adding spaces at the end of line or whatever. If they apply the patch as-is, the resulting binary could be one half of such a twin set. You could now distribute your twin as a legitimate version complete with MD5 and digital signature, while actually being a trojan. Convoluted but it could be done.

Kjella

Maybe I misunderstand but as I understand it MD5s are normally used in a checksum manner to sign or provide a fingerprint of a document. If you have an original document and compute it's MD5 then it can match some certified MD5 check sum. If someone were to generate a fake document they coul dnot design it to match the MD5 fingerprint. They could create some bit of gibberish that did match it but not a document that was useful as a forgery.

Most document formats have lots of "dead space", parts you can pretty much modify at will without changing what the user actually sees. Comments in HTML or PostScript. Old junk data in Word documents. Executables can have just about anything you like added if you know your stuff. The MD5 attacks currently available only 128 "dead space" bytes to generate a collision. So far from being a gibberish document, one can generate almost any document you want. This page has a simple example with PostScript files. Both files have the same MD5 hash, but one is a relatively harmless letter of recommendation while the other is a grant of security clearance. Get your boss to sign your letter of recommendation digitally, swap in the security clearance file, and pass it on. This is a Big Deal and a Major Problem.

See this: http://www.cits.rub.de/MD5Collisions/

It demonstrates the generation of two postscript files with the same MD5 hash that nevertheless display completely differently.

It's hard to deliver a payload when you're limited to tricking a target into downloading what would be (essentially) a random string of ones and zeroes.

Think again.

HMAC is designed to be robust even if the underlying hash function has weaknesses, within reasonable limits. SHA-1 is still within such reasonable limits (for that matter, MD5 probably is also).

The recently published attacks are not particularly useful for snooping on encrypted internet protocols such as IPSEC, SSL/TLS etc. To find a collision using the recently published attacks on MD5 and SHA-1, you must be able to control both of the colliding files. By introducing carefully chosen changes to each file you arrive at two files with the same hash. That is not very useful to a third party wishing to listen in on IPSEC, SSL/TLS, etc. However there are practical ways to exploit the new attacks. Stefan Lucks has a web site with a little story involving two PDF documents with the same hash, illustrating how this can be exploited:
http://www.cits.rub.de/MD5Collisions/

This means that the entire security of the boot process hangs on whatever data the CPU feels like sending to the chip for hashing. I could as well make a patch for GRUB that sends the "secure" version of GRUB down the SMbus and actually executes whatever nastiness I have in store.

That's a clever idea, but it doesn't work. The secret is that the trusted boot process uses a concept of "trust extension". We start off with the BIOS. That takes a hash of itself and sends it to the TPM. Then the BIOS will load and run the boot loader. But - and here is the key - before running GRUB, the BIOS take a hash of GRUB and sends it to the TPM. Then it runs GRUB.

The next step is that GRUB - or at least the TPM enabled version, performs a similar process for the OS kernel. It first takes a hash of the kernel and sends it to the TPM; then it runs the kernel. And the kernel can repeat the process with the various startup scripts and other programs that loads, a la tcgLinux or the Enforcer.

The key point is that before each component is loaded, it is "measured" (i.e. its hash is reported to the TPM). So you can create a bogus GRUB or a bad kernel, but this fact will show up in the TPM's configuration registers because your bad component got its hash reported before it ran.

The one exception is the BIOS, but TPM systems are supposed to have restricted BIOS flash capabilities so you can't re-flash the part of the BIOS which does the initial hash of itself. This is part of what they call the Core Root of Trust for Measurement (CRTM) and it is supposed to be inviolable.

Since the source is available for Linux, what would stop someone from sandboxing 'trusted' software by having the OS validate code before it's executed (slow, though a bit faster than emulation and without all the bugs), and then implenting the DRM hardware (or BIOS) instructions in software in a way that stores the keys (or plaintext information, if that is not doable) and allows access to any software to get the info.

This is one of the most commonly asked questions about the TPM. The answer is that the TPM implements what is called a "secure boot" sequence.

The first thing that happens in a TPM enabled computer is that the BIOS, on startup time, sends a hash of itself to the TPM. Then, when the BIOS goes to load the OS, it sends a hash of the boot loader (grub, in the case of Linux) to the TPM. The boot loader will be modified (see the Trusted Grub project) to take a hash of the OS kernel and send that to the TPM. And the OS itself will be modified (a la tcgLinux to take a hash of the various OS components, startup scripts, and programs as the computer boots.

The net result is that the TPM has a record of what OS was booted and what the software configuration is that is running. This allows it to distinguish between a "real" boot and an emulated one, because in the latter case it sees a hash of the emulator being loaded.

Software which runs in un-emulated mode and uses the TPM features can distinguish that case from when it is running emulated. If it locked some data using the TPM in the first mode, it won't be accessible in the second mode.

Once remote attestation is possible, networked applications will be able to report their software configuration to each other. This will be unforgeable because the TPM will sign an attestation of the software configuration, and the TPM itself will have a certificate from the manufacturer attesting that it is a legit TPM. Your emulator will not have a certified TPM key (those stay on the chip) and so it won't be able to come up with a credible forged attestation. Programs running on emulators won't be able to take part in network security applications that use these features.

Trusted Computing Group (TCG) technology makes sense in the context of Linux. Microsoft refuses to implement it. They had their own conception, which was Palladium, then NGSCB, then was dropped. So if TCG is going to go forward at all, it has to be with Linux.

It's kind of ironic, because Ross Anderson's lying Anti-TCPA FAQ tries to claim that TC exists to kill Linux. And yet it is turning out that Linux is the salvation of Trusted Computing.

There are a number of research projects in TC on Linux, including TPM Device Driver, Trusted GRUB and Secure GUI, tcgLinux, TCPA Open Source Platforms, Enforcer, and more. All Linux based.

Don't believe the FUD about TC. When implemented in Linux using Open Source software, TC gives you new options for securing and expanding the capabilities of your computer.

There's not much need for the Trusted Computing features on these chips since they are mostly used in relatively closed platforms like cell phones and PDAs. It's mostly a matter of getting the chip count down. Eventually however the same integration will show up in desktop computers.

Ironically most work integrating TC into the OS is being done on Linux. Microsoft seems to have given up on NGSCB (aka Palladium); its web site hasn't been updated for a year. Linux projects include tcgLinux, as well as the Applied Data Security Group at the University of Bochum in Germany. There's also the Enforcer project which uses the TC chip to provide TripWire-like modification detection functionality.