Entries Tagged "encryption"

Page 40 of 57

Proprietary Encryption in Car Immobilizers Cracked

This shouldn’t be a surprise:

Karsten Nohl’s assessment of dozens of car makes and models found weaknesses in the way immobilisers are integrated with the rest of the car’s electronics.

The immobiliser unit should be connected securely to the vehicle’s electronic engine control unit, using the car’s internal data network. But these networks often use weaker encryption than the immobiliser itself, making them easier to crack.

What’s more, one manufacturer was even found to use the vehicle ID number as the supposedly secret key for this internal network. The VIN, a unique serial number used to identify individual vehicles, is usually printed on the car. “It doesn’t get any weaker than that,” Nohl says.

Posted on December 23, 2010 at 2:02 PM • View Comments

New Attack Against ASP.NET

It’s serious:

The problem lies in the way that ASP.NET, Microsoft’s popular Web framework, implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions. A common mistake is to assume that encryption protects the cookies from tampering so that if any data in the cookie is modified, the cookie will not decrypt correctly. However, there are a lot of ways to make mistakes in crypto implementations, and when crypto breaks, it usually breaks badly.

“We knew ASP.NET was vulnerable to our attack several months ago, but we didn’t know how serious it is until a couple of weeks ago. It turns out that the vulnerability in ASP.NET is the most critical amongst other frameworks. In short, it totally destroys ASP.NET security,” said Thai Duong, who along with Juliano Rizzo, developed the attack against ASP.NET.

Here’s a demo of the attack, and the Microsoft Security Advisory. More articles. The theory behind this attack is here.

EDITED TO ADD (9/27): Three blog posts from Scott Guthrie.

EDITED TO ADD (9/28): There’s a patch.

EDITED TO ADD (10/13): Two more articles.

Posted on September 27, 2010 at 6:51 AM • View Comments

Master HDCP Key Cracked

The master key for the High-Bandwidth Digital Content Protection standard—that’s what encrypts digital television between set-top boxes and digital televisions—has been cracked and published. (Intel confirmed that the key is real.) The ramifications are unclear:

But even if the code is real, it might not immediately foster piracy as the cracking of CSS on DVDs did more than a decade ago. Unlike CSS, which could be implemented in software, HDCP requires custom hardware. The threat model for Hollywood, then, isn’t that a hacker could use the master key to generate a DeCSS-like program for HD, but that shady hardware makers, perhaps in China, might eventually create and sell black-market HDCP cards that would allow the free copying of protected high-def content.

Posted on September 17, 2010 at 1:57 PM • View Comments

More Skein News

Skein is my new hash function. Well, “my” is an overstatement; I’m one of the eight designers. It was submitted to NIST for their SHA-3 competition, and one of the 14 algorithms selected to advance to the second round. Here’s the Skein paper; source code is here. The Skein website is here.

Last week was the Second SHA-3 Candidate Conference. Lots of people presented papers on the candidates: cryptanalysis papers, implementation papers, performance comparisons, etc. There were two cryptanalysis papers on Skein. The first was by Kerry McKay and Poorvi L. Vora (presentation and paper). They tried to extend linear cryptanalysis to groups of bits to attack Threefish (the block cipher inside Skein). It was a nice analysis, but it didn’t get very far at all.

The second was a fantastic piece of cryptanalysis by Dmitry Khovratovich, Ivica Nikolié, and Christian Rechberger. They used a rotational rebound attack (presentation and paper) to mount a “known-key distinguisher attack” on 57 out of 72 Threefish rounds faster than brute force. It’s a new type of attack—some go so far as to call it an “observation”—and the community is still trying to figure out what it means. It only works if the attacker can manipulate both the plaintexts and the keys in a structured way. Against 57-round Threefish, it requires 2503 work—barely better than brute force. And it only distinguishes reduced-round Threefish from a random permutation; it doesn’t actually recover any key bits.

Even with the attack, Threefish has a good security margin. Also, the attack doesn’t affect Skein. But changing one constant in the algorithm’s key schedule makes the attack impossible. NIST has said they’re allowing second-round tweaks, so we’re going to make the change. It won’t affect any performance numbers or obviate any other cryptanalytic results—but the best attack would be 33 out of 72 rounds.

Our update on Skein, which we presented at the conference, is here. All the other papers and presentations are here. (My 2008 essay on SHA-3 is here, and my 2009 update is here.) The second-round algorithms are: BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein. You can find details on all of them, as well as the current state of their cryptanalysis, here. NIST will select approximately five algorithms to go on to the third round by the end of the year.

