EP3137363A1 - Überprüfung der authentizität einer balise - Google Patents

Überprüfung der authentizität einer balise

Info

Publication number
EP3137363A1
EP3137363A1 EP15725327.9A EP15725327A EP3137363A1 EP 3137363 A1 EP3137363 A1 EP 3137363A1 EP 15725327 A EP15725327 A EP 15725327A EP 3137363 A1 EP3137363 A1 EP 3137363A1
Authority
EP
European Patent Office
Prior art keywords
identifier
balise
information
rail vehicle
vehicle
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP15725327.9A
Other languages
English (en)
French (fr)
Other versions
EP3137363B1 (de
Inventor
Uwe Deichmann
Werner Friedrichs
Norbert Geduhn
Udo GOLEBNIAK
Jochen KÄPPEL
Dirk Schulz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Mobility GmbH
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP3137363A1 publication Critical patent/EP3137363A1/de
Application granted granted Critical
Publication of EP3137363B1 publication Critical patent/EP3137363B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L3/00—Devices along the route for controlling devices on the vehicle or train, e.g. to release brake or to operate a warning signal
    • B61L3/02—Devices along the route for controlling devices on the vehicle or train, e.g. to release brake or to operate a warning signal at selected places along the route, e.g. intermittent control simultaneous mechanical and electrical control
    • B61L3/08—Devices along the route for controlling devices on the vehicle or train, e.g. to release brake or to operate a warning signal at selected places along the route, e.g. intermittent control simultaneous mechanical and electrical control controlling electrically
    • B61L3/12—Devices along the route for controlling devices on the vehicle or train, e.g. to release brake or to operate a warning signal at selected places along the route, e.g. intermittent control simultaneous mechanical and electrical control controlling electrically using magnetic or electrostatic induction; using radio waves
    • B61L3/121—Devices along the route for controlling devices on the vehicle or train, e.g. to release brake or to operate a warning signal at selected places along the route, e.g. intermittent control simultaneous mechanical and electrical control controlling electrically using magnetic or electrostatic induction; using radio waves using magnetic induction
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L15/00—Indicators provided on the vehicle or train for signalling purposes
    • B61L15/0018—Communication with or on the vehicle or train
    • B61L15/0027—Radio-based, e.g. using GSM-R

Definitions

  • the invention relates to a method for operating a rail vehicle, a method for checking a tag provided by a balise, a method for providing a tag by a balise, an ETCS track equipment and a rail vehicle.
  • ETCS European Train Control System
  • An ETCS vehicle device includes e.g. an ETCS computer (EVC, also referred to as On-Board Unit (OBU)), a Driver Machine Interface (DMI), a pathway meter, a GSM-R transmission facility (including Euroradio), a Baiisen reader and a brake access
  • EMC ETCS computer
  • DMI Driver Machine Interface
  • GSM-R GSM-R transmission facility
  • Baiisen reader and a brake access
  • ETCS Level 1 uses balises as transmission medium.
  • the information conveyed by the balises are line gradients, maximum line speeds and the point at which the vehicle should stop. Together with an ETCS mode, these form the Movement Authority (MA), translated as "permission to move” or “driving license”.
  • MA Movement Authority
  • ETCS modes are also defined.
  • the modes describe the states in which the EVC can be located (see also: http://en.wikipedia.org/wiki/ETCS).
  • RBC radio control center
  • the track utilization compared to Level 1 can be increased slightly.
  • the RBC Before the RBC can calculate the information necessary for a driving license (MA), the RBC must know exactly where the train is and in which direction it is traveling. The determination of position and direction is the responsibility of the vehicle computer, which transmits this regularly via GSM-R to the route. For the determination, however, reference points on the route are needed.
  • the information about free track sections is determined via the stationary track release signal from the signal box and transferred to the line center:
  • the section is divided into sections ("blocks") as in conventional safety technology, and the train is allowed to enter the retract next section only if this is not from another Train occupied, but is reported as 'free'.
  • CRC Cyclic Redundancy Check
  • the CRC code is suitable for detecting common errors on communication channels. It is disadvantageous here that such CRC codes do not protect against intentional (malicious) manipulation of the data, e.g. in the form of different attacks. For example, the following changes could be made to the telegrams of the balise:
  • balise e.g. "Continue” (Proceed) instead of “Stop” (Stop);
  • the object of the invention is to avoid the disadvantages mentioned above and in particular to provide a possibility for a secure and reliable transmission of the data from the balise to the vehicle computer of a rail vehicle.
  • the information provided is used in particular by e.g.
  • the information contained in the information for the operation of the rail vehicle are complied with.
  • the rail vehicle is controlled based on the information, provided that the identifier could be successfully verified.
  • the successful verification of the identifier comprises, in particular, a verification of the identifier.
  • the authenticity of the balise can thus be ensured. This ensures that the information obtained also comes from the Balise and it is prevented that an attacker - disguised as a balise - unknowingly transmits the information to the rail vehicle.
  • the identifier is not checked by the vehicle computer, if it is determined that no identifier is present or if the identifier has a predetermined value. For example, a check may be omitted if there is no identifier. This can be determined by the identifier having a predetermined value, eg the field in which the identifier is transmitted is empty or has or contains a specific value.
  • the check is only performed if the identifier is recognized as such.
  • the identifier it is possible for the identifier to have an additional value, e.g. in the form of a bit pattern, for example, which is part of the identifier and / or is present in addition to this.
  • the additional value of the identifier can be prefixed or attached.
  • a data field in which the identifier could be transmitted is used for another purpose and if there is no identifier in it, this is recognized and the verification of the identifier can be dispensed with.
  • the information is not used if the verification of the identifier was unsuccessful. Unless the identifier (existing and recognized as such) could not be verified, it is assumed, for example, that the information from the balise is invalid. It can then a suitable action, such as a check of the balise and / or the transfer of the system in a safe state, such as braking or stopping the rail vehicle, initiated.
  • the identifier comprises at least one of the following options:
  • the identifier is transmitted in a block 44 of the ETCS implementation according to UNISIG.
  • the identifier is checked by the vehicle computer by determining a further identifier on the basis of the information and by comparing the identifier with the further identifier, the verification of the identifier was successful if the identifier and the other identifier are identical.
  • the identifier is encrypted
  • a further identifier is determined by the vehicle computer on the basis of the information and the decrypted identifier is compared with the further identifier
  • An alternative embodiment is that a symmetric or asymmetric encryption method is used for encryption and decryption.
  • a next refinement is that it is determined by the vehicle computer based on the identifier
  • the identifier can have a value for identification of the identifier, for example in the form of a bit pattern, by means of which it can be determined that it is an identifier.
  • the identifier may have a value for identifying the type of the identifier, so that it can be determined based on which algorithm the identifier can be checked.
  • the value for identifying the identifier and / or the value for identifying the type of identifier may be coded in a bit pattern.
  • the bit pattern can be used, for example, as a header or the like. Be part of the identifier or be transmitted separately from the identifier.
  • An embodiment consists in that upon successful verification of the identifier, the information for operating the
  • the identifier is received in a block 44 of the ETCS implementation according to UNISIG.
  • the object is achieved by means of a method for providing an identifier by a balise
  • the at least one balise is arranged such that it provides an identifier and information when driving over a rail vehicle, wherein the identifier is created based on the information was, so that based on the identifier, the authenticity of the balise of the rail vehicle is verifiable.
  • a development consists in that the identifier can be determined by means of a cryptographic hash function and that the identifier can be stored in a block 44 of the ETCS implementation according to UNISIG.
  • the object is also achieved by means of a rail vehicle with a vehicle computer which is set up in such a way that
  • the authenticity of the balise is verifiable by the rail vehicle.
  • the vehicle computer mentioned here may in particular be embodied as a processor unit and / or an at least partially hard-wired or logical circuit arrangement which is set up, for example, such that the method can be carried out as described herein.
  • Said vehicle computer can be or include any type of processor or computer or computer with correspondingly necessary peripherals (memory, input / output interfaces, input / output devices, etc.).
  • the vehicle computer may be part of a control unit of the rail vehicle.
  • FIG. 1 shows an exemplary diagram comprising a rail vehicle with a vehicle computer connected to a balise antenna, wherein the rail vehicle moves along a route in the direction of two balises;
  • the rail vehicle (also referred to as "train”) has at least one, in particular at least two cars, wherein the vehicle may be a traction vehicle, a travel car, a freight car or a combination of such parts or functions.
  • the traction unit has a driver's cab (also referred to as an operator station) and can be designed with or without drive.
  • the traction vehicle may in particular be a locomotive. Every car of the
  • Rail vehicle may be equipped with a vehicle computer; If the vehicle computer (possibly with the mobile communication interface) provides an ETCS function, it may also be called an ETCS car.
  • ETCS car In principle, it is possible that only the traction vehicles each have a vehicle computer (possibly with the mobile communication interface) or that individual cars that are not traction vehicles have such vehicle computers (possibly with the mobile communication interface).
  • a so-called packet 44 of the ETCS implementation according to UNISIG can be used to transmit a protected message (eg from the balise) to the vehicle computer of the rail vehicle.
  • the packet 44 allows the transparent transmission of (any) information.
  • the protected message can thus be transmitted in the packet 44.
  • the protected message is an identifier.
  • the identifier may include at least one of the following options (values or data):
  • the identifier can be determined based on a cryptographic hash function.
  • cryptographic hash functions are the so-called message-digest algorithms, e.g. "MD2" or "MD4" (see, e.g., RFC 1320 of the Network Working Group,
  • the identifier can be embedded in the packet 44 and transmitted as part of the balise telegram together with other information from the balise to the vehicle computer of the rail vehicle. Based on the identifier of the vehicle computer can authenticate the balise, ie determine whether the information received from the designated
  • the telegrams can additionally be used against deliberate manipulation of data (in particular so-called “man-in-the-middle” attacks, cf.
  • the identifier may include the value of a hash function.
  • Hash function (also called a scatter function) is an image that maps a large input set (the keys) to a smaller target set (the hash values).
  • the hash function is not necessarily injective.
  • the input quantity may also contain elements with different lengths, whereas the elements of the target quantity have, in particular, a fixed length. A so-called collision occurs when the same hash value is assigned to different input data.
  • the identifier may also include the value of a cryptographic hash function (also referred to as a cryptological hash function) (cf.
  • the identifier comprises a digital signature.
  • a digital signature also known as a digital signature method, is an asymmetric cryptosystem in which a sensor which uses a secret signature key (the private key) to calculate a value for a digital message (ie for any data), which is also called a digital signature. This value allows anyone to check the integrity of the message using the public verification key (the public key) (cf.
  • the telegram of the balise (or a part of the telegram of the balise) can be verified by the vehicle computer based on the public key of the balise.
  • the balise uses its secret signature key, which is preferably stored as secure as possible in the balise and can only be used by the balise itself.
  • a hash value of the telegram or a part of the telegram is stored and transmitted to the vehicle computer of the rail vehicle.
  • the vehicle computer now determines a hash value of the telegram or a part of the telegram.
  • Hash value based on the telegram or on a part of the telegram and compares this hash value with the hash value obtained in the packet 44. If both hash values are identical, it is assumed that the telegram was not intentionally manipulated.
  • the hash value of the information to be transmitted is signed by the balise (ie encrypted with the private key of the balise) and stored as an identifier in the packet 44.
  • the information and the identifier are transmitted (eg as a telegram) to the vehicle computer of the rail vehicle.
  • the vehicle computer now determines a hash value based on the information and decodes the identifier based on the public key of the balise (this can optionally be transferred from the balise).
  • the hash value determined by the vehicle computer is compared to the hash value created by the beacon. adjusted; if both are identical, then the identifier is successfully verified, the information provided by the balise can be used or further processed accordingly.
  • a mark may be included, for example in the form of a bit combination, which indicates to the vehicle computer of the rail vehicle whether the packet 44 can be used to check or authenticate the message. If this is the case, for example, one of the above-mentioned checks (verifications) can take place. If, on the other hand, the packet 44 is empty or does not have any of the possibly predetermined number of bit combinations, then no check based on the data of the packet 44 takes place. This approach is therefore also compatible with other uses of package 44.
  • each balise authenticate itself.
  • at least one data field may be provided, which is used for the transmission of the identifier, so that the sending balise can be authenticated on the basis of the identifier. If a balise can not be verified then an appropriate action can be taken, including e.g. one of the following: issuing a warning message; Transferring the system and / or at least one rail vehicle to a safe state (e.g., stoppage); Checking and, if necessary, maintaining the balise; Etc.
  • bit combination in the packet 44 may have different values, each of which is associated with a particular type of verification. For example, a given bit combination may indicate that a hash value has been stored in packet 44; it may also be specified by the value of the bit combination which hash function was used to create the hash value. Furthermore, another value of the bit combination may indicate that an electronic signature is stored. chert is or according to which algorithm the electronic signature was generated.
  • FIG. 1 shows an exemplary diagram comprising a rail vehicle 101 with a vehicle computer 102 which is connected to a balise antenna 103.
  • the rail vehicle 101 moves on a route 104 in a direction of travel 105. In the direction of travel 105, the rail vehicle 101 first passes over a balise 106, then a balise 107.
  • balises 106 and 107 are euro balises, with the balise 106 exemplifying a
  • the Transparent Data Beautyse or Controllable Balise for example, is connected by a cable to a trackside electronic unit (LEU, Lineside Electronic Unit).
  • LEU trackside Electronic Unit
  • the LEU transmits the respective telegram to the balise.
  • balise here also includes several successively provided balises a so-called Baiisentik.
  • the balise 106 and / or the balise 107 sets the rail vehicle 101 when crossing the respective balise by means of the balise antenna 103 and the vehicle computer 102
  • (Balisen) telegram having a data field (e.g., in the form of packet 44 described above) in which e.g. the identifier is included.
  • a data field e.g., in the form of packet 44 described above
  • the identifier is included.
  • the data field On the basis of the data field, a check of the integrity or authenticity of the data obtained is possible. In particular, it can thus be ensured that the information is actually received by the balise 106
  • the respective balise 106 or 107 is designed in such a way that access to a secure storage area from the outside is not possible or only with great effort.
  • a private key used to create the signature may be stored. This key is preferably suitable to secure against external access.
  • the balises in the telegram e.g., in the data field or packet 44
  • the rail vehicle can check whether the public key matches the position of the balise.
  • the data of the telegram from the vehicle computer of the rail vehicle further processed.
  • 2 shows an exemplary flow diagram of a communication between the balise 106, 107 and the vehicle computer 102 of the rail vehicle 101.
  • the balise 106, 107 creates the telegram or receives from the LEU the message to be forwarded.
  • the balise generates a hash value by means of a cryptographic hash function (eg MD4) and stores the hash value in the packet 44 of the ETCS implementation according to UNISIG (SUBSET-026-7).
  • the telegram is transmitted from the balise 106, 107 to the vehicle computer 102.
  • the vehicle computer 102 uses the telegram (based on predetermined data of the telegram, eg all data without the packet 44) in a step 204 to determine a hash value by means of a cryptographic hash function which was also used by the balise 106, 107. In a step 205, the vehicle computer 102 compares the determined hash value with that read from the packet 44
  • Hash If both hash values are identical, it is assumed that the data of the telegram have not been corrupted and an action (e.g., control of the rail vehicle 101) is made based on this data. If the two hash values are not identical, then an error message can be generated e.g. the rail vehicle and / or a signal box are displayed. In particular, in this case, the rail vehicle operation can be converted into a safe state and it can then be checked whether the balise 106, 107 is defective or whether a manipulation attempt was present.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Train Traffic Observation, Control, And Security (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)

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

Beschreibung
Überprüfung der Authentizität einer Balise 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 Bahntechno- logie 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 Baiisenleser 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 Eurobaiisen benutzt, welche beispielsweise in Ausfahrgleisen von Bahnhöfen sowie in (z.B. unregelmäßigen) Abstän- den auf freier Strecke angebracht sind. Zwischen diesen Referenzpunkten wird die Position odometrisch mittels Doppier- 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 Ab- schnitte ("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:
htt : //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 unter- schiedlicher 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 bereitgestell - ten 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öchstge- schwindigkeit ;
- 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 Informa- tion 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 kryptographisehen 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 über- mittelt.
Eine nächste Weiterbildung besteht darin, dass
- die Kennung von dem Fahrzeugrechner überprüft wird, indem anhand der Information eine weitere Kennung be- stimmt 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 kryptographisehen 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 Aus- fü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:
Fig.l 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;
Fig.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 Ab- teilen 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 Kommunikationsschnittstel- le) 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 44 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:
- verschlüsselte Daten;
- unverschlüsselte Daten;
- Daten, die basierend auf einer Hashfunktion, insbesondere einer kryptographisehen 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. Beispielsweise kann die Kennung basierend auf einer kryptog- raphischen Hash-Funktion bestimmt werden. Beispiele für kryp- tographische 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/rfcl320) .
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 Schienenfahr- zeugs ü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 Hash- wert zugeordnet wird.
Die Kennung kann auch den Wert einer kryptographisehen 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 Sen- der 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 öffent- liehen 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 ver- wendet werden kann.
Eine Möglichkeit besteht darin, dass in dem Paket 44 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 manipu- liert 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 ver- glichen; 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ög- lichkeiten 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 Bitkombi- nation 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 vorge- geben sein, welche Hashfunktion zur Erstellung des Hashwerts verwendet wurde. Weiterhin kann ein anderer Wert der Bitkombination anzeigen, dass eine elektronische Signatur gespei- chert 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 . Fig.l 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/Eurobaiise) .
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 meh- rere hintereinander vorgesehene Balisen einer sogenannten Baiisengruppe 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 bewerk- stelligen 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 öf- fentliche 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. Fig.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 Tele- gramm oder erhält von der LEU das weiterzuleitende Telegramm. In einem Schritt 202 erstellt die Balise einen Hashwert mittels einer kryptographisehen 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 kryptographisehen 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 de- fekt 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.

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 detek- tiert 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 kryptographisehen 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 Informati on 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 Ken nung identisch sind. Verfahren nach Anspruch 9, bei dem zur Verschlüsselung und zur Entschlüsselung ein symmetrisches oder ein asym metrisches 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.
16. 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.
17. ETCS-Streckenausrüstung nach Anspruch 15, bei der die Kennung mittels einer kryptographisehen Hashfunktion bestimmbar ist und bei der die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG abspeicherbar ist.
18. 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.
EP15725327.9A 2014-06-27 2015-05-27 Überprüfung der authentizität einer balise Active EP3137363B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014212516.2A DE102014212516A1 (de) 2014-06-27 2014-06-27 Überprüfung der Authentizität einer Balise
PCT/EP2015/061697 WO2015197286A1 (de) 2014-06-27 2015-05-27 Überprüfung der authentizität einer balise

Publications (2)

Publication Number Publication Date
EP3137363A1 true EP3137363A1 (de) 2017-03-08
EP3137363B1 EP3137363B1 (de) 2019-12-04

Family

ID=53269481

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15725327.9A Active EP3137363B1 (de) 2014-06-27 2015-05-27 Überprüfung der authentizität einer balise

Country Status (5)

Country Link
EP (1) EP3137363B1 (de)
DE (1) DE102014212516A1 (de)
ES (1) ES2773437T3 (de)
WO (1) WO2015197286A1 (de)
ZA (1) ZA201607726B (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016204630A1 (de) * 2016-03-21 2017-09-21 Siemens Aktiengesellschaft Verfahren zum Übertragen von Nachrichten in einem Eisenbahnsystem sowie Eisenbahnsystem
DE102016217190A1 (de) * 2016-09-09 2018-03-15 Siemens Aktiengesellschaft Verfahren zum Übermitteln einer Information von einer streckenseitigen Einrichtung zu einem Fahrzeug sowie Einrichtungen zum Durchführen eines solchen Verfahrens
DE102017209926A1 (de) * 2017-06-13 2018-12-13 Siemens Aktiengesellschaft Verfahren zum Betreiben eines spurgebundenen Verkehrssystems
EP3483032B1 (de) * 2017-11-09 2020-05-27 Siemens Mobility S.A.S. System und verfahren zum schutz der kommunikation zwischen einer balise und einem geführten fahrzeug vor übersprechen
RU2683704C1 (ru) * 2018-03-21 2019-04-01 Открытое Акционерное Общество "Российские Железные Дороги" Устройство безопасного обмена ответственной информацией по каналу связи локомотивными и стационарными устройствами безопасности на железнодорожном транспорте
RU2695971C1 (ru) * 2018-09-20 2019-07-29 Открытое Акционерное Общество "Российские Железные Дороги" Система передачи ответственной информации по защищенным каналам радиосвязи
RU2692362C1 (ru) * 2018-09-20 2019-06-24 Открытое Акционерное Общество "Российские Железные Дороги" Устройство для обмена данными по каналам радиосвязи
RU2722773C1 (ru) * 2019-12-18 2020-06-03 Акционерное общество "Научно-исследовательский и проектно-конструкторский институт информатизации, автоматизации и связи на железнодорожном транспорте" Децентрализованная система передачи ответственной информации по защищенным каналам радиосвязи
CN114162183B (zh) * 2020-09-11 2023-03-14 比亚迪股份有限公司 列车的定位处理方法、装置及列车
DE102020216277A1 (de) 2020-12-18 2022-06-23 Siemens Mobility GmbH Verfahren zur initialen Verteilung von schützenswerten Daten in einem ETCS-Zugsicherungssystem
DE102021202528A1 (de) 2021-03-16 2022-09-22 Siemens Mobility GmbH Bahntechnikgerät für eine bahntechnische Anlage und Verfahren zu deren Betrieb

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE211826T1 (de) * 1995-03-29 2002-01-15 Siemens Schweiz Ag Verfahren und kommunikationssystem zur datenübertragung zwischen zwei stationen
US8689300B2 (en) * 2007-01-30 2014-04-01 The Boeing Company Method and system for generating digital fingerprint
EP2022697B1 (de) * 2007-08-07 2010-02-03 Alstom Ferroviaria S.P.A. System zur Kommunikation zwischen Fahrzeugen, insbesondere Schienenfahrzeugen, und Streckeneinrichtungen
DE502008003266D1 (de) * 2008-02-11 2011-06-01 Siemens Schweiz Ag Verfahren und Vorrichtung zur sicheren Einstellung von einer Fahrstrasse für ein Schienenfahrzeug
EP2332804B1 (de) * 2009-12-14 2012-06-27 Siemens Schweiz AG Fahrrichtungsbezogene Streckenpunktprüfung für ETCS-Systeme

Also Published As

Publication number Publication date
WO2015197286A1 (de) 2015-12-30
DE102014212516A1 (de) 2015-12-31
ES2773437T3 (es) 2020-07-13
EP3137363B1 (de) 2019-12-04
ZA201607726B (en) 2018-04-25

Similar Documents

Publication Publication Date Title
EP3137363B1 (de) Überprüfung der authentizität einer balise
EP3612430B1 (de) Verfahren zum betreiben eines spurgebundenen verkehrssystems und vorrichtung
EP2658764B1 (de) System und verfahren für ein schlüsselmanagement eines zugsicherungssystems
EP3445635B1 (de) Verfahren zum betreiben einer ortungseinrichtung sowie ortungseinrichtung
EP2421737A1 (de) Verfahren und vorrichtung zur steuerung von eisenbahnsicherungssystemen
DE102014210190A1 (de) Fahrerlaubnis für ein Schienenfahrzeug
EP2531391B1 (de) Verfahren und vorrichtung zur überwachung der zugvollständigkeit
EP3245115B1 (de) Verfahren und vorrichtung zum ermitteln eines signalbegriffes für ein schienenfahrzeug
DE102015210427A1 (de) Verfahren sowie Einrichtung zum Ermitteln einer Fahrerlaubnis für ein spurgebundenes Fahrzeug
EP3060451A1 (de) Etcs-streckenausrüstung
EP3795451B1 (de) Verfahren zum orten eines fahrzeugs an einer für einen halt des fahrzeugs vorgesehenen station
EP3732913A1 (de) Steuereinheit und verfahren zum manipulationsgeschütztes erfassen von betriebssicherheitsrelevanten integritätsüberwachungsdaten
EP3221205B1 (de) Verfahren und vorrichtung zur sperrung und signalisierung eines mit achszählern ausgerüsteten gleisabschnittes
EP3515785B1 (de) Verfahren zum betreiben eines eisenbahnsystems sowie fahrzeug eines eisenbahnsystems
EP2088051B1 (de) Verfahren und Vorrichtung zur sicheren Einstellung von einer Fahrstrasse für ein Schienenfahrzeug
EP1586079A1 (de) Verfahren und anordnung zur mobilen datenuebertragung
EP2819907B1 (de) Verfahren zur hilfsbedienung eines fahrwegelements sowie betriebsleittechnisches system
DE102013226728A1 (de) Steuerung eines Schienenfahrzeugs
WO2014048721A2 (de) Langsamfahrstelle einer bahnstrecke
WO2020007532A1 (de) Verfahren zum sicheren austausch und zur sicheren anzeige von zustandsdaten von sicherheitstechnischen komponenten
EP1396413B1 (de) Verfahren zur Hilfsbedienung von Fahrwegelementen
DE102016217900A1 (de) Überwachung eines Schienenfahrzeugs
DE102016217913A1 (de) Überwachung eines Schienenfahrzeugs

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20161129

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS MOBILITY GMBH

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20190801

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1209033

Country of ref document: AT

Kind code of ref document: T

Effective date: 20191215

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502015011135

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: SIEMENS SCHWEIZ AG, CH

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20191204

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200305

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200304

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200304

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2773437

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20200713

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200429

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200404

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502015011135

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

26N No opposition filed

Effective date: 20200907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20200531

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200527

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200527

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200531

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191204

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20240603

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: AT

Payment date: 20240409

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20240515

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240719

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20240827

Year of fee payment: 10

Ref country code: CH

Payment date: 20240808

Year of fee payment: 10

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 502015011135

Country of ref document: DE

REG Reference to a national code

Ref country code: CH

Ref legal event code: H13

Free format text: ST27 STATUS EVENT CODE: U-0-0-H10-H13 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20251223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20250527

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 1209033

Country of ref document: AT

Kind code of ref document: T

Effective date: 20250527

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20250531

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20250527

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20250527

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20251202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20250531