Trust Your Receiver? Enhancing Location Security ------------------------------------------------ by Oscar Pozzobon Civil applications from hazardous materials tracking to network control that use a remote GNSS receiver to monitor location may require enhancing the trust of location acquisition, to assure that location data has not been spoofed or intentionally modified. A tamper-resistant receiver can quantify location solution reliability and provide cryptographic proof for remote applications. Critical applications in transportation, finance, telecommunications, information technology, energy, utilities, manufacturing, health services, emergency services, defense, and law enforcement increasingly use GPS for location services. Many of these tracking applications will require assurance that location data has not been modified to deceive a remote monitoring application. Application of secure tracking is particularly pertinent to safety-critical and key infrastructure applications, where spoofing of the location data could result in economic or life loss. Because of the widespread use of location for critical services, the location systems must provide authenticity, integrity, and hence trust. Previous vulnerability analyses of GPS in civilian applications have focused on security issues in GPS satellite signaling, for example, investigating the effects of intentional and non-intentional attacks on GPS in the U.S. transportation sector. While one study determined risk based on attacks against GPS signaling, it did not investigate the affects of intentional attacks against data communications upon which GPS location systems rely. Such data communications include GPS augmentation systems (WAAS, EGNOS, and DGPS radiobeacons) that provide GPS differential correction data to improve location accuracy and integrity monitoring of the GPS constellation. While existing GPS and space-based augmentation systems (SBAS) do not provide integrity services, the emerging Galileo and GPS III will provide various levels of integrity protection to civil users. For this reason, there is a requirement for tamper-resistant receivers that will facilitate trusted signal acquisition, provide secure key storage, and facilitate secure communication of the acquired location data to an application. Requirements for Trust The integrity of GNSS satellite signaling can be compromised either by unintentional or intentional disruption. Unintentional disruption includes radio interference, ionospheric effects, and signal blockage. Intentional disruption includes attacks such as jamming, spoofing, and meaconing (receiving radiobeacon signals and rebroadcasting them on the same frequency). Several augmentation systems mitigate unintentional disruption by monitoring the integrity of the GPS constellation. These augmentation systems provide integrity data as well as correction data to improve the accuracy of location measurements that are degraded by errors from the ionosphere, satellite clocks, and other factors. Trusted GNSS-based location systems require determination of the source of data or signaling, ensuring the origin is from an intended party (a GNSS satellite, augmentation system, or GNSS receiver), and detection of unauthorized alteration of data. Trusted location systems also require that the entities providing signaling/data or calculating the location solution from acquired signals will behave exactly as expected. Figure 1 illustrates the requirements for trust along the chain to a destination application. GNSS satellites should provide methods to prevent intentional disruption through signal authentication and data message authentication/integrity protection (1). Signal authentication is the most effective defense against signal spoofing, as unauthenticated users are denied access to the signal, and are unable to simulate the signal. SBAS should also provide signal authentication and data message authentication/integrity (2), as small errors can be introduced into a location solution by spoofing pseudorange corrections and/or integrity data. Depending on the application, these small errors may be critical. The application should be able to determine the type of signaling and authentication status of signaling used in a location solution, so it can determine the trust of the solution based on intractability to attack of the signaling authentication method used. Our proposed GNSS receiver achieves this by indicating the type of signaling and augmentation system used, and cryptographically binding this information to the location data, providing authentication and integrity protection of the location data and signaling type. Receiver status, including properties such as firmware authentication status and non-compliant behavior (such as tampering) detected by the device, should also be communicated to the application with appropriate authentication and integrity protection (3, 4). NMEA Limitations. To date, the National Marine Electronics Association (NMEA) communication standard does not provide support for authentication or cryptographic integrity. As such, the NMEA data can be simulated, resulting in very trivial and low-cost attacks against the integrity of the GNSS location data. The application should be able to authenticate the source of the NMEA data and verify the integrity of the data messages (5). This will allow the application to determine the trust of the acquired location data from the indicated device compliance, device authentication status, signaling type, and augmentation system used. As emerging solutions will provide signal authentication and data message integrity of GNSS satellites for civil applications, we focus on intentional attacks on data communications originating at the receiver. Signal and Data Security Several spoofing methods can deceive a GNSS receiver. Current GPS civil signals do not provide authenticated signaling, and rely on anomaly detection techniques to identify spoofing. This method has varying levels of success, depending on the sophistication of spoofing and detection capabilities. Data communications are also unauthenticated and do not provide cryptographic integrity protection, allowing spoofing and simulation of data messages. Prevention of intentional attacks is a requirement for both GPS signaling and that of augmentation systems such as WAAS and EGNOS that provide ranging signals in addition to integrity and correction data. Next-generation GNSS (GPS III and Galileo) will provide various levels of authenticated signaling and message data integrity to civil receivers. Of the four projected European Galileo services, Safety of Life (SOL) will control access to integrity data through encryption, while Public Regulated Services (PRS) and Commercial Services (CS) will control access to the signals themselves through encrypted ranging codes and navigation data messages. To date there is only one proposal for authenticated signaling or data message authentication in WAAS. Signal Authentication. Current civil ranging signals (C/A code) do not provide an authentication mechanism, so civil C/A code receivers cannot determine whether a signal is authentic or simulated. Several signal and navigation checks can be performed in an attempt to detect anomalies and inconsistencies with other sensors, such as inertial measurement units (IMUs). The P(Y) military code provides authenticated signaling with encrypted CDMA codes and GPS receivers with a tamper-resistant module, the selective availability anti-spoofing module (SAASM), that can decrypt codes based on a key and a declassified black-key distribution infrastructure. Encrypted spreading codes are not suitable for civil purposes, due to the complexity of key distribution and re-keying in case of compromise. In particular, the civil environment is uncontrolled and open to problems such as reverse-engineering of the tamper-resistant modules. Logan Scott, in an ION-GNSS 2003 paper titled "Anti-Spoofing and Authenticated Signal Architectures for Civil Navigation Systems," proposed two classes of spreading code authentication for civil applications: * Public spreading code authentication: Spread Spectrum Security Codes (SSSC) interleaved with the normal spreading codes are used to facilitate signal authentication. A receiver can authenticate the signal on receipt of a proposed Type 7: Authentication message, used to generate the SSSC sequence. The message is released several minutes after the sequence has already been transmitted. This allows the receiver to despread previously collected and stored samples. The signal is authenticated when the SSSC is detected at the correct power level. * Private spreading code authentication: Similar to the public version, except that it uses a tamper-resistant civil anti-spoofing security module (CASM) that stores a protected red key, used in combination with the Type 7: Authentication message to generate an SSSC used specifically for private spreading code authentication. This SSSC is transmitted in the future with respect to the authentication message, significantly reducing the authentication delays experienced in public spreading code authentication. Message Authentication. Data message authentication can significantly increase the difficulty of a spoofing attack. As the data messages would contain a digital signature, an attacker could not generate authentic data messages. The attacker would need to receive the legitimate signal in real time and replay the messages over a spoofed signal. Scott proposes a message authentication scheme, whereby a new Type 7: Authentication message authenticates Type 1-6 messages for the proposed L2C and L5 signals. Non-Cryptographic Validation. Depending on the sophistication of the spoofer and the signal validation measures used, a spoofer may successfully deceive a receiver without access to signal authentication. Non-cryptographic signal validation is based on signal and navigation checks that attempt to detect irregularities. The following signal checks can assist in detecting a spoofed signal: * Monitoring the jamming-to-noise (J/N) power ratio for above-normal energy levels * Monitoring the carrier-to-noise-density (C/[N.sub.0]) ratio for consistency or unexpected C/[N.sub.0] given the J/N * Monitoring the phase difference between antenna elements, to detect signals that come from the same direction. Navigation checks can also assist in detecting a spoofed signal: * Continuity check for time and position * Use of a trusted internal clock to detect time drift of a spoofed signal, given the likelihood it is not synchronized with GPS time * Use of other navigation sensors such as IMUs to confirm consistency * Checking for large residual errors * Use of receiver-autonomous integrity monitoring (RAIM), or other integrity monitoring functions. Receiver Security As the GNSS receiver is responsible for observing the time difference of ranging signals, calculating the location, and indicating the status of signal authentication where used, it must exhibit some form of tamper-resistance for the location to be trusted. A system is said to be tamper-resistant if it is difficult to modify or subvert, even for an assailant with physical access to it. A common form of tamper-resistance is a device or subsystem that contains information that is difficult to extract under such circumstances. To authenticate modernized civil signals and provide secure communication, GNSS receivers will need to store cryptographic keys. The primary value of a secure GNSS device is its ability to provide a trusted sanctuary in a hostile environment. Requirements of a trusted environment include: * Safe software execution: The receiver must provide a secure environment for the control of software and the access to secrets * Tamper detection: The remote application must detect signal and hardware tampering, integrity and authentication status. Security requirements for cryptographic modules are defined by the Federal Information Processing Standards (FIPS) in "Security Requirements for Cryptographic Modules" (2003). This standard provides four increasing qualitative security levels covering potential applications where cryptographic modules may be employed. Some techniques to make hardware tamper-resistant intend to thwart direct attempts at opening a device and reading information out of its memory. Others offer protection against more subtle attacks, such as timing attacks and induced hardware-fault attacks. Electronic devices that store secrets are vulnerable to: * Physical attack (drills, files, solvents, melting the protective coating) * Freezing * Application of out-of-spec voltages or power surges * Use of unusual clock signals * Radiation-induced software errors. These attacks attempt to gain access to the secrets stored in volatile and non-volatile memories. An attacker with physical access to a Galileo or GPS III receiver could use these methods to obtain the cryptographic keys and falsify time and location data. Physical attacks include direct access to electronics circuits to obtain the bits value in memory. Steel-case protection and disordered bits allocation can prevent this. Freezing the device can stop the tampering detection process and zeroization, a process that erases the secrets when tampering is detected. Temperature sensors can detect these attacks. Out-of-voltage attacks and unusual clock signals make the device behave incorrectly and eventually release its secrets. Voltage sensors can set secure voltage offsets. Internal secure clocks can prevent unusual clock signals and detect time spoofing within the drift accuracy. Design techniques to consider when building trusted GNSS receivers include: * Use of light, temperature or resistivity (or capacity) sensors to detect occurrences of malicious probing * Compact circuitry density that makes a logic probe attack less feasible * Use of error-correcting memory * Use of non-volatile memory so that the device can tell if it has been reset * Use of redundant processors to perform calculations, to compare the results before the output. To ensure correct operation of the GNSS receiver firmware, it must be authenticated so that devices where the firmware is running can be trusted, with the assurance that it has not been compromised or modified by an attacker. NMEA Data Security Achieving a chain of trust from satellite signaling to the application requires authentication and integrity of the communications between the GNSS receiver and the application. The NMEA standard protocol used by GPS receivers to transmit data does not provide support for cryptographic integrity or authentication. NMEA data can be simulated in low-cost attacks against the integrity of GNSS data. A signature provides origin authentication and implicit integrity protection, so that if a message is modified, the origin of the message changes. Privacy is an ancillary requirement in the communication of location data. Location data has the potential to be sensitive, and for this reason, confidentiality must be considered. Privacy can be achieved through encryption. Standard protocols such as secure socket layer (SSL) assure privacy in data communications using certificate-based authentication and symmetric key cryptography for session encryption. Tamper-Resistant Module We propose development of a tamper-resistant module containing a GPS receiver module, cryptographic co-processor, and secure key storage. The components are ideally packaged in a multi-chip tamper-resistant module or single chip. The receiver design includes a GNSS digital processing and correlation block (GDPCB), a data encoding and crypto processing block (DECPB) with supporting secure memory for key storage, and a cryptographic co-processor for fast signature generation, as shown in Figure 2. The GDPCB supports signal acquisition using Galileo/GPS III services providing authenticated signaling and or data messaging. Where keys are required for access to authenticated signaling, they can either be stored in the secure memory shared by the DECPB, or in internal key storage. The GDPCB outputs data messages detailing position fix, dilution of precision (DOP), active satellites, etc., used as input to the DECPB, which generates three new messages as detailed in Figure 3. * Signal State Report (SSR): Contains type and status of signaling used for the location solution, indicated by the GDPCB * Device Compliance Report (DCR): Contains status of the device detailing noncompliant activity such as tampering * Signature: Contains a digital signature of up to eight messages, identified by their sentence ID and UTC time. The key storage contains the private key used for generation of the digital signatures in the proposed signature extension to NMEA. The public key corresponding to the private key is certified and bound to the device ID (stored in ROM) in a certificate given to the application. The storage is also used to store CA public keys for verification of the GDPCB and DECPB firmware. NMEA Extensions NMEA output is RS-232 compatible, with defined bandwidths of 4800 and 9600 bps. Most GPS chips support 115 kbps, allowing transmission of more NMEA sentences at a faster frequency. An NMEA sentence begins with a dollar sign and a sentence ID, and ends with a carriage return linefeed (), where data fields are delimited by a comma. The maximum size of an NMEA sentence is 82 bytes (82 characters). Civil receivers commonly transmit these NMEA sentences: * $--GGA: GPS fix data that contains time, 3D position, and accuracy * $--GLL: Latitude and longitude * $--GSA: Number of satellites used in current solution and DOP * $--GSV: Satellites in view * $--RMC: Recommended minimum specific GNSS data (position, velocity, time). While these NMEA sentences provide information such as the signal integrity indication (introduced in NMEA version 2.3 for FAA integrity requirements) and fix quality, this information is not sufficiently detailed to quantify the trust of a location solution, nor is the information integrity-protected, and as such is trivial to simulate. We propose an NMEA signature scheme to calculate the signature of the NMEA messages in a given receiver cycle. Typically, civil receivers have a 1Hz update frequency (10 Hz for high-performance receivers) where a set of NMEA messages are output every update cycle. The signature scheme is given by A [right arrow] B: A, [M.sub.1.w] [T.sub.A], [Sig.sub.A](A, [M.sub.1.w] [T.sub.A]) where A = GNSS receiver B = Application M = Message (NMEA sentences) [T.sub.A] = Time at A (UTC time) [Sig.sub.A]{x} = Signature of x using A's private key. Figure 3 illustrates this scheme implemented in the DECPB. For each receiver cycle, data messages from the GDPCB as well as the SSR and DCR generated in the DECPB, the deviceID and UTC time are taken as input into a secure hash function F. A hash function returns a fixed length output given an input of any length. For the hash function to be secure, it must be one-way and collision free. A hash function H is said to be one-way if it is computationally infeasible to find some input x such that H(x) = h. A strongly collision-free hash function H is one for which it is computationally infeasible to find any two messages x and y such that H(x) = H(y). The message hash is encrypted using the public key encryption algorithm E, and the GNSS receiver's private key to form the signature [S.sub.A]. The application can authenticate and verify the integrity of the NMEA messages included in the signature using this process: * Reassemble signature from the proposed NMEA SIG sentences * Calculate hash of messages included in signature (identified by their sentence ID and UTC time), the deviceID and the UTC time (taken from the first of the four SIG sentences) using the secure hash function F * Verify signature by decrypting it using the certified public key corresponding to the receiver's private key (the public key should be bound to deviceID in the public key certificate). The decrypted signature is verified against the calculated hash. We propose the following NMEA messages to augment the existing protocol, providing necessary signal and device state information, and implementing the proposed signature scheme. Signal State Report. The SSR contains the GNSS satellite signal authentication service used for the location solution, type of SBAS if used, and the signal status. The signal status notifies the application of signal authentication failures and signal anomalies that have been detected. $--SSR, hhmmss.ss, gnssSigType, sbasSigType, sigStatus*hh 1) hhmmss.ss = UTC time 2) gnssSigType: 00 = GPS C/A code 01 = GPS P(Y) code 02 = GPS M code 03 = Galileo OS 04 = Galileo SOL 05 = Galileo PRS 06 = Galileo CS 3) sbasSigType: 00 = None 01 = WAAS 02 = EGNOS 4) sigStatus: 00 = Status OK 01 = GNSS signal authentication failure 02 = GNSS data authentication failure 03 = SBAS data authentication failure 04 = J/N ratio above normal 05 = C/N ratio unexpected given J/N 5) checksum At this time, signal authentication does not appear to be planned for current SBAS. Ideally, authentication should be provided, as absence of authenticated signaling could allow spoofing and data message simulation to occur undetected. The sbasSigType could be updated to support authenticated signal types when available. Device Compliance Report. The DCR contains the current software/firmware version, the current non-compliance activity status, and the number of cycles before the next DCR. If the non-compliance activity status indicated detection of non-compliance activity, the ncar field gives activity type. By specifying the number of cycles before the next DCR sentence, it allows the application to detect whether the DCR has been intentionally disrupted to hide tampering activity. $--DCR, hhmmss.ss, sVer, ncas, ncar, cbDcr*hh 1) hhmmss.ss = UTC Time 2) sVer = Software version 3) ncas = Non Compliance Activity Status 00 = Status OK 01 = Non compliance activity detected 4) ncar = Non Compliance Activity Report 00 = GNSS antenna disconnected 01 = Firmware not authenticated 02 = Undefined tampering 5) cbDcr = Cycles before next DCR 6) checksum Signature. This sentence contains the deviceID, the signature algorithm, and the number of sentences included in the signature. The remaining data is split over four sentences due to the 80-byte limit of the NMEA standard. Each SIG sentence contains two msgSID and msgUTC fields, identifying a message that is included in the signature. The signature is split into four 16-byte fields, each portion included in one of the four SIG sentences. $--SIG, hhmmss.ss, sNumber, deviceID, algorithm, numSentences, msgSID1, 3, 5, 7, msgUTC1, 3, 5, 7, msgSID2, 4, 6, 8, msgUTC2, 4, 6, 8, msgSig*hh where 1) hhmmss.ss = UTC Time 2) sNumber = Sentence Number (1 of 4) 3) deviceID = device identification (12 bytes) 4) algorithm: 0 = SHA1 withDSA 1 = SHA1 withRSA 5) numSentences = Number of sentences included in signature (maximum of 8) 6) msgSID1 .. 2 = Sentence ID e.g. GGA 7) msgUTC1 .. 2 = UTC time of sentence (ss.ss) 8) msgSig = Base64 encoded digital message signature (16 bytes over four sentences) 9) checksum. Key Distribution. A public key infrastructure manages key distribution. The manufacturer certifies the public keys of GNSS receivers and provides the certified public key to the application via an offline process such as a CD-ROM. The public key certificate is bound to the device through the deviceID, a unique device identification number. The deviceID can be included in the subject field, using the X.500 syntax, where the common name is identified as the GPS deviceID: Subject: CN = DeviceID We propose device identification as a 48-bit number composed of two parts, a 24-bit vendor ID and a 24-bit serial number. For example, assuming a vendor ID of 00:00:01, and a GPS receiver serial number of 8C:37:03, the deviceID would be 00:00:01:8C:37:03. Implementation We developed a proof of concept prototype for evaluating the performance of the authentication and integrity scheme, shown in Figure 4. Hardware. The device consists of a 16-channel GPS receiver capable of providing NMEA data at a speed of 115 kbps and 1 Hz data update frequency, a microcontroller, and a cryptographic module. The microcontroller platform embeds a microcontroller, static RAM and a flash ROM. The microcontroller has built-in Ethernet support, two integrated universal asynchronous receiver transmitters (UARTs) for serial communication, and a low-level bus protocol interface. The serial interfaces comply with RS232-C standard, and are used for communication to the GPS module and to the application. The platform provides a Java runtime environment loaded together with the APIs in the flash ROM, for execution of Java applets. The static RAM provides Java code execution and file system. The RAM contents are maintained even in the absence of system power, with the use of back-up batteries. The cryptographic module (or iButton) performs key storage and cryptographic processing and is programmable using the JavaCard API, a Java programming environment for smart cards. A Java Virtual Machine (JVM) is encased in a stainless steel container, as well as an integrated 1024-bit modular math coprocessor for cryptographic operations. The microswitches detect any tampering and, if tampered, the system erases the secret keys and data. The prototype uses RSA public key encryption technology algorithm for signing. The math coprocessor is able to perform a 1024-bit RSA encryption in less than a second. However, our test results indicate that actual performance of signature calculation is approximately seven seconds. The modules are integrated on the development board. The serial interfaces communicate with the GPS module and the application, and the bus interface with the iButton. A signal adapter converts the 3.3 V GPS module to the 5 V RS252 DSI. Software. We developed two applets: * GnssSign_host: This applet, executed in the microcontroller, reads NMEA sentences from the GPS module, generates SSR and DCR NMEA sentences, dispatches NMEA sentences, UTC time, and deviceID to the iButton for signing, generates SIG NMEA sentence from the signature data returned from the iButton, and outputs NMEA sentences to the serial interface. * GnssSign_applet: This applet, executed within the cryptographic module, produces the signature (hashing data and encrypting with private key). Secured Tracking We produced a prototype secure tracking module (Figure 5) integrating the proposed GNSS receiver with a GSM modem. The GNSS receiver outputs NMEA data with the proposed security extensions to the GSM modem, which contains a MIDP 1.0-com-pliant Java Virtual Machine running a Java applet that connects to the telematic server and compresses NMEA data to reduce communications cost. The telematic server decompresses the data and then verifies it. All sentences up to and including the four $--SIG sentences are buffered (stored in memory until the complete signature and original message are obtained) for verification. The $--SIG sentences are read to determine which buffered sentences are to be included in the verification. The identified sentences are then input to the secure hash function identified by the algorithm field of the $--SIG sentences. The resulting hash is compared with that obtained from decrypting the signature. The signature is reassembled from the four $--SIG sentences and decrypted using the receiver's public key. The correct public key is identified by the deviceID received in the NMEA data, and the public key certificate which contains the corresponding deviceID and public key. The telematic server uses algorithms to determine if non-verified data deviates significantly from the verified data, notifying the user by an alarm of any deviations or non-compliance activity reported. GSM encryption provides location data privacy. Due to security issues with GSM protocols, we will include SSL support for the next version of the tracking module. Future Work Ongoing development of the tamper-resistant GNSS receiver will incorporate interference detection and mitigation strategies, whose status will form part of the signal state report. We are also investigating the design of a single tamper-resistant chip for civil GNSS receivers that will include a cryptographic accelerator and secure key storage. We plan to test the architecture with Galileo SOL and PRS signal simulators. In addition, we are currently investigating authentication schemes for ground-based augmentation systems (GBAS) and SBAS. Acknowledgment We gratefully acknowledge the support of Siemens for providing development equipment for the GPRS module. Manufacturers The GPS module in the prototype is a Laipac UV-40 from Laipac Technology (Richmond Hill, Ontario, Canada). The prototype also incorporates a Dallas Semiconductor DS80C390 microcontroller, iButton cryptographic module, and a MAX233 signal adapter, all from Maxim Integrated Products (Sunnyvale, California), and a Siemens (Munich, Germany) TC45 GPRS modem. RELATED ARTICLE: Security Candidates Applications requiring authentication: Hazardous materials tracking. Transportation of chemicals, fuel, and radioactive waste require trust of location data. Vehicle toll collection. The European Union may use GNSS positioning in new road toll systems, and U.S. states have developed similar proposals. Aircraft. The Future Air Navigation System (FANS) uses GPS, inertial measurements, and other data for air traffic control. Access control. Location information can augment security for computer network access control and auditing. OSCAR POZZOBON received a diploma in computer science engineering in 2001 and a degree in information technology engineering in 2003 from University of Padova, Italy, and is currently a master's candidate at the University of Queensland, Australia. CHRIS WULLEMS received a bachelor's degree in information technology from the Queensland University of Technology, Australia, and is currently a doctoral candidate there. KURT KUBIK is a professor at the University of Queensland's School of Information Technology & Electrical Engineering. In 2004, the three authors founded Quality and Secure Communications (Qascom), based in Bassano del Grappa, Italy. COPYRIGHT 2004 Advanstar Communications, Inc. COPYRIGHT 2004 Gale Group