WO2017005423A1

WO2017005423A1 - Receiver for receiving gnss signals

Info

Publication number: WO2017005423A1
Application number: PCT/EP2016/062529
Authority: WO
Inventors: Ronald Weigel
Original assignee: Siemens Aktiengesellschaft
Priority date: 2015-07-08
Filing date: 2016-06-02
Publication date: 2017-01-12
Also published as: EP3281036A1; DE102015212787A1

Abstract

The invention relates to a receiver (1) for receiving GNSS signals. The invention also relates to a token (100) for use with such a receiver (1), to a vehicle and to a field device having such a receiver. In order to specify a receiver (1) and a token (100) which makes it possible to handle the keys for decrypting an encrypted GNSS system in a modular, simple and secure manner, the invention proposes a receiver (1) which has a token interface (50) having a secure interface (51) which is designed to transmit data (101) needed to represent, calculate and/or decrypt an encrypted GNSS service.

Description

description

Receiver for receiving GNSS signals The invention relates to a receiver for receiving GNSS signals.

Furthermore, the invention relates to a token for use with such a receiver, a vehicle and a field device with such a receiver.

GNSS signals are signals of a global Navigationssa ^¬ tellitensystems (English Global Navigation Satellite System) or short GNSS.

Such a receiver and such a token are used, for example, in emergency vehicles of the fire brigade, police or in railway vehicles for safety-related GNSS-based tasks.

A token, often called security token is generally a hardware component that is used to identify and Au ^¬ authentication runs of users of the receiver. The invention has for its object to provide a receiver and a token that allow the handling of the keys to decrypt an encrypted GNSS system modular, easy and secure. This object is achieved by a receiver having the features specified in claim 1.

A receiver is proposed for receiving GNSS signals, in particular Galileo signals, comprising an analog front-end capable of receiving received data and analogue signals.

Digital conversion of the received data is a digital front end, which has a processor for further processing of the analog front end converted data, a Security interface module, which is connected via a security inter ^¬ face, with the digital front end and a token interface, which is designed for receiving and contacting a token has.

In this case, the security interface module has a security ^¬ controller, which is designed to authenticate the token, the token interface a secure

Interface adapted for the transmission of data required for mapping, calculation and / or decryption of an encrypted GNSS service and / or signal is formed. The transmission of data for decoding a GNSS signal via the secure interface is conceivable. These data can be so-called pseudo random noise codes or also PRN codes. Such executed receiver has the particular advantage that the Schlüsselmana ^¬ GEMENT does not have to do with the production or commissioning ^¬ takeover of the receiver already. The key management, ie the management of the keys required for the decryption and / or calculation of the encrypted GNSS services and / or signals, is thus considerably simplified. Furthermore, it is conceivable that configuration data and / or activation information (feature activation) are transmitted to the configuration or to the activation of further functions.

In a further advantageous embodiment, the receiver in conjunction with the token for access to an encrypted GNSS service, in particular a Public Regulated Service (PRS) is formed. This is particularly advantageous because the receiver can be provided with a token only when required. The tokens can therefore be assigned to individual persons, individual ranks or individual functions, such as safety-critical functions. Such an encrypted GNSS service is, for example, the Galileo Public Regulated Service or the Galileo Commercial Service of the Galileo GNSS. These GNSS services and / or signals are more accurate and reliable. In a further advantageous embodiment of the Recei- is ver when operating without a token for accessing an unverschlüs ^¬ seltes GNSS signal, in particular Galileo Open Service, is excluded. This is particularly advantageous, since the integration density ^¬ the receiver increases and only a single receiver for the reception of unencrypted and encrypted signals is necessary. In cases where an unencrypted Sig ^¬ nal is sufficiently accurate and / or reliable enough, can be dispensed with the token.

In a further advantageous embodiment, the secure interface is formed as an optical interface and / or as an interface according to ISO 7816 and / or USB standard. Alternative interfaces, such as I2C and / or SPI and / or RS232 or a combination of the mentioned or other known interfaces are also possible. It is conceivable that the safe ^¬ technically critical data are transmitted over the optical interface, as this is significantly harder to hear. An energy supply could be made available, for example, via an interface in accordance with ISO 7816, in which case especially smart card interfaces or similar contacts should be mentioned. Also interfaces according to USB standard with a safe channel are conceivable.

