DE102015216630A1

DE102015216630A1 - Indirekter Berechtigungstransport

Info

Publication number: DE102015216630A1
Application number: DE102015216630.9A
Authority: DE
Inventors: Kai Römer; Philipp Spangenberg
Original assignee: Baimos Tech GmbH; BAIMOS TECHNOLOGIES GmbH
Current assignee: Blueid De GmbH
Priority date: 2015-08-31
Filing date: 2015-08-31
Publication date: 2017-03-02
Also published as: EP3345364A1; US20190028487A1; WO2017036686A1

Abstract

Die vorliegende Erfindung betrifft Verfahren und Systeme zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems. In einer Ausführungsform umfasst ein entsprechendes Verfahren ein Empfangen der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (200, 300) an einer Verifizierungseinheit (35) eines zu schützenden Objekts (30), wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz (10) kryptographisch signiert ist.

Description

1. Technisches Gebiet
Die vorliegende Erfindung betrifft Verfahren und Systeme zum sicheren Übertragen von Berechtigungen für Steuerfunktionen eines technischen Systems, wie beispielsweise eines Fahrzeugs. In bevorzugten Ausführungsformen wird die Sicherheit von SmartCards mit den Vorzügen Internet-fähiger Smartphones vereint, sodass eine Berechtigung für ein zu schützendes Objekt über einen unsicheren Kanal übertragen werden und trotzdem sicher und zuverlässig verwendet werden kann.
2. Technischer Hintergrund
Aus dem Stand der Technik sind Identifikations- und Schließsysteme zur Organisation von Zugangs- und Nutzungsberechtigungen in Verbindung mit technischen Systemen bekannt. Beispielsweise betrifft das Europäische Patent 1 910 134 B1 der Anmelderin ein Identifikationssystem zur berechtigungsabhängigen Nutzung eines technischen Systems. Mit einem solchen System können beispielsweise mittels eines Mobiltelefons bzw. Smartphones Steuerfunktionen eines Fahrzeugs ausgelöst werden, sodass das Fahrzeug mit dem Mobiltelefon bzw. Smartphone beispielsweise geöffnet und/oder gestartet werden kann. Mobiltelefone oder vergleichbare elektronische Endgeräte (z.B. Smartphones, PDAs (Personal Digital Assistants) und/oder Tablet-Computer) lassen sich aufgrund ihrer Internet-Konnektivität flexibel mit entsprechenden Berechtigungen ausstatten, wenn diese über eine sichere Verbindung mit derjenigen Instanz verbunden sind, welche die Berechtigungen ausstellt. Dies funktioniert jedoch nur, wenn tatsächlich auch eine Internetverbindung besteht, was gerade bei Anwendungsfällen wie einer Autovermietung nicht immer der Fall ist, beispielsweise wenn das Fahrzeug sich in einer Tiefgarage befindet.
Andere aus dem Stand der Technik bekannte Identifikations- und Schließsysteme setzen anstatt von Mobiltelefonen oder anderen elektronischen Endgeräten sogenannte Smartcards als „Schlüssel“ ein, auf welchen entsprechende Berechtigungen abgespeichert werden können. In solchen Systemen wird es jedoch bislang als erforderlich angesehen, dass die Smartcard direkt vor Ort bei einer vertrauenswürdigen Instanz (beispielsweise dem Fahrzeugvermieter) mit den Berechtigungen beschrieben wird, was unflexibel und arbeitsintensiv ist.
Der vorliegenden Erfindung liegt deshalb das Problem zugrunde, Verfahren und Systeme bereitzustellen, mit dem Berechtigungsträger, beispielsweise Smartcards, sicher und flexibel mit Berechtigungen ausgestattet werden können, sodass die oben im Zusammenhang mit dem Stand der Technik angesprochenen Nachteile zumindest zum Teil überwunden werden.
3. Zusammenfassung der Erfindung
Dieses Problem wird gemäß einem Aspekt der Erfindung durch ein Verfahren zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems gelöst. In der Ausführungsform nach Anspruch 1 wird die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal an einer Verifizierungseinheit eines zu schützenden Objekts empfangen. Erfindungsgemäß ist hierbei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz kryptographisch signiert.
Dadurch, dass die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz (auch „TrustCenter“ genannt) kryptographisch signiert – und vorzugsweise auch von dieser ausgestellt worden – ist, kann die Berechtigung über einen unsicheren bzw. ungesicherten Kanal übertragen werden und ist trotzdem sicher und zuverlässig verwendbar. Ein ungesicherter Kanal ist eine Kommunikation zwischen zwei Einheiten über mindestens eine Schnittstelle, bei der auf dem Übertragungsweg nicht sichergestellt werden kann, dass ein Datenpaket von Unberechtigten ausgelesen oder verändert werden kann. Bei einem solchen unsicheren Kanal kann es sich beispielsweise um das Internet, eine SMS, einen QR-Code, GSM, BTLE, Zigbee, allgemeine Funkstrecken wie z.B. 866 MHz, einen Transportkanal über einen Berechtigungsträger, oder ähnliches handeln. Denn durch die, vorzugsweise digitale, Signatur sichert das TrustCenter den Umfang und den Inhalt der Berechtigung kryptographisch ab, was vom Empfänger überprüft werden kann. Unter einer digitale Signatur ist ein asymmetrisches Kryptosystem zu verstehen, bei dem ein Sender mit Hilfe eines geheimen Signaturschlüssels (dem Private Key) zu einer digitalen Nachricht (d. h. hier der zumindest einen Berechtigung) einen Wert berechnet, der ebenfalls digitale Signatur genannt wird. Dieser Wert ermöglicht es jedem, mit Hilfe des öffentlichen Verifikationsschlüssels (dem Public Key) die nichtabstreitbare Urheberschaft und Integrität der Nachricht (hier der zumindest einen Berechtigung) zu prüfen. Als Signaturverfahren können beispielsweise solche basierend auf Primfaktorzerlegung, wie z.B. RSA, solche basierend auf diskreten Logarithmen, z.B. El-Gamal, DSA, solche basierend auf elliptischen Kurven, z.B. ECDSA, oder ähnliche zum Einsatz kommen.
Gemäß einem Aspekt der vorliegenden Erfindung kann die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal von einem Transportberechtigungsträger empfangen werden. Der Transportberechtigungsträger kann die zumindest eine Berechtigung zuvor von der vertrauenswürdigen Instanz empfangen haben. Hiermit wird es beispielsweise möglich, die zumindest eine Berechtigung von der vertrauenswürdigen Instanz (dem TrustCenter) auf ein Smartphone (welches in diesem Beispiel der Transportberechtigungsträger ist) und dann vom Smartphone auf die Verifizierungseinheit (die sich beispielsweise in einem Fahrzeug als zu schützendes Objekt befinden kann) zu übertragen. Hierdurch wird die Flexibilität des Verfahrens erheblich erhöht, da beliebige herkömmliche elektronische Endgeräte, wie beispielsweise Smartphones, als Transportmedium für die zumindest eine Berechtigung verwendet werden können. Gleichzeitig bleibt die Echtheit der übertragenen zumindest einen Berechtigung dank der oben beschriebenen Signatur gewahrt, obwohl die zumindest eine Berechtigung über einen ungesicherten Kanal (z.B. das internetfähige Smartphone) übertragen wird. Es versteht sich, dass anstatt eines Smartphones jede andere Art von Berechtigungsträger zum Einsatz kommen kann (weitere Beispiele siehe unten) und dass der Begriff „Transport“-Berechtigungsträger lediglich verdeutlichen soll, dass der Berechtigungsträger als Transportmittel für die zumindest eine Berechtigung verwendet wird; dies schließt jedoch nicht aus, dass der Berechtigungsträger nicht auch selbst in der Lage ist, Berechtigungen aktiv zu verwenden.
Alternativ oder zusätzlich kann die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal von der vertrauenswürdigen Instanz empfangen werden. Beispielsweise ist es vorstellbar, dass die Verifizierungseinheit (beispielsweise im Fahrzeug) die zumindest eine Berechtigung direkt, z.B. über eine Internetverbindung, vom TrustCenter abholt.
Vorzugsweise wird ferner die zumindest eine Berechtigung von der Verifizierungseinheit auf einen Zielberechtigungsträger über einen zweiten, vorzugsweise ungesicherten, Kommunikationskanal übertragen. Hierdurch wird es ermöglicht, dass die zumindest eine Berechtigung, welche die Verifizierungseinheit ggf. von dem oben erläuterten Transportberechtigungsträger, z.B. ein Smartphone, erhalten hat, auf einen weiteren Berechtigungsträger, beispielsweise eine Smartcard, übermittelt wird. Dieser erfindungsgemäße Aspekt trägt der Forderung mancher Automobilhersteller Rechnung, wonach ein Smartphone zwar zum Entriegeln der Fahrzeugtüren eingesetzt werden kann, nicht jedoch zum Starten des Fahrzeugs, was in diesem Beispiel mittels der Berechtigung auf der Smartcard erfolgt. In diesem Aspekt, d.h. der Übertragung von zumindest einer Berechtigung auf beliebige Berechtigungsträger über einen ungesicherten Kommunikationskanal, zeigt sich die signifikante Flexibilitätssteigerung des erfindungsgemäßen Verfahrens, welches dank der Signatur der zumindest einen Berechtigung trotzdem höchsten Sicherheitsstandards genügt.
Die vorliegende Erfindung ermöglicht außerdem auch eine direkte Übermittlung zumindest einer Berechtigung von einem Transportberechtigungsträger auf einen Zielberechtigungsträger. Hierzu wird ein Verfahren zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems bereitgestellt, in welchem die zumindest eine Berechtigung von einem Transportberechtigungsträger über einen dritten, vorzugsweise ungesicherten, Kommunikationskanal an einem Zielberechtigungsträger empfangen wird. Um auch hier die Echtheit der zumindest einen Berechtigung zu garantieren, ist diese von einer vertrauenswürdigen Instanz kryptographisch signiert.
Wie weiter oben bereits erläutert wurde, kann die zumindest eine Berechtigung an dem Transportberechtigungsträger von der vertrauenswürdigen Instanz über einen, bevorzugt ungesicherten, vierten Kommunikationskanal empfangen werden. Ferner wird es wie ebenfalls weiter oben beschrieben wurde, möglich dass die zumindest eine Berechtigung auf ihre Echtheit und ihren Ursprung in der vertrauenswürdigen Instanz überprüft wird, was vorzugsweise von der Verifizierungseinheit des zu schützenden Objekts durchgeführt wird.
Ferner kann das Verfahren den weiteren Schritt des Authentisierens des Zielberechtigungsträgers gegenüber der Verifizierungseinheit aufweisen. Somit kann der Zielberechtigungsträger (beispielsweise eine Smartcard) seine Identität gegenüber der Verifizierungseinheit eindeutig nachweisen. Auch der Transportberechtigungsträger kann eine Authentifizierungseinheit aufweisen, um sich gegenüber der Verifizierungseinheit zu authentisieren. Dabei kann der Transportberechtigungsträger eine geringer starke Authentifizierungseinheit als der Zielberechtigungsträger aufweisen.
Vorzugsweise ist die zumindest eine Berechtigung einem oder mehreren Berechtigungsträgern, beispielsweise zumindest dem Zielberechtigungsträger, zugeordnet. Somit können bestimmte Zielberechtigungsträger mit Berechtigungen für bestimmte Steuerungsfunktionen (z.B. Deaktivieren der Wegfahrsperre eines Fahrzeugs, Entriegeln eines Fahrzeugs, Verriegeln eines Fahrzeugs, Freigeben der vollen Fahrzeugleistung, Buchung beginnen, Buchung beenden, Freischalten von Zusatzfunktionen wie z.B. Navigationsgerät oder Sitzheizung, oder ähnliches) ausgestattet werden.
Die hier genannten Berechtigungsträger, d.h. der Transportberechtigungsträger und/oder der Zielberechtigungsträger kann ein Internet-fähiger Berechtigungsträger, ein Mobiltelefon, ein Smartphone, ein PDA, ein Tablet-Computer, eine Smartwatch, eine Smartcard, eine NFC-Karte, ein Smart Token, ein Fahrzeugschlüssel, eine RFID-Karte und/oder eine SIM-Karte sein.
Die zumindest eine Berechtigung ist bevorzugt ein Zertifikat, besonders bevorzugt ein digitales Zertifikat, beispielsweise ein Public-Key-Zertifikat nach dem Standard X.509, oder auch ein anderes proprietäres Zertifikatsystem. Die zumindest eine Berechtigung kann eine oder mehrere der folgenden Limitierungen aufweisen: eine zeitliche Limitierung, eine funktionale Limitierung, eine Kanallimitierung, eine Limitierung auf einen oder mehrere Berechtigungsträger und/oder Berechtigungsträgergruppen, eine Limitierung auf ein oder mehrere zu schützende Objekte, eine örtliche Limitierung und/oder eine personenbezogene Limitierung.
In einem weiteren Aspekt der vorliegenden Erfindung können ein oder mehrere Transportberechtigungsträger (20) dafür verwendet werden, die Berechtigung (bzw. Auch mehrere Berechtigungen) an ein Ziel (d.h. vorzugsweise einen Zielberechtigungsträger (40) oder eine Verifikationseinheit (35)) zu übermitteln, solange bis das Ziel dies dem Sender (10) (d.h. vorzugsweise einer vertrauenswürdigen Instanz), bestätigt. Hierdurch wird der Absender, d.h. im allgemeinen das TrustCenter, darüber informiert, dass die Berechtigung am Ziel angekommen ist, sogar wenn die Berechtigung hierzu über eine Kette von Berechtigungsträgern wandert. Es versteht sich, dass weitere Aspekte der vorliegenden Erfindung eine solche Kette von Berechtigungsträgern auch ohne die oben genannte Bestätigung vorsehen können.
Die vorliegende Erfindung betrifft ferner ein Computerprogramm, aufweisend Anweisungen zum Implementieren eines der oben erläuterten Verfahren.
Außerdem wird ein System zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems bereitgestellt, wobei das System eine Verifizierungseinheit eines zu schützenden Objekts aufweist, die geeignet ist zum Empfangen der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal, wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz kryptographisch signiert ist. Ferner wird ein System zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems bereitgestellt, wobei das System einen Zielberechtigungsträger aufweist, der geeignet ist zum Empfangen der zumindest einen Berechtigung über einen dritten Kommunikationskanal von einem Transportberechtigungsträger, wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz kryptographisch signiert ist. Im Übrigen können Ausführungsformen der oben erläuterten Systeme eingerichtet sein, um alle oder zumindest einige der weiter oben erläuterten Verfahren durchzuführen. Weitere vorteilhafte Ausgestaltungen der erfindungsgemäßen Systeme sind in den abhängigen Patentansprüchen angegeben.
4. Figurenbeschreibung
Im Folgenden wird die Erfindung unter Bezugnahme auf die beiliegenden Figuren näher beschrieben. Es zeigen:
1: Ein schematisches Blockdiagramm, welches das Zusammenspiel verschiedener Komponenten gemäß Ausführungsformen der Erfindung illustriert; und
2: Eine beispielhafte Berechtigung im XML-Format gemäß Ausführungsformen der Erfindung (sogenanntes „BlueID Ticket“).
5. Beschreibung bevorzugter Ausführungsbeispiele
Bevorzugte Ausführungsformen der vorliegenden Erfindung stellen computerimplementierte Verfahren und Systeme bereit, welche die Sicherheit von Smartcards mit den Vorzügen Internet-fähiger Smartphones vereinen. Hierbei kann zumindest eine Berechtigung für ein zu schützendes Objekt über einen unsicheren Kanal auf einen Berechtigungsträger übertragen und trotzdem sicher und zuverlässig verwendet werden. Nachfolgend wird der Einfachheit halber der Begriff „Berechtigung“ sowohl im Singular als auch im Plural verwendet, es versteht sich jedoch, dass die vorliegende Erfindung auf eine beliebige Anzahl von Berechtigungen anwendbar ist.
Erfindungsgemäße Systeme umfassen dabei je nach Ausführungsform zumindest eine Teilmenge der nachfolgend mit Verweis auf 1 erläuterten Komponenten:

