Le weblog entièrement nu

Comme précédemment, c'est pas pour moi c'est pour des potes, Magali et Antoine, qui se sont mariés dans les Hautes-Alpes fin août. Ça s'est bien passé, il a fait très beau, et je ne vous en parle que parce que j'avais été bombardé photographe officiel. Mes impressions sont sensiblement les mêmes que la première fois (sauf que cette fois j'avais prévu les cartes mémoire en quantité suffisante), donc je ne vais pas les répéter. Suivez le lien.

L'autre lien à suivre, pour ceux que ça intéresse, c'est celui de ma sélection director's cut. 200 photos, pas toutes de moi. On notera au passage certaines prises par un Leica M9, que ça frime devant les photographes mais qu'au final ça fait pas toujours la mise au point au bon endroit, et que souvent ça vignette en plus. Je ricane doucement, avec mon bête Canon 400D qui coûte 20 fois moins cher.

Bref. Ça fait deux mariages, et la question se pose : où et quand sera le troisième ? Je ne sais pas le dire précisément, mais j'en profite pour faire un peu de pub-copinage : mon pote Xavier (oui, le même) s'est récemment mis à son compte en tant que photographe. Son site web ne parle que de mariages, de portraits et de ce genre de choses convenues, mais je pense que si vous avez besoin d'un reportage photo au bout du monde il se laissera convaincre sans trop de difficultés. Et puis bon, il est Normand, donc habitué à travailler dans des conditions de luminosité difficiles (non c'est pas vrai, il fait toujours beau en Normandie). Allez donc voir son site, et faites-lui faire des affaires. J'ai pas d'actions, mais peut-être que s'il s'achète du matériel encore plus moderne il me revendra l'actuel à un prix dérisoire, et ça peut éventuellement m'intéresser.

You have a computer. You're afraid of it being stolen by baddies or raided by the police, so you've encrypted its hard disk with LUKS. You also want to carry around some of your crypto keys (SSH and/or GPG), or any kind of sensitive data, on an USB key, so you can restore a normal activity in case the computer gets stolen or becomes untrustworthy. You like things that Just Work, including automounting with autofs (no GUI popups, no need to manually unmount and so on). But of course, you can't very well just mount the drive and store your keys on it in the clear. Well, actually you can (I did it for way too long), but let's assume you want to do without. Because USB keys get stolen or lost, too.

autofs just handles the mounting of the drives, not their unlocking, and there's no hook in there specifically for LUKS. There is, however, a more generic way of running arbitrary commands on mounting: the program maps. It's all described in the documentation, so I'll just paste the relevant parts of my /etc/auto.removable, with a few comments. Remember to make it executable and reference it in /etc/auto.master.

 #! /bin/sh

 volume=$1

 autoluks () {
     dev=/dev/$1
     cryptname=${1}_crypt
     cryptdev=/dev/mapper/$cryptname
     keyfile=/etc/private/$cryptname.key
     options=$2

     [ ! -e $dev ] && exit 0
     if [ -b $cryptdev ] && ! cryptsetup status $cryptname | grep -q device:.*$dev ; then
         cryptsetup remove $cryptname | logger
     fi
     cryptsetup --key-file $keyfile luksOpen $dev $cryptname | logger
     [ -b $cryptdev ] && echo $options :$cryptdev || true
 }

 case "$volume" in
     # LUKS-encrypted volumes
     lacie-keys)
         autoluks lacie-keys -fstype=ext4,ro,noatime,nodev,noexec,nosuid
         ;;
     lacie-keys-rw)
         autoluks lacie-keys -fstype=ext4
         ;;
     lacie-backups)
         autoluks lacie-backups -fstype=ext4
         ;;

     # Non-encrypted volumes
     cd)
         echo -fstype=iso9660,ro,nodev,nosuid            :/dev/cdrom
         ;;
     floppy)
         echo -fstype=auto,sync,nodev,nosuid             :/dev/fd0
         ;;
 esac

