Notebook-Diebstahlschutz über Kurzstreckenfunk (z.B. Bluetooth)

Zur Komfortsteigerung würde man eine Kontaktzeit einprogrammieren können, innerhalb derer die Zusatzhardware auch ohne Kontakt zu externen Geräten ihr Einverständnis signalisiert. Kontakt zu einem Gerät während des Betriebs des Rechners würde den Ablauf der Kontaktzeit zurücksetzen (was aber eine Softwareschnittstelle voraussetzte). "Stromausfall" würde die Kontaktzeit auf Null reduzieren, so dass der Mechanismus nicht durch derart simple Manipulationen auszuhebeln wäre.

Mit Hilfe der Schlüssel wäre es möglich, Schlüssel derselben und der untergeordneten Klassen zu überschreiben. D.h., der Kunde könnte seinen Schlüssel ändern, aber auch der OEM könnte den Kundenschlüssel neu setzen. Der Kunde bekäme den Schlüssel per SMS, E-Mail o.ä. auf sein mobiles Gerät. Die Schlüssel ohne Unterstützung des OEM programmieren zu können, wäre nicht ungefährlich.

Auf den mobilen Geräten müsste eine Applikation installiert werden, die einerseits die Schlüssel speichern (und ggf. im- und exportieren) und andererseits mit dem PC kommunizieren (freischalten und Schlüssel ändern) kann. Diese Applikation könnte aber auch auf dem PC laufen, so dass die Aktivität der mobilen Geräte sich wirklich auf das Aussenden signierter Daten beschränkte. Diese Applikation sollte auch in der Lage sein, im laufenden Betrieb einen Authentifizierungsversuch zu starten, der dazu diente, die Kontaktzeit zurückzusetzen.

Die Schlüssel müssten nicht einmal auf einem mobilen Gerät hinterlegt werden: Das System könnte ohne weiteres so ausgelegt werden, dass auch im normalen Betrieb, also nach dem Booten, eine entsprechende Authentifizierung möglich ist. Diese könnte dazu verwendet werden, den Ablauf der Kontaktzeit zurückzusetzen, so dass beim nächsten Booten gar nicht nach einem mobilen Gerät gesucht werden müsste. Dies wäre für den Benutzer sehr komfortabel, und am Internet hängen innerhalb mehrerer Tage inzwischen wohl alle Rechner. Ein gestohlenes Gerät bekäme seine Schlüssel natürlich nicht mehr übers Netz, weil der Besitzer diese Funktion serverseitig sperren ließe.

Im Prinzip könnte man die Schlüssel sogar lokal ablegen, so dass der Anwender im Betrieb die Kontaktzeit ganz autark zurücksetzen kann. Die Software sollte die Schlüssel dann aber bitte (wirklich) gut verschlüsselt auf dem Rechner ablegen.

Dies wäre aber nur eine Erweiterung des Funksystems, kein kompletter Ersatz, da es immer mal passieren könnte, dass die Kontaktzeit erreicht wird. In diesem Fall müsste beim Booten ein geeignetes Gerät in der Nähe sein.

Es muss ins Ermessen des jeweiligen Kunden gestellt sein, ob er das System nutzen will oder nicht. Es muss also abschaltbar sein, ohne dadurch eine Hintertür für Diebe zu öffnen, den Schutz auszuhebeln. Dies könnte durch eine Programmierung erreicht werden, zu der alle oder einzelne Schlüssel autorisiert sind und die die Kontaktzeit auf "unendlich" setzt, aber bei einem Stromausfall erhalten bleibt.

Das System muss so beschaffen sein, dass es nur unter großem (unwirtschaftlichem) Aufwand zu umgehen ist, weil zu befürchten ist, dass sich dieser Aufwand für professionelle Diebe lohnte und der Sinn des System damit ad absurdum geführt würde. Die Wirtschaftlichkeit des Aufwands ist dabei vor dem Hintergrund zu betrachten, dass nicht durch einmaligen hohen Aufwand derjenige im Einzelfall reduziert werden können darf, denn das wäre ein Anreiz für profesionelle Diebe oder quasi-kriminelle Entwickler (mit der Zielgruppe Notebookdiebe), diesen Aufwand auf sich zu nehmen.

