Bobulate

On Wednesday the Washington Post’s “Security Fix” blog had a small item on privacy issues with the smart grid. It was most interesting for me because of the graph that was included: by looking at a simple metric (power draw in the house) one could reach conclusions on what was happening inside. Breakfast, lunch and dinner can be spotted. This isn’t much of an issue if the data is available only to the power company, stored securely, and applied only to its intended purpose for which it is collected. Presumably that’s to optimize power delivery.

But when the information is used outside of that context, then bad things can happen.

This kind of concern applies to all kinds of metrics that indirectly show what is happening inside a closed box. Consider an active developer on software project where the source repository is available publicly. This applies to lots of them — and CIA.vc makes relevant stats for many even more public. By looking at time stamps you can find out roughly when the developer is active. How accurate this is depends on the style of development, but I know I’m a commit-early, commit-often guy so you can (or used to be able to) find out when I’m awake by watching commits. No commits? I must be elsewhere. Commits skewed by three hours? I must be in Brasil, hacking.

Even that information isn’t all that bad, although it’s a derived piece of information that possibly wasn’t intended to be public. But you can use it for nefarious purposes (e.g. housebreaking). Power consumption of an encryption chip was once used to determine whether it was doing a multiply cycle or an add — and knowing that revealed bits of the key being used, and so extracted the key from the chip. That’s the kind of ancillary information leakage that we can also worry about.

All in all I think it comes down to: data collection technology isn’t bad per se, but the safeguards around the collected data and the purposes to which the data is put might be. Privacy then is a matter of trust in the people that hold the data to do the right thing (regrettably humans are susceptible to temptation).

Attached to LinuxWorld is the InfoSecurity trade show (or the other way around, since LW is about a fifth of the size of IS). It’s a nice opportunity to find out about networking, crypto, and other things going on in that part of the world. Security isn’t exactly my thing, although when I was running CodeYard I was located across the hall from the security research group at the University of Nijmegen — and of course I’m never without my Fellowship of FSFE GPG-card.

At the NLUUG conference last week I heard of the Yubikey — unfortunately I missed the actual talk by Henk, so I’m still a little confused as to what you can actually achieve with such a device that acts as a USB keyboard and spits out 16 fixed characters followed by 32 random ones. One-time passwords, sure, but I’m just not creative enough to come up with what to do then.

The FSFE is an enthusiastic user of GPG encryption and digital certificates (from CAcert) because we feel that Freedom and Privacy (through the use of strong encryption) go hand in hand. So I was happy to meet some folks from a company called Legid who are pushing certificates (S/MIME and otherwise) as means for digital signing, and have a hardware-software combination that uses a smartcard with a neat wifi-and-usb (?) enabled terminal to handle them. The terminal also apparently supports something that looks like OpenID, sending authentication requests and authorization requests (e.g. when trying to pass a doorway) to different parties for permission. The long term goal is to have everyone with a smartcard and a collection of personal (i.e. bound to your real identity) certificates for legally sound document signing; naturally you’ll want more certificates to handle the different online identities you have.

Going from there to the “but email clients are too difficult” end of the spectrum, I chatted with a company that does secure document silos — to which I largely responded “why on earth would I want a new, locked-down, non-interoperable web-based silo for document exchange?” This might signal a difference in workflows — I have different client apps for different activities (but because it’s KDE4 they integrate really well) and don’t see much value in having to go to a website to retrieve a document when encrypted attachments (S/MIME or otherwise) have been part of email for tupping ages. The company (DigiNotar) claims that that’s too complicated, and I suppose for people who have a web-browser based workflow anyway, that kind of makes sense. Especially if the silo combines document management with security — the idea behind the silo is partly that you can keep better logs of document access and document reading. Again, a move towards being able to say “I know you read the document, because you were logged in (with your client certificate) and downloaded the encrypted version offered by the portal and then sent back a signature on the document.”

For such a silo my concerns quickly turn to interoperability; I have a bank that communicates with me through such a closed sercure silo — or rather, it doesn’t communicate with me because their silo doesn’t work with my choices of browsers (and the one they do support doesn’t run on my hardware).

All in all, good to see work on privacy going on; in so far as it’s possible to get a good idea of what’s going on from a chat at a trade fair.

While looking to install smbclient on my laptop this morning to talk to some devices on my home network, I was pointed at a security advisory regarding SMB2. It’s about a known defect the SMB2 implementation on Windows 7 — kind of interesting to have pre-release security defects publicised already. The FSFE’s statement is here, and you can find English-language Heise coverage here.

The intermediate work-around — isolate Windows machines from the Internet with a good firewall — is good practice anyway. Do not let SMB traffic escape from your local network.