Digitale Schlüssel (iButtons / SmartButtons) klonen

Herkömmliche („Analoge“) Schlüssel sind inzwischen ein gut erforschtes Thema: Die Lockpicker beschäftigen sich ausgiebig damit, Schlösser ganz ohne Schlüssel zu öffnen, und vorhandene Schlüssel können je nach Bauart anhand von Fotos rekonstruiert werden — teilweise kann das Duplikat sogar direkt ausgedruckt werden.

Auch für unsere Vereinsräume haben wir Schlüssel und ein zugehöriges Schließsystem. Da es bei über 80 Mitgliedern aber nicht sinnvoll ist, einen einzigen Schlüssel für jedes Mitglied nachmachen zu lassen, verwenden wir digitale Schlüssel: Sogenannte iButtons bzw. SmartButtons. Jedes Mitglied erhält einen iButton, der eine eindeutige ID aus 48 bit Daten und 8 bit Prüfsumme enthält. Ist eine an der Tür eingelesene ID in der Liste der erlaubten IDs enthalten, wird die Tür aufgeschlossen. Da diese ID nicht verschlüsselt und in unserem Fall sogar auf dem Gehäuse aufgedruckt ist, besteht auch hier die theoretische Möglichkeit, iButtons zu klonen. Die Frage ist nur, wie viel Aufwand es ist.

Knapp drei Jahre nach Installation dieses Schließsystems wissen wir: Gar nicht so viel. Zum Klonen muss nur die ID vom Gehäuse ab- oder aus dem iButton ausgelesen und anschließend ein „Blanko-iButton“ damit bespielt werden.

ID auslesen

Auch wenn die ID nicht aufgedruckt ist, kann sie einfach ausgelesen werden. Dazu werden lediglich ein an einen PC angeschlossener Onewire-Master und ein offen herumliegender iButton benötigt: Auf den READ ROM-Befehl vom Master antwortet der iButton (als einziges am Bus angeschlossenes Gerät) mit seiner ID.

Onewire in Software

Ein normaler iButton enthält keine Intelligenz: Seine ID ist in einem ROM fest eingestellt, die Buskommunikation läuft über eine minimale State Machine ab — Also komplett in Hardware. Zur Stromversorgung enthält er einen kleinen Kondensator, der während des High-Pegels der Datenleitung aufgeladen wird.

Um beliebige Schlüssel emulieren zu können, muss das von iButtons verwendete Onewire-Protokoll allerdings in Software implementiert werden. Als Hardware kann fast alles verwendet werden, in diesem Fall ist es ein mit 8MHz getakteter AVR-Chip (Atmel ATTiny 2313A). Die Herausforderung liegt dabei im Protokoll: Auf eine Aktion vom Bus-Master muss innerhalb weniger Mikrosekunden reagiert werden, was bei 8MHz Takt nur 20 bis 30 Instruktionen erlaubt, um die korrekte Reaktion herauszufinden. Ein erster Versuch in C scheiterte daran, eine Assembler-Implementierung funktioniert dafür einwandfrei.

Dieser Code tut nichts anderes, als auf den READ ROM-Befehl zu warten und darauf in acht Paketen á 1 Byte mit der einkompilierten ID zu antworten. Um eine andere ID zu verwenden, muss nur die Assemblerdatei neu erzeugt und auf den AVR übertragen werden. Wir haben sogar ein Beweisvideo, in dem unsere Tür von einem so geklonten iButton geöffnet wird. Dazu ist an den Klon-Button nur ein USB-Akku zur Stromversorgung angeschlossen.

Der Code enthält ebenfalls experimentelle Unterstützung für den SEARCH ROM-Befehl, der auch bei mehreren gleichzeitig angeschlossenen iButtons IDs auslesen kann. Dieser scheint in der Praxis aber nicht verwendet zu werden.

Und die Sicherheit?

Mit diesem Code können beliebige iButton-IDs mit einem Hardwareaufwand von ca. 5€ geklont werden. Verwendet werden sie zum Beispiel in Türen oder Kassensystemen.

Dennoch sind die Sicherheitsauswirkungen zumindest für uns erfreulich gering: Letztendlich ist eine iButton-ID als Authentifizierungsmerkmal genau so sicher wie ein klassischer Schlüssel. Beide können nur dann geklont werden, wenn sie offen herumliegen oder abfotografiert werden. Solange iButtons mit der einem Schlüssel gebürenden Vorsicht behandelt werden, besteht also keine signifikante Gefahr. Auch hat das Protokoll keine Möglichkeit, nach dem Vorhandensein einer spezifischen ID zu fragen, so dass „Ja-Sager“, die sich als beliebige Schlüssel-ID ausgeben, nicht möglich sind. Es bleibt nur das Ausprobieren aller 2⁴⁸ IDs, was viel zu lange dauert, um praktikabel zu sein.

Wir werden unsere Tür daher weiterhin mit iButtons öffnen, da die Vorteile (eine ID pro Mitglied und leichtes Sperren bei Verlust) den Nachteilen überwiegen. Ob wir auch längerfristig dabei bleiben, oder auf ein intelligenteres System nach Art von Public/Private Key Auth umstellen, wird sich zeigen.