Die offensichtlichen Gefahrenstellen sind:

1. BIOS-Flash

2. Schlüsseländerung/Deaktivierung

3. Hardwaremanipulationen

Es müsste sichergestellt sein, dass Änderungen am BIOS den Mechanismus nicht außer Kraft setzen können, die Boot-Blockade dürfte sich also nicht auf eine simple Softwareabfrage "Booterlaubnis vom Chip erteilt?" beschränken. Der Chip müsste das Booten in Hardware blockieren, so dass das BIOS gar keine andere Wahl hätte, als sich mit dem Chip auseinanderzusetzen. Der Mechanismus könnte beispielsweise weitere Rechnerkomponenten – etwa den IDE-Adapter – erst freischalten müssen. Alternativ könnte man nach einer bestimmten Zeit nach dem Power-up einen Hardware-Reset auslösen, was sogar ohne Chipsatzanpassungen realisierbar wäre.

Die Umgehungsmöglichkeit Löschen des Flash-Speichers könnte man – wenn das denn technisch praktikabel ist – dadurch sabotieren, dass auch das Flashen an die Abfrage eines Schlüssels gekoppelt wird, wenn der Schutz aktiv ist. Aber auch dann könnte man immer noch den Flash-Baustein wechseln. Erstrebenswert ist also, zumindest für einen Teil der Daten (Prüfsumme) einen Speicherbereich zu nutzen, der nicht (mit wirtschaftlichem Hardwareaufwand) manipulierbar ist.

wünschenswerte Änderungen an den mobilen Geräten

Es soll dem Kunden möglich sein, die Schlüssel zu ändern und den Mechanismus zu deaktivieren. Es wäre aber sicherzustellen, dass dies nicht einfach mit dem gleichfalls gestohlenen Mobiltelefon möglich wäre (wenngleich dies üblicherweise wesentlich schwieriger wäre als der Notebookdiebstahl alleine). Mögliche Ansätze wären die Verwendung von Schlüsselpaaren, einem unverschlüsselten zum Freischalten des Bootvorgangs und einem verschlüsselten zum Ändern der Schlüssel im Notebook. Diese Lösung, die ein Sperren des Änderungsschlüssels nach einer bestimmten Zahl von Fehlversuchen erforderlich machte, hätte den Vorteil, dass sie sehr wirksam wäre, und den Nachteil, dass der Kunde womöglich den Schlüsselcode vergisst, da er ihn ja fast nie verwendet. Man könnte auch den Schlüssel mit der Handy-PIN verschlüsseln, denn die muss der Kunde ja sowieso eingeben. Den Änderungsschlüssel würde man nicht beim Einschalten des Handys entschlüsseln, so dass ein Handydieb das Gerät nur zum Aktivieren, nicht aber zum Ändern verwenden könnte.

Netzkontakt

Generell sollte es nicht möglich sein, die Schlüssel mit vertretbarem Aufwand aus dem Gerät zu extrahieren, und alle Schlüssel sollten nur dann funktionieren, wenn das Telefon erfolgreich im Netz eingebucht ist (weil sich das nach dem Diebstahl verhindern lässt). Natürlich wirft das die Frage auf, was passiert, wenn der Nutzer mal kein Netz hat. Hier ist ein sinnvoller Mittelweg zu wählen; etwa der, dass das Telefon zwischen kein Empfang und Einbuchen unmöglich unterscheidet, letzteres am besten noch zwischen gescheiterten Authentisierungen und fehlender Netzkapazität. Je nach Status könnten dann sinnvolle Timeouts gewählt oder die Funktion (bis zum nächsten erfolgreichen Einbuchen) komplett deaktiviert werden.

