Three months ago A Splice-and-Cut Cryptanalysis of the AES was presented. This attack uses bicliques to recover the key of a reduced-round AES slightly faster than the exhaustive key search. The fact that attacks always get better; they never get worse is emphasized by the new result: Biclique Cryptanalysis of the Full AES. For example, to break all rounds of AES-128, the attack needs 2⁸⁸ data and 2^126.18 time. Although the attack is only about 3 times faster than the worst-case exhaustive search (like, finding a two-digit code after 28 computations instead of trying all 100), and thus does not pose a threat in practice, perhaps it will be a source of inspiration for more practical attacks.

Reprinted with permission from Hagai Bar-El Security blog.

Cars will soon be (almost) fully automated. News on experiments with cars that drive by themselves, in different scenarios and situations, make it seem obvious that soon enough the role of the driver is to be similar to that of a pilot in a passenger jet. Many people feel some itch of discomfort with this thought; the itch of “we are not there yet”. Let us see if and why we “are not there” yet, and what we can do about it.

Experiments are performed, and at a high level they seem to work. Therefore, as it appears, we are almost there, or at least we are on the right track, functionality-wise.

If there is an aspect from which our technology is not ready, it is that of security and reliability.

If there is an aspect from which we and our technology are not ready, it is that of security and reliability. Truth be told, today we cannot design an even simpler software application without having it suffer (at least) occasional reliability glitches. We prove over and over again that we just cannot build a sophisticated application that will just work without bugs and glitches, let alone be secure. Intuitively, bugs that we can afford in IT applications, and even in GPS applications, we cannot afford in the robot that turns the steering-wheel.

Whenever I raise this concern, I am often reminded of aviation software. A passenger jet is full of code as well, and nonetheless civil aviation is considered safe. However, there are at least three reasons why this comparison does not apply. First, I cannot back it up with any figures (if anyone does have any — please post a comment), but it is intuitive that the complexity of the car steering application is to be higher than that of a passenger jet. A passenger jet is more sophisticated of an apparatus, but it seems as the number of real-time events it needs to cope with, as well as the sophistication of their circumstances, are lower. Second, as any reader of the RISKS newsgroup can easily tell, aviation software is far from perfect. It does have its glitches, including cases of shutting the engines down during flight. Fortunately, there is still a pilot on board to handle such situations manually using human knowledge and common sense. This function will not exist in a self-driving car, even if there is someone sitting at the drivers seat. The pilot is a trained individual, operating by strict regulations, sitting in the aircraft for this purpose alone. A typical car driver in a self-driving car will soon enough drift into playing with the kids, sleeping, reading, or just daydreaming, without keeping his hands and attention on the automatic wheel that seems to behave nicely for years already. Third, cars play in a more active, competitive and ever-changing market than jets, with competition that is powered by individual retail customers demanding more features on a model-by-model basis. The Boeing 747 is with us for 40 years. Software in it may have changed, but probably not as dramatically as that of a car that the user changes every half a decade with an expectation of improvement.

There is no reason to believe that when pressed by requirements and regulation, a software provider cannot do better in this respect.

Despite all that, I am not as worried as probably expected. Means for making reasonably-secure and reasonably-reliable software exist, they are just expensive. So far, we succeeded in avoiding costly secure coding methodologies because we could afford to. Our software today breaks, not because there was no way to make it less breakable, but because there was no incentive for the provider to make it so. Simply put, the software provider pays the cost of security, but does not pay the cost of insecurity, so its preference is clear. There is still no reason to believe that when pressed by customer requirements and by regulation, a software provider cannot do better in this respect. At least as much as I can see, car makers are aware of the challenge that stands in front of them.

Will car steering software be all hundred-percent safe? Obviously not. Bugs and vulnerabilities will be found, and these might cost lives, like other failures in critical equipment; failures that we usually tolerate as long as kept within reason. This is a price we have to pay for advancing the state of the art into the unknown. Nevertheless, given all that the car industry should know and understand, and given that it comprehends what needs to be done at all costs, we may just as well be on the right track.

The 27th Chaos Communication Congress (27C3) is the annual conference organized by the Chaos Computer Club (CCC). Last year, at 26C3, researches showed a rainbow table attack on GSM’s A5/1 encryption.

A bit of history: The GSM encryption was introduced in 1987 and then it was disclosed and shown insecure in 1994. As time passes the attacks become better and better, but for some reason the GSMA prefer to claim that the attacks are not practical:

Over the past few years, a number of academic papers setting out, in theory, how the A5/1 algorithm could be compromised have been published. However, none to date [2009-12-30] have led to a practical attack capability being developed against A5/1 that can be used on live, commercial GSM networks.

[…] In 2007-8, a hacking group claimed to be building an attack on A5/1 by constructing a large look-up table1 of approximately 2 Terabytes – this is equivalent to the amount of data contained in a 20 kilometre high pile of books.

[…] All in all, we consider this research, which appears to be motivated in part by commercial considerations, to be a long way from being a practical attack on GSM. More broadly, A5/1 has proven to be a very effective and resilient privacy mechanism.

One may suspect that there is a conspiracy to keep encryption easy to crack, but after reading the hilarious comment about 20 km of books (a 2 TB hard drive costs about $100) one is forced to apply the Hanlon’s razor.

Yesterday (2010-12-28), at 27C3, researches have shown how to reduce the attacker’s budget down to a PC, cheap mobile phones, and open source software:

Now that GSM A5/1 encryption can be cracked in seconds, the complexity of wireless phone snooping moved to signal processing. Since GSM hops over a multitude of channels, a large chunk of radio spectrum needs to be analyzed, for example with USRPs, and decoded before storage or decoding. We demonstrate how this high bandwidth task can be achieved with cheap programmable phones.

Security thru obscurity does not hold for long: once it becomes easy to present a GSM air interface to standard GSM handset, insecurities in the handsets becomes easier to find. Another 27C3 lecture (SMS-o-Death) shows what one can learn about security of “feature phones”:

We show how we analyzed these type of phones for SMS security issues and what kind of problems to overcome in the process. We show results for the major mobile phone manufacturers in the world. Everyone of them has problems. Finally we show what kind of global scale attacks one can carry out with these kind of bugs. The attacks range from interrupting phone calls, to disconnecting people from the network, and sometimes even bricking phones remotely.