Entries Tagged "keys"

Page 12 of 15

Giving Out Replacement Hotel Keys

It’s a tough security trade-off. Guests lose their hotel room keys, and the hotel staff needs to be accommodating. But at the same time, they can’t be giving out hotel room keys to anyone claiming to have lost one. Generally, hotels ask to see some ID before giving out a replacement key and, if the guest doesn’t have his wallet with him, have someone walk to the room with the key and check their ID.

This normally works pretty well, but there’s a court case in Brisbane right now about a hotel giving a room key to someone who ended up sexually attacking the woman who had rented the room.

In civil action launched yesterday, the woman alleges the man was given the spare access key to her room by a hotel staffer.

The article doesn’t say what kind of authentication the hotel requested or received.

Posted on November 13, 2008 at 12:12 PMView Comments

Man-in-the-Middle Attacks

Last week’s dramatic rescue of 15 hostages held by the guerrilla organization FARC was the result of months of intricate deception on the part of the Colombian government. At the center was a classic man-in-the-middle attack.

In a man-in-the-middle attack, the attacker inserts himself between two communicating parties. Both believe they’re talking to each other, and the attacker can delete or modify the communications at will.

The Wall Street Journal reported how this gambit played out in Colombia:

“The plan had a chance of working because, for months, in an operation one army officer likened to a ‘broken telephone,’ military intelligence had been able to convince Ms. Betancourt’s captor, Gerardo Aguilar, a guerrilla known as ‘Cesar,’ that he was communicating with his top bosses in the guerrillas’ seven-man secretariat. Army intelligence convinced top guerrilla leaders that they were talking to Cesar. In reality, both were talking to army intelligence.”

This ploy worked because Cesar and his guerrilla bosses didn’t know one another well. They didn’t recognize one anothers’ voices, and didn’t have a friendship or shared history that could have tipped them off about the ruse. Man-in-the-middle is defeated by context, and the FARC guerrillas didn’t have any.

And that’s why man-in-the-middle, abbreviated MITM in the computer-security community, is such a problem online: Internet communication is often stripped of any context. There’s no way to recognize someone’s face. There’s no way to recognize someone’s voice. When you receive an e-mail purporting to come from a person or organization, you have no idea who actually sent it. When you visit a website, you have no idea if you’re really visiting that website. We all like to pretend that we know who we’re communicating with—and for the most part, of course, there isn’t any attacker inserting himself into our communications—but in reality, we don’t. And there are lots of hacker tools that exploit this unjustified trust, and implement MITM attacks.

Even with context, it’s still possible for MITM to fool both sides—because electronic communications are often intermittent. Imagine that one of the FARC guerrillas became suspicious about who he was talking to. So he asks a question about their shared history as a test: “What did we have for dinner that time last year?” or something like that. On the telephone, the attacker wouldn’t be able to answer quickly, so his ruse would be discovered. But e-mail conversation isn’t synchronous. The attacker could simply pass that question through to the other end of the communications, and when he got the answer back, he would be able to reply.

This is the way MITM attacks work against web-based financial systems. A bank demands authentication from the user: a password, a one-time code from a token or whatever. The attacker sitting in the middle receives the request from the bank and passes it to the user. The user responds to the attacker, who passes that response to the bank. Now the bank assumes it is talking to the legitimate user, and the attacker is free to send transactions directly to the bank. This kind of attack completely bypasses any two-factor authentication mechanisms, and is becoming a more popular identity-theft tactic.

There are cryptographic solutions to MITM attacks, and there are secure web protocols that implement them. Many of them require shared secrets, though, making them useful only in situations where people already know and trust one another.

The NSA-designed STU-III and STE secure telephones solve the MITM problem by embedding the identity of each phone together with its key. (The NSA creates all keys and is trusted by everyone, so this works.) When two phones talk to each other securely, they exchange keys and display the other phone’s identity on a screen. Because the phone is in a secure location, the user now knows who he is talking to, and if the phone displays another organization—as it would if there were a MITM attack in progress—he should hang up.

Zfone, a secure VoIP system, protects against MITM attacks with a short authentication string. After two Zfone terminals exchange keys, both computers display a four-character string. The users are supposed to manually verify that both strings are the same—”my screen says 5C19; what does yours say?”—to ensure that the phones are communicating directly with each other and not with an MITM. The AT&T TSD-3600 worked similarly.

This sort of protection is embedded in SSL, although no one uses it. As it is normally used, SSL provides an encrypted communications link to whoever is at the other end: bank and phishing site alike. And the better phishing sites create valid SSL connections, so as to more effectively fool users. But if the user wanted to, he could manually check the SSL certificate to see if it was issued to “National Bank of Trustworthiness” or “Two Guys With a Computer in Nigeria.”

No one does, though, because you have to both remember and be willing to do the work. (The browsers could make this easier if they wanted to, but they don’t seem to want to.) In the real world, you can easily tell a branch of your bank from a money changer on a street corner. But on the internet, a phishing site can be easily made to look like your bank’s legitimate website. Any method of telling the two apart takes work. And that’s the first step to fooling you with a MITM attack.