– Eine vertrauenswürdige Instanz 10 (auch „TrustCenter“ genannt), welche geeignet ist, eine oder mehrere Berechtigungen zu erstellen und zu signieren. Ein TrustCenter ist allgemein ein Dienst, dem alle Parteien vertrauen und der in der Lage ist, Berechtigungen auszustellen und dann zu signieren. Er kümmert sich darum, dass nur der Berechtigte Berechtigungen ausstellen kann und dass die zur Ausstellung der Berechtigung notwendigen Geheimnisse sicher verwahrt und verwendet werden. Idealerweise, aber nicht zwingend, ist ein TrustCenter an das Internet angeschlossen, damit die Berechtigungen einfach und schnell verteilt werden können. Da dies allerdings ein Sicherheitsrisiko darstellt, sollte das TrustCenter bevorzugt mehrere Schichten aufweisen, um somit einen besseren Schutz und notfalls eine bessere Mitigation bei Angriffen zu erreichen. Dabei hat die äußerste Schicht typischerweise die Aufgabe, Angriffe abzuwehren und die innere(n) Schicht(en) zu schützen. Eine zweite Schicht ist typischerweise für die Verwaltung und Ausstellung von Berechtigungen und/oder die Überprüfung der Erlaubnis zur Erstellung von Berechtigungen zuständig. Eine dritte Schicht übernimmt typischerweise die Signierung der Berechtigungen. Optimaler Weise ist noch eine vierte Schicht vorgesehen, die der sicheren Abspeicherung der kryptographischen Geheimnisse dient. Hierzu wird häufig ein sogenanntes Hardware Secure Element verwendet, welches allerdings auch in der dritten Schicht integriert sein kann. Ein TrustCenter kann an verschiedenen Stellen im Gesamtsystem angeordnet werden. Idealerweise ist der Aufstellort gegen unberechtigten Zugriff (digital wie auch physikalisch) geschützt, wird überwacht um Manipulation zu erkennen und hat eine hohe Verfügbarkeit für das Abrufen von erstellten Berechtigungen. Zumeist wird dies in einem besonderen Bereich eines Rechenzentrums der Fall sein. Es wird allerdings auch häufig ein Aufstellort im Arbeitsraum des Wachmanns gewählt. Somit ist das Sicherheitsniveau niedrig. Betrieben werden kann ein TrustCenter beispielsweise als CloudService für eine Mehrzahl von Nutzern durch eine vertrauenswürdige Instanz, wie z.B. das Unternehmen der Anmelderin, oder auch lokal durch die IT-Abteilung des jeweiligen Unternehmens.
– Zumindest ein zu schützendes Objekt 30 (auch „secured Object“ genannt), welches durch das erfindungsgemäße Berechtigungssystem verwaltet wird. Hierbei kann es sich beispielsweise um Fahrzeuge (z.B. KFZ, LKW, Nutzfahrzeuge), elektrische und/oder elektronische Maschinen (z.B. Waschanlage für das Auto, Aufzüge), Schlösser (z.B. elektronisches Zylinderschloss, elektronischer Beschlag, elektronischer Türöffner), Schranken und/oder Tore, Schiebetüren und/oder Drehtüren, oder ähnliches handeln.
– Eine oder mehrere Berechtigungen, welche vorzugsweise einem oder mehreren definierten Berechtigungsträgern zugeordnet sind. Eine Berechtigung kann beispielsweise im XML-Format definiert werden. Im Ausführungsbeispiel nach 2 wird beispielsweise die Signatur, die im Feld permission->signature abgespeichert ist, über alle Nutzdaten zwischen den permission-Tags gebildet. Somit kann eine Verifizierungseinheit die Echtheit überprüfen.
– Ein oder mehrere Berechtigungsträger 20, 40, welche geeignet sind, eine oder mehrere (signierte) Berechtigungen zu speichern. Ein Berechtigungsträger 20, 40 kann eine Authentifizierungseinheit aufweisen, welche geeignet ist, sich gegenüber der Verifizierungseinheit 35 (siehe unten) kryptographisch zu authentisieren. Ein solcher Berechtigungsträger 20, 40 ist somit zum Transport und zur Speicherung bzw. Nutzung zumindest einer Berechtigung geeignet (z.B. eine Smartcard oder ein Smartphone). Berechtigungsträger 20, 40 ohne Authentifizierungseinheit können sich nicht authentisieren und stellen somit keine vollwertigen Schlüssel dar; sie dienen lediglich zum Transport zumindest einer Berechtigung (z.B. ein USB-Stick).
– Eine Verifizierungseinheit 35 im zu schützenden Objekt 30 (oder mit dem schützenden Objekt 30 verbunden), welche geeignet ist, zu prüfen ob die zumindest eine Berechtigung korrekt und unverändert vom TrustCenter 10 stammt und/oder ob der Berechtigungsträger 20, 40 der ist, für den er sich ausgibt (Authentifizierung). Die Verifizierungseinheit ist vorzugsweise ein abgeschlossenes System, das gegen Manipulation geschützt ist. Es kann einen Prozessor aufweisen, der geeignet ist um die Kommunikation mit dem Berechtigungsträger zu steuern und/oder die Verifikation der Berechtigung durchzuführen. Bei einem Fahrzeug ist dies häufig das BCM (Body Control Module). Bei besonders kleinen und stromverbrauchsorientierten Implementierungen, wie beispielsweise elektronischen Schließzylindern, wird dies häufig direkt in der Kommunikationseinheit, also z.B. dem BluetoothLE-Chip durchgeführt.

