XML encryption standard hack

I started writing a post about the XML encryption hack, but in the course of researching the topic I came across this great post by Matthew Green on his "A Few Thoughts on Cryptographic Engineering" blog. Matthew's post covers pretty much everything I wanted to say and more - so I'll forgo my post and let you read all about it there.

Blogroll: Top security news sources

To the right (that's your right - my left) you'll see a new field - "Security RSS/Blog Roll". This is a list of security news sources I read (mostly via RSS).

Over the years I've looked for a good blogroll on security subjects that interest me. There is no lack of sources that cover standard IT security subjects like network penetration and malware. But there are much fewer sources on designing secure systems and securing devices. Since I haven't managed to find such a blogroll anywhere I've decided to create my own.

Following is a short description of these sources - the best I'm aware of.

DuQu: A Malware Rashomon*

No self-respecting security blog can ignore [insert dramatic music] ...

DuQu: Son of Stuxnet

G.E.S. original art

Doctor, is it Siri-ous?

Last week the web was full of reports of a "security hole" in Siri, Apple's new voice control mechanism for the iPhone. ZDNet went so far as to headline "Siri not so serious about security".

So what's the "security hole"? The default iPhone configuration is such that Siri is active even when the iPhone is locked with a passcode. This means that a person with access to your supposedly secure locked iPhone can, for example, send emails from your phone using Siri. It's not difficult to understand the kind of attacks that this would allow someone impersonating you, not to mention the prank potential.

HTTPS: (Sub)Standard Security pt.3

In the first post in this series on the deficiencies of standardized security systems I promised a post on "X.509 certificates". By this I intended to discuss the commonly used system for authenticating and securing communications with web sites, widely known as SSL. As SSL (or to be precise, TLS) is just one component of this system (and is also used for other purposes) I will use the term "HTTPS system", though in fact the same system is used for more than just the HTTPS protocol.

German government Trojan and collateral damage

As you may have heard, the Chaos Computing Club (CCC) reverse engineered a Trojan written by the German government for the purpose of legal wiretapping.

Though the Trojan itself is legal in Germany (as long as it's only installed according to court orders), the CCC unveiled a few embarrassing facts about the Trojan.

The list of issues is long but can be summarized by one point - the Trojan developers didn't make any significant effort to prevent other parties from utilizing the Trojan for their own purposes.

One of the reasons security systems fail is because the designers of the system focused on a single adversary and didn't consider others. In this case it's likely that the designers of this Trojan were focused on ensuring that the Trojan's targets wouldn't identify and remove the Trojan. They didn't realize that their most formidable adversaries aren't the targets but members of the hacker community who are happy for an opportunity to embarrass the government.

More importantly, since the Trojan developers' goal was to "attack" their targets, they didn't realize that at the same time they were still obligated to prevent undue damage to them.

This isn't the first time a security system failed in such a way. Perhaps the most famous case is the Sony Copy Protection rootkit (Wikipedia), which some consider to have been, when revealed, the final nail in the coffin of copy protecting music CDs.

For a security system to succeed it must not cause undue damage. Anything but the tiniest amount of collateral damage is unacceptable and is likely to bring the downfall of the system.

Following the announcement from CCC several anti-virus developers have announced that due to the collateral damage they will be treating this Trojan as malware. The German government developers will need to come up with something new - perhaps they should ask the CCC for some tips.

GSM A5/1: (Sub)Standard Security pt.2

GSM is a widely deployed standard for cellular communications, including security aspects. This post will describe one aspect of the GSM security architecture, how GSM security has been hacked and why.

The GSM standard deals with two main security concerns - payment and privacy. The first goal is to ensure that the person making a call pays for it. The second goal is to prevent unauthorized parties from accessing communications over the GSM network. This post will concentrate on the second area - privacy.

Cell phone bug?

The initial GSM standard, published in 1990, stipulates the usage of an algorithm called A5/1 for scrambling GSM voice communications. A5/1 has two important characteristics: it uses a 64-bit key and was intended to be kept secret.

Keeping an algorithm implemented by dozens of device manufacturers secret is good for as long as it lasts - which isn't very long. A5/1 remained secret for a few years, but was fairly quickly reverse engineered and was published on the Internet in 1999.

Cryptanalysts found several weaknesses in the A5/1 algorithm - but none as significant as the fact that the algorithm uses a 64-bit key.

Using a 64-bit key to encrypt data is fine as long as one of the following conditions is true:

1. You're living in the 20th century.
2. You're living in the early 21st century and the data secured by any specific key is not very valuable and there is no single known plain-text encrypted with each key