#!/bin/blog

October 21, 2011

Update: Booten vom verschlüsselten USB-Stick

Filed under: Paranoia — Tags: , , — martin @ 9:02 pm

Also, die Sache mit den USB-Sticks von Lok-IT war sicher eine tolle Idee, das Problem ist aber, daß man de-facto nicht von ihnen booten kann funktioniert.

Grub, Kernel und initrd werden zwar geladen. Leider erfolgt innerhalb der initrd aber scheinbar ein Reset des USB-Systems. Ein normaler USB-Stick holpert da irgendwie drüber (das funktioniert mit /boot auf dem Stick problemlos), aber der Lok-IT sperrt sich sicherheitshalber automatisch.

Das ist schade, aber kein Beinbruch. Das letzte Wort wird da auch hoffentlich noch nicht gesprochen sein.

Es trifft zu, daß der USB-Bus beim Hochfahren zurückgesetzt wird und sich der Stick in diesem Moment aus Selbstschutz sperrt. Das ist aber überhaupt kein Problem. Man muß lediglich in /etc/fstab dafür sorgen, daß das System beim Hochfahren nicht versucht /boot zu mounten oder zu checken. Beide Daumen nach oben für meinen unknackbaren Terrorlaptop! 🙂

Und, nein, es wird kein HOWTO dazu geben. Wer dafür ein Kochrezept braucht, sollte besser die Finger davon lassen.

October 18, 2011

Der “sicherste USB-Stick der Welt”

Filed under: Hardware — Tags: , , — martin @ 6:44 am

In den letzten Tagen hat sich ja leider herauskristallisiert, daß die Bürger der Bundesrepublik Deutschland verfassungswidrig mit Computerwanzen abgehört werden. Man darf zum gegenwärtigen Zeitpunkt vielleicht hoffen, daß der Staat keine Methode hat, um andere Betriebssysteme als das des Marktführers Microsoft abzuhören, aber natürlich haben diese Nachrichten meine Paranoia geradezu beflügelt.

Insbesondere kam mir schlagartig die Frage eines Kollegen in den Sinn, als er mich irgendwann dabei beobachtete, wie ich die LUKS-Passphrase für meine Linux-Workstation eingab: “Wie hat sich Dein Rechner denn bei Dir authentifiziert?” – Gute Frage: Ich habe natürlich nicht sichergestellt, daß niemand die wahlweise auf dem Root-Dateisystem oder auf der initial RAM-Disk (initrd) liegende Abfrage der Passphrase manipuliert hat.

Wie kann man sicherstellen, daß in der eigenen Abwesenheit keine Manipulationen am Linux-Betriebssystem (bzw. den Dateien, von denen es bootet) vorgenommen wurden? Eigentlich ganz einfach: Das root-Filesystem muß verschlüsselt werden, und die Umgebung von der das System gebootet wird, also das /boot-Filesystem mit Kernel und initrd muß vor Manipulationen geschützt werden. Also mußte ein manipulationssicherer USB-Stick her. (Update: Booten vom verschlüsselten USB-Stick)

Ich habe mich also auf die Suche nach einem USB-Stick mit PIN-Eingabe gemacht. Nach kurzer Recherche bin ich auf die folgenden Modelle gekommen:

Beide benutzen Verschlüsselungschipsätze von ClevX. Ich habe mich für den teuren Stick von Lok-IT entschieden, da sowohl der verwendete Chipsatz von ClevX als auch das Endprodukt FIPS-zertifiziert sind. Das einfachere Modell von Corsair ist leider berüchtigt dafür, daß es standardmäßig eine leere Administrator-PIN als Hintertür mitbringt; des weiteren war bei der ersten Corsair-Generation der Flash-Chip relativ leicht zugänglich und nur schwach gegen physische Angriffe gesichert. Die Aussagen dazu, ob bei Corsair verschlüsselt oder nur der Zugriff auf den Flash-Chip kontrolliert wird, sind noch dazu widersprüchlich. Insgesamt ist also die Historie des billigen Corsair-Stick wenig beeindruckend; bei sorgfältiger Herangehensweise wird aber sicher auch er für viele Angreifer nicht zu knacken sein.

Die Elektronik im Stick von Lok-IT ist mit schwarzem hartem Epoxidharz vergossen; darüber hinaus werden die auf dem Flash-Chip gespeicherten Daten vom ClevX-Controller verschlüsselt. (Herstellerangaben)