Natürlich kann weder ein Notebook noch ein mobiles Gerät permanent senden oder auch nur lauschen, um allzeit automatisch bereit zu sein, das ginge zu sehr zu Lasten der Stromversorgung. Am einfachsten wäre natürlich, die Empfangsfunktion auf dem mobilen Gerät im Bedarfsfall manuell auszulösen. Das erfordert Benutzeraktivität und drückt so die Bequemlichkeit. Andererseits ist es für viele vielleicht ganz nett, daran erinnert zu werden, dass ihr Rechner derart geschützt ist.

Das Problem reduziert sich immens, wenn man mit Timeouts arbeitet (was sich im Verschlüsselungsfall allerdings verbietet). Dann holt sich der Rechner seine Timeout-Resets aus dem Internet. Für den Fall, dass das nicht klappt, kann man ein Zeitfenster festlegen, dessen Breite von der Genauigkeit der Uhren in PC und dem anderen Gerät nach unten hin limitiert wird. So könnten beide Geräte beispielsweise zu jeder vollen Stunde für 30 Sekunden versuchen Kontakt aufzunehmen. So h¨tte man regelmäszlig;ige Updates ohne großen Mehrverbrauch.

Anders als heute müssten die Chipsätze für jeden OEM individuell programmiert werden, weil nur das Vorhandensein eines OEM-spezifischen Schlüssels die Programmierung der Nutzerschlüssel durch diesen überhaupt erst ermöglicht.

Man kann den Kunden nicht dem Risiko aussetzen, dass er an seinen Rechner nicht mehr herankommt, weil ihm sein Schlüssel abhanden gekommen ist und sein Lieferant nicht mehr existiert. Für diesen Fall sollte der Chipsatzhersteller mit seinen Kunden vereinbaren, dass er deren Schlüssel an ein oder mehrere andere Unternehm,en weitergibt, damit diese den Support übernehmen können.

Da der Diebstahlschutz nur über die Intelligenz der Diebe funktioniert (sie müssen das Objekt als nicht lohnend erkennen), hat man es mit einer Art Netzwerkeffekt zu tun: Die Wirkung setzt erst ein, wenn das System verbreitet ist. Natürlich besteht eine erhebliche Chance, dass derart unverkäfliche Geräte dann wiederauftauchen. Genauso möglich ist natürlichm, dass die Asozialen ihre Beute aus Frust kaputtschlagen.

Als problematisch könnte sich erweisen, dass die Geräte irgendwie als derart geschützt kenntlich gemacht werden müssen, damit gar nicht erst der Versuch eines Diebstahls unternommen wird. Wenn diese Kennzeichnung allerdings in großem Umfang von Leuten kopiert wird, deren Notebooks nicht darüber verfügen, könnten sich die Gauner gezwungen sehen, doch zu klauen, um dann zu testen, was sie da ergaunert haben, die Schutztechnik oder den Bluff. Damit wäre die erhoffte Wirkung dahin, lediglich die Wiederbeschaffungsaussichten wären dann höher (zumal die Diebe in dem Fall gleich prüften, womit sie es zu tun haben). Denkbar ist natürlich, für die Kennzeichnung etwas zu wählen, was man mit einer Marke gegen unzulässiges Kopieren (in großem Umfang) schützen kann.

Man müsste bereits im Vorfeld dafür sorgen, dass möglichst viele mobile Geräte als Schlüsselträger dienen können. Enorm hilfreich wäre es, wenn man dies einfach per Java-Applikation erledigen könnte. Allerdings sollte man dann nicht durch Installation zusätzlicher Software den Schlüssel auslesen können.

