Entries Tagged "encryption"

Page 47 of 53

The Unabomber's Code

This is interesting. Ted Kaczynski wrote in code:

In a small journal written in code, he documented his thoughts about the crimes he was committing. That code was so difficult, a source says the CIA couldn’t crack it—until someone found the key itself among other documents, and then translated it.

Look at the photo. It was a manual, pencil-and-paper cipher. Does anyone know the details of the algorithm?

Posted on December 6, 2006 at 12:53 PMView Comments

Attacking Bank-Card PINs

Research paper by Omer Berkman and Odelia Moshe Ostrovsky: “The Unbearable Lightness of PIN Cracking“:

Abstract. We describe new attacks on the financial PIN processing API. The attacks apply to switches as well as to verification facilities. The attacks are extremely severe allowing an attacker to expose customer PINs by executing only one or two API calls per exposed PIN. One of the attacks uses only the translate function which is a required function in every switch. The other attacks abuse functions that are used to allow customers to select their PINs online. Some of the attacks can be applied on a switch even though the attacked functions require issuer’s keys which do not exist on a switch. This is particularly disturbing as it was widely believed that functions requiring issuer’s keys cannot do any harm if the respective keys are unavailable.

Basically, the paper describes an inherent flaw with the way ATM PINs are encrypted and transmitted on the international financial networks, making them vulnerable to attack from malicious insiders in a bank.

One of the most disturbing aspects of the attack is that you’re only as secure as the most untrusted bank on the network. Instead of just having to trust your own issuer bank that they have good security against insider fraud, you have to trust every other financial institution on the network as well. An insider at another bank can crack your ATM PIN if you withdraw money from any of the other bank’s ATMs.

The authors tell me that they’ve contacted the major credit card companies and banks with this information, and haven’t received much of a response. They believe it is now time to alert the public.

Posted on November 17, 2006 at 7:31 AMView Comments

Skimming RFID Credit Cards

It’s easy to skim personal information off an RFID credit card.

From The New York Times:

They could skim and store the information from a card with a device the size of a couple of paperback books, which they cobbled together from readily available computer and radio components for $150. They say they could probably make another one even smaller and cheaper: about the size of a pack of gum for less than $50. And because the cards can be read even through a wallet or an item of clothing, the security of the information, the researchers say, is startlingly weak. ‘Would you be comfortable wearing your name, your credit card number and your card expiration date on your T-shirt?’ Mr. Heydt-Benjamin, a graduate student, asked.

And from The Register:

The attack uses off-the-shelf radio and card reader equipment that could cost as little as $150. Although the attack fails to yield verification codes normally needed to make online purchases, it would still be potentially possible for crooks to use the data to order goods and services from online stores that don’t request this information.

Despite assurances by the issuing companies that data contained on RFID-based credit cards would be encrypted, the researchers found that the majority of cards they tested did not use encryption or other data protection technology.

And from the RFID Journal:

I don’t think the exposing of potential vulnerabilities of these cards is a huge black eye for the credit-card industry or for the RFID industry. Millions of people won’t suddenly have their credit-card numbers exposed to thieves the way they do when someone hacks a bank’s database or an employee loses a laptop with the card numbers on it. But it is likely that these vulnerabilities will need to be addressed as the technology becomes more mature and criminals start figuring out ways to abuse it.

Posted on November 7, 2006 at 12:49 PMView Comments

Seagate Encrypted Drive

Seagate has announced a product called DriveTrust, which provides hardware-based encryption on the drive itself. The technology is proprietary, but they use standard algorithms: AES and triple-DES, RSA, and SHA-1. Details on the key management are sketchy, but the system requires a pre-boot password and/or combination of biometrics to access the disk. And Seagate is working on some sort of enterprise-wide key management system to make it easier to deploy the technology company-wide.

The first target market is laptop computers. No computer manufacturer has announced support for DriveTrust yet.

More details in these articles.

Posted on November 7, 2006 at 7:04 AMView Comments

The Doghouse: SecureRF

SecureRF:

Claims to offer the first feasible security for RFIDs. Conventional public key cryptography (such as RSA) is far too computationally intensive for an RFID. SecureRF provides a similar technology at far lower footprint by harnessing a relatively obscure area of mathematics: infinite group theory, which comes (of all places) from knot theory, a branch of topology.

Their website claims to have “white papers” on the theory, but you have to give them your personal information to get it. Of course, they reference no actual published cryptography papers. “New mathematics” is my Snake-Oil Warning Sign #2—and I strongly suspect their documentation displays several other of the warning signs, too. I’d stay away from this one.

Posted on October 9, 2006 at 7:47 AMView Comments

FairUse4WM News

