September 01, 2005
Trusted by whom?
By AJ Milne

Been reading up on 'trusted computing'. As one of the sections in the site I hadn't heard much about prior to starting up here, it's a bit of necessary.

Inevitably, I've come across the criticisms. There's The EFF's brief on the subject, and Ross Anderson's very critical FAQ. Both spend some time, naturally enough, on the thorny issue of remote attestation.

Remote attestation, for those of you as new to this space as am I, is a feature of trusted computing in which running software can be signed by a remote authority, and the signature verified by remote systems and local users. One of the obvious advantages is for DRM: if you can remotely verify that the software to which you're talking is the client you trust with the content, you can decide whether to pass the protected content to the app or not on that basis.

The trouble, as the critics above point out, is the mechanism is ripe for abuse. The now sadly rich history of certain sites insisting that a certain browser be running before they talk to it could get a lot more detailed, in years to come, if remote attestation becomes widespread. Anticompetitive practices could gain some serious potency, if you can't just tell your client 'fine, tell the server you're IE, if that's what it wants to hear', and have the mere fact that the HTTP and HTML specifications are supposed to be open standards assurance enough that you can run the software you want to run on your machine, thank you very much.

I'm sympathetic to the concern, as you can probably tell from the phrasing of the above.

I'm fond of a lot of odd software, for various reasons. And sometimes, it's about trust. I consult, I do security, I've got clients in a few different chat networks. I run the delightful open-source Gaim--a multiprotocol chat client that talks to Yahoo's network as easily as AOL's--both because of this convenience and, because, frankly, I'm not sure I trust a lot of the folks running chat networks to write software I want running on my machine. With Gaim, I get the open-source assurance--a lot of eyes, including my own, if I so desire, on the code, making sure stupid stuff and malicious stuff doesn't get running. That, I trust.

If remote attestation does, as the critics suggest it might, start preventing this sort of thing, it's not going to improve my confidence in the security of my machines. Not if it means a lot of folk who occasionally do ship some rather crufty, security-hole-ridden code, get to say what runs or does not run on my box, if I want to use certain network services (And note, that I write this about an hour after posting this bit on a portable device which came--surprise--with its own worm... factory installed.)

Hrm. Right. So are these the sorta folk who may wind up deciding what I get to trust?

Not sure I like where that's going.

Should probably fire up a forum topic on this, shouldn't I?

August 25, 2005
Firmware vulnerabilities between keyboard and chair
By AJ Milne

Interviewed one of CERT's people this morning about incident trends over the last few quarters. Story coming up in news shortly over it.

One of the trends is interesting: attacks against clients are on the increase. It's a little less about server vulnerabilities, this year, more about phishing, exploiting browser vulnerabilities, getting users to click on stuff they shouldn't, getting spyware installed, that sort of thing.

Wondering what this means for designers thinking security. Some of this, it's about social engineering, and maybe that's beyond our purview. Firmware vulnerabilities between the keyboard and the chair haven't traditionally been our thing. Or not so much directly.

Still. Interesting. Thought for the day for thinking designers: what more can be done to engineer against basic human credulousness?

August 22, 2005
Biowha?
By AJ Milne

So your humble editor has been exploring the worlds of trusted computing and biometrics, last few days. Seems there's a thought going 'round midst the powers that be at the editorial board that these are things a security site should cover.

I'm a crypto guy, mostly, most days. These things, they're new to me. So you might have to bear with us a few days, as we get up to speed, here.

Interesting stuff, tho'. Oddest thought yet out of biometrics: in some areas of the field, credential theft can be a real pain in... whatever part of the body they steal. Or steal an impression of. In systems design in biometrics, the thought often is you don't want the whole fingerprint in the system; you want to be able to verify the fingerprint scanned is the right one. Because if someone can steal the whole fingerprint from the database, somehow, that's bad news for whoever owns those fingerprints. Identity theft when you can't just call the credit card company and ask for new fingerprints, it's trouble.

August 14, 2005
Welcome to the Security DesignLine
By AJ Milne

Welcome to the security design line blog. I'm your editor, AJ Milne.

It's been an interesting few years in network security. On the commercial side, we've seen large E-commerce servers compromised for their credit card data. In standards, there's the slow and steady migration to longer keys and more demanding algorithms, as Moore's law keeps the pressure on. On the theoretical side, we've seen advances toward finding collisions in such ubiquitous hash functions as MD5 and the members of the SHA family.

Never a dull moment, really. So, I'm looking forward to doing my bit to help you keep it up with it all.

In the blog you're reading now, I'll be doing less formal pieces—reflections on recent news, ill-advised gut reactions to wild rumors, that kind of thing.

So welcome aboard, and hang on. Should be a lively ride.