In other news, we’re once again making Skein polo shirts available to the public. Those of you who attended either of the two SHA-3 conferences might have noticed the stylish black Skein polo shirts worn by the Skein team. Anyone who wants one is welcome to buy it, at cost. Details (with photos) are here. All orders must be received before October 1, and we’ll have all the shirts made in one batch.

Posted on September 1, 2010 at 6:01 AM • View Comments

WikiLeaks Insurance File

Now this is an interesting development:

In the wake of strong U.S. government statements condemning WikiLeaks’ recent publishing of 77,000 Afghan War documents, the secret-spilling site has posted a mysterious encrypted file labeled “insurance.”

The huge file, posted on the Afghan War page at the WikiLeaks site, is 1.4 GB and is encrypted with AES256. The file’s size dwarfs the size of all the other files on the page combined. The file has also been posted on a torrent download site.

It’s either 1.4 Gig of embarrassing secret documents, or 1.4 Gig of random data bluffing. There’s no way to know.

If WikiLeaks wanted to prove that their “insurance” was the real thing, they should have done this:

  1. Encrypt each document with a separate AES key.
  2. Ask someone to publicly tell them to choose a random document.
  3. Publish the decryption key for that document only.

That would be convincing.

In any case, some of the details might be wrong. The file might not be encrypted with AES256. It might be Blowfish. It might be OpenSSL. It might be something else. Some more info here.

EDITED TO ADD (8/9): Weird Iranian paranoia:

An Iranian IT expert warned here on Wednesday that a mysterious download file posted by the WikiLeaks website, labeled as ‘Insurance’, is likely a spy software used for identifying the information centers of the United States’ foes.

“The mysterious file of the WikiLeaks might be a trap for intelligence gathering,” Hossein Mohammadi told FNA on Wednesday.

The expert added that the file will attract US opponents and Washington experts can identify their enemy centers by monitoring individuals’ or organizations’ tendency and enthusiasm for the file.

Posted on August 4, 2010 at 7:52 AM • View Comments

UAE to Ban BlackBerrys

The United Arab Emirates—Dubai, etc.—is threatening to ban BlackBerrys because they can’t eavesdrop on them.

At the heart of the battle is access to the data transmitted by BlackBerrys. RIM processes the information through a handful of secure Network Operations Centers around the world, meaning that most governments can’t access the data easily on their own. The U.A.E. worries that because of jurisdictional issues, its courts couldn’t compel RIM to turn over secure data from its servers, which are outside the U.A.E. even in a national-security situation, a person familiar with the situation said.

This is a weird story for several reasons:

1. The UAE can’t eavesdrop on BlackBerry traffic because it is encrypted between RIM’s servers and the phones. That makes sense, but conventional e-mail services are no different. Gmail, for example, is encrypted between Google’s servers and the users’ computers. So are most other webmail services. Is the mobile nature of BlackBerrys really that different? Is it really not a problem that any smart phone can access webmail through an encrypted SSL tunnel?

2. This an isolated move in a complicated negotiation between the UAE and RIM.

The U.A.E. ban, due to start Oct. 11, was the result of the “failure of ongoing attempts, dating back to 2007, to bring BlackBerry services in the U.A.E. in line with U.A.E. telecommunications regulations,” the country’s Telecommunications Regulatory Authority said Sunday. The ban doesn’t affect telephone and text-messaging services.

And:

The U.A.E. wanted RIM to locate servers in the country, where it had legal jurisdiction over them; RIM had offered access to the data of 3,000 clients instead, the person said.

There’s no reason to announce the ban over a month before it goes into effect, other than to prod RIM to respond in some way.

3. It’s not obvious who will blink first. RIM has about 500,000 users in the UAE. RIM doesn’t want to lose those subscribers, but the UAE doesn’t want to piss those people off, either. The UAE needs them to work and do business in their country, especially as real estate prices continue to collapse.

4. India, China, and Russia threatened to kick BlackBerrys out for this reason, but relented when RIM agreed to “address concerns,” which is code for “allowed them to eavesdrop.”

Most countries have negotiated agreements with RIM that enable their security agencies to monitor and decipher this traffic. For example, Russia’s two main mobile phone providers, MTS and Vimpelcom, began selling BlackBerrys after they agreed to provide access to the federal security service. “We resolved this question,” Vimpelcom says. “We provided access.”

