DE102014212516A1

DE102014212516A1 - Überprüfung der Authentizität einer Balise

Info

Publication number: DE102014212516A1
Application number: DE102014212516.2A
Authority: DE
Inventors: Uwe Deichmann; Werner Friedrichs; Norbert Geduhn; Udo Golebniak; Jochen Käppel; Dirk Schulz
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2014-06-27
Filing date: 2014-06-27
Publication date: 2015-12-31
Also published as: ES2773437T3; ZA201607726B; EP3137363A1; WO2015197286A1; EP3137363B1

Abstract

Es wird vorgeschlagen, die Authentizität einer Balise zu überprüfen. Hierzu wird von der Balise eine Kennung bereitgestellt, die als Teil des Telegramms von der Balise zu dem Fahrzeugrechner eines Schienenfahrzeugs übermittelt wird. Anhand der Kennung kann die Authentizität der Balise von dem Fahrzeugrechner verifiziert werden. Vorteilhaft wird die Kennung in dem Paket 44 der ETCS-Implementierung gemäß UNISIG übermittelt. Weiterhin kann als Kennung ein Hashwert einer kryptographischen Hashfunktion verwendet werden. Hierbei ist es von Vorteil, dass Manipulationen der von der Balise bereitgestellten Telegramme aufgedeckt werden können.

Description

