Entries Tagged “cryptography”
Page 22 of 44
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.
Yesterday, NIST announced the five hash functions to advance to the third (and final) round in the SHA-3 selection process: BLAKE, Grøstl, JH, Keccak, and Skein. Not really a surprise; my predictions -- which I did not publish -- listed ECHO instead of JH, but correctly identified the other four. (Most of the predictions I saw guessed BLAKE, Grøstl, Keccak, and Skein, but differed on the fifth.)
NIST will publish a report that explains its rationale for selecting the five it did.
Next is the Third SHA-3 Candidate Conference, which will probably be held in March 2012 in Washington, DC, in conjunction with FSE 2012. NIST will then pick a single algorithm to become SHA-3.
More information about Skein and the SHA-3 selection process, including lots of links, is here. Version 1.3 of the Skein paper, which discusses the new constant to defeat the Khovratovich-Nikolié-Rechberger attack, is here (description of the tweak here). And there's this new analysis of Skein.
And if you ordered a Skein polo shirt in September, they've been shipped.
Interesting story of the withdrawal of the A5/2 encryption algorithm from GSM phones.
I think that's where my collection will be going, too.
Talk #1: "The Art of Forensic Warfare," Andy Clark. Riffing on Sun Tzu's The Art of War, Clark discussed the war -- the back and forth -- between cyber attackers and cyber forensics. This isn't to say that we're at war, but today's attacker tactics are increasingly sophisticated and warlike. Additionally, the pace is greater, the scale of impact is greater, and the subjects of attack are broader. To defend ourselves, we need to be equally sophisticated and -- possibly -- more warlike.
Clark drew parallels from some of the chapters of Sun Tzu's book combined with examples of the work at Bletchley Park. Laying plans: when faced with an attacker -- especially one of unknown capabilities, tactics, and motives -- it's important to both plan ahead and plan for the unexpected. Attack by stratagem: increasingly, attackers are employing complex and long-term strategies; defenders need to do the same. Energy: attacks increasingly start off simple and get more complex over time; while it's easier to defect primary attacks, secondary techniques tend to be more subtle and harder to detect. Terrain: modern attacks take place across a very broad range of terrain, including hardware, OSs, networks, communication protocols, and applications. The business environment under attack is another example of terrain, equally complex. The use of spies: not only human spies, but also keyloggers and other embedded eavesdropping malware. There's a great World War II double-agent story about Eddie Chapman, codenamed ZIGZAG.
Talk #2: "How the Allies Suppressed the Second Greatest Secret of World War II," David Kahn. This talk is from Kahn's article of the same name, published in the Oct 2010 issue of The Journal of Military History. The greatest secret of World War II was the atom bomb; the second greatest secret was that the Allies were reading the German codes. But while there was a lot of public information in the years after World War II about Japanese codebreaking and its value, there was almost nothing about German codebreaking. Kahn discussed how this information was suppressed, and how historians writing World War II histories never figured it out. No one imagined as large and complex an operation as Bletchley Park; it was the first time in history that something like this had ever happened. Most of Kahn's time was spent in a very interesting Q&A about the history of Bletchley Park and World War II codebreaking.
Talk #3: "DNSSec, A System for Improving Security of the Internet Domain Name System," Whitfield Diffie. Whit talked about three watersheds in modern communications security. The first was the invention of the radio. Pre-radio, the most common communications security device was the code book. This was no longer enough when radio caused the amount of communications to explode. In response, inventors took the research in Vigenère ciphers and automated them. This automation led to an explosion of designs and an enormous increase in complexity -- and the rise of modern cryptography.
The second watershed was shared computing. Before the 1960s, the security of computers was the physical security of computer rooms. Timesharing changed that. The result was computer security, a much harder problem than cryptography. Computer security is primarily the problem of writing good code. But writing good code is hard and expensive, so functional computer security is primarily the problem of dealing with code that isn't good. Networking -- and the Internet -- isn't just an expansion of computing capacity. The real difference is how cheap it is to set up communications connections. Setting up these connections requires naming: both IP addresses and domain names. Security, of course, is essential for this all to work; DNSSec is a critical part of that.
The third watershed is cloud computing, or whatever you want to call the general trend of outsourcing computation. Google is a good example. Every organization uses Google search all the time, which probably makes it the most valuable intelligence stream on the planet. How can you protect yourself? You can't, just as you can't whenever you hand over your data for storage or processing -- you just have to trust your outsourcer. There are two solutions. The first is legal: an enforceable contract that protects you and your data. The second is technical, but mostly theoretical: homomorphic encryption that allows you to outsource computation of data without having to trust that outsourcer.
Diffie's final point is that we're entering an era of unprecedented surveillance possibilities. It doesn't matter if people encrypt their communications, or if they encrypt their data in storage. As long as they have to give their data to other people for processing, it will be possible to eavesdrop on. Of course the methods will change, but the result will be an enormous trove of information about everybody.
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.
EDITED TO ADD (9/28): There's a patch.
Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft's software trusts more than 100 private and government institutions.
Disturbingly, some of these trusted certificate authorities have decided to delegate their powers to yet more organizations, which aren't tracked or audited by browser companies. By scouring the Net for certificates, security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motorsand a UAE mobile phone company called Etisalat.
In 2005, a company called CyberTrust—which has since been purchased by Verizon—gave Etisalat, the government-connected mobile company in the UAE, the right to verify that a site is valid. Here's why this is trouble: Since browsers now automatically trust Etisalat to confirm a site's identity, the company has the potential ability to fake a secure connection to any site Etisalat subscribers might visit using a man-in-the-middle scheme.
EDITED TO ADD (9/14): EFF has gotten involved.
Quantum cryptography is often touted as being perfectly secure. It is based on the principle that you cannot make measurements of a quantum system without disturbing it. So, in theory, it is impossible for an eavesdropper to intercept a quantum encryption key without disrupting it in a noticeable way, triggering alarm bells.
Vadim Makarov at the Norwegian University of Science and Technology in Trondheim and his colleagues have now cracked it. "Our hack gave 100% knowledge of the key, with zero disturbance to the system," he says.
The cunning part is that while blinded, Bob's detector cannot function as a 'quantum detector' that distinguishes between different quantum states of incoming light. However, it does still work as a 'classical detector' recording a bit value of 1 if it is hit by an additional bright light pulse, regardless of the quantum properties of that pulse.
That means that every time Eve intercepts a bit value of 1 from Alice, she can send a bright pulse to Bob, so that he also receives the correct signal, and is entirely unaware that his detector has been sabotaged. There is no mismatch between Eve and Bob's readings because Eve sends Bob a classical signal, not a quantum one. As quantum cryptographic rules no longer apply, no alarm bells are triggered, says Makarov.
"We have exploited a purely technological loophole that turns a quantum cryptographic system into a classical system, without anyone noticing," says Makarov.
Makarov and his team have demonstrated that the hack works on two commercially available systems: one sold by ID Quantique (IDQ), based in Geneva, Switzerland, and one by MagiQ Technologies, based in Boston, Massachusetts. "Once I had the systems in the lab, it took only about two months to develop a working hack," says Makarov.
Just because something is secure in theory doesn't mean it's secure in practice. Or, to put it more cleverly: in theory, theory and practice are the same; but in practice, they're very different.
The paper is here.
As part of NIST's SHA-3 selection process, people have been implementing the candidate hash functions on a variety of hardware and software platforms. Our team has implemented Skein in Intel's 32 nm ASIC process, and got some impressive performance results (presentation and paper). Several other groups have implemented Skein in FPGA and ASIC, and have seen significantly poorer performance. We need help understanding why.
For example, a group led by Brian Baldwin at the Claude Shannon Institute for Discrete Mathematics, Coding and Cryptography implemented all the second-round candidates in FPGA (presentation and paper). Skein performance was terrible, but when they checked their code, they found an error. Their corrected performance comparison (presentation and paper) has Skein performing much better and in the top ten.
We suspect that the adders in all the designs may not be properly optimized, although there may be other performance issues. If we can at least identify (or possibly even fix) the slowdowns in the design, it would be very helpful, both for our understanding and for Skein's hardware profile. Even if we find that the designs are properly optimized, that would also be good to know.
A group at George Mason University led by Kris Gaj implemented all the second-round candidates in FPGA (presentation, paper, and much longer paper). Skein had the worst performance of any of the implementations. We're looking for someone who can help us understand the design, and determine if it can be improved.
Another group, led by Stefan Tillich at University of Bristol, implemented all the candidates in 180 nm custom ASIC (presentation and paper). Here, Skein is one of the worst performers. We're looking for someone who can help us understand what this group did.
Three other groups -- one led by Patrick Schaumont of Virginia Tech (presentation and paper), another led by Shin'ichiro Matsuo at National Institute of Information and Communications Technology in Japan (presentation and paper), and a third led by Luca Henzen at ETH Zurich (paper with appendix, and conference version) -- implemented the SHA-3 candidates. Again, we need help understanding how their Skein performance numbers are so different from ours.
We're looking for people with FPGA and ASIC skills to work with the Skein team. We don't have money to pay anyone; co-authorship on a paper (and a Skein polo shirt) is our primary reward. Please send me e-mail if you're interested.
Photo of Bruce Schneier by Per Ervland.
Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.