A couple of weeks I ago I wrote about the battle between Microsoft’s DRM system and FairUse4WM, which breaks it. The news for this week is that Microsoft has patched their security against FairUseWM 1.2 and filed a lawsuit against the program’s anonymous authors, and those same anonymous authors have released FairUse4WM 1.3, which breaks the latest Microsoft patch.

We asked Viodentia about Redmond’s accusation that he and/or his associates broke into its systems in order to obtain the IP necessary to crack PlaysForSure; Vio replied that he’s “utterly shocked” by the charge. “I didn’t use any Microsoft source code. However, I believe that this lawsuit is a fishing expedition to get identity information, which can then be used to either bring more targeted lawsuits, or to cause other trouble.” We’re sure Microsoft would like its partners and the public to think that its DRM is generally infallible and could only be cracked by stealing its IP, so Viodentia’s conclusion about its legal tactics seems pretty fair, obvious, and logical to us.

What’s interesting about this continuing saga is how different it is from the normal find-vulnerability-then-patch sequence. The authors of FairUse4WM aren’t finding bugs and figuring out how to exploit them, forcing Microsoft to patch them. This is a sequence of crack, fix, re-crack, re-fix, etc.

The reason we’re seeing this—and this is going to be the norm for DRM systems—is that DRM is fundamentally an impossible problem. Making it work at all involves tricks, and breaking DRM is akin to “fixing” the software so the tricks don’t work. Anyone looking for a demonstation that technical DRM is doomed should watch this story unfold. (If Microsoft has any chance of winning at all, it’s via the legal route.)

Posted on September 28, 2006 at 12:55 PMView Comments

Did Hezbollah Crack Israeli Secure Radio?

According to Newsday:

Hezbollah guerrillas were able to hack into Israeli radio communications during last month’s battles in south Lebanon, an intelligence breakthrough that helped them thwart Israeli tank assaults, according to Hezbollah and Lebanese officials.

Using technology most likely supplied by Iran, special Hezbollah teams monitored the constantly changing radio frequencies of Israeli troops on the ground. That gave guerrillas a picture of Israeli movements, casualty reports and supply routes. It also allowed Hezbollah anti-tank units to more effectively target advancing Israeli armor, according to the officials.

Read the article. Basically, the problem is operational error:

With frequency-hopping and encryption, most radio communications become very difficult to hack. But troops in the battlefield sometimes make mistakes in following secure radio procedures and can give an enemy a way to break into the frequency-hopping patterns. That might have happened during some battles between Israel and Hezbollah, according to the Lebanese official. Hezbollah teams likely also had sophisticated reconnaissance devices that could intercept radio signals even while they were frequency-hopping.

I agree with this comment from The Register:

Claims that Hezbollah fighters were able to use this intelligence to get some intelligence on troop movement and supply routes are plausible, at least to the layman, but ought to be treated with an appropriate degree of caution as they are substantially corroborated by anonymous sources.

But I have even more skepticism. If indeed Hezbollah was able to do this, the last thing they want is for it to appear in the press. But if Hezbollah can’t do this, then a few good disinformation stories are a good thing.

Posted on September 20, 2006 at 2:35 PMView Comments

Media Sanitization and Encryption

Last week NIST released Special Publication 800-88, Guidelines for Media Sanitization.

There is a new paragraph in this document (page 7) that was not in the draft version:

Encryption is not a generally accepted means of sanitization. The increasing power of computers decreases the time needed to crack cipher text and therefore the inability to recover the encrypted data can not be assured.

I have to admit that this doesn’t make any sense to me. If the encryption is done properly, and if the key is properly chosen, then erasing the key—and all copies—is equivalent to erasing the files. And if you’re using full-disk encryption, then erasing the key is equivalent to sanitizing the drive. For that not to be true means that the encryption program isn’t secure.

I think NIST is just confused.

Posted on September 11, 2006 at 11:43 AMView Comments

ScatterChat

ScatterChat is a secure instant messaging client. From the press release:

ScatterChat is unique in that it is intended for non-technical human rights activists and political dissidents operating behind oppressive national firewalls. It is an instant messaging client that provides end-to-end encryption over the Electronic Frontier Foundation-endorsed Tor network. Its security features include resiliency against partial compromise through perfect forward secrecy, immunity from replay attacks, and limited resistance to traffic analysis, all reinforced through a pro-actively secure design.

A nice application of Tor.

EDITED TO ADD (8/8): There are flaws in the protocol. There’s an advisory on one of them.

Posted on July 31, 2006 at 1:48 PMView Comments

1 45 46 47 48 49 53

Sidebar photo of Bruce Schneier by Joe MacInnis.