LBS


User authentication schemes for GNSS selective broadcasting

Sep 2010 | No Comment

In this paper three different solutions are proposed for the problem of location-based selective broadcasting of traffic messages

Although at present its implementation within the full operational capability is under discussion and called into doubt due to recent changed circumstances in the overall system management, one of the initially planned features of GALILEO satellite positioning services was signal authentication ([1] and [7]). Authentication consists in confirming that a transmitted signal corresponds to the true source. In navigation systems the transmission of signals, that takes place over a radio link, is subject to eventual spoofing attacks ([5], [6]).

With authentication, a certified GALILEO receiver can use the signal and is guaranteed that no forged signal occurs ([4]), while an uncertified receiver cannot gain any assurance about this. Hence, authentication provides a security service that can be used both to accomplish a certain level of anti-spoofing capability and is a key element in a scenario where traceability is needed. For this reason the idea of signal authentication in GALILEO services has aroused in the user-segment community a lot of possible scenarios in tracking related applications.

An authenticated signal can avail future road toll payments, GNSS based insurance policy, new flight management computer and location based access control. Within these wide applications areas, secure tracking has become a new application field that is steady growing ([2] and [3]).

It is worth noting that the ideas the techniques proposed in this paper are based on, still continue to keep working even in absence of the authentication service: however, in this case the robustness of the non anti tamper solutions against unauthorized access results weakened.

Problem: position-based service

The main purpose of this work consists in to investigate some suitable functional and processing schemes in order to allow a GNSS user equipped with a radioreceiver and processing card for gaining access to restricted information.

The availability of such information is considered restricted in the sense that they are supposed to be subject to a couple of constraints:

1. the user has to be an authorized user

2. each authorized user must have access only to a subset of the complete set of data, a subset that is strictly related to the user actual position.

Moreover, an important additional constrain is required to be fulfilled:

3. the information are broadcast to all the users by a Local Element (LE), that is, no selective transmission is performed among authorized users by point to point data links or directional communications.

In particular, possible information that fall within the definition given above could be traffic information or marine/ land vehicle positions relative to a certain geographical area. These information could be broadcast from a service provider, sited in a base station and equipped with suitable data acquisition devices (such as radars, transponders or other kinds of sensors), and digital link broadcasting facilities. A user in that area could be interested to know the vehicular traffic situation around him, that is in its immediate vicinity, in order to take decisions about where is better to go or how to behave. It is not interested to know the traffic situation of the whole region and, more important, the traffic situation data related to the whole area could be considered sensitive information by the service provider or by competent authorities that would deny whole data avail ability to every single user for security reasons. Hence, selective delivering of information based on the user local position is necessary.

The proposed idea is that data, transmitted by way of digital data-links, are not broadcast or received by directional antennas in order to perform selective delivering depending on the local user position. Differently, software processing schemes based on both well known encryption techniques and GNSS-de rived authenticated pseudoranges are proposed.

The typology of information that constitute the broadcast message are, for each user inside a predefined geographical area:

• position (longitude and latitude, height is considered irrelevant for a maritime scenario)

• heading or ground-track velocity direction

• type of vehicle. All these data are supposed to be gathered by the service provider by external sensors.

An approach to the solution

The main requirement consists in giving a selected traffic information related to a selected area. A system user cannot have the possibility to know all the positions of the other users in the entire zone interested by the service but only in a reduced portion around him.

The idea is discussed on a maritime scenario. It is assumed that there are a ground based station (Local Element, LE) that ciphers traffic information and users on board boats/ ships (Mobile Elements, ME) that have to decrypt this message.

Pseudoranges are chosen as keys for ciphering the traffic message. The entire zone interested by the service is divided into cells of equal area forming a grid (see Figure 1).

Fig 1. Cell grid structure for a geographical area where the service is active

In every cell must be defined a reference point, called Hot-Spot, that is taken as the reference from all the ships inside that cell. Each Hot Spot has its ranges from the GNSS satellites. The pseudoranges of the Hot Spot are defined as the keys for decrypting that part of the broadcast message where the traffic information corresponding to that cell are contained. Every boat/ ship inside that cell must know which is its reference Hot Spot. Hence, based on the vehicle actual pseudoranges (that are strictly related to its actual position), the user has to obtain the pseudoranges of its reference Hot Spot.

The idea is that the broadcast message has an header, encrypted by means of a key that is available to all the users subscribing the service. The header contains the structure of the grid of the cells covering the service area: number of cells, orientation of the grid respect to the North, size of the cells. Moreover the header contain the set of GNSS Satellite Identification Number (PRN) to identify the subset of GNSS satellites with respect the pseudoranges has to be computed to. Therefore, the Local Element and all the users share the same satellites to compute their respective pseudoranges (this assumes that within the geographical area covered by the cell grid there are a set of satellites in view to all the GNSS receivers).

An important feature of the processing scheme is related to the authentication service available from GALILEO satellites, in its form of Navigation Message Authentication (NMA). One of the most important problem is that the users are moving across the area interested by the service and they can pass from a cell to another cell with a different Hot Spot. In order to avoid lack of information in the neighbourhood when an user is close to the edge of its reference cell, the traffic information, ciphered with the key of a cell, includes also the traffic information of the surrounding eight cells.

–~~~~~~~~~~~~–

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.

Niki Regina

Ph D student, Department of Electronics, Computer Systems and Telecommunications (DEIS) of the University of Bologna, Italy

Matteo Zanzi

Researcher, ARCES research centre of the University of Bologna, Italy
My Coordinates
EDITORIAL
News
INDUSTRY | GPS | GALILEO UPDATE | LBS | GIS | REMOTE SENSING
Mark your calendar
SEPTEMBER 2010 TO NOVEMBER 2011

«Previous 1 2View All| Next»

Pages: 1 2

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...


Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.