Das wohl größte Problem bei der Einführung so einer Technik ist der anfallende Supportaufwand: Immer wieder werden Kunden in irgendeiner Form Unsinn verzapfen und darauf angewiesen sein, dass der Hersteller ihnen einen neuen Schlüssel installiert. Dies ist zwar nicht mit viel Aufwand verbunden, aber die Infrastruktur dafür muss geschaffen werden. Außerdem muss klar sein, wie sich die Kunden ihrerseits authentisieren müssen, denn es wäre blamabel, wenn der Service nichtsahnend dem Notebookdieb seine Beute in Gang setzte. Außerdem muss es leicht möglich sein, das Handy zu wechseln. Dafür könnte die Möglichkeit geschaffen werden, die Schlüssel einfach per SMS/MMS an die alte Nummer zu schicken. Im UMTS-Zeitalter könnte der Kunde das z.B. per E-Mail im Prinzip auch selber.

Problematisch für den Kunden wären die seltenen Situationen, in denen mal "falscher Alarm" ausgelöst wird: Der Kunde wechselt das Handy, es geht kaputt, und dann steht der Rechner. Vermeiden ließe sich dies über die Option eines Zurücksetzens der Ablaufzeit via Internet. Das könnte der Hersteller anbieten. Außerdem könnte – unabhängig davon – eine Software auf dem Rechner installiert werden, die überprüft, ob die Authentifizierung verdächtig lange nicht stattgefunden hat, und ggf. den Nutzer warnt.

Da von der Computerpresse über die dies nutzenden Gerätehersteller genügend Leute ein Interesse daran hätten und neue Chipsätze sowieso eine gewisse Aufmerksamkeit erfahren, würde sich dies schon rumsprechen.

Es mag sogar hilfreich sein, mal etwas Qualitativ-ganz-Neues zu haben, worüber man bei der Chipsatzvorstellung reden kann.

Da die OEMs vermutlich keine Lust haben, einzelne Modelle bis zum St.-Nimmerleinstag zu unterstützen und gleichzeitig der Wert eines Notebooks nach ein paar Jahren wirklich nicht mehr zum Klauen animiert, mag es sinnvoll sein, nach Ablauf dieser Zeit die OEM-Schlüssel oder sogar den Herstellerschlüssel für einen bestimmten Chipsatz (bzw. eine Serie) zu veröffentlichen, so dass die Hardware auch unter widrigen Umständen weiterhin genutzt werden kann.

Etwas aufpassen wird man mit dem Datenschutzt müssen. Es ist nicht uneingeschränkt zu begrüßen, wenn Geräte dadurch eindeutig identifizierbar werden. Man denke nur an den Ärger mit der CPU-ID.

Dieses System könnte – sofern es nicht patentfähig ist – schnell von anderen imitiert werden; wobei "schnell" allerdings in Relation zu den Produktzyklen zu sehen ist. Allerdings ist das Interesse bei Herstellern, die im Hochpreissegment und generell bei Notebooks mit ihren Chipsätzen nicht so präsent sind, wohl als mäßig einzuschätzen.

Durch eine geeignete Integration in den Chipsatz wäre es möglich, eine softwaretransparente Festplattenverschlüsselung zu verwenden. Der Chip würde dann beim Booten den Schlüssel ans IDE-Interface übermitteln. Damit die Platte in anderen Rechnern lesbar bleibt, sollte allerdings dieser Schlüssel auslesbar sein. Dies wäre für Firmennotebooks sehr interessant, auf denen vertrauliche Daten liegen. Das kann man zwar auch heute schon regeln, nämlich in Software, aber wer macht das schon? Dafür müsste allerdings die Möglichkeit geschaffen werden, dem Anwender die Änderung der Kontaktzeit unmöglich zu machen, so dass wirklich bei jedem Booten ein entsprechendes mobiles Gerät in der Nähe sein muss.

Dieses Prinzip lässt sich auf andere Geräte ausdehnen. Sinnvoll ist dies wohl nur bei entsprechend hohem Diebstahlrisiko. Dies hätte allerdings mit PC-Chipsatzhardware dann wenig zu tun.

Mobiltelefone könnte man natürlich prima aus dem jeweiligen Telefonnetz versorgen.