In a further advantageous embodiment, the receiver has a coding field, in particular an input field for inputting a pin or a biometric input field. Thus, a so-called two-factor authentication can be performed in which, for example, a PIN or a Finderabdruck in addition to a token to unlock the advanced features of the token must be queried. In this case, the coding field communicates with, for example, an instance for the authorization query and / or access protection in the receiver. The protection against unauthorized access to the encrypted GNSS services and / or signals is increased again. The object is further achieved by a token for use with a receiver, wherein the token is designed for connection to the token interface of the receiver, has a security controller for authenticating the token on the receiver, a token processor for generating data that is necessary are the respective satellite signal in the receiver to map, calculate and / or decrypt, and has a secure token interface for transmitting the data to the receiver. These may be, for example, PRN codes.

In this embodiment, the token can be made particularly small and light. The key management, that is the management of the encrypted for the decryption

GNSS services and / or signals necessary key is, he ^¬ considerably simplified because the token can be separately removed from the receiver let us re ^¬ siege and simple. For a perso ^¬ nalized responsibility of the carrier of the token is possible. Key management, it is no longer necessary to roll out the receiver consuming from its final destination to entfer ^¬ nen or. The security requirements for such a receiver without tokens are significantly lower and also a theft of the receiver without the token represents an extremely low risk.

In a further advantageous embodiment, the secure token interface is formed as an optical interface and / or an interface according to ISO 7816 and / or USB standard. Alternative interfaces, such as I2C and / or SPI and / or RS232 or a combination of the mentioned or other known interfaces are also possible. Analogous to the secure interface of the receiver is the si ^¬ chere token interface also optically feasible. The token provides the data relevant for the use of the encrypted GNSS services and / or signals via this interface. In a further advantageous embodiment, the token has a tamper protection. In this case, a tamper protection can be, for example, a function implemented in the token processor and / or in the security controller of the token, which complicates or excludes manipulation or unauthorized reading out of the token. Alternatively, the tamper protection measures may also be purely mechanical measures that make it impossible, for example, to open the token. For this purpose, a casting of the complete token board and the housing in a resin, such as an epoxy resin, conceivable. When opening the token, the resin would cause the processors or safety controllers to break off and thus become permanently unusable. In a further advantageous embodiment, the token has a means for mechanical destruction of the token processor and / or the security controller.

Should it be necessary to manually and mechanically destroy the token despite the existing security measures, it is conceivable to provide a means of mechanical destruction. This may for example be one or more levers, a mechanism in the interior of the token auslö ^¬ sen, such as a needle, which then destroys the processor and / or the safety controller.

In a further advantageous embodiment of the tokens comprises a code field, in particular a box for entering egg ^¬ nes PINs or a biometric input field on. In order to enable token side two-factor authentication, a simplified, small input field for a PIN could be provided or also a biometric input ^¬ field, which is executable for example in the form of a fingerprint scanner, be provided. With regard to the receiver, this has the advantage that fewer interfaces are needed on the receiver to the outside and thus a more robust design of the receiver is possible. It is also conceivable that the token has an authentication interface via which the token, in particular a user security token, can be authenticated. This interface can be designed for example as an RFID interface or NFC interface.

In a further advantageous embodiment, the token has a key interface, which is provided for programming the token with keys.

Keys are the data necessary for the decryption and / or calculation of the encrypted services. The keys are therefore necessary so that the token in conjunction ^¬ tion with the receiver can decrypt the encrypted GNSS signal. Simplified key management is a key advantage of the token. For example, it is conceivable that the key interface is used once in the production of the token and then sealed. It is conceivable that the key interface from outside the token is not accessible. On the other hand, it is likewise possible for the token to be programmable again with new keys via its key ^interface . For this, the token could be provided with new keys at the certifying body. It is conceivable that the key interface has further security features. It might be necessary to use a corresponding programming ^device with a corresponding secure interface for programming the token with new keys. Furthermore, a particularly advantageous use of a receiver according to the invention in a vehicle is proposed.

The receiver according to the invention is particularly advantageous in connection with a vehicle, since in the vehicle only the receiver must be installed and the necessary keys can be added later with each user via the token. A vehicle does not necessarily have to be a motor vehicle, it can also so ^¬ spindles han a rail vehicle or a watercraft. The use of a receiver according to the invention in aircraft or helicopters is conceivable. In an advantageous embodiment of a vehicle, the receiver is seen in conjunction with the token for unlocking advanced functions or authorization levels of the vehicle ^¬ before. If a vehicle is thus equipped with a receiver according to the invention, then it is conceivable that extended functions are enabled when using a To ^¬ ken. It may be correspondingly important emergency vehicles, for example, in a crisis, but it is equally conceivable that an otherwise normal vehicle using a receiver ^¬ will switch freige when transporting particularly essential goods with a To ^¬ ken for these safety-related transport task. Furthermore, a particularly advantageous use of a

