Entries Tagged "protocols"

Page 2 of 2

Breaking Diffie-Hellman with Massive Precomputation (Again)

The Internet is abuzz with this blog post and paper, speculating that the NSA is breaking the Diffie-Hellman key-exchange protocol in the wild through massive precomputation.

I wrote about this at length in May when this paper was first made public. (The reason it’s news again is that the paper was just presented at the ACM Computer and Communications Security conference.)

What’s newly being talked about his how this works inside the NSA surveillance architecture. Nicholas Weaver explains:

To decrypt IPsec, a large number of wiretaps monitor for IKE (Internet Key Exchange) handshakes, the protocol that sets up a new IPsec encrypted connection. The handshakes are forwarded to a decryption oracle, a black box system that performs the magic. While this happens, the wiretaps also record all traffic in the associated IPsec connections.

After a period of time, this oracle either returns the private keys or says “i give up”. If the oracle provides the keys, the wiretap decrypts all the stored traffic and continues to decrypt the connection going forward.


This would also better match the security implications: just the fact that the NSA can decrypt a particular flow is a critical secret. Forwarding a small number of potentially-crackable flows to a central point better matches what is needed to maintain such secrecy.

Thus by performing the decryption in bulk at the wiretaps, complete with hardware acceleration to keep up with the number of encrypted streams, this architecture directly implies that the NSA can break a massive amount of IPsec traffic, a degree of success which implies a cryptanalysis breakthrough.

That last paragraph is Weaver explaining how this attack matches the NSA rhetoric about capabilities in some of their secret documents.

Now that this is out, I’m sure there are a lot of really upset people inside the NSA.

EDITED TO ADD (11/15): How to protect yourself.

Posted on October 16, 2015 at 6:19 AMView Comments

SS7 Vulnerabilities

There are security vulnerabilities in the phone-call routing protocol called SS7.

The flaws discovered by the German researchers are actually functions built into SS7 for other purposes — such as keeping calls connected as users speed down highways, switching from cell tower to cell tower — that hackers can repurpose for surveillance because of the lax security on the network.

Those skilled at the myriad functions built into SS7 can locate callers anywhere in the world, listen to calls as they happen or record hundreds of encrypted calls and texts at a time for later decryption. There also is potential to defraud users and cellular carriers by using SS7 functions, the researchers say.

Some details:

The German researchers found two distinct ways to eavesdrop on calls using SS7 technology. In the first, commands sent over SS7 could be used to hijack a cell phone’s “forwarding” function — a service offered by many carriers. Hackers would redirect calls to themselves, for listening or recording, and then onward to the intended recipient of a call. Once that system was in place, the hackers could eavesdrop on all incoming and outgoing calls indefinitely, from anywhere in the world.

The second technique requires physical proximity but could be deployed on a much wider scale. Hackers would use radio antennas to collect all the calls and texts passing through the airwaves in an area. For calls or texts transmitted using strong encryption, such as is commonly used for advanced 3G connections, hackers could request through SS7 that each caller’s carrier release a temporary encryption key to unlock the communication after it has been recorded.

We’ll learn more when the researchers present their results.

Posted on December 19, 2014 at 6:41 AMView Comments

The Security of the Fortuna PRNG

Providing random numbers on computers can be very difficult. Back in 2003, Niels Ferguson and I designed Fortuna as a secure PRNG. Particularly important is how it collects entropy from various processes on the computer and mixes them all together.

While Fortuna is widely used, there hadn’t been any real analysis of the system. This has now changed. A new paper by Yevgeniy Dodis, Adi Shamir, Noah Stephens-Davidowitz, and Daniel Wichs provides some theoretical modeling for entropy collection and PRNG. They analyze Fortuna and find it good but not optimal, and then provide their own optimal system.

Excellent, and long-needed, research.

Posted on March 11, 2014 at 6:28 AMView Comments

Dispute Resolution Systems for Security Protocols

Interesting paper by Steven J. Murdoch and Ross Anderson in this year’s Financial Cryptography conference: “Security Protocols and Evidence: Where Many Payment Systems Fail.”

Abstract: As security protocols are used to authenticate more transactions, they end up being relied on in legal proceedings. Designers often fail to anticipate this. Here we show how the EMV protocol — the dominant card payment system worldwide — does not produce adequate evidence for resolving disputes. We propose five principles for designing systems to produce robust evidence. We apply these to other systems such as Bitcoin, electronic banking and phone payment apps. We finally propose specific modifications to EMV that could allow disputes to be resolved more efficiently and fairly.

Ross Anderson has a blog post on the paper.

Posted on February 6, 2014 at 6:05 AMView Comments

Multiple Protocol Attacks

In 1997, I wrote about something called a chosen-protocol attack, where an attacker can use one protocol to break another. Here’s an example of the same thing in the real world: two different parking garages that mask different digits of credit cards on their receipts. Find two from the same car, and you can reconstruct the entire number.

I have to admit this puzzles me, because I thought there was a standard for masking credit card numbers. I only ever see all digits except the final four masked.

Posted on December 20, 2011 at 6:24 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.