Man-in-the-middle isn’t new, and it doesn’t have to be technological. But the internet makes the attacks easier and more powerful, and that’s not going to change anytime soon.

This essay originally appeared on Wired.com.

Posted on July 15, 2008 at 6:47 AMView Comments

Kaspersky Labs Trying to Crack 1024-bit RSA

I can’t figure this story out. Kaspersky Lab is launching an international distributed effort to crack a 1024-bit RSA key used by the Gpcode Virus. From their website:

We estimate it would take around 15 million modern computers, running for about a year, to crack such a key.

What are they smoking at Kaspersky? We’ve never factored a 1024-bit number—at least, not outside any secret government agency—and it’s likely to require a lot more than 15 million computer years of work. The current factoring record is a 1023-bit number, but it was a special number that’s easier to factor than a product-of-two-primes number used in RSA. Breaking that Gpcode key will take a lot more mathematical prowess than you can reasonably expect to find by asking nicely on the Internet. You’ve got to understand the current best mathematical and computational optimizations of the Number Field Sieve, and cleverly distribute the parts that can be distributed. You can’t just post the products and hope for the best.

Is this just a way for Kaspersky to generate itself some nice press, or are they confused in Moscow?

EDITED TO ADD (6/15): Kaspersky <a href=http://www.securityfocus.com/news/11523″>now says:

The company clarified, however, that it’s more interested in getting help in finding flaws in the encryption implementation.

“We are not trying to crack the key,” Roel Schouwenberg, senior antivirus researcher with Kaspersky Lab, told SecurityFocus. “We want to see collectively whether there are implementation errors, so we can do what we did with previous versions and find a mistake to help us find the key.”

Schouwenberg agrees that, if no implementation flaw is found, searching for the decryption key using brute-force computing power is unlikely to work.

“Clarified” is overly kind. There was nothing confusing about Kaspersky’s post that needed clarification, and what they’re saying now completely contradicts what they did post. Seems to me like they’re trying to pretend it never happened.

EDITED TO ADD (6/30): A Kaspersky virus analyst comments on this entry.

Posted on June 12, 2008 at 12:30 PMView Comments

KeeLoq Still Broken

That’s the key entry system used by Chrysler, Daewoo, Fiat, General Motors, Honda, Toyota, Lexus, Volvo, Volkswagen, Jaguar, and probably others. It’s broken:

The KeeLoq encryption algorithm is widely used for security relevant applications, e.g., in the form of passive Radio Frequency Identification (RFID) transponders for car immobilizers and in various access control and Remote Keyless Entry (RKE) systems, e.g., for opening car doors and garage doors.

We present the first successful DPA (Differential Power Analysis) attacks on numerous commercially available products employing KeeLoq. These so-called side-channel attacks are based on measuring and evaluating the power consumption of a KeeLoq device during its operation. Using our techniques, an attacker can reveal not only the secret key of remote controls in less than one hour, but also the manufacturer key of the corresponding receivers in less than one day. Knowing the manufacturer key allows for creating an arbitrary number of valid new keys and generating new remote controls.

We further propose a new eavesdropping attack for which monitoring of two ciphertexts, sent from a remote control employing KeeLoq code hopping (car key, garage door opener, etc.), is sufficient to recover the device key of the remote control. Hence, using the methods described by us, an attacker can clone a remote control from a distance and gain access to a target that is protected by the claimed to be “highly secure” KeeLoq algorithm.

We consider our attacks to be of serious practical interest, as commercial KeeLoq access control systems can be overcome with modest effort.

I’ve written about this before, but the above link has much better data.

EDITED TO ADD (4/4): A good article.

Posted on April 4, 2008 at 6:03 AMView Comments

Animal Rights Activists Forced to Hand Over Encryption Keys

In the UK:

In early November about 30 animal rights activists are understood to have received letters from the Crown Prosecution Service in Hampshire inviting them to provide passwords that will decrypt material held on seized computers.

The letter is the first stage of a process set out under RIPA which governs how the authorities handle requests to examine encrypted material.

Once a request has been issued the authorities can then issue what is known as a Section 49 notice demanding that a person turn the data into an “intelligible” form or, under Section 51 hand over keys.

Although much of RIPA came into force many years ago, the part governing the handing over of keys only passed in to law on 1 October 2007. This is why the CPS is only now asking for access to files on the seized machines.

Alongside a S49 notice, the authorities can also issue a Section 54 notice that prevents a person revealing that they are subject to this part of RIPA.

Actually, we don’t know if the activists actually handed the police their encryption keys yet. More about the law here.

If you remember, this was sold to the public as essential for fighting terrorism. It’s already being misused.

Posted on November 28, 2007 at 12:12 PMView Comments

British Nuclear Security Kind of Slipshod