Die Lieferung des Stick erfolgt in einer öffnungsresistenten Blisterverpackung. Der Stick hat ein massives Metallgehäuse und ist bei geschlossener Kappe wasserdicht. Auf seiner Rückseite ist ein gut lesbarer Barcode mit einer Seriennummer aufgedruckt. Der Stick ist nicht zu unförmig, aber am Macbook Air läßt er sich nur mit Mühe am linken USB-Port einstecken.

Beim Stick handelt es sich um ein autonom funktionsfähiges System, das über einen eingebauten LiPo-Akku zur Stromversorgung verfügt, welcher am USB-Bus geladen wird. Mit Hilfe der eigenen Stromversorgung sind alle PIN-Aktionen im ausgestöpselten Zustand verfügbar. Nach dem Entsperren kann der Stick 30 Sekunden lang in Ruhe in den PC eingesteckt werden. Wird der Stick später wieder gezogen, erfolgt automatisch die Sperrung. Wie das mit dem Entsperren funktioniert, sieht man schön im Video des Herstellers:

Der Stick ist aufgrund dieser Funktionsweise wie jeder normale USB-Stick verwendbar. Es ist keine Unterstützung durch das Betriebssystem erforderlich, es können beliebige Dateisysteme angelegt werden, es kann gebootet werden.

Nach dem Auspacken ist zur Inbetriebnahme zwingend die Vergabe einer PIN erforderlich; dabei wird von der beiligenden Kurzanleitung das Setzen der User-PIN beschrieben. Der Stick erzwingt eine Länge der PIN von mindestens 7 Ziffern und akzeptiert keine PINs, die aus Wiederholungen der selben Ziffer (1111111) oder aus einer aufeinanderfolgenden Ziffernfolge (3456789) bestehen.

Der Stick verfügt über klare und dokumentierte Policies für die Vergabe von zwei PINs für den User selbst und den Administrator, vulgo “Cryptographic Officer” oder “CO”. Die Kurzanleitung gibt nur her, wie die PIN für den User gesetzt werden kann; eine Anleitung zum Setzen der PIN für den CO mußte ich mühsam ergoogeln.

Die Interaktion zwischen User und CO ergibt Sinn und kann im Detail in der FIPS Security Policy des Lok-IT nachgelesen werden. Ist die User-PIN gesetzt, kann keine PIN für den Crypto-Officer mehr gesetzt werden, ohne daß zuvor die User-PIN eingegeben wird. Benutzt der CO seine PIN um den Stick zu entsperren, wird die vergebene PIN des Users gelöscht und kann nur durch den CO neu gesetzt werden. Eine fortwährende Kompromittierung der Userdaten durch den CO ist folglich nicht möglich.

Ab Werk sind auf dem Stick 6 vorgenerierte und nicht veränderbare AES-Schlüssel hinterlegt, von denen der erste zum Verschlüsseln der gespeicherten Daten verwendet wird. Eine Möglichkeit, den Stick auf den Auslieferungszustand zurückzusetzen, existiert nicht. Hat man beide PINs vergessen, bleibt nur noch, die PIN zehnmal falsch einzugeben. Daraufhin wird der Inhalt des Stick verworfen, indem der Controller den verwendeten Schlüssel löscht. Daraus folgt, daß dieser Vorgang nur sechsmal möglich ist; danach ist der Stick unbrauchbar.

Ob der Stick von Lok-IT, der laut Hersteller nicht nur von der Apple-Entwicklungsabteilung, sondern auch von der US-Regierung benutzt wird, auch eine Hintertür für die US-Regierung enthält, vermag dieses Review leider nicht zu sagen. Wer sich ernsthaft vor CIA, DHS und NSA schützen muß, wird seinen gesunden Menschenverstand in Verschlüsselungsfragen aber sicher sehr genau auf die Probe stellen.

Wenn man sich vom hohen Preis nicht abschrecken läßt, bekommt man mit dem Lok-IT ein kleines Stück Hardware, das den meisten Anforderungen an die Sicherheit der darauf gespeicherten Daten gerecht werden sollte.