The launch of BlackBerry service by China Mobile was delayed until RIM negotiated an agreement that enables China to monitor traffic.

Similarly, last week India lifted a threat to ban BlackBerry services after RIM agreed to address concerns.

[…]

Nevertheless, while RIM has declined to comment on the details of its arrangements with any government, it issued an opaque statement on Monday: “RIM respects both the regulatory requirements of government and the security and privacy needs of corporations and consumers.”

How did they do that? Did they put RIM servers in those countries, and allow the government access to the traffic? Did they pipe the raw traffic back to those countries from their servers elsewhere? Did they just promise to turn over any data when asked?

RIM makes a big deal about how secure its users’ data is, but I don’t know how much of that to believe:

RIM said the BlackBerry network was set up so that “no one, including RIM, could access” customer data, which is encrypted from the time it leaves the device. It added that RIM would “simply be unable to accommodate any request” for a key to decrypt the data, since the company doesn’t have the key.

The BlackBerry network is designed “to exclude the capability for RIM or any third party to read encrypted information under any circumstances,” RIM’s statement said. Moreover, the location of BlackBerry’s servers doesn’t matter, the company said, because the data on them can’t be deciphered without a decryption key.

Am I missing something here? RIM isn’t providing a file storage service, where user-encrypted data is stored on its servers. RIM is providing a communications service. While the data is encrypted between RIM’s servers and the BlackBerrys, it has to be encrypted by RIM—so RIM has access to the plaintext.

In any case, RIM has already demonstrated that it has the technical ability to address the UAE’s concerns. Like the apocryphal story about Churchill and Lady Astor, all that’s left is to agree on a price.

5. For the record, I have absolutely no idea what this quote of mine from the Reuters story really means:

“If you want to eavesdrop on your people, then you ban whatever they’re using,” said Bruce Schneier, chief security technology officer at BT. “The basic problem is there’s encryption between the BlackBerries and the servers. We find this issue all around about encryption.”

I hope I wasn’t that incoherent during the phone interview.

EDITED TO ADD (8/5): I might have gotten a do-over with Reuters. On a phone interview yesterday, I said: “RIM’s carefully worded statements about BlackBerry security are designed to make their customers feel better, while giving the company ample room to screw them.” Jonathan Zittrain picks apart one of those statements.

Posted on August 3, 2010 at 11:08 AM • View Comments

Location-Based Quantum Encryption

Location-based encryption—a system by which only a recipient in a specific location can decrypt the message—fails because location can be spoofed. Now a group of researchers has solved the problem in a quantum cryptography setting:

The research group has recently shown that if one sends quantum bits—the quantum equivalent of a bit—instead of only classical bits, a secure protocol can be obtained such that the location of a device cannot be spoofed. This, in turn, leads to a key-exchange protocol based solely on location.

The core idea behind the protocol is the “no-cloning” principle of quantum mechanics. By making a device give the responses of random challenges to several verifiers, the protocol ensures that multiple colluding devices cannot falsely prove any location. This is because an adversarial device can either store the quantum state of the challenge or send it to a colluding adversary, but not both.

Don’t expect this in a product anytime soon. Quantum cryptography is mostly theoretical and almost entirely laboratory-only. But as research, it’s great stuff. Paper here.

Posted on August 3, 2010 at 6:25 AM • View Comments

WPA Cracking in the Cloud

It’s a service:

The mechanism used involves captured network traffic, which is uploaded to the WPA Cracker service and subjected to an intensive brute force cracking effort. As advertised on the site, what would be a five-day task on a dual-core PC is reduced to a job of about twenty minutes on average. For the more “premium” price of $35, you can get the job done in about half the time. Because it is a dictionary attack using a predefined 135-million-word list, there is no guarantee that you will crack the WPA key, but such an extensive dictionary attack should be sufficient for any but the most specialized penetration testing purposes.

[…]

It gets even better. If you try the standard 135-million-word dictionary and do not crack the WPA encryption on your target network, there is an extended dictionary that contains an additional 284 million words. In short, serious brute force wireless network encryption cracking has become a retail commodity.

FAQ here.

In related news, there might be a man-in-the-middle attack possible against the WPA2 protocol. Man-in-the-middle attacks are potentially serious, but it depends on the details—and they’re not available yet.

EDITED TO ADD (8/8): Details about the MITM attack.

Posted on July 27, 2010 at 6:43 AM • View Comments

1 … 38 39 40 41 42 … 57

Sidebar photo of Bruce Schneier by Joe MacInnis.