Ein besonderer Vorteil der vorliegenden Erfindung ist es, dass ein nicht mit dem Internet verbundener Berechtigungsträger 40 für das Ausführen, Veranlassen bzw. Auslösen einer Steuerungsfunktion eines technischen Systems 30 berechtigt werden kann, ohne dass hierfür die zumindest eine Berechtigung mit dem Berechtigungsträger 40 am TrustCenter 10 abgeholt werden muss. Dies wird dadurch erzielt, dass die Berechtigung und die Authentifizierung voneinander getrennt sind. Durch eine digitale Signatur sichert das TrustCenter 10 den Umfang und Inhalt der Berechtigung kryptographisch ab, also welcher Berechtigungsträger 40 was machen darf. Zum Zeitpunkt der Berechtigungserstellung muss die Identität des Zielberechtigungsträgers 40 dem TrustCenter 10 bekannt sein.
Nach der Erstellung der Berechtigung im TrustCenter 10 kann dank der erfindungsgemäßen Verfahren und Systeme die Berechtigung nicht nur direkt vom TrustCenter 10 auf den Berechtigungsträger 40 heruntergeladen werden, sondern über einen beliebigen unsicheren Kanal (beispielsweise über einen weiteren Berechtigungsträger 20, einen sogenannten „Transportberechtigungsträger“) auf den Zielberechtigungsträger 40 übertragen werden. Trotzdem kann die Berechtigung auf dem Zielberechtigungsträger 40 sicher und zuverlässig genutzt werden.
Zum Ausstatten eines Zielberechtigungsträgers 40 mit einer oder mehreren Berechtigungen sieht die vorliegende Erfindung verschiedene beispielhafte Ausführungsformen vor:
Beispiel 1:

1. Das TrustCenter 10 überträgt die Berechtigung über den Kanal 100 (z.B. Internet, SMS, QR-Code, GSM, online angebundener Kartenleser/-schreiber, oder einen anderen wie eingangs genannten unsicheren Kanal) auf den Transportberechtigungsträger 20 (z.B. ein Smartphone). Optional kann der Transportberechtigungsträger 20 ebenfalls eine oder mehrere Berechtigungen für das zu sichernde Objekt 30 aufweisen und/oder die übertragene Berechtigung nutzen.
2. Der Transportberechtigungsträger 20 überträgt die Berechtigung über den Kanal 600 vorzugsweise direkt (z.B. vorzugsweise über NFC, je nach Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0–3.0) oder Bluetooth LE / Smart) auf den Zielberechtigungsträger 40 (z.B. eine Smartcard).

Besonders vorteilhaft ist hierbei, dass die Berechtigung über einen unsicheren Kanal (z.B. Smartphone) vom TrustCenter 10 auf den Zielberechtigungsträger 40 (z.B. Smartcard) übertragen werden kann. Insbesondere ist kein physischer Kontakt zwischen Zielberechtigungsträger 20 und TrustCenter 10 nötig. Dieses Ausführungsbeispiel kann jedoch durch Vorgaben des Transportberechtigungsträgers 20 beschränkt werden (beispielsweise erlauben nicht alle derzeit erhältlichen Smartphones eine direkte Kommunikationsverbindung mit einer Smartcard).
Beispiel 2:

1. Das TrustCenter 10 überträgt die Berechtigung über den Kanal 100 (z.B. Internet, SMS, QR-Code, GSM, online angebundener Kartenleser/-schreiber, oder einen anderen wie eingangs genannten unsicheren Kanal) auf den Transportberechtigungsträger 20 (z.B. ein Smartphone). Optional kann der Transportberechtigungsträger 20 ebenfalls eine oder mehrere Berechtigungen für das zu sichernde Objekt 30 aufweisen und/oder die übertragene Berechtigung nutzen.
2. Der Transportberechtigungsträger 20 überträgt die Berechtigung über den Kanal 200 (z.B. vorzugsweise Bluetooth LE oder classic, NFC, Zigbee, allgemeine Funkstrecken wie z.B. 866 MHz, oder einen anderen wie eingangs genannten unsicheren Kanal) auf die Verifizierungseinheit 35 des zu sichernden Objekts 30 (z.B. ein Fahrzeug).
3. Die Verifizierungseinheit 35 überträgt die Berechtigung über den Kanal 400 (z.B. vorzugsweise NFC, je nach Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0–3.0) oder Bluetooth LE / Smart) auf den Zielberechtigungsträger 40 (z.B. eine Smartcard), vorzugsweise sobald dieser mit der Verifizierungseinheit 35 kommuniziert.

Auch hier kann die Berechtigung über einen unsicheren Kanal (z.B. Smartphone) vom TrustCenter 10 auf den Zielberechtigungsträger 40 (z.B. Smartcard) übertragen werden. Anschließend kann die Verifizierungseinheit 35 eingerichtet sein, um die Berechtigung wieder aus ihrem Speicher zu löschen. Dies kann insbesondere im Kontext von Autovermietungen vorteilhaft sein, bei denen die Verifizierungseinheit eines gegebenen Fahrzeugs binnen kurzer Zeit mit einer Vielzahl von Berechtigungen (für die verschiedenen Kunden) beladen wird, was zu Speicherengpässen führen könnte. Ferner fordern manche Automobilhersteller, dass eine Berechtigung niemals im Fahrzeug verbleiben darf, was ebenfalls durch dieses Ausführungsbeispiel adressiert wird.
Beispiel 3:

1. Die Verifizierungseinheit 35 des zu schützenden Objekts 30 lädt die Berechtigung über den Kanal 300 vorzugsweise direkt (z.B. über Internet, allgemeine Funkstrecken wie z.B. 866 MHz, SMS, GSM, oder einen anderen wie eingangs genannten unsicheren Kanal) vom TrustCenter 10 herunter.
2. Die Verifizierungseinheit 35 überträgt die Berechtigung über den Kanal 400 (z.B. vorzugsweise NFC, je nach Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0–3.0) oder Bluetooth LE / Smart) auf den Zielberechtigungsträger 40 (z.B. eine Smartcard), vorzugsweise sobald dieser mit der Verifizierungseinheit 35 kommuniziert.

Hierbei ist besonders vorteilhaft, dass die Berechtigung ohne zeitintensive Umwege auf den Berechtigungsträger gelangen kann, da die Verifizierungseinheit bevorzugt direkt mit dem Internet verbunden ist. Zudem kann die Zustellung einer Berechtigung einfach nachvollzogen werden. Ein möglicher Nachteil ist hier, dass eine Onlineanbindung notwendig ist. Sobald z.B. in einer Tiefgarage keine Internetverbindung bei einem z.B. Fahrzeug vorhanden ist, kann keine neue Berechtigung aufgespielt werden. Hier muss dann ein alternativer Kanal benutzt werden, da das Fahrzeug ja nicht ohne Berechtigung aus der Tiefgarage kommt.
Sobald die Berechtigung auf den Zielberechtigungsträger 40 übertragen wurde, kann diese entsprechend benutzt werden. Um zu überprüfen, ob ein Berechtigungsträger eine Aktion durchführen darf, werden in bevorzugten Ausführungsformen zwei Schritte durchgeführt:

1. Die Berechtigung wird von der Verifizierungseinheit geladen (z.B. aus einem lokalen Speicher oder vom Berechtigungsträger) und wird von der Verifizierungseinheit überprüft. Dabei wird bevorzugt zunächst ein Hash über den Inhalt erstellt und dann die Signatur mittels Public-Key des ausstellenden TrustCenters verifiziert. Nun wird der Inhalt analysiert. Wenn die Berechtigung für die Verifizierungseinheit bestimmt ist und die weiteren Limitierungen eintreffen, wird die Identität des dazugehörigen Berechtigungsträgers aus der Berechtigung ausgelesen.
2. Nun kann die Identität des Berechtigungsträgers überprüft werden. Hierzu wird vorzugsweise überprüft, ob in dem Berechtigungsträger ein bestimmtes Geheimnis vorhanden ist. Die dazu nötigen Überprüfungsdaten lassen sich aus der Indentitätsbeschreibung des Berechtigungsträgers herleiten. Üblicherweise wird dazu eine Zufallszahl an den Berechtigungsträger gesandt und dessen Antwort kryptographisch über den Public-Key des Berechtigungsträgers aus der Berechtigung verifiziert. Wenn der Berechtigungsträger zur Berechtigung passt, so wird die Aktion durchgeführt bzw. freigegeben.

Ferner erlaubt die vorliegende Erfindung auch Ausführungsformen, in welchen die Berechtigung auf der Verifizierungseinheit 35 verbleibt, d.h. nicht auf den Zielberechtigungsträger 40 übertragen wird. Die entsprechenden Abläufe sind:
Beispiel 4:

1. Das TrustCenter 10 überträgt die Berechtigung über den Kanal 100 (z.B. Internet, Internet, allgemeine Funkstrecken wie z.B. 866 MHz, SMS, GSM, oder einen anderen wie eingangs genannten unsicheren Kanal) auf den Transportberechtigungsträger 20 (z.B. ein Smartphone). Optional kann der Transportberechtigungsträger 20 ebenfalls eine oder mehrere Berechtigungen für das zu sichernde Objekt 30 aufweisen und/oder die übertragene Berechtigung nutzen.
2. Der Transportberechtigungsträger 20 überträgt die Berechtigung über den Kanal 200 (z.B. vorzugsweise NFC, je nach Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0–3.0) oder Bluetooth LE / Smart) auf die Verifizierungseinheit 35 des zu sichernden Objekts 30 (z.B. ein Fahrzeug).

Beispiel 5:

1. Die Verifizierungseinheit 35 des zu schützenden Objekts 30 lädt die Berechtigung über den Kanal 300 vorzugsweise direkt (z.B. über Internet, allgemeine Funkstrecken wie z.B. 866 MHz, SMS, GSM, oder einen anderen wie eingangs genannten unsicheren Kanal) vom TrustCenter 10 herunter.

Hierdurch können besonders schnelle Verifikationszeiten erreicht werden (siehe den Pfeil 500 in 1), da die Berechtigung nicht auf den Zielberechtigungsträger 40 übertragen werden muss. Zudem kann eine Vorverifikation der Berechtigung stattfinden. Somit muss die Berechtigung nicht mehr zum Zeitpunkt der Ausführung überprüft werden, sondern kann dann bereits als sicher angesehen werden.
In allen dargestellten Ausführungsformen muss der Berechtigungsträger 40 und/oder die Verifizierungseinheit 35 vorzugsweise am TrustCenter 10 bekannt gemacht werden, um die Authentifizierung zu ermöglichen. Dies geschieht vorzugsweise vor der Erstellung der zumindest einen Berechtigung durch das TrustCenter 10. Das Bekanntmachen kann dabei folgendes umfassen:

1. Die Verifizierungseinheit erhält vor Einsatzbeginn den Public-Key des Trust Centers, dem sie vertrauten soll. Dies passiert meist bei der Produktion oder bei der Inbetriebname mittels eines Konfigurationstools.
2. Die Identität der Berechtigungsträger und der Identifier der Verifikationseinheit muss dem TrustCenter spätestens beim Erstellen einer Berechtigung vorliegen, damit diese in die Berechtigung eingetragen werden können.

Alle hier beschriebenen Ausführungsformen haben gemeinsam, dass die Berechtigungen vom TrustCenter 10 signiert sind und von der Verifizierungseinheit 35 auf ihre Echtheit und ihren Ursprung im TrustCenter 10 überprüft werden können, sodass die Berechtigungen auch über ungesicherte bzw. unsichere Kanäle vertrieben werden können.
Im Rahmen der vorliegenden Erfindung können unter anderem die folgenden Berechtigungsträger 20, 40 zum Einsatz kommen:

– Internet-verbundene bzw. temporär mit dem Internet verbundene, im Allgemeinen Internet-fähige Vorrichtungen: – Smartphone – Mobiltelefone mit der Möglichkeit zum Aufspielen von Anwendungsprogrammen (sogenannten „Apps“) – Smartwatch
– Offline-Vorrichtungen bzw. Vorrichtungen mit asynchroner Anbindung ohne direkte Internetverbindung: – NFC-Karte, z.B. Smartcard – SmartToken, z.B. Autoschlüssel, Gebäudeschlüssel, Zugangskarte, usw. – RFID-Karte – SIM-Karte – Smartwatch

Die hier erläuterte zumindest eine Berechtigung kann eine oder mehrerer der folgenden Komponenten umfassen:

– Zeitliche Limitierung, z.B. Gültigkeitszeitraum
– Funktionale Limitierung, z.B. nur Funktion „Öffnen“
– Kanalgebundenheit, z.B. nur NFC
– Limitierung auf einen oder mehrere Berechtigungsträger oder deren Gruppe
– Limitierung auf ein oder mehrere zu schützende Objekte
– Örtliche Limitierung, z.B. nur in München oder nur im Umkreis von x Metern von einem bestimmten Ort
– Limitierung auf Personen, Personengruppen und/oder Benutzerrollen

Nachfolgend wird ein illustratives Anwendungsbeispiel erläutert, welches die Vorteile der vorliegenden Erfindung verdeutlichen soll:
Bei einer Autovermietung hat jeder Nutzer eine persönliche Kundenkarte, nämlich eine Smartcard 40, welche dem Benutzer eindeutig zugeordnet ist. Der Benutzer bucht ein Auto direkt mit seinem Smartphone 20. Kurz vor Buchungsbeginn erhält der Benutzer zum einen die zeitlich zur Buchung passende digitale Berechtigung und die Position des Fahrzeugs 30 auf sein Smartphone 20. Der Benutzer begibt sich zum Fahrzeug 30, welches sich in der Tiefgarage der Autovermietung befindet, und öffnet dieses mit dem Smartphone 20 mittels z.B. des Datenkanals BLE („Bluetooth Low Energy“) bzw. mittels eines der in den Europäischen Patenten EP 1 910 134 B1 , EP 2 564 583 B1 und EP 2 193 607 B1 der Anmelderin beschriebenen Verfahren und setzt sich hinein. Um die Sicherheit zu erhöhen, kann das Starten des Fahrzeugs 30 nur mit der persönlichen Smartcard 40 erfolgen. Deshalb wurde während des Öffnungsvorgangs vom Smartphone 20 die Berechtigung zum Starten des Fahrzeugs 30 auf dessen Verifizierungseinheit 35 übertragen, wobei die Berechtigung der Smartcard 40 zugeordnet ist. Der Benutzer legt die Smartcard 40 auf einen Leser 35 im Fahrzeug 30 und die Berechtigung wird auf die Smartcard 40 übertragen. Nun kann die Smartcard 40 vom Fahrzeug 30 bzw. der Verifizierungseinheit 35 authentifiziert und die Berechtigung verifiziert werden. Das Fahrzeug 30 kann anschließend gestartet werden.
Ferner kann die Smartcard 40 auch die Lokalisierung (Thatchem) und/oder die Zertifizierung (z.B. CC EAL₅₊) übernehmen. Die Verwendung einer SmartCard von einem renomierten Hersteller wie z.B. G&D bringt zudem den Vorteil, dass diese Karten in einer Ausführung am Markt erworben werden können, die höchsten Anforderungen an Identitätsträger genügt. Dies ist z.B. eine Zertifizierung nach Common Criteria (z.B. EAL₅₊). Eine SmartCard, die NFC als Kommunikationskanal verwendet, löst zudem das Problem der Erkennung des Berechtigungsträgers im Fahrzeug, da diese nur in einem Leser gelesen werden können, der einen auf wenige Zentimeter beschränkten Lesebereich hat.
Bezugszeichenliste

10: Vertrauenswürdige Instanz („TrustCenter“)
20: Transportberechtigungsträger
30: Zu schützendes Objekt
35: Verifizierungseinheit
40: Zielberechtigungsträger
100: Übertragung der Berechtigung vom TrustCenter auf den Transportberechtigungsträger
200: Übertragung der Berechtigung vom Transportberechtigungsträger auf die Verifizierungseinheit
300: Übertragung der Berechtigung vom TrustCenter auf die Verifizierungseinheit
400: Übertragung der Berechtigung von der Verifizierungseinheit auf den Zielberechtigungsträger
500: Authentifizierung des Zielberechtigungsträgers
600: Übertragung der Berechtigung vom Transportberechtigungsträger auf den Zielberechtigungsträger

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