The astute reader will have noticed that the “keys” volume is mounted either read-only or read-write with the same mechanism. This volume contains SSH keys that I use quite regularly, that filesystem is going to be mounted and unmounted very often. USB keys, and flash memory in general, don't really like repeated writes. Fortunately, the SSH keys are mostly read, and very rarely written to, so I can afford to mount the partition read-only and save the write cycles for when I generate new keys (the mere action of mounting a partition read-write changes it, even if the files in it are never modified). The “backups” volume is mostly accessed in write mode, and much less frequently anyway, so there's no need for a distinction there.

This supposes that the partitions on the USB key appear as /dev/lacie-keys and /dev/lacie-backups. Due to the dynamic naming of devices, you may like to use rules similar to the following in /etc/udev/rules.d/local.

 KERNEL=="sd[a-z]1", ATTRS{idProduct}=="1027", ATTRS{idVendor}=="059f", ATTRS{manufacturer}=="LaCie", ATTRS{product}=="LaCie iamaKey", SYMLINK+="lacie-keys"
 KERNEL=="sd[a-z]2", ATTRS{idProduct}=="1027", ATTRS{idVendor}=="059f", ATTRS{manufacturer}=="LaCie", ATTRS{product}=="LaCie iamaKey", SYMLINK+="lacie-backups"

You'll also need to initialize LUKS on the partitions, save the key, make the filesystems, and so on. If you're still with me, you probably know what I'm talking about, then I don't need to explain about that.

This setup works for me, but there's no guarantee and so on. Based on a tutorial found on the Debian Administration website (great resource, by the way).

Update: I'm told a large part of the script could be replaced with pmount. If you like short scripts, you may want to investigate that too.

Update 2: Josselin points out a different solution using Gnome, udisks, gnome-disk-utility and Nautilus. It's worth checking out, for those who like to run all that and click around. I can't test it right now (Gnome/Nautilus currently refuses to mount any USB key, for some presumably transitional reason), but I have no reason to believe it's inherently broken. I just don't like having to do anything when I plug my key or before I unplug it, and I'm not always running a graphical session with a desktop.

For some time, I've had this idea brewing for how the 'net would work without DNS. Initially I was mostly thinking of how to get rid of the dark side of the registrar business, but it appears that maybe it could help with security in general too. It may not be feasible at all, or I may have forgotten extremely crucial points. I'm not a DNS guru, so bear with me and consider this as a thought experiment. This is, however, a proposal for how the Internet could be made truly decentralized, or acentric. Made so, because it currently is very centralized on at least two counts: the DNS is an inherently hierarchical structure of authority; and so is the situation with the SSL certificates used for “securing” websites. Let's start with DNS, if you will.

Basically, the idea is to replace the current Domain Name System, which is centralised in nature (even if subdomains can be delegated) with a fully decentralised system with no central authority.

The point of current DNS is to map names to IP addresses in a unique way. It currently works by registering a “this name is managed by such-and-such server, ask for details at such-and-such IP address” message. Of course, since there's only one namespace (or a limited number thereof, if you consider that TLDs are different namespaces), there needs to be a central authority to resolve conflicts, because some names will be more popular than others.

I propose to start with a cryptographic key pair (think GPG key). Anyone can create their key pair; we assume that it's extremely unlikely for two people to generate the same keys, and that it's also very hard for two people to generate keys with the same fingerprint. By (being the only one) knowing the secret part of a key, I am the authority on what can be signed with it. I could for instance sign records that say that www points to this set of IP addresses, and smtp points to that other address. Within my area of authority, which is to say within my domain. Which is identified by the fingerprint of my key pair.

