-
Die Erfindung betrifft einen Receiver zum Empfang von GNSS-Signalen.
-
Des Weiteren betrifft die Erfindung einen Token zur Verwendung mit einem derartigen Receiver, ein Fahrzeug sowie ein Feldgerät mit einem derartigen Receiver.
-
GNSS-Signale sind dabei Signale eines globalen Navigationssatellitensystems (englisch Global Navigation Satellite System) oder kurz GNSS.
-
Ein derartiger Receiver und ein derartiger Token, kommen beispielsweise in Einsatzfahrzeugen der Feuerwehr, Polizei oder in Bahnfahrzeugen bei sicherheitsrelevanten GNSS gestützten Aufgaben zum Einsatz.
-
Der Erfindung liegt die Aufgabe zugrunde, einen Receiver und einen Token anzugeben, der die Handhabung der Schlüssel zum Entschlüsseln eines verschlüsselten GNSS Systems modular, einfach und sicher ermöglicht.
-
Diese Aufgabe wird durch einen Receiver mit den im Anspruch 1 angegebenen Merkmalen gelöst.
-
Es wird ein Receiver zum Empfang von GNSS-Signalen, insbesondere von Galileo-Signalen, vorgeschlagen, der ein analoges Frontend, das zum Empfang von Empfangsdaten und zur Analog-Digital-Wandlung der Empfangsdaten ausgebildet ist, ein digitales Frontend, das einen Prozessor zur weiteren Verarbeitung der vom analogen Frontend gewandelten Daten aufweist, ein Sicherheits-Interface-Modul, das über ein Sicherheits-Interface, mit dem digitalen Frontend verbunden ist und ein Token-Interface, das zur Aufnahme und Kontaktierung eines Tokens ausgebildet ist, aufweist.
-
Dabei weist das Sicherheits-Interface-Modul einen Sicherheitscontroller auf, der zur Authentifizierung des Tokens ausgebildet ist, wobei das Token-Interface eine sichere Schnittstelle aufweist, die zur Übermittlung von Daten, die zur Abbildung, Berechnung und/oder Entschlüsselung eines verschlüsselten GNSS-Dienstes und/oder -Signals erforderlich sind, ausgebildet ist. Auch die Übermittlung von Daten zur Dekodierung eines GNSS-Signals über die sichere Schnittstelle ist denkbar. Diese Daten können dabei sogenannte Pseudo Random Noise Codes oder auch PRN-Codes sein. Ein so ausgeführter Receiver hat den besonderen Vorteil, dass das Schlüsselmanagement nicht bereits mit der Produktion oder der Inbetriebnahme des Receivers geschehen muss. Das Schlüsselmanagement, also die Verwaltung der für die Entschlüsselung und/oder Berechnung der verschlüsselten GNSS-Dienste und/oder -Signale nötigen Schlüssel, wird so erheblich vereinfacht. Weiterhin ist denkbar, dass Konfigurationsdaten und/oder Freischaltinformationen (Feature Activation) zur Konfiguration oder zur Freischaltung von weiteren Funktionen übermittelt werden.
-
In einer weiteren vorteilhaften Ausgestaltung ist der Receiver in Verbindung mit dem Token zum Zugriff auf einen verschlüsselten GNSS-Dienst, insbesondere einen Public Regulated Service (PRS), ausgebildet. Dies ist besonders vorteilhaft, da der Receiver nur dann mit einem Token versehen werden kann, wenn es erforderlich ist. Die Token können also einzelnen Personen, einzelnen Dienstgraden oder einzelnen Funktionen, wie beispielsweise sicherheitskritischen Funktionen, zugewiesen werden. Ein solcher verschlüsselter GNSS-Dienst ist dabei beispielsweise der Galileo Public Regulated Service oder der Galileo Commercial Service des Galileo GNSS. Diese GNSS-Dienste und/oder -Signale weisen eine höhere Genauigkeit und Zuverlässigkeit auf.
-
In einer weiteren vorteilhaften Ausgestaltung ist der Receiver bei Betrieb ohne Token zum Zugriff auf ein unverschlüsseltes GNSS Signal, insbesondere Galileo Open Service, ausgebildet. Dies ist besonders vorteilhaft, da die Integrationsdichte des Receivers steigt und nur ein einzelner Receiver zum Empfang von unverschlüsselten und verschlüsselten Signalen nötig ist. In Fällen, in denen ein unverschlüsseltes Signal ausreichend genau und/oder ausreichend zuverlässig ist, kann auf den Token verzichtet werden.
-
In einer weiteren vorteilhaften Ausgestaltung ist die sichere Schnittstelle als eine optische Schnittstelle und/oder als eine Schnittstelle gemäß ISO 7816 und/oder USB-Standard ausgebildet. Alternative Schnittstellen, wie I2C und/oder SPI und/oder RS232 oder einer Kombination aus den genannten oder weiteren bekannten Schnittstellen sind ebenfalls möglich. Es ist denkbar, dass über die optische Schnittstelle die sicherheitstechnisch kritischen Daten übertragen werden, da diese bedeutend schwerer abhörbar ist. Eine Energieversorgung könnte beispielsweise über eine Schnittstelle gemäß ISO 7816 zur Verfügung gestellt werden, wobei hier vor allem Smartcard-Schnittstellen oder ähnliche Kontaktierungen zu nennen sind. Auch Schnittstellen gemäß USB-Standard mit einem sicheren Kanal sind denkbar.
-
In einer weiteren vorteilhaften Ausgestaltung weist der Receiver ein Codierfeld auf, insbesondere ein Eingabefeld zur Eingabe eines Pins oder ein biometrisches Eingabefeld. So kann eine so genannte Zwei-Faktor-Authentifizierung durchgeführt werden, in dem beispielsweise eine PIN oder ein Finderabdruck zusätzlich zu einem Token zum Freischalten der erweiterten Funktionen des Tokens abgefragt werden muss. Dabei kommuniziert das Codierfeld mit beispielsweise mit einer Instanz zur Berechtigungsabfrage und/oder Zugriffsschutz im Receiver. Der Schutz vor unberechtigten Zugriffen auf die verschlüsselten GNSS-Dienste und/oder -Signale wird so nochmals erhöht.
-
Die Aufgabe wird weiterhin durch einen Token zur Verwendung mit einem Receiver gelöst, wobei der Token zur Verbindung mit dem Token-Interface des Receivers ausgebildet ist, einen Sicherheitscontroller zur Authentifizierung des Tokens am Receiver aufweist, einen Token-Prozessor zur Generierung von Daten, die notwendig sind das jeweilige Satellitensignal im Empfänger abzubilden, zu berechnen und/oder zu entschlüsseln, aufweist und eine sichere Token-Schnittstelle zur Übertragung der Daten an den Receiver aufweist. Dabei kann es sich beispielsweise um PRN-Codes handeln.
-
In dieser Ausführungsform kann der Token besonders klein und leicht ausgeführt werden. Das Schlüsselmanagement, also die Verwaltung der für die Entschlüsselung der verschlüsselten GNSS-Dienste und/oder -Signale nötigen Schlüssel, wird so erheblich vereinfacht, da der Token separat vom Receiver gelagert und einfach entfernt werden kann. Damit ist eine personalisierte Verantwortung des jeweiligen Trägers des Tokens möglich. Zur Schlüsselverwaltung ist es damit nicht mehr nötig, den Receiver aufwändig aus seinem Endverbleib zu entfernen oder auszubauen. Die Security-Anforderungen an einen derartigen Receiver ohne Token sind deutlich geringer und auch ein Diebstahl des Receivers ohne den Token stellt ein äußerst geringes Risiko dar.
-
In einer weiteren vorteilhaften Ausgestaltung ist die sichere Token-Schnittstelle als eine optische Schnittstelle und/oder eine Schnittstelle gemäß ISO 7816 und/oder USB-Standard ausgebildet. Alternative Schnittstellen, wie I2C und/oder SPI und/oder RS232 oder einer Kombination aus den genannten oder weiteren bekannten Schnittstellen sind ebenfalls möglich. Analog zur sicheren Schnittstelle des Receivers ist die sichere Token-Schnittstelle ebenfalls optisch ausführbar. Der Token liefert über diese Schnittstelle die zur Nutzung der verschlüsselten GNSS-Dienste und/oder -Signale relevanten Daten.
-
In einer weiteren vorteilhaften Ausgestaltung weist der Token einen Tamper-Schutz auf. Ein Tamper-Schutz kann dabei beispielsweise im Token-Prozessor und/oder im Sicherheitscontroller des Tokens implementierte Funktion sein, die eine Manipulation oder ein unbefugtes Auslesen des Tokens erschwert oder ausschließt. Alternativ kann es sich bei den Tamper-Schutz-Maßnahmen auch um rein mechanische Maßnahmen handeln, die es beispielsweise unmöglich machen, den Token zu öffnen. Dazu wäre ein vergießen der kompletten Token-Platine und des Gehäuses in ein Harz, beispielsweise ein Epoxidharz, denkbar. Beim Öffnen des Tokens würde das Harz dazu führen, dass die Prozessoren bzw. die Sicherheitscontroller abreißen und damit dauerhaft unbrauchbar werden.
-
In einer weiteren vorteilhaften Ausgestaltung weist der Token ein Mittel zur mechanischen Zerstörung des Tokens-Prozessors und/oder des Sicherheitscontrollers auf.
-
Sollte es also trotz der vorhandenen Sicherheitsmaßnahmen nötig sein, den Token manuell und mechanisch zu zerstören, ist es denkbar, ein Mittel zur mechanischen Zerstörung vorzusehen. Dabei kann es sich beispielsweise um einen oder mehrere Hebel handeln, die eine Mechanik im Inneren des Tokens auslösen, wie beispielsweise eine Nadel, die dann den Prozessor und/oder den Sicherheitscontroller zerstört.
-
In einer weiteren vorteilhaften Ausgestaltung weist der Token ein Codierfeld, insbesondere ein Eingabefeld zur Eingabe eines PINs oder ein biometrisches Eingabefeld, auf. Um auch tokenseitig eine Zwei-Faktor-Authentifizierung zu ermöglichen, könnte ein vereinfachtes, kleines Eingabefeld für einen PIN vorgesehen sein oder ebenfalls ein biometrisches Eingabefeld, das beispielsweise in Form eines Fingerabdruckscanners ausführbar ist, vorgesehen sein. Dies hat bezüglich des Receivers den Vorteil, dass am Receiver weniger Schnittstellen nach außen benötigt werden und somit ein robusteres Design des Receivers möglich wird.
-
Ebenso ist denkbar, dass der Token eine Authentisierungsschnittstelle aufweist, über die der Token, insbesondere ein Benutzer-Security-Token, authentisierbar ist. Diese Schnittstelle kann beispielsweise als RFID-Schnittstelle oder NFC-Schnittstelle ausgebildet sein.
-
In einer weiteren vorteilhaften Ausgestaltung weist der Token eine Schlüssel-Schnittstelle auf, die zur Programmierung des Tokens mit Schlüsseln vorgehsehen ist.
-
Schlüssel sind dabei die Daten, die für die Entschlüsselung und/oder Berechnung der verschlüsselten Dienste nötig sind. Die Schlüssel sind also notwendig damit der Token in Verbindung mit dem Receiver das verschlüsselte GNSS-Signal entschlüsseln kann. Das vereinfachte Schlüsselmanagement ist ein zentraler Vorteil des Tokens. Beispielsweise ist denkbar, dass die Schlüsselschnittstelle einmalig bei der Produktion des Token verwendet und anschließend versiegelt wird. Dabei ist denkbar, dass die Schlüsselschnittstelle von außerhalb des Token nicht zugänglich ist. Andererseits ist es ebenfalls möglich, dass der Token über seine Schlüsselschnittstelle immer wieder mit neuen Schlüsseln programmierbar ist. Dazu könnte der Token bei der zertifizierenden Stelle mit neuen Schlüsseln versehen werden. Es ist dabei denkbar, dass die Schlüsselschnittstelle weitere Sicherheitsmerkmale aufweist. Es könnte dafür nötig sein, ein entsprechendes Programmiergerät mit einer entsprechenden sicheren Schnittstelle zur Programmierung des Tokens mit neuen Schlüsseln zu verwenden.
-
Weiterhin wird eine besonders vorteilhafte Verwendung eines erfindungsgemäßen Receivers in einem Fahrzeug vorgeschlagen.
-
Der erfindungsgemäße Receiver ist besonders in Verbindung mit einem Fahrzeug vorteilhaft, da in das Fahrzeug lediglich der Receiver eingebaut werden muss und die nötigen Schlüssel nachträglich mit jedem Benutzer über den Token hinzugefügt werden können. Bei einem Fahrzeug muss es sich dabei nicht zwangsläufig um ein Kraftfahrzeug handeln, es kann sich ebenso um ein Schienenfahrzeug oder um ein Wasserfahrzeug handeln. Auch der Einsatz eines erfindungsgemäßen Receivers in Flugzeugen oder Helikoptern ist denkbar.
-
In einer vorteilhaften Ausgestaltung eines Fahrzeugs ist der Receiver in Verbindung mit dem Token zur Freischaltung erweiterter Funktionen oder Berechtigungslevels des Fahrzeugs vorgesehen.
-
Ist ein Fahrzeug also mit einem erfindungsgemäßen Receiver ausgerüstet, so ist es denkbar, dass bei Verwendung eines Token erweiterte Funktionen freigeschaltet werden. Dabei kann es sich beispielsweise im Krisenfall um entsprechend wichtige Einsatzfahrzeuge handeln, es ist aber ebenso denkbar, dass beim Transport von besonders wichtigen Gütern ein sonst normales Fahrzeug unter Verwendung eines Receivers mit einem Token für diese sicherheitsrelevante Transportaufgabe freigeschalten wird.
-
Weiterhin wird eine besonders vorteilhafte Verwendung eines Receivers in einem Feldgerät vorgeschlagen. Bei einem Feldgerät kann es sich dabei um einen tragbaren Receiver mit einem Display handeln, der für Navigationsaufgaben verwendbar ist. Auch ein Feldempfänger, der im Krisenfall auf beispielsweise den Galileo Public Regulated Service hochgestuft werden könnte ist denkbar. Es ist aber ebenso denkbar, dass es sich bei dem Feldgerät um einen Receiver handelt, der beispielsweise an ein Transportgut oder an/in einen Container angebracht werden kann, um eine entsprechende Sicherheitsstufe zu erreichen. Dieses Feldgerät kann alternativ ein Zeiterfassungsgerät sein, das zur sicheren Erfassung und Ausgabe der Zeit ausgebildet ist.
-
Im Folgenden wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und erläutert. Es zeigen:
-
1 eine schematische Darstellung eines Receivers und eines Token,
-
2 eine schematische Darstellung eines Token,
-
3 der Signallaufplan von GNSS-Signalen,
-
4 ein Ausführungsbeispiel eines Token und
-
5 ein Ausführungsbeispiel eines Receivers.
-
1 zeigt einen Receiver 1, der ein analoges Frontend 10, ein digitales Frontend 20 und ein Sicherheitsinterface-Modul 40 aufweist. Das analoge Frontend 10 weist weiterhin eine Antennenanordnung 13 sowie einen A/D-Wandler 12 auf. Das analoge Frontend 10 ist zum Empfang von Empfangsdaten 11, die beispielsweise GNSS-Signale GNSS-S oder PRS-Signale PRS-S sein können. Das analoge Frontend 10 kann ebenso einen Verstärker zur Verstärkung der Empfangsdaten 11 aufweisen. Der A/D-Wandler 12 gibt dann die von ihm in digitale Form gewandelten Empfangsdaten 11 an das digitale Frontend 20 weiter. Das digitale Frontend 20 weist einen Prozessor 21 sowie eine Host-Schnittstelle 22 auf. Der Prozessor 21 kann beispielsweise ein FPGA mit integriertem ARM-Prozessor sein und führt dabei unter anderem das Berechnen von sogenannten PVT-Werten (Position Velocity Time) durch. Die Host-Schnittstelle 22 ist als optional anzusehen und ermöglicht die Verbindung des Receivers 1 mit weiteren Geräten. Dazu zählen beispielsweise jede Form von Rechnern oder PCs, Steuergeräte oder in einem Fahrzeug beispielsweise eine übergeordnete Fahrzeugsteuerung. Über ein Sicherheits-Interface 30 ist nun das digitale Frontend 20 mit dem Sicherheits-Interface-Modul 40 verbunden. Das Sicherheits-Interface-Modul 40 weist einen Sicherheitscontroller 41 sowie eine Instanz zur Berechtigungsabfrage oder zum Zugriffsschutz 42 auf. Der Sicherheitscontroller 41 kann beispielsweise als ein Sicherheitscontroller SLE 78 von Infineon ausgebildet sein. Das Sicherheits-Interface-Modul 40 weist außerdem ein Token-Interface 50 auf. Das Token-Interface 50 ist zur Aufnahme eines Token 100 ausgebildet und weist eine sichere Schnittstelle 51 und eine weitere Schnittstelle 52 auf. Das Token-Interface 50 ermöglicht es also, einen Token 100 beliebig oft mit dem Receiver zu verbinden und wieder zu entfernen. Die sichere Schnittstelle 51 ist dabei zur Übertragung der für die Entschlüsselung eines verschlüsselten GNSS-Dienstes nötigen Daten vorgesehen und kann beispielsweise als optische Schnittstelle ausgebildet sein. Es ist aber ebenso denkbar, dass die sichere Schnittstelle 51 eine gängige Schnittstelle wie USB ist, die mit entsprechenden Sicherheitsmechanismen abgesichert ist.
-
Ergänzend ist in 1 der Token 100 zu sehen, der analog zum Token-Interface 50 eine sichere Token-Schnittstelle 151 und eine zweite Token-Schnittstelle 152 aufweist. Dabei könnte die sichere Token-Schnittstelle 151 als optische Schnittstelle ausgebildet sein und die zweite Token-Schnittstelle 152 eine zur Spannungsversorgung des Tokens 100 ausgebildete Schnittstelle sein.
-
2 zeigt eine größere Darstellung des bereits in 1 gezeigten Token 100. Analog dazu sind die sichere Token-Schnittstelle 151 sowie die zweite Token-Schnittstelle 152 zu sehen. Eine Schlüssel-Schnittstelle 153 ist ebenso gezeigt, wie ein Token-Prozessor 120 und ein Sicherheitscontroller 141. Der Sicherheitscontroller 141 des Tokens 100 hat dabei vor allem die Aufgabe:
- – eine Authentifizierung gegenüber dem Sicherheitscontroller 41 des aus 1 bekannten Receivers 1 durchzuführen,
- – die Schlüssel zum Entschlüsseln eines verschlüsselten GNSS-Signals sicher zu speichern und
- – sicherheitsrelevante Dienste und Funktionen, insbesondere kryptografische Funktionen und Informationen bereitzustellen.
-
Die Authentifizierung kann dabei einerseits über die sichere Token-Schnittstelle 151 oder alternativ über einen sicheren Kanal in der zweiten Token-Schnittstelle 152 geschehen. Die Trennung des Kanals der Authentifizierung von dem Kanal der sicheren Datenübertragung hat den Vorteil, dass ein weiterer redundanter Kanal zur Verfügung steht. Der Token-Prozessor 120 kann beispielsweise als FPGA mit integriertem Tamper-Schutz ausgebildet sein. Soll beispielsweise das Signal des Galileo Public-Regulated-Service oder auch PRS-Signal ausgewertet werden, so wäre es die Hauptaufgabe des Token-Prozessors 120 so genannte PRN-Codes (Pseudo Random Noise-Codes) zu generieren. Diese PRN-Codes sind notwendig um das jeweilige Satellitensignal im Empfänger abbilden und letztendlich Nutzen zu können.
-
3 zeigt schematisch einen Signallaufplan innerhalb des Receivers 1. Zu sehen sind die Empfangsdaten 11, die vom analogen Frontend 10 in gewandelte Daten 111 umgewandelt werden. Dabei liegen Empfangsdaten 11 als analoges Signal vor und werden vom analogen Frontend in ein digitales Signal gewandelt. Das digitale Frontend 20 ist dann in der Lage, die gewandelten Daten 111 entsprechend auszuwerten. Die Daten, die vom Token 100 als Daten zur Abbildung, Berechnung und/oder zur Entschlüsselung eines verschlüsselten GNSS-Dienstes 101 geliefert werden, werden über das Token-Interface 50 und das Sicherheits-Interface-Modul 40 über das Sicherheits-Interface 30 dem digitalen Frontend 20 zur Verfügung gestellt. Die Berechnung der eigentlichen Positionsdaten, zum Beispiel die sogenannten PVT-Daten, geschieht dann im digitalen Frontend 20 bzw. in dessen Prozessor 21.
-
In 4 ist ein Ausführungsbeispiel eines Token 100 zu sehen. Die sichere Token-Schnittstelle 151 ist hier als optische Schnittstelle ausgeführt, die nach vorne aus dem Token herausführt und deshalb nicht direkt sichtbar ist. Die zweite Token-Schnittstelle 152 ist hier als konventionelle Kontaktierung in Form einer Kontaktierung nach ISO 7816 oder auch als Smartcard-Kontaktanordnung ausgeführt. Weiterhin zu sehen sind zwei Hebel 199, die mit einem Mechanismus zur mechanischen Zerstörung des Sicherheitscontrollers 141 und/oder des Token-Prozessors 120 verbunden sind. Dabei kann es sich beispielsweise um eine Nadel innerhalb des Gehäuses handeln. Des Weiteren ist ein Codierfeld 130 zu sehen, das eine weitere Authentifizierung ermöglicht. Dabei kann es sich um ein verkleinertes Feld zur PIN Eingabe oder um ein biometrisches Eingabegerät wie einen Fingerabdrucksensor handeln.
-
5 zeigt einen Receiver 1 in einem Gehäuse 2, das ein Codierfeld 130 aufweist, das in diesem Fall als Tastenfeld zur Eingabe eines PINs ausgebildet ist. Ebenfalls zu sehen sind ein Token-Interface 50 sowie dessen sichere Schnittstelle 51 und weitere Schnittstelle 52. Ein Receiver in dieser Form könnte beispielsweise in ein Fahrzeug eingebaut sein.
-
Zusammenfassend betrifft die Erfindung einen Receiver 1 zum Empfang von GNSS-Signalen. Des Weiteren betrifft die Erfindung einen Token 100 zur Verwendung mit einem derartigen Receiver 1, ein Fahrzeug sowie ein Feldgerät mit einem derartigen Receiver. Um einen Receiver 1 und einen Token 100 anzugeben, der die Handhabung der Schlüssel zum Entschlüsseln eines verschlüsselten GNSS Systems modular, einfach und sicher ermöglicht, wird ein Receiver 1 vorgeschlagen, der ein Token-Interface 50 mit einer sicheren Schnittstelle 51 aufweist, die zur Übermittlung von Daten 101, die zur Abbildung, Berechnung und/oder Entschlüsselung eines verschlüsselten GNSS-Dienstes erforderlich sind, ausgebildet ist.
-
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 Nicht-Patentliteratur
-
- ISO 7816 [0011]
- ISO 7816 [0011]
- ISO 7816 [0015]
- ISO 7816 [0039]