Laut Hersteller ist die Version ohne FIPS-Zertifizierung identisch mit der nicht FIPS-zertifizierten Version, mit dem Unterschied, daß keine Aussage hinsichtlich der FIPS-Compliance gemacht wird. Das kann man beim Kauf evtl. in Betracht ziehen um ein paar Euros einzusparen, falls einem der Schritt hinunter zum eher spielzeughaften Corsair Padlock zu groß erscheint.

December 4, 2008

Using a USB key for the LUKS passphrase

Filed under: Paranoia, UNIX & Linux — Tags: , , — martin @ 10:43 pm

When I had installed my notebook with Ubuntu 8.04 “Horny Hard-on”, I had opted to put the /home filesystem onto an encrypted partition on /dev/sda4. However, after a few months, entering the passphrase after turning on the computer doesn’t seem to be that attractive anymore. I have therefore decided to try to store the passphrase on a spare USB key.

This is how I migrated my LUKS container to a passphrase stored on USB media.

First, I filled the USB key with random data:
# dd if=/dev/urandom of=/dev/sdc

Then, I siphoned off 256 bytes from the USB key, to be used as the passphrase:
# dd if=/dev/sdc of=/home/martin/foo.key bs=1 count=256

foo.key is required temporarily. You may keep a copy of it stored in a safe place, or you may leave the interactive password in place as a fall-back measure. Which is what I’m doing.

The new passphrase can be added to the LUKS container like this:
# cryptsetup luksAddKey /dev/sda4 /home/martin/foo.key

Cryptsetup asks for “any passphrase”. That is one of the numerous possible passphrases that may be assigned to a LUKS device at once. Such as the interactive passphrase that is already in place.

When the new passphrase has been added, foo.key can be deleted.

Next, I determined the USB id of my USB key:
# ls -l /dev/disk/by-id/ | grep sdc
lrwxrwxrwx 1 root root 9 2008-12-04 21:31 usb-LG_XTICK_AAAAAAAAAAAAAAAAA-0:0 -> ../../sdc

I found that I needed a little helper script that extracts 256 bytes from the USB key and pipes them to stdout:

#!/bin/bash
# Script: /usr/local/sbin/dd-luks-key.sh
if [ -e $1 ]
then
dd if=$1 bs=1 count=256
fi

And now the change to /etc/crypttab:

# Old entry; ask for password:
#sda4_crypt /dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee none luks
# New entry; execute the keyscript with the USB id as the argument:
sda4_crypt /dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /dev/disk/by-id/usb-LG_XTICK_AAAAAAAAAAAAAAAAA-0\:0 luks,keyscript=/usr/local/sbin/dd-luks-key.sh

That’s it. I can now reboot with the USB key plugged in and observe how the system automatically mounts the LUKS container. The USB key is not partitioned, so Gnome will not automatically mount it. It can just be pulled anytime after bootup.

If I had chosen to delete the interactive passphrase, which is stored in key slot 0:
# cryptsetup luksDelKey /dev/sda4 0

Be advised that this is no real-deal tough-minded security, but something that will protect the machine only against the type of attackers (e.g. thieves) who are out for your hardware but not for your data. Don’t leave the USB key close to the laptop. Use this responsibly. Thanks!

I’m not conviced that I will stick with this, as it’s far below my usual standard of paranoia. Nevertheless, I have gained a few nice insights into the LUKS system.

February 19, 2008

USB slow in MacOS 10.5.2?

Filed under: Software — Tags: , , , — martin @ 9:46 pm

Oh well, the troubles with MacOS 10.5.2 aren’t about to stop. Now I’m discovering that USB transfers from my camera’s memory card are painfully slow, no matter whether I use a card reader or connect the camera directly to USB. The hardware is USB 2 but the transfer speed feels more like USB 1, which means that it is very, veeery, veeeeery slow. Once again, I’m not alone in this, although many (if not most) users seem to have had the same problem before upgrading to 10.5.2 already:

An interesting observation is that in these discussions, random stuck-in-the-mud Firewire proponents show up and start telling people that USB has always been inferior anyway. Weird. As if anyone could just plug in their digital camera through Firewire instead of USB.

I’ll now try a reboot and a few resets of the whatever-manager. I doubt it helps, but it’s probably worth a try. (Update: A reboot and three ritualistic Alt+Cmd+P+R resets have fixed it, at least for now.)

Create a free website or blog at WordPress.com.