Die Erfindung betrifft ein Verfahren zum Betrieb eines Schienenfahrzeugs, ein Verfahren zum Überprüfen einer von einer Balise bereitgestellten Kennung, ein Verfahren zum Bereitstellen einer Kennung durch eine Balise, eine ETCS-Streckenausrüstung sowie ein Schienenfahrzeug.
Das "European Train Control System" (ETCS) ist eine Komponente eines einheitlichen europäischen Eisenbahnverkehrsleitsystems, das unter dem Buchstabenkürzel ERTMS entwickelt wurde. Die zweite technische Komponente dieser digitalen Bahntechnologie ist das Bahn-Mobilfunksystem GSM-R. ETCS soll die Vielzahl der in den Ländern eingesetzten Zugsicherungssysteme ablösen, mittelfristig im Hochgeschwindigkeitsverkehr Verwendung finden und langfristig im gesamten europäischen Schienenverkehr umgesetzt werden.
Eine ETCS-Fahrzeugeinrichtung umfasst z.B. einen ETCS-Rechner (EVC, European Vital Computer, auch bezeichnet als Fahrzeugrechner (OBU, On-board Unit)), eine Führerstandsanzeige (DMI, Driver Machine Interface), eine Wegmesseinrichtung, eine GSM-R-Übertragungseinrichtung (einschließlich Euroradio), einen Balisenleser und einen Bremszugriff (http://de.wikipedia.org/wiki/ETCS).
ETCS Level 1 benutzt Balisen als Übertragungsmedium. Die von den Balisen übermittelten Informationen sind Streckengradienten, Streckenhöchstgeschwindigkeiten und der Punkt, an dem das Fahrzeug wieder stehen soll. Zusammen mit einem ETCS-Modus bilden diese die Movement Authority (MA), übersetzt etwa "Berechtigung zur Bewegung" oder "Fahrerlaubnis". Damit kann die fahrzeugseitige ETCS-Ausrüstung kontinuierlich die Einhaltung der erlaubten Geschwindigkeit (und Richtung) überwachen und rechtzeitig eine Zwangsbremsung auslösen.
Am Ende der MA ("End of Authority", EoA) – beispielsweise ein HALT zeigendes Signal – soll das Schienenfahrzeug zum Stehen kommen.
Neben den ETCS-Levels sind auch ETCS-Modi definiert. Die Modi beschreiben die Zustände, in denen sich der EVC befinden kann (siehe auch: http://de.wikipedia.org/wiki/ETCS).
Bei ETCS Level 2 werden nahezu alle Informationen mittels Euroradio von der Streckenzentrale (Radio Block Center, RBC) zum Fahrzeug übertragen. Zusätzlich besteht die Möglichkeit, Informationen vom Zug an die Strecke zu übertragen und die Informationen können auch im Stillstand ausgetauscht werden. Damit kann die Streckenauslastung gegenüber Level 1 etwas erhöht werden. Bevor vom RBC die für eine Fahrerlaubnis (MA) notwendigen Informationen berechnet werden können, muss dieses wissen, wo genau sich der Zug befindet und in welche Richtung er fährt. Die Ermittlung von Position und Richtung obliegt dabei dem Fahrzeugrechner, dieser übermittelt diese regelmäßig über GSM-R an die Strecke. Zur Bestimmung werden jedoch Referenzpunkte auf der Strecke benötigt. Hierfür werden Eurobalisen benutzt, welche beispielsweise in Ausfahrgleisen von Bahnhöfen sowie in (z.B. unregelmäßigen) Abständen auf freier Strecke angebracht sind. Zwischen diesen Referenzpunkten wird die Position odometrisch mittels Doppler-Radar am Triebfahrzeugboden und Radimpulsgebern an den Triebfahrzeugachsen ermittelt. Teilweise werden auch Beschleunigungssensoren verwendet.
Die Information über freie Gleisabschnitte wird wie in ETCS Level 1 über die ortsfeste Gleisfreimeldung vom Stellwerk ermittelt und an die Streckenzentrale übergeben: Die Strecke ist – wie bei konventioneller Sicherungstechnik – in Abschnitte ("Blöcke") geteilt, und der Zug darf in den nächsten Abschnitt nur einfahren, wenn dieser nicht von einem anderen Zug belegt, sondern als ‚frei‘ gemeldet ist. (Quelle: http://de.wikipedia.org/wiki/European_Train_Control_System.)
Die korrekte Übermittlung eines Telegramms der ETCS-Balise wird mittels einer zyklischen Redundanzprüfung (CRC, "Cyclic Redundancy Check") sichergestellt. Hierbei wird ein Prüfwert (auch bezeichnet als CRC-Code) für Daten bestimmt, um Fehler bei der Übertragung aufdecken zu können (vergleiche z.B. http://de.wikipedia.org/wiki/Zyklische_Redundanzprüfung).
Der CRC-Code ist geeignet, um übliche Fehler auf Kommunikationskanälen erkennen zu können. Hierbei ist es von Nachteil, dass derartige CRC-Codes keinen Schutz vor einer absichtlicher (böswillige) Manipulation der Daten z.B. in Form unterschiedlicher Angriffe bieten. Beispielsweise könnten folgende Veränderungen an den Telegrammen der Balise vorgenommen werden:

– eine Veränderung der Fahrerlaubnis (MA);
– eine Veränderung einer von der Balise bereitgestellten Information, z.B. "Weiterfahrt" (Proceed) anstelle von "Anhalten" (Stop);
– eine Veränderung von Geschwindigkeitswerten, so dass beispielsweise eine höhere Geschwindigkeit übermittelt wird als die eigentlich vorgesehene Höchstgeschwindigkeit;
– eine Veränderung einer fahrteinschränkenden Signalisierung;
– eine Veränderung von Entfernungswerten.

Bei solchen Manipulationen handelt es sich um Angriffe auf die von der Balise bereitgestellten Daten, die mittels des CRC-Codes nicht detektiert werden können. Beispielsweise können die manipulierten Daten (mit den für diese passenden CRC-Codes) von einem Angreifer bereitgestellt werden während das Schienenfahrzeug die Balise überfährt. Dies ist gerade für sicherheitsrelevante Daten unerwünscht.
Die Aufgabe der Erfindung besteht darin, die vorstehend genannten Nachteile zu vermeiden und insbesondere eine Möglichkeit für eine sichere und verlässliche Übertragung der Daten von der Balise an den Fahrzeugrechner eines Schienenfahrzeugs zu schaffen.
Diese Aufgabe wird gemäß den Merkmalen der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen sind insbesondere den abhängigen Ansprüchen entnehmbar.
Zur Lösung der Aufgabe wird ein Verfahren zum Betrieb eines Schienenfahrzeugs vorgeschlagen,

– bei dem eine Information zum Betrieb des Schienenfahrzeugs und eine Kennung von einer Balise zu einem Fahrzeugrechner des Schienenfahrzeugs übertragen wird,
– bei dem die Kennung von dem Fahrzeugrechner überprüft wird,
– bei dem bei erfolgreicher Überprüfung der Kennung die Information genutzt wird.

Beispielsweise werden Information und Kennung zusammen in einem Telegramm von der Balise an den Fahrzeugrechner des Schienenfahrzeugs übertragen.
Die bereitgestellte Information wird insbesondere dadurch genutzt, dass z.B. in den Informationen enthaltene Vorgaben für den Betrieb des Schienenfahrzeugs eingehalten werden. Insbesondere wird das Schienenfahrzeug basierend auf der Information gesteuert, sofern die Kennung erfolgreich verifiziert werden konnte.
Hierbei sei angemerkt, dass die erfolgreiche Überprüfung der Kennung insbesondere ein Verifizieren der Kennung umfasst. Durch das Verifizieren der Kennung kann somit die Authentizität der Balise sichergestellt werden. So ist gewährleistet, dass die erhaltene Information auch von der Balise stammt und es wird verhindert, dass ein Angreifer – getarnt als Balise – unerkannt die Information an das Schienenfahrzeug übermittelt.
Eine Weiterbildung ist es, dass die Kennung von dem Fahrzeugrechner nicht überprüft wird, falls bestimmt wird, dass keine Kennung vorhanden ist oder falls die Kennung einen vorgegebenen Wert aufweist.
Beispielsweise kann von einer Überprüfung abgesehen werden, falls keine Kennung vorhanden ist. Dies kann dadurch bestimmt werden, dass die Kennung einen vorgegebenen Wert aufweist, z.B. das Feld, in dem die Kennung übertragen wird, leer ist oder einen bestimmten Wert aufweist bzw. enthält.
Auch kann von der Überprüfung abgesehen werden, falls die Kennung einen vorgegebenen Wert nicht aufweist. In diesem Fall wird die Überprüfung nur dann durchgeführt, wenn die Kennung als solche erkannt wird. Hierzu ist es möglich, dass die Kennung einen zusätzlichen Wert z.B. in Form eines Bitmusters umfasst, der beispielsweise Teil der Kennung ist und/oder zusätzlich zu dieser vorhanden ist. So kann der zusätzliche Wert der Kennung vorangestellt oder dieser angehängt sein.
Wird beispielsweise ein Datenfeld in dem die Kennung übertragen werden könnte für einen anderen Zweck genutzt und ist darin keine Kennung vorhanden, so wird dies erkannt und die Überprüfung der Kennung kann entfallen.
Eine andere Weiterbildung ist es, dass die Information nicht genutzt wird, falls die Überprüfung der Kennung nicht erfolgreich war.
Sofern die (vorhandene und als solche erkannte) Kennung nicht verifiziert werden konnte, wird beispielsweise angenommen, dass die Information von der Balise ungültig ist. Es kann dann eine geeignete Aktion, z.B. eine Überprüfung der Balise und/oder das Überführen des Systems in einen sicheren Zustand, z.B. ein Abbremsen oder Anhalten des Schienenfahrzeugs, eingeleitet werden.
Insbesondere ist es eine Weiterbildung, dass die Information nicht genutzt wird, falls die Kennung detektiert wurde und die Überprüfung der Kennung nicht erfolgreich war.
Auch ist es eine Weiterbildung, dass das Schienenfahrzeug in einen sicheren Zustand überführt wird, falls die Überprüfung der Kennung nicht erfolgreich war.
Ferner ist es eine Weiterbildung, dass die Kennung mindestens eine der folgenden Möglichkeiten umfasst:

– verschlüsselte Daten;
– unverschlüsselte Daten;
– Daten, die basierend auf einer Hashfunktion, insbesondere einer kryptographischen Hashfunktion, bestimmt wurden;
– Daten, die basierend auf einem MD4 Algorithmus bestimmt wurden;
– eine Signatur;
– ein Zertifikat;
– einen Wert zur Identifikation der Kennung;
– einen Wert zur Identifikation eines Typs der Kennung.

Im Rahmen einer zusätzlichen Weiterbildung wird die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG übermittelt.
Eine nächste Weiterbildung besteht darin, dass

– die Kennung von dem Fahrzeugrechner überprüft wird, indem anhand der Information eine weitere Kennung bestimmt wird und die Kennung mit der weiteren Kennung verglichen wird,
– die Überprüfung der Kennung erfolgreich war, falls die Kennung und die weitere Kennung identisch sind.

Eine Ausgestaltung ist es, dass

– (z.B. von der Balise) die Kennung verschlüsselt wird;
– die Kennung von dem Fahrzeugrechner entschlüsselt wird,
– von dem Fahrzeugrechner anhand der Information eine weitere Kennung bestimmt wird und die entschlüsselte Kennung mit der weiteren Kennung verglichen wird,
– die Überprüfung der Kennung erfolgreich war, falls die entschlüsselte Kennung und die weitere Kennung identisch sind.

Eine alternative Ausführungsform besteht darin, dass zur Verschlüsselung und zur Entschlüsselung ein symmetrisches oder ein asymmetrisches Verschlüsselungsverfahren eingesetzt wird.
Eine nächste Ausgestaltung ist es, dass anhand der Kennung von dem Fahrzeugrechner bestimmt wird,

– ob die Kennung vorhanden ist und
– falls die Kennung vorhanden ist, welche Art der Überprüfung der Kennung durchzuführen ist.

Beispielsweise kann die Kennung einen Wert zur Identifikation der Kennung z.B. in Form eines Bitmusters aufweisen anhand dessen bestimmbar ist, dass es sich um eine Kennung handelt. Auch kann die Kennung einen Wert zur Identifikation des Typs der Kennung aufweisen, so dass bestimmbar ist, anhand welches Algorithmus die Kennung überprüft werden kann. Der Wert zur Identifikation der Kennung und/oder der Wert zur Identifikation des Typs der Kennung können in einem Bitmuster codiert sein. Das Bitmuster kann z.B. als ein Header o.ä. Teil der Kennung sein oder auch separat von der Kennung übertragen werden.
Die Ausführungen bzw. Merkmale betreffend das vorstehend erläuterte Verfahren gelten für die folgenden Ansprüche, insbesondere Anspruchskategorien, entsprechend.
Die Aufgabe wird auch gelöst anhand eines Verfahrens zum Überprüfen einer von einer Balise bereitgestellten Kennung,

– bei dem von einem Fahrzeugrechner eines Schienenfahrzeugs die Kennung und eine Information von der Balise empfangen werden,
– bei dem die Kennung von dem Fahrzeugrechner überprüft wird.

Eine Ausgestaltung besteht darin, dass bei erfolgreicher Überprüfung der Kennung die Information zum Betrieb des Schienenfahrzeugs genutzt wird.
Auch ist es eine Ausgestaltung, dass die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG empfangen wird.
Ferner wird die Aufgabe gelöst mittels eines Verfahrens zum Bereitstellen einer Kennung durch eine Balise,

– bei dem eine Kennung basierend auf einer Information erstellt wird,
– bei dem die Kennung und die Information beim Überfahren der Balise einem Schienenfahrzeug bereitgestellt werden,
– so dass anhand der Kennung die Authentizität der Balise von dem Schienenfahrzeug überprüfbar ist.

Zusätzlich wird die Aufgabe gelöst mittels einer ETCS-Streckenausrüstung

– mit mindestens einer Balise,
– wobei die mindestens eine Balise derart eingerichtet ist, dass sie beim Überfahren einem Schienenfahrzeug eine Kennung und eine Information bereitstellt, wobei die Kennung basierend auf der Information erstellt wurde, so dass anhand der Kennung die Authentizität der Balise von dem Schienenfahrzeug überprüfbar ist.

Eine Weiterbildung besteht darin, dass die Kennung mittels einer kryptographischen Hashfunktion bestimmbar ist und dass die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG abspeicherbar ist.
Auch wird die Aufgabe gelöst anhand eines Schienenfahrzeugs mit einem Fahrzeugrechner, der derart eingerichtet ist, dass

– die Kennung und eine Information von der Balise empfangbar sind,
– anhand der Kennung die Authentizität der Balise von dem Schienenfahrzeug überprüfbar ist.

Der hier genannte Fahrzeugrechner kann insbesondere als eine Prozessoreinheit und/oder eine zumindest teilweise festverdrahtete oder logische Schaltungsanordnung ausgeführt sein, die beispielsweise derart eingerichtet ist, dass das Verfahren wie hierin beschrieben durchführbar ist. Besagter Fahrzeugrechner kann jede Art von Prozessor oder Rechner oder Computer mit entsprechend notwendiger Peripherie (Speicher, Input/Output-Schnittstellen, Ein-Ausgabe-Geräte, etc.) sein oder umfassen. Der Fahrzeugrechner kann Teil einer Steuereinheit des Schienenfahrzeugs sein.
Auch wird die oben genannte Aufgabe gelöst mittels eines Systems umfassend mindestens eine der hier beschriebenen Vorrichtungen.
Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden schematischen Beschreibung von Ausführungsbeispielen, die im Zusammenhang mit den Zeichnungen näher erläutert werden. Dabei können zur Übersichtlichkeit gleiche oder gleichwirkende Elemente mit gleichen Bezugszeichen versehen sein.
Es zeigen:
1 ein beispielhaftes Schaubild umfassend ein Schienenfahrzeug mit einem Fahrzeugrechner, der mit einer Balisen-Antenne verbunden ist, wobei sich das Schienenfahrzeug auf einer Strecke in Richtung zweier Balisen bewegt;
2 ein beispielhaftes Ablaufdiagramm einer Kommunikation zwischen der Balise und dem Fahrzeugrechner des Schienenfahrzeugs.
Es sei angemerkt, dass das Schienenfahrzeug (auch bezeichnet als "Zug") mindestens einen, insbesondere mindestens zwei Wagen aufweist, wobei der Wagen ein Triebfahrzeug, ein Reisewagen, ein Güterwagen oder eine Kombination aus derartigen Abteilen oder Funktionen sein kann. Das Triebfahrzeug weist eine Führerkabine (auch bezeichnet als Bedienplatz) auf und kann mit oder ohne Antrieb ausgeführt sein. Das Triebfahrzeug kann insbesondere eine Lokomotive sein. Jeder Wagen des Schienenfahrzeugs kann mit einem Fahrzeugrechner ausgestattet sein; stellt der Fahrzeugrechner (ggf. mit der mobilen Kommunikationsschnittstelle) eine ETCS-Funktion bereit, kann dieser ggf. auch als ETCS-Wagen bezeichnet werden. Grundsätzlich ist es möglich, dass nur die Triebfahrzeuge je einen Fahrzeugrechner (ggf. mit der mobilen Kommunikationsschnittstelle) bzw. dass auch einzelne Wagen, die keine Triebfahrzeuge sind, derartige Fahrzeugrechner (ggf. mit der mobilen Kommunikationsschnittstelle) aufweisen.
Die hier vorgeschlagene Lösung ermöglicht insbesondere eine abgesicherte Übertragung von sicherheitsrelevanten Informationen an das Schienenfahrzeug, z.B. von einer Balise an das Schienenfahrzeug.
Hierfür kann beispielsweise ein sogenanntes Paket 444 der ETCS-Implementierung gemäß UNISIG (SUBSET-026-7) genutzt werden, um eine geschützte Nachricht (z.B. von der Balise) an den Fahrzeugrechner des Schienenfahrzeugs zu übermitteln. So erlaubt das Paket 44 die transparente Übermittlung von (beliebigen) Informationen. Die geschützte Nachricht kann somit in dem Paket 44 übermittelt werden.
Bei der geschützten Nachricht handelt es sich beispielsweise um eine Kennung. Die Kennung kann beispielsweise mindestens eine der folgenden Möglichkeiten (Werte bzw. Daten) umfassen:

Beispielsweise kann die Kennung basierend auf einer kryptographischen Hash-Funktion bestimmt werden. Beispiele für kryptographische Hash-Funktionen sind die sogenannten Message-Digest Algorithmen, z.B. "MD2" oder "MD4" (siehe z.B. RFC 1320 der Network Working Group, http://tools.ietf.org/html/rfc1320).
Die Kennung kann in das Paket 44 eingebettet sein und als Teil des Balisen-Telegramms zusammen mit anderen Informationen von der Balise an den Fahrzeugrechner des Schienenfahrzeugs übermittelt werden. Anhand der Kennung kann der Fahrzeugrechner die Balise authentifizieren, d.h. bestimmen, ob die erhaltenen Informationen von der dafür vorgesehenen Balise stammen.
Hierdurch können die Telegramme zusätzlich gegen absichtliche Manipulationen von Daten (insbesondere sogenannte "Man-in-the-Middle" Angriffe, vgl. z.B. http://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff) gesichert werden.
Die Kennung kann den Wert einer Hashfunktion umfassen. Die Hashfunktion (auch bezeichnet als Streuwertfunktion) ist eine Abbildung, die eine große Eingabemenge (die Schlüssel) auf eine kleinere Zielmenge (die Hashwerte) abbildet. Die Hashfunktion ist nicht zwingend injektiv. Insbesondere kann die Eingabemenge auch Elemente mit unterschiedlichen Längen enthalten, wohingegen die Elemente der Zielmenge insbesondere eine feste Länge aufweisen. Eine sogenannte Kollision tritt dann auf, wenn unterschiedlichen Eingabedaten derselbe Hashwert zugeordnet wird.
Die Kennung kann auch den Wert einer kryptographischen Hashfunktion (auch bezeichnet als kryptologische Hashfunktion) umfassen (vgl. http://de.wikipedia.org/wiki/Kryptologische_Hashfunktion). Hierbei handelt es sich um eine spezielle Form der Hashfunktion, die kollisionsresistent und/oder eine Einwegfunktion ist. Die Einwegfunktion ist komplexitätstheoretisch "leicht" berechenbar, aber "schwer" umzukehren. Einwegfunktionen sind auch Funktionen, zu denen bisher keine in angemessener Zeit praktisch ausführbare Umkehrung bekannt ist.
Es gibt schlüssellose und schlüsselabhängige kryptographische Hashfunktionen.
Auch ist es möglich, dass die Kennung eine digitale Signatur umfasst. Eine digitale Signatur, auch digitales Signaturverfahren, ist ein asymmetrisches Kryptosystem, bei dem ein Sender mit Hilfe eines geheimen Signaturschlüssels (dem Private Key) zu einer digitalen Nachricht (d.h. zu beliebigen Daten) 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 Integrität der Nachricht zu prüfen (vgl. http://de.wikipedia.org/wiki/Digitale_Signatur).
Beispielsweise kann so anhand des öffentlichen Schlüssels der Balise das Telegramm der Balise (oder ein Teil des Telegramms der Balise) von dem Fahrzeugrechner verifiziert werden. Die Balise nutzt zur Verschlüsselung ihren geheimen Signaturschlüssel, der vorzugsweise möglichst manipulationssicher in der Balise gespeichert ist und nur von der Balise selbst verwendet werden kann.
Eine Möglichkeit besteht darin, dass in dem Paket 444 ein Hashwert des Telegramms oder eines Teils des Telegramms gespeichert und an den Fahrzeugrechner des Schienenfahrzeugs übermittelt wird. Der Fahrzeugrechner ermittelt nun einen Hashwert basierend auf dem Telegramm oder auf einem Teil des Telegramms und vergleicht diesen Hashwert mit dem in dem Paket 44 erhaltenen Hashwert. Sind beide Hashwerte identisch, wird angenommen, dass das Telegramm nicht absichtlich manipuliert wurde.
Eine alternative Möglichkeit besteht darin, dass der Hashwert der zu übertragenden Information von der Balise signiert (also mit dem privaten Schlüssel der Balise verschlüsselt) und als Kennung in dem Paket 44 abgespeichert wird. Die Information und die Kennung werden (z.B. als Telegramm) an den Fahrzeugrechner des Schienenfahrzeugs übermittelt. Der Fahrzeugrechner ermittelt nun einen Hashwert basierend auf der Information und decodiert die Kennung anhand des öffentlichen Schlüssels der Balise (dieser kann optional von der Balise mitübertragen werden). Der von dem Fahrzeugrechner ermittelte Hashwert wird mit dem von der Balise erstellten Hashwert verglichen; sind beide identisch, so ist die Kennung erfolgreich verifiziert, die von der Balise bereitgestellte Information kann entsprechend verwendet oder weiterverarbeitet werden.
Beispielsweise kann in dem Paket 44 eine Markierung z.B. in Form einer Bitkombination enthalten sein, die dem Fahrzeugrechner des Schienenfahrzeugs anzeigt, ob das Paket 44 zur Überprüfung bzw. Authentifikation des Telegramms verwendet werden kann. Ist dies der Fall, kann z.B. eine der vorstehend erläuterten Überprüfungen (Verifikationen) erfolgen. Ist das Paket 44 hingegen leer oder weist es keine der ggf. mehreren vorgegebenen Bitkombinationen auf, so findet keine Überprüfung basierend auf den Daten des Pakets 44 statt. Dieser Ansatz ist somit auch kompatibel mit anderen Verwendungsmöglichkeiten des Pakets 44.
Auch ist es eine Option, dass je nach Anwendungsfall gefordert werden kann, dass sich jede Balise authentifiziert. In einem solchen Fall kann mindestens ein Datenfeld vorgesehen sein, das zur Übermittlung der Kennung genutzt wird, so dass anhand der Kennung die sendende Balise authentifiziert werden kann. Kann eine Balise nicht verifiziert werden, so kann eine geeignete Aktion durchgeführt werden, umfassend z.B. eine der folgende Möglichkeiten: Ausgabe einer Warnmeldung; Überführen des Systems und/oder mindestens eines Schienenfahrzeugs in einen sicheren Zustand (z.B. Stillstand); Überprüfung und ggf. Wartung der Balise; etc.
Eine weitere Option besteht darin, dass eine solche Bitkombination in dem Paket 44 unterschiedliche Werte aufweisen kann, von denen jeder mit einer bestimmten Überprüfungsart verknüpft ist. Beispielsweise kann eine vorgegebene Bitkombination anzeigen, dass in Paket 44 ein Hashwert abgespeichert wurde; es kann auch durch den Wert der Bitkombination vorgegeben sein, welche Hashfunktion zur Erstellung des Hashwerts verwendet wurde. Weiterhin kann ein anderer Wert der Bitkombination anzeigen, dass eine elektronische Signatur gespeichert ist bzw. nach welchem Algorithmus die elektronische Signatur generiert wurde.
Die Verwendung des Pakets 44 zur transparenten Übermittlung von zur Überprüfung des Telegramms verwendbaren Daten ist lediglich beispielhaft zu verstehen. Grundsätzlich ist es möglich, andere oder zusätzliche Datenfelder zu verwenden, um für die hier beschriebene Überprüfung relevante Informationen von einem Sender an den Fahrzeugrechner des Schienenfahrzeugs zu übermitteln. Die Übermittlung der Daten kann beispielsweise drahtlos (z.B. über Funk, über Nahfeldkommunikation, über ein Telekommunikationsnetzwerk, etc.) oder drahtgebunden erfolgen.
1 zeigt ein beispielhaftes Schaubild umfassend ein Schienenfahrzeug 101 mit einem Fahrzeugrechner 102, der mit einer Balisen-Antenne 103 verbunden ist. Das Schienenfahrzeug 101 bewegt sich auf einer Strecke 104 in eine Fahrtrichtung 105. In der Fahrtrichtung 105 überfährt das Schienenfahrzeug 101 zunächst eine Balise 106, danach eine Balise 107.
Bei den Balisen 106 und 107 handelt es sich beispielsweise um Euro-Balisen, wobei beispielhaft die Balise 106 eine Transparentdatenbalise und die Balise 107 eine Festdatenbalise ist (vgl. http://de.wikipedia.org/wiki/Eurobalise).
Die Transparentdatenbalise (Transparent Data Balise oder Controllable Balise) ist beispielsweise mit einem Kabel mit einer streckenseitigen elektronischen Einheit (LEU, Lineside Electronic Unit) verbunden. Die LEU übermittelt der Balise das jeweils zu übertragende Telegramm.
Hierbei sei angemerkt, dass der Begriff Balise hier auch mehrere hintereinander vorgesehene Balisen einer sogenannten Balisengruppe umfasst.
Die Balise 106 und/oder die Balise 107 stellt dem Schienenfahrzeug 101 beim Überfahren der jeweiligen Balise mittels der Balisen-Antenne 103 und dem Fahrzeugrechner 102 ein (Balisen-)Telegramm bereit, das ein Datenfeld aufweist (z.B. in Form des vorstehend beschriebenen Pakets 44), in dem z.B. die Kennung enthalten ist. Anhand des Datenfelds ist eine Überprüfung der Integrität bzw. Authentizität der erhaltenen Daten möglich. Insbesondere kann so sichergestellt werden, dass die Informationen tatsächlich von der Balise 106 und/oder 107 stammen und dass diese nicht verfälscht wurden.
Vorzugsweise ist die jeweilige Balise 106 bzw. 107 so ausgeführt, dass ein Zugriff auf einen sicheren Speicherbereich von außen nicht oder nur mit sehr hohem Aufwand zu bewerkstelligen ist. In einem solchen gesicherten Speicherbereich kann ein privater Schlüssel, der zum Erstellen der Signatur verwendet wird, gespeichert sein. Dieser Schlüssel ist vorzugsweise vor Zugriffen von außen geeignet zu sichern.
Eine Option ist es, dass die Balise in dem Telegramm (z.B. in dem Datenfeld bzw. dem Paket 44) auch den öffentlichen Schlüssel der Balise (auch bezeichnet als öffentlicher Verifikationsschlüssel oder Zertifikat) übermittelt. Vorzugsweise kann von dem Schienenfahrzeug überprüft werden, ob der öffentliche Schlüssel zu der Position der Balise passt. Vorzugsweise werden nur dann und nur wenn die Verifikation der Daten erfolgreich war, die Daten des Telegramms von dem Fahrzeugrechner des Schienenfahrzeugs weiter verarbeitet.
2 zeigt ein beispielhaftes Ablaufdiagramm einer Kommunikation zwischen der Balise 106, 107 und dem Fahrzeugrechner 102 des Schienenfahrzeugs 101.
In einem Schritt 201 erstellt die Balise 106, 107 das Telegramm oder erhält von der LEU das weiterzuleitende Telegramm. In einem Schritt 202 erstellt die Balise einen Hashwert mittels einer kryptographischen Hashfunktion (z.B. MD4) und speichert den Hashwert in dem Paket 44 der ETCS-Implementierung gemäß UNISIG (SUBSET-026-7). In einem Schritt 203 wird das Telegramm von der Balise 106, 107 zu dem Fahrzeugrechner 102 übermittelt. Der Fahrzeugrechner 102 bestimmt anhand des Telegramms (basierend auf vorgegebenen Daten des Telegramms, z.B. allen Daten ohne das Paket 44) in einem Schritt 204 einen Hashwert mittels einer kryptographischen Hashfunktion, die auch von der Balise 106, 107 verwendet wurde. In einem Schritt 205 vergleicht der Fahrzeugrechner 102 den bestimmten Hashwert mit dem aus dem Paket 44 gelesenen Hashwert. Sind beide Hashwerte identisch, so wird angenommen, dass die Daten des Telegramms nicht verfälscht wurden und es wird eine Aktion (z.B. Steuerung des Schienenfahrzeugs 101) basierend auf diesen Daten veranlasst. Sollten die beiden Hashwerte nicht identisch sein, so kann eine Fehlermeldung z.B. dem Schienenfahrzeug und/oder einem Stellwerk angezeigt werden. Insbesondere kann in diesem Fall der Schienenfahrzeugbetrieb in einen sicheren Zustand überführt werden und es kann anschließend geprüft werden, ob die Balise 106, 107 defekt ist oder ob ein Manipulationsversuch vorlag.
Obwohl die Erfindung im Detail durch das mindestens eine gezeigte Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht darauf eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.
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

http://de.wikipedia.org/wiki/ETCS [0003]
http://de.wikipedia.org/wiki/ETCS [0006]
http://de.wikipedia.org/wiki/European_Train_Control_System. [0008]
http://de.wikipedia.org/wiki/Zyklische_Redundanzprüfung [0009]
http://tools.ietf.org/html/rfc1320 [0051]
http://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff [0053]
http://de.wikipedia.org/wiki/Kryptologische_Hashfunktion [0055]
http://de.wikipedia.org/wiki/Digitale_Signatur [0057]
http://de.wikipedia.org/wiki/Eurobalise [0066]

Claims

Verfahren zum Betrieb eines Schienenfahrzeugs (101), – bei dem eine Information zum Betrieb des Schienenfahrzeugs (101) und eine Kennung von einer Balise (106, 107) zu einem Fahrzeugrechner (102) des Schienenfahrzeugs (101) übertragen wird, – bei dem die Kennung von dem Fahrzeugrechner (102) überprüft wird, – bei dem bei erfolgreicher Überprüfung der Kennung die Information genutzt wird.
Verfahren nach Anspruch 1, bei dem die Kennung von dem Fahrzeugrechner (102) nicht überprüft wird, falls bestimmt wird, dass keine Kennung vorhanden ist oder falls die Kennung einen vorgegebenen Wert aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Information nicht genutzt wird, falls die Überprüfung der Kennung nicht erfolgreich war.
Verfahren nach einem der Ansprüche 1 oder 2, bei dem die Information nicht genutzt wird, falls die Kennung detektiert wurde und die Überprüfung der Kennung nicht erfolgreich war.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Schienenfahrzeug in einen sicheren Zustand überführt wird, falls die Überprüfung der Kennung nicht erfolgreich war.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Kennung mindestens eine der folgenden Möglichkeiten umfasst: – verschlüsselte Daten; – unverschlüsselte Daten; – Daten, die basierend auf einer Hashfunktion, insbesondere einer kryptographischen Hashfunktion, bestimmt wurden; – Daten, die basierend auf einem MD4 Algorithmus bestimmt wurden; – eine Signatur; – ein Zertifikat; – einen Wert zur Identifikation der Kennung; – einen Wert zur Identifikation eines Typs der Kennung.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG übermittelt wird.
Verfahren nach einem der vorhergehenden Ansprüche, – bei dem die Kennung von dem Fahrzeugrechner überprüft wird, indem anhand der Information eine weitere Kennung bestimmt wird und die Kennung mit der weiteren Kennung verglichen wird, – bei dem die Überprüfung der Kennung erfolgreich war, falls die Kennung und die weitere Kennung identisch sind.
Verfahren nach einem der Ansprüche 1 bis 7, – bei dem die Kennung verschlüsselt wird, – bei dem die Kennung von dem Fahrzeugrechner entschlüsselt wird, – bei dem von dem Fahrzeugrechner anhand der Information eine weitere Kennung bestimmt wird und die entschlüsselte Kennung mit der weiteren Kennung verglichen wird, – bei dem die Überprüfung der Kennung erfolgreich war, falls die entschlüsselte Kennung und die weitere Kennung identisch sind.
Verfahren nach Anspruch 9, bei dem zur Verschlüsselung und zur Entschlüsselung ein symmetrisches oder ein asymmetrisches Verschlüsselungsverfahren eingesetzt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem anhand der Kennung von dem Fahrzeugrechner bestimmt wird, – ob die Kennung vorhanden ist und – falls die Kennung vorhanden ist, welche Art der Überprüfung der Kennung durchzuführen ist.
Verfahren zum Überprüfen einer von einer Balise (106, 107) bereitgestellten Kennung, – bei dem von einem Fahrzeugrechner (102) eines Schienenfahrzeugs (101) die Kennung und eine Information von der Balise (106, 107) empfangen werden, – bei dem die Kennung von dem Fahrzeugrechner (102) überprüft wird.
Verfahren nach Anspruch 12, bei dem bei erfolgreicher Überprüfung der Kennung die Information zum Betrieb des Schienenfahrzeugs genutzt wird.
Verfahren nach einem der Ansprüche 12 oder 13, bei dem die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG empfangen wird.
Verfahren zum Bereitstellen einer Kennung durch eine Balise (106, 107), – bei dem eine Kennung basierend auf einer Information erstellt wird, – bei dem die Kennung und die Information beim Überfahren der Balise (106, 107) einem Schienenfahrzeug (102, 101) bereitgestellt werden, – so dass anhand der Kennung die Authentizität der Balise (106, 107) von dem Schienenfahrzeug (102, 101) überprüfbar ist.
ETCS-Streckenausrüstung – mit mindestens einer Balise (106, 107), – wobei die mindestens eine Balise (106, 107) derart eingerichtet ist, dass sie bei Überfahren einem Schienenfahrzeug (101) eine Kennung und eine Information bereitstellt, wobei die Kennung basierend auf der Information erstellt wurde, so dass anhand der Kennung die Authentizität der Balise (106, 107) von dem Schienenfahrzeug (101) überprüfbar ist.
ETCS-Streckenausrüstung nach Anspruch 15, bei der die Kennung mittels einer kryptographischen Hashfunktion bestimmbar ist und bei der die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG abspeicherbar ist.
Schienenfahrzeug (101) mit einem Fahrzeugrechner (102), der derart eingerichtet ist, dass – die Kennung und eine Information von der Balise (106, 107) empfangbar sind, – anhand der Kennung die Authentizität der Balise (106, 107) von dem Schienenfahrzeug (101) überprüfbar ist.