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

Überprüfung der authentizität einer balise Download PDF

Info

Publication number
EP3137363B1
EP3137363B1 EP15725327.9A EP15725327A EP3137363B1 EP 3137363 B1 EP3137363 B1 EP 3137363B1 EP 15725327 A EP15725327 A EP 15725327A EP 3137363 B1 EP3137363 B1 EP 3137363B1
Authority
EP
European Patent Office
Prior art keywords
identifier
balise
rail vehicle
information
checking
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.)
Active
Application number
EP15725327.9A
Other languages
English (en)
French (fr)
Other versions
EP3137363A1 (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 Mobility GmbH
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 Mobility GmbH filed Critical Siemens Mobility GmbH
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

Images

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 Balise reader and a brake access (http://de.wikipedia.org/wiki/ETCS).
  • EMC On-Board Unit
  • DMI Driver Machine Interface
  • GSM-R transmission facility including Euroradio
  • a Balise reader and a brake access (http://de.wikipedia.org/wiki/ETCS).
  • 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
  • the on-board ETCS equipment can continuously monitor compliance with the permitted speed (and direction) and promptly initiate emergency braking.
  • 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).
  • the RBC radio control center
  • 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.
  • reference points on the route are needed.
  • Eurobalises are used, which are installed, for example, in railway sidings and at (for example, irregular) free-distance distances. Between these reference points, the position is determined odometrically by means of Doppler radar on the traction vehicle floor and Radimpulsgebers on the traction vehicle axles. Partial acceleration sensors are also used.
  • the information on free track sections is determined as in ETCS Level 1 on the stationary track release signal from the interlocking and passed to the line center:
  • the route is - as in conventional security technology - divided into sections ("blocks"), and the train may in the next section retract only if not from another Train occupied, but is reported as 'free'. (Source: http://en.wikipedia.org/wiki/European_Train_Control_System.)
  • CRC Cyclic Redundancy Check
  • Such manipulations are attacks on the data provided by the balise, which can not be detected by the CRC code.
  • the manipulated data (with the appropriate CRC codes for it) may be provided by an attacker as the rail vehicle passes over the balise. This is undesirable especially for security-relevant data.
  • the EP 2 022 697 A1 and the EP 0 735 381 A2 Describe systems and procedures in which the balancing identification is checked on board the vehicle.
  • 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.
  • information and identifier are transmitted together in a telegram from the balise to the vehicle computer of the 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 as long as the identifier could be successfully verified.
  • the successful verification of the identifier comprises, in particular, a verification of the identifier.
  • a verification of the identifier By verifying the identifier can thus authenticity the balise will 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 of the vehicle computer is not checked, if it is determined that no identifier is present or if the identifier has a predetermined value.
  • a check may be omitted if there is no identifier. This can be determined by the identifier having a predetermined value, e.g. the field in which the identifier is transmitted is empty or has a certain 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.
  • Another development is that the information is not used if the verification of the identifier was unsuccessful.
  • 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 is transmitted in a block 44 of the ETCS implementation according to UNISIG.
  • An alternative embodiment is that a symmetric or asymmetric encryption method is used for encryption and decryption.
  • a next embodiment is that it is determined on the basis of the identifier of the rail vehicle, which type of verification of the identifier is performed.
  • 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.
  • One embodiment is that, upon successful verification of the identifier, the information for operating the rail vehicle is used.
  • the identifier is received in a block 44 of the ETCS implementation according to UNISIG.
  • 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 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.
  • the rail vehicle (also referred to as a "train”) comprises at least one, in particular at least two, wagons, which may be a traction vehicle, a travel wagon, a freight wagon or a combination of such compartments 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.
  • Each 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 ETCS car.
  • the solution proposed here makes possible, in particular, a secure transmission of safety-relevant information to the rail vehicle, for example from a balise to the rail vehicle.
  • a so-called packet 44 of the ETCS implementation according to UNISIG can be used to transmit a protected message (for example from the balise) to the vehicle computer of the rail vehicle.
  • a protected message for example from the balise
  • the packet 44 allows the transparent transmission of (any) information.
  • the protected message can thus be transmitted in the packet 44.
  • the identifier may be determined based on a cryptographic hash function.
  • cryptographic hash functions are the so-called message-digest algorithms, e.g. "MD2" or "MD4" (see, for example, RFC 1320 of the Network Working Group, http://tools.ietf.org/html/rfc1320).
  • the identifier may be embedded in the packet 44 and transmitted as part of the balise telegram along 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 obtained comes from the designated Beautyse.
  • the telegrams can additionally be secured against deliberate manipulation of data (in particular so-called “man-in-the-middle” attacks, cf., for example, http://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff).
  • the identifier may include the value of a hash function.
  • the hash function (also referred to as 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) (see http://en.wikipedia.org/wiki/Cryptological_Hashfunction).
  • a cryptographic hash function also referred to as a cryptological hash function
  • the one-way function is complexity-theoretically “easy” to calculate, but “difficult” to reverse.
  • One-way functions are also functions for which no in a reasonable amount of time practically practicable inversion is known.
  • the identifier comprises a digital signature.
  • a digital signature also digital signature method, is an asymmetric cryptosystem, in which a transmitter using a secret signature key (the private key) to a digital message (ie to any data) calculated a value, which is also called digital signature. This value allows anyone to verify the integrity of the message using the public verification key (the public key) (see http://en.wikipedia.org/wiki/Digital_Signature).
  • 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 securely 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 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 with the hash value created by the balise; 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 e.g. in the form of a bit combination which indicates to the vehicle computer of the rail vehicle whether the packet 44 can be used for checking or authenticating the telegram. If this is the case, e.g. one of the above-mentioned checks (verifications) done. 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 the 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.
  • a given bit combination may indicate that a hash value has been stored in packet 44; it may also be predetermined by the value of the bit combination which hash function was used to create the hash value.
  • another value of the bit combination may indicate that stored an electronic signature or according to which algorithm the electronic signature was generated.
  • the use of the packet 44 for the transparent transmission of data that can be used for checking the telegram is to be understood merely as an example. In principle, it is possible to use other or additional data fields in order to transmit relevant information from a transmitter to the vehicle computer of the rail vehicle for the check described here.
  • the transmission of the data may, for example, be wireless (e.g., via radio, near field communication, via a telecommunications network, etc.) or wired.
  • FIG. 11 shows an exemplary diagram including a rail vehicle 101 having a vehicle computer 102 connected to a balise antenna 103.
  • the rail vehicle 101 moves on a route 104 in a direction of travel 105.
  • the rail vehicle 101 first passes over a balise 106, then a balise 107.
  • the balises 106 and 107 are, for example, Euro balises, with the balise 106 being a transparent data balise by way of example and the balise 107 being a fixed data balise (see http://de.wikipedia.org/wiki/Eurobalise).
  • 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 consecutively provided balises a so-called balise group.
  • the balise 106 and / or the balise 107 provides the rail vehicle 101 when crossing the respective balise by means of the balise antenna 103 and the vehicle computer 102 a (balise) telegram having a data field (eg in the form of the above-described package 44) in which eg the identifier is included.
  • a data field eg in the form of the above-described package 44
  • a check of the integrity or authenticity of the data obtained is possible. In particular, it can thus be ensured that the information actually originates from the balise 106 and / or 107 and that these have not been corrupted.
  • the respective balise 106 or 107 is designed so that access to a secure memory area from the outside is not or only with great effort to accomplish.
  • a private key used to create the signature may be stored. This key is preferably suitable to secure against external access.
  • the balise in the telegram also transmits the public key of the balise (also referred to as a public verification key or certificate).
  • the public key of the balise also referred to as a public verification key or certificate.
  • it can be checked by the rail vehicle 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.
  • FIG. 11 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 creates 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.
  • the vehicle computer 102 compares the determined hash value with the hash value read from the packet 44. If both hash values are identical, then it is assumed that the data of the telegram have not been corrupted and an action (eg control of the rail vehicle 101) based on this data is initiated. If the two hash values are not identical, an error message such as the rail vehicle and / or an interlocking can be 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 there was a manipulation attempt.

Landscapes

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

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 EP 2 022 697 A1 und die EP 0 735 381 A2 beschreiben jeweils Systeme und Verfahren bei denen die Balisenkennung an Bord des Fahrzeugs überprüft wird.
  • 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,
    • so dass anhand der Kennung die Authentizität der Balise von dem Schienenfahrzeug überprüft wird,
    • bei dem bei erfolgreicher Überprüfung der Kennung die Information zum Betrieb des Schienenfahrzeugs 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.
  • Die Kennung von dem Fahrzeugrechner wird nicht überprüft, 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 Schienenfahrzeug ü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 Schienenfahrzeug entschlüsselt wird,
    • von dem Schienenfahrzeug 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 Schienenfahrzeug bestimmt wird, 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,
    • so dass anhand der Kennung die Authentizität der Balise 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üft wird.
  • 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 empfangen werden,
    • anhand der Kennung die Authentizität der Balise von dem Schienenfahrzeug überprüft wird.
  • 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:
    • Fig.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;
    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 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 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 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.
  • 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-inthe-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 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 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.
  • Fig.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.
  • 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 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, der durch die Ansprüche definiert ist, zu verlassen.

Claims (17)

  1. 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,
    - so dass anhand der Kennung die Authentizität der Balise (106, 107) von dem Schienenfahrzeug (101) überprüft wird,
    - bei dem bei erfolgreicher Überprüfung der Kennung die Information zum Betrieb des Schienenfahrzeuges (101) genutzt wird.
  2. Verfahren nach Anspruch 1, bei dem die Information nicht genutzt wird, falls die Überprüfung der Kennung nicht erfolgreich war.
  3. Verfahren nach nach Anspruch 1, bei dem die Information nicht genutzt wird, falls die Kennung detektiert wurde und die Überprüfung der Kennung nicht erfolgreich war.
  4. 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.
  5. 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.
  6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG übermittelt wird.
  7. Verfahren nach einem der vorhergehenden Ansprüche,
    - bei dem die Kennung von dem Schienenfahrzeug (101) ü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.
  8. Verfahren nach einem der Ansprüche 1 bis 6,
    - bei dem die Kennung verschlüsselt wird,
    - bei dem die Kennung von dem Schienenfahrzeug (101) entschlüsselt wird,
    - bei dem von dem Schienenfahrzeug (101) 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.
  9. Verfahren nach Anspruch 8, bei dem zur Verschlüsselung und zur Entschlüsselung ein symmetrisches oder ein asymmetrisches Verschlüsselungsverfahren eingesetzt wird.
  10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem anhand der Kennung von dem Schienenfahrzeug (101) bestimmt wird, welche Art der Überprüfung der Kennung durchzuführen ist.
  11. 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,
    - so dass anhand der Kennung die Authentizität der Balise (106, 107) von dem Fahrzeugrechner (102) überprüft wird.
  12. Verfahren nach Anspruch 11, bei dem bei erfolgreicher Überprüfung der Kennung die Information zum Betrieb des Schienenfahrzeugs genutzt wird.
  13. Verfahren nach einem der Ansprüche 11 oder 12, bei dem die Kennung in einem Block 44 der ETCS-Implementierung gemäß UNISIG empfangen wird.
  14. 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üft wird.
  15. 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üft wird.
  16. ETCS-Streckenausrüstung nach Anspruch, 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.
  17. Schienenfahrzeug (101) mit einem Fahrzeugrechner (102), der derart eingerichtet ist, dass
    - die Kennung und eine Information von der Balise (106, 107) empfangen werden,
    - anhand der Kennung die Authentizität der Balise (106, 107) von dem Schienenfahrzeug (101) überprüft wird.
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 EP3137363A1 (de) 2017-03-08
EP3137363B1 true 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 (10)

* 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
HUE050120T2 (hu) * 2017-11-09 2020-11-30 Siemens Mobility S A S Rendszer és eljárás egy balíz és egy vezetett jármû közötti kommunikáció áthallás elleni védelmére
RU2683704C1 (ru) * 2018-03-21 2019-04-01 Открытое Акционерное Общество "Российские Железные Дороги" Устройство безопасного обмена ответственной информацией по каналу связи локомотивными и стационарными устройствами безопасности на железнодорожном транспорте
RU2692362C1 (ru) * 2018-09-20 2019-06-24 Открытое Акционерное Общество "Российские Железные Дороги" Устройство для обмена данными по каналам радиосвязи
RU2695971C1 (ru) * 2018-09-20 2019-07-29 Открытое Акционерное Общество "Российские Железные Дороги" Система передачи ответственной информации по защищенным каналам радиосвязи
RU2722773C1 (ru) * 2019-12-18 2020-06-03 Акционерное общество "Научно-исследовательский и проектно-конструкторский институт информатизации, автоматизации и связи на железнодорожном транспорте" Децентрализованная система передачи ответственной информации по защищенным каналам радиосвязи
CN114162183B (zh) * 2020-09-11 2023-03-14 比亚迪股份有限公司 列车的定位处理方法、装置及列车
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
DE59608544D1 (de) * 1995-03-29 2002-02-14 Siemens Schweiz Ag Zuerich 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
ATE506241T1 (de) * 2008-02-11 2011-05-15 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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
ES2773437T3 (es) 2020-07-13
ZA201607726B (en) 2018-04-25
DE102014212516A1 (de) 2015-12-31
EP3137363A1 (de) 2017-03-08
WO2015197286A1 (de) 2015-12-30

Similar Documents

Publication Publication Date Title
EP3137363B1 (de) Überprüfung der authentizität einer balise
EP2658764B1 (de) System und verfahren für ein schlüsselmanagement eines zugsicherungssystems
DE102014210190A1 (de) Fahrerlaubnis für ein Schienenfahrzeug
EP3445635B1 (de) Verfahren zum betreiben einer ortungseinrichtung sowie ortungseinrichtung
EP3245115B1 (de) Verfahren und vorrichtung zum ermitteln eines signalbegriffes für ein schienenfahrzeug
DE102010026433A1 (de) Steuernetzwerk für ein Schienenfahrzeug
WO2010121906A1 (de) Verfahren und vorrichtung zur steuerung von eisenbahnsicherungssystemen
DE102017209926A1 (de) Verfahren zum Betreiben eines spurgebundenen Verkehrssystems
EP3060451A1 (de) Etcs-streckenausrüstung
WO2018050479A1 (de) Überwachung eines schienenfahrzeugs in einem etcs sicherungssystem
EP3732913A1 (de) Steuereinheit und verfahren zum manipulationsgeschütztes erfassen von betriebssicherheitsrelevanten integritätsüberwachungsdaten
EP3795451B1 (de) Verfahren zum orten eines fahrzeugs an einer für einen halt des fahrzeugs vorgesehenen station
EP3515785B1 (de) Verfahren zum betreiben eines eisenbahnsystems sowie fahrzeug eines eisenbahnsystems
DE10107571A1 (de) System zur Überprüfung der Vollständigkeit eines Fahrzeugverbundes
EP2088051B1 (de) Verfahren und Vorrichtung zur sicheren Einstellung von einer Fahrstrasse für ein Schienenfahrzeug
WO2013156299A2 (de) Verfahren zur hilfsbedienung eines fahrwegelements sowie betriebsleittechnisches system
WO2014048721A2 (de) Langsamfahrstelle einer bahnstrecke
WO2020007532A1 (de) Verfahren zum sicheren austausch und zur sicheren anzeige von zustandsdaten von sicherheitstechnischen komponenten
WO2015090933A1 (de) Steuerung eines schienenfahrzeugs
EP3221205B1 (de) Verfahren und vorrichtung zur sperrung und signalisierung eines mit achszählern ausgerüsteten gleisabschnittes
DE102016217913A1 (de) Überwachung eines Schienenfahrzeugs
DE102016217900A1 (de) Überwachung eines Schienenfahrzeugs
DE102016217905A1 (de) Überwachung eines Schienenfahrzeugs
EP4124540A1 (de) Verfahren und vorrichtung betreiben einer fahrsperre für ein spurgebundenes fahrzeug

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: ES

Payment date: 20230823

Year of fee payment: 9

Ref country code: CH

Payment date: 20230808

Year of fee payment: 9

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