EP 1910134 B1 [0002, 0037]
EP 2564583 B1 [0037]
EP 2193607 B1 [0037]

Claims

Ein Verfahren zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems, wobei das Verfahren die folgenden Schritte aufweist: a. Empfangen der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (200, 300) an einer Verifizierungseinheit (35) eines zu schützenden Objekts (30); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz (10) kryptographisch signiert ist.
Das Verfahren nach Anspruch 1, wobei die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal (200) von einem Transportberechtigungsträger (20) empfangen wird.
Das Verfahren nach Anspruch 1, wobei die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal (300) von der vertrauenswürdigen Instanz (10) empfangen wird.
Das Verfahren nach einem der vorstehenden Ansprüche, ferner aufweisend: Übertragen der zumindest einen Berechtigung von der Verifizierungseinheit (35) auf einen Zielberechtigungsträger (40) über einen zweiten Kommunikationskanal (400).
Ein Verfahren zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems, wobei das Verfahren die folgenden Schritte aufweist: a. Empfangen der zumindest einen Berechtigung über einen dritten Kommunikationskanal (600) an einem Zielberechtigungsträger (40) von einem Transportberechtigungsträger (20); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz (10) kryptographisch signiert ist.
Das Verfahren nach einem der vorstehenden Ansprüche 2, 4 oder 5, ferner aufweisend: Empfangen der zumindest einen Berechtigung an dem Transportberechtigungsträger (20) von der vertrauenswürdigen Instanz (10) über einen vierten Kommunikationskanal (100).
Das Verfahren nach einem der vorstehenden Ansprüche, ferner aufweisend: Überprüfen der zumindest einen Berechtigung auf ihre Echtheit und ihren Ursprung in der vertrauenswürdigen Instanz (10).
Das Verfahren nach einem der vorstehenden Ansprüche 4–7, ferner aufweisend: Authentisieren (500) des Zielberechtigungsträgers (40) gegenüber der Verifizierungseinheit (35) in der Verifizierungseinheit (35).
Das Verfahren nach einem der vorstehenden Ansprüche 2 oder 5–8, wobei der Transportberechtigungsträger (20) eine Authentifizierungseinheit aufweist, um sich gegenüber der Verifizierungseinheit (35) authentisieren zu können.
Das Verfahren nach Anspruch 9, wobei der Transportberechtigungsträger (20) eine geringer starke Authentifizierungseinheit als der Zielberechtigungsträger (40) aufweist.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die zumindest eine Berechtigung einem Berechtigungsträger (20, 40) oder mehreren Berechtigungsträgern (20, 40) zugeordnet ist.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei der Transportberechtigungsträger (20) und/oder der Zielberechtigungsträger (40) ein Internet-fähiger Berechtigungsträger, ein Mobiltelefon, ein Smartphone, ein Tablet-Computer, eine Smartwatch, eine Smartcard, eine NFC-Karte, ein Smart Token, ein Fahrzeugschlüssel, eine RFID-Karte und/oder eine SIM-Karte ist.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die zumindest eine Berechtigung ein Zertifikat ist.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die zumindest eine Berechtigung eine oder mehrere der folgenden Limitierungen aufweist: eine zeitliche Limitierung, eine funktionale Limitierung, eine Kanallimitierung, eine Limitierung auf einen oder mehrere Berechtigungsträger und/oder Berechtigungsträgergruppen, eine Limitierung auf ein oder mehrere zu schützende Objekte, eine örtliche Limitierung und/oder eine personenbezogene Limitierung.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei ein oder mehrere Transportberechtigungsträger (20) dafür verwendet werden, die Berechtigung an ein Ziel, vorzugsweise einen Zielberechtigungsträger (40) oder eine Verifikationseinheit (35) zu übermitteln, solange bis das Ziel dies dem Sender (10), vorzugsweise einer vertrauenswürdigen Instanz, bestätigt.
Ein Computerprogramm, aufweisend Anweisungen zum Implementieren eines Verfahrens nach einem der vorstehenden Ansprüche 1–15.
Ein System zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems, wobei das System aufweist: a. eine Verifizierungseinheit (35) eines zu schützenden Objekts (30), die geeignet ist zum Empfangen der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (200, 300); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz (10) kryptographisch signiert ist.
Das System nach Anspruch 17, ferner aufweisend: einen Transportberechtigungsträger (20), der geeignet ist zum Senden der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (200) an die Verifizierungseinheit (35).
Das System nach Anspruch 15, ferner aufweisend: die vertrauenswürdige Instanz (10), die geeignet ist zum Senden der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (300) an die Verifizierungseinheit (35).
Das System nach einem der vorstehenden Ansprüche 17–19, ferner aufweisend: einen Zielberechtigungsträger (40), der geeignet ist zum Empfangen der zumindest einen Berechtigung von der Verifizierungseinheit (35) über einen zweiten Kommunikationskanal (400).
Ein System zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems, wobei das System aufweist: a. einen Zielberechtigungsträger (40), der geeignet ist zum Empfangen der zumindest einen Berechtigung über einen dritten Kommunikationskanal (600) von einem Transportberechtigungsträger (20); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz (10) kryptographisch signiert ist.