Receivers proposed in a field device. In a Feldge ^¬ advises it can involve a portable receiver with a display which can be used for navigation tasks. Also a field receiver, which will be upgraded in a crisis, for example, the Galileo Public Regulated Service could ^¬ te is conceivable. However, it is also conceivable that the field device is a receiver which can be attached, for example, to a transport item or to a container in order to achieve a corresponding security level. This field device may be a Zeiterfassungsge ^¬ advises alternatively formed reliably detect and output time.

In the following the invention will be described and explained in more detail with reference to the embodiments illustrated in the figures. Show it: 1 shows a schematic representation of a receiver of a token,

2 shows a schematic representation of a token,

3 shows the signal sequence diagram of GNSS signals,

4 shows an embodiment of a token and

5 shows an embodiment of a receiver.

1 shows a receiver 1 having an analog front end 10, a digital front end 20 and a safety interface module 40. The analog front end 10 further includes a ^¬ An antenna arrangement 13 as well as an A / D converter 12th The analog front end 10 is for receiving receive data 11, which may be GNSS signals GNSS-S or PRS signals PRS-S, for example. The analog front end 10 may also include an amplifier for amplifying the receive data 11. The A / D

Converter 12 then forwards the received data 11, which has been converted into digital form, to digital front-end 20. The di ^¬ gitale front end 20 includes a processor 21 and a host interface 22nd The processor 21 may, for example, be an FPGA with an integrated ARM processor and, inter alia, performs the calculation of so-called PVT values (Position Velocity Time). The host interface 22 is to be regarded as optional and allows the connection of the receiv ^¬ verse 1 with other devices. These include, for example, any form of computers or PCs, control units or in a vehicle, for example, a higher-level vehicle control. Via a safety interface 30, the digital Fron is now tend ^¬ 20 connected to the safety interface module 40th The security interface module 40 has a security controller 41 as well as an instance for authorization query or access protection 42. The security controller 41 can be designed, for example, as a security controller SLE 78 by Infineon. The security interface module 40 also includes a token interface 50. The token interface 50 is configured to receive a token 100, and has a secure interface 51 and a further sectional ^¬ point 52. So the token interface 50 allows any number of times to connect ei ^¬ nen token 100 to the receiver and to remove again. The secure interface 51 is provided for transmitting the data necessary for the decryption of an encrypted GNSS service and may be designed, for example, as an optical interface. However, it is also conceivable that the secure interface 51 is a common interface such as USB, which is secured with corresponding ^¬ security mechanisms.

In addition, the token 100 can be seen in FIG. 1, which analogous to the token interface 50 has a secure token interface 151 and a second token interface 152. In this case, could be the secure token interface 151 be formed as an optical interface of the ^¬ le and the second token interface 152 be formed for the power supply of the token 100 interface.

2 shows a larger version of the ge already in FIG 1 ^¬ showed token 100. Similarly, the secure token interface 151 and the second token interface 152 to be seen. A key interface 153 is also shown, as well as a token processor 120 and a security controller 141. The security controller 141 of the token 100 has the following task in particular:

to perform an authentication with respect to the security controller 41 of the receiver 1 known from FIG. 1,

Safely store the keys for decrypting an encrypted GNSS signal and

- provide security-related services and functions, in particular cryptographic functions and information.

The authentication can be done on the one hand via the secure token interface 151 or alternatively via a secure channel in the second token interface 152. The separation of the channel of authentication from the channel of secure data transmission has the advantage that another redundant channel is available. The token processor 120 may be embodied, for example, as an FPGA with integrated tamper protection. For example, if the signal of Galileo Public Regulated Service or PRS signal are evaluated ^¬ , it would be the main task of the token processor 120 to generate so-called PRN codes (pseudo random noise codes). This PRN codes are necessary to map to the respective satellite signal in the receiver and last ^¬ finally be able to benefit.

FIG 3 schematically shows a signal flow diagram within the receiver 1. It shows the reception data 11 are converted by the ana ^¬ lied front end 10 in converted data 111th Receiving data 11 are present as an analog signal and are converted by the analog front end into a digital signal. The digital front end 20 is then able to evaluate according to the ge ^¬ transformed data 111th The data provided by the token 100 as data for mapping, computation and / or decryption of an encrypted GNSS service 101 is transmitted via the token interface 50 and the security interface module 40 via the security interface 30 to the digital Frontend 20 provided. The Be ^¬ calculation of the actual position data, for example the so-called PVT data then takes place in the digital front end 20 or in a processor 21st

