On the road to Bandol

The recent DNS vulnerability has prompted Bruce Schneier to write an essay on the fight against vulnerabilities, and the fact that good design also means defending against unknown vulnerabilities, which concludes by:

That’s what a good design looks like. It’s not just secure against known attacks; it’s also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards … everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

My day job has led me to look in great details at many smart card implementations, and most smart card software designers do a great job against known vulnerabilities. They are quite numerous, like DPA, fault induction, and a few more.

Part of our evaluation work consists in performing source code reviews, and in performing intensive functional testing. We sometimes uncover vulnerabilities, but in most cases we don’t. The mostly identify potential vulnerabilities, that can only cause trouble if an attack that goes beyond the state-of-the-art is performed. For instance, a typical case is to identify a poor data integrity protection on a chip that resisted to all known fault induction attacks. Fixing such a bug seems useless, but new ways of inducing faults are invited every year: laser last year, radioactivity next year, and some unknown stuff the year after.

The bad news is that most developers don’t like the fact that we signal future vulnerabilities when they have size and performance issues to deal with urgently; the only they will do immediately about these attacks is explaining how unlikely they are. The good news is that the same developers don’t like to leave vulnerabilities behind, especially if they can’t say that they weren’t aware; eventually, they will fix the issue.

In the end, Bruce is right: smart cards are like Internet, but with two differences: attacks usually remain confidential (not always, NXP knows that); and smart card hardware and software designers are regularly confronted to customers with high security demands, evaluators of all kinds, and an entire ecosystem that feeds on security issues. We’re just developers, just a bit more secure.