User authentication schemes for GNSS selective broadcasting

Sep 2010 | No Comment

Proposed architecture

Two different types of functional architecture for the processing schemes are presented. The second part of the message, that contains traffic information, is always ciphered by means of the ranges of the Hot Spots. The differences among the three models are in what is ciphered in the first part of the message. The first and second architecture use a symmetric key only to cipher some partial information.

The Local Element creates a grid of cells and each Mobile Element has to know its reference Hot Spot in order to generate the pseudoranges used as deciphering key.

Anti Tamper Solution
Local Element Architecture

The Local Element broadcasts a message organized in three different parts, each one is encrypted with a different key (see Figure 2).

Figure 2. Broadcast message for architecture a)

The first part contains the pseudoranges of the map origin of the cell grid together with the PRN of the selected satellites used for position computation. This information is ciphered with a common key given to all the users of the service. It is important to underline that the map origin can be changed after every new message broadcasting. The LE, who has to be a certified Galileo user, uses the authentication signature of the satellites to cipher the ranges of all the Hot Spots. In fact, in a NMA scheme the satellites add authentication bits to the navigation message stream, and these data are available to an authenticated receiver.

The local traffic information is ciphered with a number of keys equal to the number of Hot Spots. Each key is represented by the difference between the ranges of the Hot Spot and the ones of the origin of the map. The ranges or pseudoranges are computed by using the satellites selected with the PRN part of the message. Consequently, the Local Element ciphers the local traffic information of a cell with the key corresponding to that cell.

Mobile Element Architecture

The Mobile Element (see Figure 3) must be an authorized user. Consequently, it knows the common key given to all the users of the service and can decrypt the information about PRN and map origin.

It is now presented how the mobile element can restore the other two keys. The second part of the message contains the information related to the ranges of all the Hot Spots. All these elements are ciphered with a key generated by using the authentication signature of the satellites. In this way, only a certified user of the Galileo service can extract the authentication messages from its receiver and, together with the PRN information already decrypted, it is able to construct the second key.

PRN numbers together with selected pseudoranges are used as second key for the reference Hot Spot decryption/ selection algorithm. This program chooses the Hot Spot ranges nearest to the selected pseudoranges corresponding to the user actual position.

Once the algorithm outputs the ranges of the reference Hot Spot, the Mobile Element is able to restore the third key. In fact it is based on the difference between the map origin ranges, given in first part of the message, and the reference Hot Spot ranges. After decryption of the selected third part of the message, the user can read the traffic information in its and contiguous cells.

An Anti Tamper device can be used. It makes inaccessible from the outside of the device the information obtained by the use of the second key.

Discrete Solution

The second proposed scheme tries to solve the problem of unauthorized access to information without the use of an Anti Tamper device.

Local E lement Architecture

The idea for this solution is based on the assumption that, in a maritime scenario, ships cannot have a distance less than a certain small value. Consequently, the entire area interested by the service is divided into small cells area. These microcells are grouped into macro-cells which only reference to a single Hot Spot each. In this scheme the Local Element divides the message (see Figure 4) in three parts, each one ciphered with a different key.

Fig 4. Broadcast message for architecture b)

The first key is always common to all the users and is used to encrypt the following information:

• PRN
• map origin ranges
• size of the micro cells

The Local Element ciphers the reference Hot Spot of a macro cell through a key that it is composed by four different fields:

1. The “identification number” of the micro-cell, that it is different for every user because a single microcell can contain only one vehicle.

2. The boat/ship ground velocity

3. The identification type of the ship.

4. The authentication message of the selected PRN satellite.

A single Hot Spot is ciphered as many time as the number of users related to that Hot Spot.

Consequently, in this scheme, the LE is required to create as many keys as the number of users.

The traffic information, third part of the message, is ciphered through a key always based on the ranges of the reference Hot Spot.

The identification type of the ship assumes that there is a sort of communication between the user and the Local Element, or a system that recognizes what kind of ship is located in a specified micro-cell.

Mobile Element Architecture

In this architecture (see Figure 5), as in case a) architecture, the mobile element must be certified in order to use this service. In this way the user, through the usage of the common key, decrypts satellite PRN, the map origin ranges and the size of the cell. The receiver, in order to decrypt its reference Hot Spot, must create the second key which is made by the elements listed in the Local Element description.

Fig 5. Type b) functional architecture

The identification number of the cell is created by an internal simple discretization algorithm that use the map origin ranges and the size of the cell, decrypted by using the common key, together with the selected pseudoranges from a Galileo receiver. Also in this case the selected satellites, whose pseudoranges are in use, are given by the PRN information.

The GNSS service is assumed to deliver the authentication message of each satellite. Consequently, together with the ground velocity information, the user is able to generate the second key and to decipher which is its reference Hot Spot. Once the reference Hot Spot has been decrypted, the receiver uses this information as a key and it is able to decrypt the traffic information of its related area.

Conclusion

In this paper three different solutions are proposed for the problem of location-based selective broadcasting of traffic messages. According to the analysis achieved in the preceding sections, it is worth emphasising advantages and disadvantages of each architecture.

The first proposed functional architecture is quite secure against an eventual attack for the presence of an anti-tamper receiver. Besides, it is not very heavy from the computational burden point of view. In fact the Local Element ciphers information with a number of keys equal to the number of Hot Spots.The second proposed architecture does not contemplate the use of an anti-tamper receiver and the eventual attacks are prevented by the use of the ground velocity and the ship type inside the second key. This solution is less secure then the first while the computational effort remains similar. Moreover, a communication link between the Local Element and Mobile Elements is contemplated in order to make the vehicle type known.

References

Chris Wullems, Oscar Pozzobon, Kurt Kubic, “Signal Authentication and Integrity Schemes for Next Generation Global Navigation Satellite System”, ENC-GNSS Convention, Much, 2008.

Oscar Pozzobon, Chris Wullens, Kurt Kubic, “Secure Tracking using Trusted GNSS Receivers and Galielo Authentication Service”, Journal of Global Positioning System, 2005.

Oscar Pozzobon, Chris Wullens, Kurt Kubic, “Requirements for Enhancing Trust, Security and Integrity of GNSS Location Services”, ION 60th Annual Meeting/U.S. Air force Institute of Technology & The U.S. Air Force Research Laboratory, Dayton, Ohio, June 2004

Logan S., “Anti-Spoofing & Authenticated Signal Architectures for Civil Navigation System”, ION GPS/GNSS, Portland, Oregon, September, 2003.

Hein G., Kneissì F., Rodriguez J., Wallner, “Authenticating GNSS Proofs against Spoofs”, Part I, Inside GNSS, July-August 2007

Hein G., Kneissì F., Rodriguez J., Wallner, “Authenticating GNSS Proofs against Spoofs”, Part II, Inside GNSS, September-October 2007

Galilei Consortium, “The Galilei Project: GALILEO Design Consolidation”, European Commission, 2003.