FIG. 4 shows an exemplary embodiment of a token 100. The secure token interface 151 is designed as an opti ^¬ cal interface that leads out to the front from the token and therefore is not directly visible. The second token interface 152 is designed here as a conventional contact in the form of a contact according to ISO 7816 or as a smart card contact arrangement. Further seen are two levers 199 which are connected to a mechanism for mechanical ^¬ rule destruction of the security controller 141 and / or token processor 120th This can be at ^¬ play, be a needle within the housing. Furthermore, a coding field 130 can be seen, which is another

Authentication allows. This can be a reduced PIN input field or a biometric input device such as a fingerprint sensor. 5 shows a receiver 1 in a housing 2, which has a coding field 130, which in this case is designed as a keypad for entering a PIN. Also on display are a token interface 50 and its secure interface of ^¬ le 51 and another interface 52. A receiver in this form could for example be installed in a vehicle.

In summary, the invention relates to a receiver 1 for receiving GNSS signals. Furthermore, the invention relates to a token 100 for use with such a receiver 1, a vehicle and a field device with a derarti ^¬ gen receiver. In order to specify a receiver 1 and a token 100 which makes it possible to handle the keys for decrypting an encrypted GNSS system in a modular, simple and secure manner, a receiver 1 is proposed which has a token interface 50 with a secure interface 51 for transmission data 101 required for mapping, calculating and / or decrypting an encrypted GNSS service.

Claims

claims

1. Receiver (1) for receiving GNSS signals (GNSS-S), in particular Galileo signals, comprising:

- An analog front end (10), which is designed to receive reception ^¬ data (11) and for analog-to-digital conversion of the receive data (11),

a digital front end (20) having a processor (21) for further processing of the data (111) converted by the analog front end (10),

- A security interface module (40) that has a

Security interface (30), connected to the digital front end (20) and

a token interface (50), which is designed to receive and contact a token (100),

wherein the safety interface module (40) comprises a safety ^¬ controller (41), which is designed to authenticate the token (100)

wherein the token interface (50) comprises a secure interface (51) adapted to communicate data (101) required to map, compute and / or decrypt an encrypted GNSS service.

2. Receiver according to claim 1, wherein the receiver is formed (1) in connection with the token (100) for access to an encrypted GNSS service, in particular a Public Regulated ^¬ Ser vice (PRS).

3. Receiver according to one of the preceding claims, wherein the receiver (1) when operating without tokens (100) for accessing an unencrypted GNSS signal, in particular Galileo Open Service (OS) is formed.

4. Receiver according to one of the preceding claims, wherein the secure interface (51) is designed as an optical ^{Schnittstel ¬} le and / or as an interface according to ISO 7816 and / or USB standard.

5. Receiver according to one of the preceding claims, wherein the receiver (1) has a coding field (33), in particular an input field for inputting a pin or a biometric input field.

A token (100) for use with a receiver (1) according to any one of claims 1 to 5, wherein the token (100):

- Is designed for connection to the token interface (50) of the receiver (1),

a security controller (141) for authenticating the token (100) on the receiver (1),

- A token processor (120) for generating data

(101), which are required for mapping, calculating and / or deconstructing an encrypted GNSS service, and

- Has a secure token interface (151) for transmitting the data (101) to the receiver (1).

7. token wherein the secure token interface (151) includes an optical interface and / or an interface according to ISO 7816 and / or USB standard is formed of ^¬ as claimed in claim 6.

8. Token according to claim 6 or 7, wherein the token (100) has a tamper protection (155).

A token according to any one of claims 6 to 8, wherein the token (100) comprises means (199) for mechanically destroying the token processor (120) and / or the security controller (141).

10. Token according to one of claims 6 to 9, wherein the token (100) has a coding field (130), in particular an input field for inputting a pin or a biometric input field, on ^¬ .

The token of any one of claims 6 to 10, wherein the token (100) comprises a key interface (153) provided for programming the token (100) with keys.

12. vehicle, comprising a receiver (1) according to one of claims 1 to 5.

13. The vehicle of claim 12, wherein the receiver (1) in conjunction with the token (100) for enabling extended

Functions or authorization levels of the vehicle is provided.

14. Field device with a receiver according to one of claims 1 to 5.