You are on page 1of 13

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 (<CR><LF>), 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 <CR><LF>
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 <CR><LF>
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 <CR><LF>
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

You might also like