What do we have so far? A mechanism that allows in a decentralised way to verify who's authoritative on the F5566852EB92BD779CF137190EA756B5144843F5 “domain”. In DNS terms, more probably F55...3F5.some-tld. Now let's publish the signed records on a decentralised peer-to-peer network. I'm not up to date with the latest trends in that domain, but I think something like Gnutella or Freenet would qualify, since it doesn't need central hubs but only an initial list of nodes, and it does automatic discovery of new nodes. Projects such as the FreedomBox (name likely to be changed) will probably help with that. Anyway, when looking up www.F55...3F5.some-tld, the resolver gets the signed record (and the public part of the key) from the P2P network, checks the signature, and uses the contents of the record to determine the IP address. No central or delegated registry involved at any point. Lesser risk of a single point of failure, which means better resilience against outages. Also, a better resilience against DNS-based censorship, be it promoted by non-democratic states or by greedy corporations.

Of course, F5566852EB92BD779CF137190EA756B5144843F5 isn't a terribly easy “name” to remember or transmit. But the string of hex could be presented to the user in some other form easier to recognize for people without geek super-powers. My favourite would be the bibi-binary representation, but I'm told that the bubble-babble method works equally well. It would still be unreasonable to expect people to remember such names, and especially to type them into their web browsers or e-mail agents. A possible solution to that would be to use a short form, such as 144843F5 (or its bibi-binary equivalent), complemented by a visual representation of the full fingerprint such as the one SSH does. That pair could be displayed on business cards, email signatures, glossy brochures, advertisements and so on, and allow users to just type the strange word or flash the 2D barcode, check that the funny picture matches (in case the strange word returns several results), and get the website they want. Which they can of course bookmark under a name they can remember, probably even the same name that everyone else uses to bookmark that website. And nothing precludes convenient directories mapping names to full URLs (like search engines currently do) — as long as users check that the visual representation of the site they go to matches what they've seen elsewhere.

That “elsewhere” could, of course, take advantage of the natural web of trust that emerges in of GPG-using communities. If I'm directed at a website whose key I don't immediately recognize, then I can see who trusts that key to be legitimate (by checking the signatures), and who trusts them, and so on. Ultimately, the decision is mine to make, and mine only. In any case, once I know what URL I want to visit, I can be sure this DNS replacement will give me the right IP address (or addresses). DNS servers replying with advertisement sites instead of correct ones, and DNS-based filtering, will be things of the past.

Of course, having the right IP address only solves the attacks on the DNS part. Eavesdropping can also happen by diverting traffic at the IP level. But we have a trustable way to know information related to a domain, so let's use it: the signed record can also contain the fingerprint of cryptographic keys (SSL or SSH or whatever). So we can be sure we're actually talking to the correct server, rather than to some man-in-the-middle spy. With the same guarantees of correctness as the ones for the DNS, backed by the web of trust and out-of-band validation. Again, we get rid of the hierarchy of “certification authorities”, some of which have been known for helping organizations get at the (supposedly secret) data people exchange over the net.

To summarize: with this scheme, if I know the site I want to access is F55...3F5, then I can be certain that a) I get the right IP address for it and b) I'm actually talking to it. And nobody in-between can intercept the traffic, if the site is properly administrated and its private key is kept secure. And from the site admin's point of view, there's no need to trust DNS registrars and SSL certification authorities not to fool around with the data, or blackmail me into paying increasing fees for keeping my URL working or my SSL key certified. There's still the problem of the allocation for the IP addresses themselves, but two major parts of the centralized and hierarchical net can be gotten rid of.

There are proposals attempting to fix part of the problems already, but they're incomplete. DNSSEC only solves the authentication of DNS records, not the centralisation problem. Monkeysphere aims at adding a web of trust to the SSL certificates system, but the CA chain problem seems to persist (although I must admit I'm not up to speed with the actual details).

This is of course only a rough draft, full of technical considerations yet certainly not exhaustive. I've thought about it though, and I believe there are no theoretical problems with the implementation of such a scheme (apart for the handling of expiration and revocations, probably). The main obstacle to mass-adoption I can envision is the UI part, and the entrenched habit of just typing a keyword into a search engine and implicitly trusting its results, then blindly trusting the website itself; but even if mass-adoption isn't reached, I can't see anything wrong with giving those who want to be careful a more secure Internet.