No two-person control or complicated safety features: until 1998, you could arm British nukes with a bicycle lock key.

To arm the weapons you just open a panel held by two captive screws—like a battery cover on a radio—using a thumbnail or a coin.

Inside are the arming switch and a series of dials which you can turn with an Allen key to select high yield or low yield, air burst or groundburst and other parameters.

The Bomb is actually armed by inserting a bicycle lock key into the arming switch and turning it through 90 degrees. There is no code which needs to be entered or dual key system to prevent a rogue individual from arming the Bomb.

Certainly most of the security was procedural. But still….

Posted on November 21, 2007 at 12:50 PMView Comments

UK Police Can Now Demand Encryption Keys

Under a new law that went into effect this month, it is now a crime to refuse to turn a decryption key over to the police.

I’m not sure of the point of this law. Certainly it will have the effect of spooking businesses, who now have to worry about the police demanding their encryption keys and exposing their entire operations.

Cambridge University security expert Richard Clayton said in May of 2006 that such laws would only encourage businesses to house their cryptography operations out of the reach of UK investigators, potentially harming the country’s economy. “The controversy here [lies in] seizing keys, not in forcing people to decrypt. The power to seize encryption keys is spooking big business,” Clayton said.

“The notion that international bankers would be wary of bringing master keys into UK if they could be seized as part of legitimate police operations, or by a corrupt chief constable, has quite a lot of traction,” he added. “With the appropriate paperwork, keys can be seized. If you’re an international banker you’ll plonk your headquarters in Zurich.”

But if you’re guilty of something that can only be proved by the decrypted data, you might be better off refusing to divulge the key (and facing the maximum five-year penalty the statue provides) instead of being convicted for whatever more serious charge you’re actually guilty of.

I think this is just another skirmish in the “war on encryption” that has been going on for the past fifteen years. (Anyone remember the Clipper chip?) The police have long maintained that encryption is an insurmountable obstacle to law and order:

The Home Office has steadfastly proclaimed that the law is aimed at catching terrorists, pedophiles, and hardened criminals—all parties which the UK government contents are rather adept at using encryption to cover up their activities.

We heard the same thing from FBI Director Louis Freeh in 1993. I called them “The Four Horsemen of the Information Apocalypse“—terrorists, drug dealers, kidnappers, and child pornographers—and have been used to justify all sorts of new police powers.

Posted on October 11, 2007 at 6:40 AMView Comments

Florida E-Voting Study

Florida just recently released another study of the Diebold voting
machines. They—and it was real security researchers like the California study, and not posers—studied v4.6.5 of the Diebold TSx and v1.96.8 of the Diebold Optical Scan. (California studied older versions (v4.6.4 of the TSx and v1.96.6 of the Optical Scan).

The most interesting issues are (1) Diebold’s apparent “find- then-patch” approach to computer security, and (2) Diebold’s lousy use of cryptography.

Among the findings:

  • Section 3.5. They use RSA signatures, apparently to address previously documented flaws in the literature. But their signature verification step has a problem. It computes H = signature**3 mod N, and then compares _only 160 bits of H_ with the SHA1 hash of a message. This is a natural way to implement RSA signatures if you just read a security textbook. But this approach is also insecure—the report demonstrates how to create a 250-line Java program to forge RSA signatures over (basically) arbitrary messages of their choosing.
  • Section 3.10.3. The original Hopkins report talked about the lack of crypto for network (or dialup) communications between a TSX voting machine and the back-end GEMs server. Apparently, Diebold tried to use SSL to fix the problem. The RABA report analyzed Diebold’s SSL usage and found a security problem. Diebold then tried to patch their SSL implementation. This new report looks at the patched version, and finds that it is still vulnerable to a man-in-the-middle attack.
  • Section 3.7.1.1. Key management. Avi Rubin has already summarized some of the highlights.

    This is arguably worse than having a fixed static key in all of the machines. Because with knowledge of the machine’s serial number, anyone can calculate all of the secret keys. Whereas before, someone would have needed access to the source code or the binary in the machine.

    Other attacks mentioned in the report include swapping two candidate vote counters and many other vote switching attacks. The supervisor PIN is protected with weak cryptography, and once again Diebold has shown that they do not have even a basic understanding of how to apply cryptographic mechanisms.

Avi Rubin has a nice overall summary, too:

So, Diebold is doing some things better than they did before when they had absolutely no security, but they have yet to do them right. Anyone taking any of our cryptography classes at Johns Hopkins, for example, would do a better job applying cryptography. If you read the SAIT report, this theme repeats throughout.

Right. These are classic examples of problems that can arise if (1) you “roll your own” crypto and/or (2) employ “find and patch” rather than a principled approach to security.

It all makes me wonder what new problems will arise from future security patches.

The good news is that Florida has decided not to certify the TSX at this time. They may try to certify a revised version of the OS (optical scan) system.

Posted on August 6, 2007 at 6:34 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.