tracking management system for security enhancement · este trabalho apresenta um srgt com uma...
TRANSCRIPT
Tracking Management System for Security Enhancement
José Luis Alexandre Cabral Almeida
Thesis to obtain the Master of Science Degree in:
Telecommunications and Informatics Engineering
Supervisor: Prof. Artur Miguel do Amaral Arsénio
Examination Committee
Chairperson: Prof. Paulo Jorge Pires Ferreira
Supervisor: Prof. Artur Miguel do Amaral Arsénio
Member of Committee: Prof. João Pedro Faria Mendonça Barreto
May 2014
Acknowledgments
To the ones who made it possible...
Abstract
Over the past years many commercial Real-Time Tracking Management systems (RTMS) were
introduced into the market. The solutions started to be designed for simple tracking purposes, but
vendors soon realized that tracking systems would benefit from the design of new services (service
layer). Using a taxi company as example, the location of the fleet can be retrieved through simple
tracking. But in addition, services such as the identification of the drivers who exceed speed limits,
wasting fuel, become possible through the service layer.
From the analysis of many RTMS solutions currently on the market, a suitable solution for general Law
Enforcement Agencies (LEAs) was not yet found. The majority are only available as a service (in the
cloud) or do not provide confidentiality on the transmitted data, in contrast to the requirement of data
delimitation to LEAs infra-structures and high confidentiality of data. A list of requirements was
gathered from one of the Portuguese LEAs, GNR (Guarda Nacional Republicana) to fully understand
the generic daily challenges. Main requirements raised by GNR strive with issues such as: cost, data
exchange security, bi-directional communication services, network performance, fault tolerance and
user-friendly interface.
This work presents a RTMS solution and corresponding service layer specifically conceived for LEAs.
A number of tests are performed in order to measure quantitatively the behavior of the solution.
Keywords: Real-Time Tracking management system, Law Enforcement Agencies, GPS, fleet
management, Geolocation, Mobile, Android.
Resumo
Nos últimos anos, muitos Sistemas de Rastreamento e Gestão em Tempo-Real (SRGT) têm
aparecido no mercado. As soluções começaram por ser desenvolvidas para simples rastreamento,
mas os vendedores cedo se aperceberam que os benefícios eram alavancados pela camada de
serviços. Numa empresa de táxis como exemplo, o simples rastreamento apenas possibilitaria a
localização da frota, mas com uma camada de serviços seria possível identificar os condutores que
têm uma condução pouco económica e não respeitam os limites legais de velocidade.
Apesar da existência de um grande número de soluções SRGT no mercado, não foi encontrada
nenhuma solução específica para Forças de Segurança Pública (FSP) em geral. As soluções de
mercado começam por falhar na base. Só estão disponíveis como serviço (na núvem), ou não
suportam o grau de segurança exigido. O alto nível de confidencialidade da informação, assim como
a delimitação da informação às infraestruturas da organização, são requisitos críticos de uma FSP.
Uma lista de requisitos foi levantada apartir do contacto informal com uma FSP portuguesa (Guarda
Nacional Republicana, GNR). Assim como a compreensão dos desafios de uma FSP no dia-a-dia.
Como princípios gerais, a GNR preza por uma solução de baixo custo, que cumpra altos padrões de
segurança, que disponibilize serviços de comunicação bidireccionais, com alta performance e
tolerância à qualidade da rede, numa interface de utilizador extremamente intuitiva.
Este trabalho apresenta um SRGT com uma camada de serviços especificamente desenhada para as
FSPs. No final é realizado um conjunto de testes, no sentido de medir quantitativamente o
comportamento da solução.
Palavras-chave: Sistemas de Rastreamento e Gestão em Tempo-Real,Forças de Segurança
Pública, Segurança, Geolocalização, Mobile, Android.
Contents
1 Introduction ......................................................................................................................................... 12
1.1 Motivation .................................................................................................................................... 12
1.2 Objectives .................................................................................................................................... 13
2 State of the Art ................................................................................................................................... 14
2.1 RTMS........................................................................................................................................... 14
2.1.1 Tracking Units ....................................................................................................................... 15
2.1.2 Tracking Server .................................................................................................................... 16
2.2 GPS ............................................................................................................................................. 17
2.2.1 Concept ................................................................................................................................ 17
2.2.2 Operation .............................................................................................................................. 18
2.2.3 GPS Security ........................................................................................................................ 19
2.3 Communication ............................................................................................................................ 20
2.4 Security ........................................................................................................................................ 22
2.5 LEAs ............................................................................................................................................ 25
2.5.1 Portuguese LEAs .................................................................................................................. 25
2.5.2 Requirements ....................................................................................................................... 26
2.5.3 United Kingdom Police Case ................................................................................................ 27
2.6 Market Solutions .......................................................................................................................... 29
2.7 Related Work ............................................................................................................................... 30
3 Solution ............................................................................................................................................... 32
3.1 Overall Solution ........................................................................................................................... 32
3.2 Central Station (Tracking Server) ................................................................................................ 32
3.2.1 Architecture .......................................................................................................................... 32
3.2.2 Database Structure ............................................................................................................... 35
3.2.3 Server Configuration ............................................................................................................. 37
3.3.1 Architecture .......................................................................................................................... 37
3.3.2 User Interface (UI) ................................................................................................................ 38
3.4 Technical Implementation ........................................................................................................... 40
3.4.1 Subscription .......................................................................................................................... 40
3.4.2 Monitoring ............................................................................................................................. 42
3.4.2.1 Real-Time status messages .......................................................................................... 42
3.4.2.2 Lost status messages .................................................................................................... 43
3.4.3 File exchange ....................................................................................................................... 45
3.4.7 Report ................................................................................................................................... 47
3.4.8 LEA data synchronization (people, vehicles and risk map) .................................................. 49
4 Evaluation ........................................................................................................................................... 51
4.1 Metrics ......................................................................................................................................... 51
4.2 Testbed ........................................................................................................................................ 52
4.3 Experimental Tests ...................................................................................................................... 53
4.4 Experimental Results ................................................................................................................... 54
4.4.1 CPU ...................................................................................................................................... 54
4.4.2 Memory ................................................................................................................................. 55
4.4.3 Message lost rate ................................................................................................................. 56
4.4.4 Maximum status delay .......................................................................................................... 56
4.4.5 Network Traffic ..................................................................................................................... 56
5 Conclusions and future work .............................................................................................................. 58
5.1 Conclusions ................................................................................................................................. 58
5.2 Future work .................................................................................................................................. 59
6 References ......................................................................................................................................... 59
A. Annexes ............................................................................................................................................ 62
A.1 Tracking Server database script ................................................................................................. 62
A.2 Risk map file (sample)................................................................................................................. 64
A.3 Performance bash script ............................................................................................................. 65
A.4 Network latency (testbed) ........................................................................................................... 68
A.5 NTP offset ................................................................................................................................... 69
A.6 Data extraction shell script .......................................................................................................... 70
A.7 No security (Security.java) .......................................................................................................... 71
A.8 Encryption only (Security.java) ................................................................................................... 72
A.9 Encryption + Mac (Security.java) ................................................................................................ 74
A.10 CPU values ............................................................................................................................... 76
A.11 Memory values .......................................................................................................................... 78
A.12 Maximum status delay values ................................................................................................... 80
A.13 Network traffic values ................................................................................................................ 82
List of Figures
Figure 1 GPS data pusher device and data puller mobile app .................................................... 16
Figure 2 GPS satellite constellation. ........................................................................................... 17
Figure 3 MPA PlayBook In-Car ................................................................................................... 28
Figure 4 High-level solution architecture. .................................................................................... 32
Figure 5 High-level architecture of tracking server. ..................................................................... 34
Figure 6 UML Database model. .................................................................................................. 36
Figure 7 High-level architecture of mobile app. ........................................................................... 38
Figure 8 Mobile App, Dashboard ................................................................................................. 39
Figure 9 Mobile App, Risk Map ................................................................................................... 39
Figure 10 Mobile App, Subscription (Login) ................................................................................ 39
Figure 11 Mobile App, Job dispatch and POI .............................................................................. 39
Figure 12 Mobile App, Menu ....................................................................................................... 40
Figure 13 Mobile App, Report...................................................................................................... 40
Figure 14 Subscription operation ................................................................................................ 41
Figure 15 Live status message format. ....................................................................................... 42
Figure 16 Lost status message recovery operation. ................................................................... 44
Figure 17 File transmission operation (from mobile app to tracking server). .............................. 45
Figure 18 File transmission operation (from tracking server to mobile app). .............................. 46
Figure 19 Report internal data representation............................................................................. 47
Figure 20 Reports transmission operation. ................................................................................. 48
Figure 21 LEA data synchronization operation. .......................................................................... 49
Figure 22 Risk map file data structure. ........................................................................................ 50
Figure 23 Testbed network topology ........................................................................................... 52
Figure 24 CPU consumption ....................................................................................................... 55
Figure 25 Memory consumption .................................................................................................. 55
Figure 26 Maximum status delay ................................................................................................ 56
Figure 27 Network Traffic ............................................................................................................ 57
List of Tables
Table 1 LEA requirements ........................................................................................................... 27
Table 2 RTMS features and descriptions. ................................................................................... 33
Table 3 Tracking server database tables. ................................................................................... 37
Table 4 Tracking server configuration parameters. ..................................................................... 37
Table 5 Testbed hardware........................................................................................................... 52
Table 6 Testbed software ............................................................................................................ 53
Acronyms
AES Advanced Encryption Standard
A-GPS Assisted GPS
API Application Programming Interface
APN Access Point Name
BTS Base Transceiver Station
CAN Controller area network
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DBMS Database Management Systems
DoS Denial of Service
DVB-T Digital Video Broadcasting - Terrestrial
EDAC Error Detection And Correction
EGNOS European Geostationary Navigation Overlay Service
GLONASS Russian Global Navigation Satellite System
GNNSS Global Navigation Satellite System
GPS Global Positioning System
GSM Global System for Mobile
HTTPS HyperText Transfer Protocol Secure
IKE Internet Key Exchange
IMEI International Mobile Equipment Identity
INS Inertial Navigation System
IP Internet Protocol
ISP Internet Service Provider
LAN Local Area Network
LEA Law Enforcement Agencies
MAC Message Authentication Code
MIC Message Integrity Code
NAT Network Address Translation
NTP Network Time Protocol
POI Points of Interest
RNSI Rede Nacional de Segurança interna
RSA Ronald Rivest, AdiShamir e Leonard Adleman, (Cryptographic Algorithm)
RTMS Real-Time Management System
SCOT Sistema de Contra Ordenações de Trânsito
SHA Secure Hash Algorithm
SIG Sistema de Informação Geográfica
SIRESP Sistema Integrado das Redes de Emergência e Segurança de Portugal
SMS Short Message Service
SOS Real-Time Management System
SSL Secure Socket Layer
TCP Transmission Control Protocol
TETRA TErrestrialTrunkedRAdio
UDP UserDatagramProtocol
UML Unified Modeling Language
UTC Universal Time Coordinated
WAAS Wide Area Augmentation System
12
1 Introduction
1.1 Motivation
Law enforcement agencies (LEAs) have primary responsibility for the maintenance of public order,
prevention and detection of crimes. LEAs also protect the life, freedom and property of citizens. They
fight on a daily basis for the indispensable order of society, but incidents are becoming increasingly
more complex, and LEAs human resources are limited. Therefore, it is strictly required to maximize
the efficiency of these organizations. This can be achieved by improving the coordination and
supporting process of the operational workforce. Good coordination and support levels
requireinformation/data availability on a real-time basis, not only directly to the field workforce but also
for the human resourcesin charge of the corresponding decision support.
Informal meetings with Portuguese LEA officers were heldunder the scope of this thesis, in order to
understand the operational and management challenges of an LEA and to elaborate the solution
requirements. The most relevant challenge is the use of radio (voice) as a single tool of
communication between agents. Despite radio network coverage and voice quality have been
improved [1] over the last 5 years, it was concluded that the single use of radio is far from reaching
the transmission requirements for real-time and complete information. From a management
perspective, there is a notable lack of efficiency to get a clear (mind) picture of the fleet location using
a single voice channel (radio). The latter is enough to justify the adoption of a Real-Time Tracking
Management System (RTMS) - a system that provides the location of the fleet according to a
geographical map on a real time basis. The inefficient process of enquiry the fleet location, employing
voice data on a vehicle by vehicle strategy, should in contrast be replaced by a system that provides
instantaneously a clear picture of the fleet location. However, the location information is not the only
issue raised. Another example where voice channel fails is the transmission of multimedia data (e.g.
image of a suspect).
The adoption of an RTMS opens the doors to new services, denominated as services layer. This layer
enables,for instance,the fleet to receive a job/mission with specific geographic coordinates and
respective navigation support to easily and time efficiently get on site.The issuing of a SOS signal,
together with associated location coordinates, requesting support from nearby agents, is also an
example of a requirement that justifies the implementation of a service layer. Under these
circumstances, a RTMS with specific service layer designed for LEAs is required. Many RTMS
solutions on the market were designed to meet big market segments needs, such as transport of
goods, public transports and segments with a big fleet workforce spread by the territory (e.g. electricity
company). These market segments are not willing to increment costs by demanding the encryption of
all data traffic or increase therate of location updates from fleet to the second, since it does not
represent a relevant added value to the business. However, these are critical requirements for LEAs.
Nevertheless, big differences compared to those solutions reside on the service layer, since crime
13
fighting is an exclusive mission of a LEA. Services such as the querying for suspects, missing
persons, stolen vehicles or the geographic report/mapping of criminal incidents, as well as
corresponding risk map for an efficient patrol, are examples of distinct needs for a specific LEA service
layer design.
These facts underlie the motivation to design a specific RTMS to LEAs - a simple, efficient, secure,
and low cost solution capable of distinctively enhance the LEAs operational activity management and
consequent citizens safety.
1.2 Objectives
The main objective of the work described in this dissertation is the design and development of a
specific RTMS for LEAs - a simple but efficient solution, that fills current (generic) LEAs requirements
and opens the doors to easily integratenew services and features focused on crime fighting.
The approach to be followed includes the following steps:
Understanding LEAs daily challenges, from the field workforce perspective to the coordination
level, and translate it into IT requirements.
Analyze the state-of-the-art of a RTMS against LEAs needs.
Identification of a suitable architecture and respective technologies that fills the most important
LEAs requirements.
Full design and implementation.
Test and evaluation.
14
2 State of the Art
2.1RTMS
A RTMS is a system for real-time monitoring of an asset motion and corresponding data (e.g.
temperature, average speed, fuel consumption, etc.). This system is fed from timely ordered sequence
of data fetched from many possible data sources (e.g. GPS receiver for geospatial information
purposes). RTMSs can have a bi-directional communication channel, enabling the transmission of
data/control commands from/to data sources. RTMSs are designed to manage multiple streams of
data originated from those sources, and display it to the end-user using a suitable representational
model (e.g. geospatial data against a geographical map).
RTMSs are used in many different scenarios, such as tracking of valuable assets (e.g. gold
shipments), workforce management (e.g. field engineers), or public transportation (e.g. real-time
information to customers such as delay) [2] . Vehicle tracking systems are also popular in consumer
vehicles as a theft prevention and retrieval device. The owner, along with the police, can simply follow
on real-time the position of the vehicle using the RTMS, and thus it becomes possible to easily locate
a stolen vehicle.When it comes to the LEAs, the major RTMSs are commonly used by fleet operators
for management functions such as fleet tracking, routing, dispatch, on-board information and security.
Over the scope of this thesis, solely RTMSs with geospatial data purposes are taken into account. The
most popular positioning system used by RTMSs is the Global Positioning System (GPS). The GPS
and other positioning systems are further discussed insection 2.2.
Despite the wide spectrum of possible usage scenarios for RTMSs, these systems are mainly
composed of three major components:
1. Tracking unit (data source): captures the location information at given time intervals, and reports
(push/pull) it to a tracking server. Location information may be coupled with other
sensors/modules data. In case of bi-directional communication, tracking unit has (additional)
responsibility in receiving data/control commands from tracking server.
2. Tracking server: The tracking server has three responsibilities: receive data from the tracking
unit, securely store it, and provide this information, on demand, to the user front-end. In case of bi-
directional communications, tracking server hasthe (additional) responsibility in transmiting
data/control commands to tracking unit.
3. RTMS Front-end: The user interface determines the procedure to access information, view asset
valuable information such as location, and elicit important details from it. In case of bi-directional
communication, the end-user might use front-end user interface to transmit data/control
commands to tracking units (through tracking server). Front-end is considered as pure user
interface design, and so it will be out of this thesis scope.
15
Tracking units, as wll as tracking server RTMS components, are described in more detail over the next
sections.
2.1.1 Tracking Units
A tracking unit is a device that determines the precise location of a vehicle, person, or other asset to
which it is attached, and it transmits the position of the asset at specific time intervals to the tracking
server. It may be transmitted using wide coverage communication technologies, such as cellular
technologies (data, Short Message Service - SMS), WiFi, radio or satellite modem embedded in the
mobile unit. This allows the asset's location to be fetched, stored and consequently displayed against
a map either in real time or for posterior tracking analysis, according to the user front-end control (via
tracking server).
A tracking unit essentially contains a module that receives the signal, and calculates the geospatial
coordinates. However, it must be connected to an additional communication module in order to enable
the unit to transmit the information to the tracking server. Nevertheless, more information originated
from other modules may be coupled to the end-data transmitted to the tracking server (e.g.
temperature, door open, etc.).
Smartphones as other daily-life gadgets (e.g. tablets) with GPS built-in, can be easily turned into a
tracking unit device, simply running a GPS tracking software. This is suitable for human related
tracking applications [3] .
Two main groups of tracking unit devices can be found on a RTMS:
1. Data Pushers (or beacons)
Data pushers are the most common type of tracking units, used for tracking an asset, a person or a
vehicle. Data pushers push information to a tracking server at specific time intervals,or optionally on
an event-triggered basis (e.g. vehicle is out of fuel).
Typical data pushers used in commercial fleet management are connected directly to the vehicle
through the Controller Area Network bus (CAN-bus), which provides not only geospatial information,
but also detailed vehicle information, such as fuel consumption or even coolant temperature.
Commercial solutions are typically configured to update rates in intervals of minutes to hours, and use
SMS to push the data to the tracking server. The use of SMS is not only explained by low mobile
operator tariffs, but also due to notable performance on low network coverage areas.
2. Data Pullers (or transponders)
The only difference between data pullers and data pushers is the logic used to report/update data.
Data pullers are always on, but they only update information when queried.
16
They are usually used in cases whether the location of the tracker only needs to be known
occasionally (e.g. placed in property that may be stolen), or the device does not have a constant
source of energy to send data on a regular basis, like freights or containers.
Data pullers are popular in Smartphone's (see Figure 1), in order to locate the device in case of being
lost/robbed (anti-theft apps). For instance, the original owner of the smartphone sends a special SMS
(query) to his device, which turns on the built-in GPS (or other location system) module and
consequently replies with an SMS (or mail) containing the actual Smartphone location.
Figure 1 (left) GPS data pusher device1, (right) data puller mobile app2
2.1.2 Tracking Server
A tracking server is a service (software and suitable computer hardware), which communicates
directly with tracking units. Typically tracking servers only have one-way data flow (unidirectional) from
the tracking unit to the server. Nevertheless, a bidirectional communication channel can be
implemented in order to transmit data/control commands from/to tracking units. For instance, the
dispatch of a job (from the tracking server) containing the customer position to the taxi driver (tracking
unit) is a good example of the bidirectional requirement. In a car theft example scenario, the tracking
server may transmit a "turn off engine" control command, which will be received by a tracking unit and
consequently executed by the module responsible to turn off the engine.
Communication is not the only role of a tracking server. The data received from tracking units has to
be parsed and stored in a database. The database can be implemented in the same tracking server
machine.Nevertheless, this approach may overload the general system performance. A higher number
of tracking assets and corresponding update ratio demands higher computing resources. For instance,
a fleet of 51 vehicles with an update ratio of 3 seconds generates a minimum of 17 messages per
second assuming no additional traffic is generated (e.g. retransmission due to network issues). A high
load of messages might require changes in terms of architecture, from the single main frame to
parallel database machines connected to the tracking server through high-speed channels. This
architecture enables the process of many database operations simultaneously, increasing the overall
system performance [5] .
1Source: trackingtheworld.com, last accessed on May 9th, 2014 2 Source: preyproject.com, last accessed on May 9th, 2014
17
Another role of the tracking server is to serve the stored data to the front-end. Depending on the front-
end solution adopted, tracking server data might be accessed directly through a connection to the
database management system, or indirectly via the tracking server back-end Application Programming
Interface (API), commonly found on web based front-end solutions.
2.2 GPS
2.2.1 Concept
The Global Positioning System (GPS) is a Global Navigation Satellite System (GNSS) that provides
location and time information 24 hours a day. Requiring an unobstructed line of sight to four or more
GPS satellites, the system provides critical capabilities to military, civil and commercial users around
the world. It is maintained by the U.S. Department of Defense and is freely accessible to anyone with
a GPS receiver [6] . GPS was originally intended for military applications, but in 1983 the government
made the system available for civilian use. US Air Force claims for 31 operational GPS satellites, plus
3-4 decommissioned satellites ("residuals") that can be reactivated if needed3.
Figure 2 GPS satellite constellation4.
The GPS satellite constellation (Navstar) is currently a mix of new and legacy satellites (see Figure 2).
Advances in technology and new demands on the existing system have now led to efforts for
modernizing the GPS system and iteratively implement a new generation of GPS satellites. The GPS
modernization program is an ongoing, multibillion-dollar effort to upgrade the GPS space and control
segments with new features to improve GPS performance. These features include notable lifespan
improvement, and new civilian and military signals, which impact the overall performance of the
system [7] .
3Source: GPS.gov, last accessed on May 9th, 2014 4Source: GPS.gov/systems/gps/space, last accessed on May 9th, 2014
18
The Russian Global Navigation Satellite System (GLONASS) has a total of 24 operational satellites on
orbit, enabling full global coverage. The planned European Union Galileo positioning system, as well
asthe Chinese Compass navigation system, are both scheduled to be fully operational by 2020 at the
earliest [8] .
2.2.2 Operation
Each GPS satellite transmits data that indicates its location and the time the message was
transmitted. All GPS satellites synchronize operations so that these repeating signals are transmitted
at the same instant. The signals, moving at the speed of light, arrive at a GPS receiver at slightly
different times because some satellites are farther away than others. The distance to the GPS
satellites can be determined by estimating the amount of time it takes for their signals to reach the
receiver. When the receiver estimates the distance to at least four GPS satellites, it can calculate its
position in three dimensions. Many GPS units show derived information such as elevation, direction,
speed and accuracy.
When turned on, the GPS units take time to obtain the satellite signals required to calculate actual
position (process called GPS lock). The time taken depends on which of the three modes GPS unit
starts on:
Cold start - Typically, when the GPS unit is turned on for the first time, it does not contain any
previous/context information. Therefore, it attempts to locate satellites and then calculates a GPS lock.
This takes the longest time because there is no à-priori known information.
Warm start - GPS unit remembers its last calculated position, the UTC Time (Universal Time
Coordinated), the almanac (information of the orbit for each satellite), but it does not remember which
satellites were previously in view. The receiver has a list of satellites to look for because it knows its
last position, and the almanac data helps to identify which satellites are visible in the sky. Warm start
takes less time than cold start.
Hot start - Fastest mode. GPS unit remembers its last calculated position - the satellites in view, the
almanac used and the UTC Time.This way,it makes an attempt to lock onto the same satellites, and to
calculate a new position based upon the previous information.
In an attempt to speed up the lock time, device manufacturers and mobile operators have introduced
the Assisted GPS technology (A-GPS), which downloads the current ephemeris (detailed information
about the location of the GPS satellites) via the wireless networks and helps triangulate the general
user’s position with the Base transceiver station (BTS) of the mobile operator [9] .
19
2.2.3 GPS Security
GPS is widely used by both government and private industry for many important applications.
Therefore, threats to GPS security are currently a concern, since the civilian GPS signals are not
secure. Three main threats are known to date.
The first threat is the unintentional degradation of the signal by increased radio usage on GPS
frequency bands. DVB-T (Digital Video Broadcasting — Terrestrial) service is one example of the
unintentional interference with GPS quality of signal. DVB-Tservices are operational in more than 40
countries, and will be in many more in the coming years [10] . The second threat is exploited by using
GPS signal jammers, known as jamming attack. GPS signal jammers are devices that intentionally
prevent GPS tracking devices from receiving the original GPS signal (essential to pick up their
position). GPS satellite signal power is extremely low at the surface of the Earth. GPS signal jammers
exploit this by emitting their own signal at the same frequency of GPS, yet with greater strength which
confuses/block other GPS signals (intentional denial of use).
The third threat is the transmission of intentional counterfeit signals, known as spoofing attack. It
involves feeding the GPS receiver with fake GPS signals so that it believes it is located somewhere in
space and time, which it is not. Despite the military GPS signals being encrypted, an episode of an US
stealth drone spoof in Iran was reported5, the spoofing technique made the craft “land on its own
where we (Iran engineers) wanted it to".
Threats take advantage of the characteristics that define GPS technology: very low signal power,
single civil frequency and the known signal structure [11] . Under these circumstances, several
countermeasures were proposed to avoid, or at least detect suspicious GPS signal activity:
1) Monitor the absolute GPS signal strength: If the absolute value of the observed signal
exceeds some preset threshold, the GPS receiver would alert the user. Unsophisticated GPS spoofing
attacks provide signal strengths many orders of magnitude larger than any possible satellite signal at
the Earth’s surface.
2) Monitor the relative GPS signal strength: The receiver software could be modified so that
the average signal strength could be recorded and compared from one moment to the next. An
extremely large change in relative signal strength would be characteristic of counterfeit signal
presence.
3) Monitor the signal strength of each received satellite signal: The relative and absolute
signal strengths are tested individually for each of the satellite signals. The counterfeit signal tends to
have equal strength for each artificial satellite. Real satellite signals, however, vary from satellite to
satellite and change over time. If the signal characteristics are too perfect, there is probably something
wrong and the user should be alerted.
5Source: theregister.co.uk/2011/12/15/us_spy_drone_gps_spoofing/, last accessed on May 9th, 2014
20
4) Monitor satellite identification codes and number of satellite signals received:
Counterfeit GPS signal transmit multiple satellites (typically 10), more than the number of real
satellites often detected by a GPS receiver in the field at a given time. Keeping track of both the
number of satellite signal received and the satellite identification codes over time may prove helpful in
determining if foul play is occurring. This is especially true for unsophisticated spoofing attacks where
the adversaries do not attempt to mimic the true satellite constellation at a given time.
5) Check the time intervals: On counterfeit GPS signal, the time between each satellite signal
reception is a constant. This is not the case with real satellites.
6) Do a time comparison: Many current GPS receivers do not have an accurate clock. By using
timing data from an accurate, continuously running clock to compare to the time derived from the GPS
signal, we can check on the veracity of the received GPS signal.
7) Perform a sanity check: An accelerometer and compass can be used to independently
monitor the physical trajectory of the receiver. A discrepancy between the accelerometer data and the
GPS receiver would raise a red flag and alert the user.
The countermeasures proposed require fine level of information from the GPS receiver, such as signal
strength from each satellite and timely ordered storage, in order to perform comparison over time.
These requirements might not be found in many commercial GPS receivers on the market, which turn
to be impossible to implement.
2.3 Communication
Communication between tracking units and tracking server is a critical aspect on an RTMS. The lost or
even delay of data over the network might turn impossible to use an RTMS. For instance, the use of
LEA RTMS on a criminal car chase context requires an efficient communication system in order to
provide details of the fleet location (along with other information) at the closest to real time. Otherwise,
LEA criminal intersection plan implementation might not succeed due to the latency/disparity of the
fleet location on the RTMS (LEA decision point) and real location on the field.
Typically, RTMSs use existing mobile operators network to communicate. Mobile operators provide
nationwide network coverage (ideally), along with interconnection with other mobile operators from
other countries, making it a global network. Additionally, the large-scale manufacturing of mobile
equipment turned it cheap, network specifications such as speed and delay are satisfactory, and
corresponding rates are relatively cheap compared to solutions such as satellite.
Within mobile operator solutions, communication can be performed by SMS and data services. SMS
might not be desirable for RTMS applications that require a high update rate of data from the tracking
unit. Firstly, the use of SMS implies a new hardware to the tracking server, Global System for Mobile
(GSM) modems. Turning the tracking server solution more complex, since the high update rate by
SMS from many tracking units easily push the modem into bottleneck. Nevertheless, SMS feature
21
could be implemented recurring to the integration of a mobile operator professional SMS-Gateway
service to solve this bottleneck issue. Other disadvantages of SMS usage regards the message size
limit of 160 bytes after headers, the delay, and the fact that most mobile operators service plans
charge by number of SMS instead of number of bytes.
Assuming a data service is adopted, the choice of the transport protocol (e.g. TCP, Transmission
Control Protocol) has a notable impact on the overall communication performance. The use of
connection oriented protocols show important disadvantages for real-time applications over mobile
operators networks, especially on intermittent network coverage scenarios. For instance, the usage of
TCP under these conditions triggers frequent TCP sockets timeout events, leading to several attempts
to re-establish a new connection with tracking server. The process of TCP connection establishment is
known as the three-way handshake, and it is time wasted comparing to the connection less oriented
protocols, like the User Datagram Protocol (UDP).
Another issue concerns the delay during handover between mobile operator Cells or Internet Protocol
(IP) address roaming. Congestion control mechanisms interpret these delays as a congestion loss.
And therefore automatically reduce throughput considerably, reaching zero in the worst-case scenario.
This drastic throughput reduction, along with the consequent (time consuming) throughput recovery
process, represents a notable degradation of performance. These scenarios do not have the same
impact on connectionless protocols such as UDP, where network intermittence or excessive delays
may generate temporary loss of packets, but easily recovered by re-transmission algorithms coded on
the application level. This way, time consuming tasks like the throughput recovery and connection re-
establishment are avoided [12] .Another disadvantage of connection oriented transport protocols is the
segment header overhead. For instance, TCP segment has a minimum of 20 bytes of header in every
segment, whereas UDP only has 8 bytes. TCP needs more header data (e.g. Sequence number) in
order to guarantee certain features of the protocol (e.g. reliability), while UDP, which gives no
guarantees, only contains the necessary header data to make the packet reach the destination. A
bigger overhead size means better probability of loss of packet and higher variance in end-to-end
delay [13] .
Mobile operators connections identify clients in a given network by an Access Point Name (APN). The
common APN defines the network with internet access. However internet access is typically achieved
through Network Address Translation (NAT) gateways, which dynamically allocate private IP
addresses to the mobile terminals. NAT prevents inbound connections, since there are no externally
visible IP addresses. Thus, the establishment of a connection must be always initiated by the device
beyond NAT (e.g. tracking unit). In addition, there are many different NAT implementations with
different application-level knowledge and different binding time-outs for ports and sessions (IP/port
mapping) [14] . In fact, a simple UDP test between a Portuguese mobile operator (TMN) and an
independent Internet service provider (ISP, Cabovisão), have shown that (over a slight minority of
NATs) UDP datagrams arrived ISP node, with a local IP address as source. Therefore, unless working
in exceptional situations, RTMSs developers must always assume the worst scenarios for tracking
units in terms of mobile operator network topology, for instance being persistently jumping between
22
different NAT implementations with outrageous delays due NAT resource allocations, or unexpected
changes of IP due to lack of normalization, such as intermittent roaming support. This latter property
requires the tracking server tobe able to identify the tracking units based on data payload rather than
the IP protocol header. For instance, the International Mobile Equipment Identity (IMEI) of tracking unit
might be included in data payload for this purpose, since IMEI is an unique identifier of the mobile
communication hardware module [15] .
2.4 Security
In order to RTMSs work properly, an efficient communication between tracking units and tracking
server must be accomplished. However, LEA RTMS communication process in the single sense as
clear data exchange is not enough. Additional security measures should be performed over the clear
communication channel, in order to deny any chance of unintended users to fetch information or to
have any influence in the proper RTMS behavior. Hence, three main security functions should be
implemented - Confidentiality, authentication and integrity. Confidentiality ensures the sender that the
message can only be read by an intended receiver. This function implies the encryption of the
message in a pre-arranged way between sender and receiver (tracking server and tracking units).
Data exchange between tracking units and tracking server, may contain valuable information to
criminals’ eyes such as the real-time location of the LEA work force. This is a precious piece of
information for any criminal activity over the field (e.g. Bank robbery escape). Assuming data
exchange is done over an insecure channel (e.g. mobile operators network, a third party network not
trusted by the LEA), encryption of data plays an important role within LEAs proper work. Encryption
will assure that no sensitive information is gathered in case of interception.
The encryption process is defined through the specification of an algorithm and key(s). Where
algorithm defines the generic procedure of data modeling and the key(s) is the corresponding
parameter responsible to generate distinct behaviors. The algorithm and the key shall be chosen
accordingly to the value of the information to be protected and the expected threats. The strength of
an encryption algorithm is derived from the mathematical properties of the algorithm. For example,
RSA algorithm derives its strength from the difficulty of factoring large numbers. If a method that
radically speeds up the factoring of large numbers is discovered, the RSA algorithm can be broken
[16] . If the algorithm is publicly available, then the strength of the encryption is only dependent on
keeping the key secret. An attacker can conduct a brute force attack by trying all possible key
combinations. The challenge is then to decide on a suitable key length, such that a brute force attack
will not be successful in a timeframe shorter than the lifespan of the message that it is protecting.
However, attackers may limit the space of the brute force as much as they can. For instance,
attackers may try to gather information such as the default configuration values (e.g. length of the key)
of a specific RTMS solution or the computational limitation for random numbers generation, and
narrow brute-force attack accordingly.
23
Despite innumerous possible attacks against encryption, the most common are:
1) Ciphertext-only: This attack tries to find the original message (or algorithm and corresponding
key), taking only as input the encrypted message.
2) Known-plaintext: Same as previous, but besides the encrypted message, the original message
(or only parts of it) are also known.
3) Chosen-plaintext: The attacker is able to write the original message, and consequently tries to
find the original message (or algorithm and corresponding key) based on the posterior encrypted
message.
4) Adaptive-chosen-plaintext: It is derived from the previous attack, but the attacker selects parts
of the original message based on encrypted messages previously retrieved.
An important aspect of encryption solution is the key management. The strongest algorithms and the
longest keys are useless, if the keys are not generated, distributed and destroyed in a secure manner.
Stealing keys is an attractive option for the attacker because he does not need to expend resources to
break the encryption algorithm, when he can break the key generation algorithm.
Encryption operations are computationally intensive. Therefore, the power consumption of encryption
operations must be taken into account when deciding the best algorithm and the key length for an LEA
RTMS, since tracking units may do not have an "infinite" energy source. In addition, many encryption
algorithms encrypt data in fixed block sizes. If the data is larger than the block size the last part of the
message is usually padded to the full block size, resulting in a significant increase of the message
length. Specially, if applied on short messages, such as those transmitted by tracking units, containing
not much more than the corresponding device location. The increase of the message
length,representadditional transmission data, which in turn increases the power consumption on
tracking units as well.Despite energy consumption not being an issue of tracking server, the speed of
encryption/decryption is. Algorithms that have more operations and longer keys, take more time
processing. Thus, tracking server may receive an enough amount of message per second (depending
on number of tracking units assigned), which is not capable to decrypt and consequently encrypt
corresponding reply message within a valid timeframe. Replies out of valid timeframe may trigger
tracking units to resend the same message, turning tracking server as a bottleneck.
Encryption can be grouped into two categories, symmetric and asymmetric. Symmetric encryption
(e.g. Advanced Encryption Standard - AES) is the process where a single key (secret key) is used for
both encryption and decryption. Only the owners of the secret key can decrypt the message, if more
than one entity needs access to encrypt/decrypt the message, the secret key must be shared among
them. Asymmetric encryption (e.g. RSA) uses two related keys, one for encryption (private key) and
the other for decryption (public key). The private key is kept secret, while public key is announced to
the public in order to decrypt messages encrypted by the corresponding private key. Symmetric
encryption is much faster and energy efficient than asymmetric [17] . These aspects, makes
symmetric encryption more desired for RTMS, especially in scenarios with high rate of message
24
updates. In addition, tracking units might do not have enough computational resources to perform
asymmetric encryptions operations in valid time frame.
Symmetric encryption has a disadvantage, regarding the need to pre-share the keys among the
senders and receivers, increasing complexity along with the number of users. Key distribution must be
exchanged securely via some trusted communications channel or through some key exchange
mechanisms [18] . Nevertheless, key distribution should not be an issue for an LEA, since users have
direct access to a trusted channel through daily physical presence on LEA facilities. Secure key
exchange mechanisms, such as Internet Key Exchange (IKE) and Secure Socket Layer (SSL), have
been developed to facilitate symmetric or asymmetric key exchanges across insecure networks.
However, these protocols assume relatively high band width, real-time connectivity between the
sender and receiver. For example, the set up of an SSL session requires an exchange of at least four
messages before the secure session is established. The adoption of SSL over RTMS may not be
desirable due to network issues, analogous reasons as TCP handshake (discussed in previous
chapter). Additionally, SSL solution can easily generate heavy peaks of computational resources on
tracking server side, due to (unexpected) SSL session setup initiation by many tracking units at the
same time (e.g. tracking server reboot or intermittent network coverage scenarios).
The integrity of the message is also important. This ensures that the message was not modified in an
unauthorized or undetected manner during the communication. This security function can be
performed through the addition of a message integrity code (MIC) to the tail of the original message
and posterior encryption of the whole. As the receiver decrypts the message, he compares the MIC
received against the local processed MIC. If there is a mismatch, the message integrity was violated.
MIC is a piece of information derived only from the original message. It can be an error detection and
correction code (EDAC) like a cyclic redundancy check (CRC), or a cryptographic hash function output
(e.g. Secure Hash Algorithm, SHA-1). Nevertheless, both have different strengths. EDAC are suited to
detect accidental changes to data and are commonly used in networks and storage devices. These
algorithms were not intended to protect against intentionally changes, but rather to catch accidents like
network errors and disk write errors. The emphasis of an EDACis more on speed than on security[19] .
On the other hand, hash functions used on cryptographic algorithms (message digests) are one-way-
hash. One-way-hash have the property (per design) that it is hard to find the input that produced a
specific hash value. It is hard to make two different inputs that give the same one-way-hash (low
collision property). The emphasis of message digest algorithms is on security over speed. However,
the output size of many message digest functions may be bigger than tracking units original
messages, leading to waste of energy (data transmission and computational resources). A practical
measure would be the truncation of the output of the hash function to the desirable value. However,
this solution can turn collision resistance much lower than expected (depending on the algorithm),
since the majority of the message digest functions were designed to a specific output size.
Nevertheless, the use of the MIC does not guarantee the receiver who was the originator of the
message. Authenticity security function is performed through message authentication code (MAC). In
25
fact, MAC not only implements authenticity but also message integrity as well. Besides the original
message, MAC algorithm uses also the secret key as input (opposing to MIC). The output is a code
(or tag) which only holders of the key can verify the authenticity. The inclusion of the MAC on the tail
of the original message, which is respectively encrypted, is a secure way to assure confidentiality,
authenticity and integrity of the communication.
The implementation of security functions on a RTMS, do not guarantee total security. However, it
makes the attack more difficult to succeed. Additional measures should be addressed during the
design of a secure RTMS, in order to avoid the following methods used by the attackers:
1) Man-in-middle Attack: The attacker might have access to the Mobile operator network, or any
part of the network between the tracking server and tracking units. This positioning enables the
attacker to perform active eavesdropping, intercept all messages and even inject new ones. Under
these circumstances, it would be possible to arrange an attack that eludes tracking units to
communicate with attacker tracking server, instead of the authentic LEA tracking server.
On the other hand, the attacker may be interested to passively capture all the data, in order to
perform encryption attacks.
2) Replay Attack: The attacker can misuse the previously exchanged messages between the
tracking server and tracking units. For instance, the constant replay of a message sent previously
by tracking unit may elude the tracking server to perceive that the vehicle is stopped.
3) Denial of Service (DoS) Attack: Attacks that have simply the mission to put the LAE RTMS
completely or partially inaccessible. For instance, an attacker can send a bigger number of false
requests than the tracking server can manage, leading the RTMS to the state of unusable.
2.5 LEAs
2.5.1 Portuguese LEAs
LEAs jurisdiction typically follow the national administrative territory structure, and the same happens
in Portugal. The Portuguese territory is divided into eighteen districts (islands not included), each one
being controlled by the respective agency department and consecutively divided into sub-departments
that control one or more agencies. An agency can have one or more vehicles, and each one reports
directly to his respective agency Central Station. Minor issues are managed within the local station
bounds. However issues can turn out to be more complex and escalate through the local station, sub-
department, department or even General Command (highest point of decision support)6. Over this
context, an additional coordination difficulty is implied to those who are in charge with their respective
workforce on field. This challenging coordination gets complicated due to the actual inefficiency of
communication, or lack of extra information channels. Currently, the hierarchical superior (someone
who is in charge of several sub-departments) coordinates his workforce, uniquely by radio (voice).
6Source: www.GNR.pt, last accessed on May 9th, 2014
26
This raises several issues, such as the inability to provide a clear picture of an accident scenario, or
the difficulties that decision makers have in building a mental geospatial image of a wide distributed
workforce on field based on many radio conversations in parallel of ongoing processes. Assuming
error tends to propagate over the chain, information that reaches the decision support level may loose
value.
Sistema de Informação Geográfica7(SIG), is a system currently deployed that provides the geo-spatial
position of each radio and respective status. Despite the lack of services, it is currently only available
to the department (and upper) levels. Hence, it is not used by the lower department levels, which are
the ones that solve the majority (day-by-day) issues.
The actual radio infrastructures underlie a network called Sistema Integrado das Redes de
Emergência e Segurança de Portugal (SIRESP), which supports a Terrestrial Trunked Radio (TETRA)
for all Portuguese LEAs. TETRA is defined as a good long-range communication system with strong
security standards. However, communications services provided are barely constrained to voice. The
actual version of standard supports a maximum of 115.2 kbit/s in 25kHz (Portugal) or up to 691.2
kbit/s in an expanded 150 kHz channel [1] . Under these circumstances, it is possible to argue that
LEAs cannot rely on Tetra systems for the majority of services that imply the exchange of important
multimedia data (e.g. image of a suspect).
Besides radio infrastructures, Portuguese LEAs are served by a national data communication
infrastructure called Rede Nacional de Segurança Interna (RNSI). RNSI is the LEAs private cloud8. It
provides data network connection between agencies and the respective services. Examples of such
services are the internet, email, VoIP, along with specific applications required day by day for the
proper work of the organization, like traffic infraction system (called Sistema de Contra Ordenações de
Trânsito- SCOT). Applications like RTMS should benefit from RNSI infra-structures as well, more
specifically in terms of security, high availability along with possible interconnection with other
applications (e.g. SCOT).
2.5.2 Requirements
Within the scope of this dissertation, informal meetings with GNR (Portuguese LEA) officers were held
in order to raise and guide general LEAs requirements and consequently translate them into IT
requirements.
The understanding of requirements implies the proper understanding of the following concepts:
Vehicle - Represents the LEA structure used to transport LEA field workforce. They are equipped with
a device (hardware and software) that enables the exchange of relevant information (e.g. Location).
Vehicles are not only able to transmit, but also to receive data as well. Vehicles exchange information
with Central Stations. 7Source:GNR.pt/default.asp?do=tnov0r6r_vz24r05n/016vpvn5/016vpvn5_qr5p4vpn1&fonte=noticias&id=728&Me
s=3, last accessed on May 9th, 2014 8Source: www.RNSI.mai.gov.pt, last accessed on May 9th, 2014
27
Table 1 lists all the requirements.
#No Description
1 Global solution does not replace actual LEA radio solution, but work as LEA enhancement tool.
2 Global solution shall follow low cost approach, not only in terms of hardware but software licensing as well.
3 Vehicles shall provide to Central Station their Location, Name and corresponding motion Status (e.g. on move, stopped).
4 Central Station shall be able to monitor all the assigned vehicles information with minor delay as possible (Real-time data approach).
5 Data exchange shall be tolerant to network failures.
6 Data traffic exchange shall be minimized as much as possible.
7 Data exchange shall be: - Confidential: Data must be encrypted in a way that only the credentials owners can
retrieve the information. - Authenticated: Any valid data receiver must be able to uniquely identify the sender. - Incorruptible: Alteration of original data between sender and receiver shall be
detectable and consequently discarded.
8 Data storage shall be delimited to LEA own infra-structures.
9 Vehicles shall have an SOS feature, which alarms the Central station.
10 Shall be possible to send a file to one or more vehicles from the Central Station (downstream).
11 Vehicles shall have a reporting feature, which will enable the report of 'Event' (Location, Time, Type), 'Person' (ID, Drive License, Name, Free Text) and 'Vehicle' (License Plate, Free Text) to the Central Station.
12 Shall be possible to take photo from vehicle and send corresponding file to the Central-Station (upstream).
13 Shall be possible to dispatch a job (respective coordinates) from Central Station to one or more vehicles at same time.
14 Shall be possible to send POI (Points of Interest) from Central Station to one or more vehicles at same time
15 Vehicle and Central Station shall be synced with a list of 'Persons' (suspects and lost).
16 Vehicle and Central Station shall be synced with a list of 'Vehicles' (suspects and robbed).
17 Shall be possible to design a risk map layer from Central Station. This layer shall vary along the time for each day of week.
18 Vehicles shall be able to sync and visualize risk map layer provided from the Central Station.
19 Central Station shall be able to have an history feature, capable of represent previous locations of the fleet and corresponding events on map.
Table 1 LEA requirements
Central Station - Physically present in LEA facilities as a room, conceived for being the central point
of monitoring/coordination of one or more vehicles assigned to the Central Station. Central Station
responsibilities can be temporary overtaken by another Central Station with higher hierarchy.
2.5.3 United Kingdom Police Case
The United Kingdom Police currently has an ongoing plan to maximize efficiency through the adoption
of mobile technology, in order toincrease the time officers spend on the streets in contact with local
communities. The traditional model pushed officers to waste time on the round-trips to the stations,
since there was no way to perform their tasks locally (on the field).This applies to tasks such as formal
submission of an incident or a simple access to local and national database system. Under these
28
circumstances, officers needed a secure mobile access to their station systems9.The solution adopted
by UK Police is constituted by a Tablet (Playbook by RIM) along with several mobile apps that
provides access to Police station back-end services. These Tablets only have WiFi and Bluetooth
connectivity, the network access is provided by the individual Smartphone (BlackBerry by RIM)
bridged with the respective Tablet. All the data security transmission is secured over proprietary
technologies (e.g. network protocols) by RIM. There are a total of 56 police forces in the UK, 44 are
already using this mobile solution. The tablet software is developed by a company called 'Mobile
Innovations' (Canada).
Additionally, Sussex Police Department has a trial running to check the viability of the Tablet as an in-
car option. If successful, they will install the in-car Tablet solution in about 400 of their vehicles in
place of the older ones10 (Magellan, by JP Sá Couto Portugal11). The in-car solution is called MPA
PlayBook In-Car, and is a bundle of different hardware accessories, as described in Figure 3.
Figure 3 MPA PlayBook In-Car
United Kingdom Police vehicles will be able to securely access and search multiple police data bases,
relay information about their position and status, securely email, SMS and send alerts, scan drivers
licenses and print traffic tickets. The system seems to be quiet promising, since it was fully designed
to interoperate with UK Police backend systems. As a commercial solution, all the efforts are reflected
over the final price. The MPA PlayBook In-Car bundle price is 2500€ (BlackBerry not included)12. The
price of the backend systems, services and respective commercial support that continuously operate
with UK Police legacy systems are not publicly available. Nevertheless, it is known that Metropolitan
9 Source: www.Blackberry.co.uk/casestudies (UK Police Customer Success) last accessed on May 27th, 2013 10Source: http://tbkconsultblog.com/2013/02/08/magellan-computers-installed-in-uk-police-cars/ last accessed on
May 27th, 2013 11Source: http://crackberry.com/uk-police-get-blackberry-playbook last accessed on May 27th, 2013 12 Source: http://www.mobinnoco.com/accessories/mpa-in-vehicle-choice/ last accessed on May 27th, 2013
29
UK Police are currently spending 385 Million Euros a year on technology13, which is completely out of
budget in the majority of the worldwide countries. In addition, the high price for well-conceived
solutions does not solve the biggest challenge of these systems: the network access. The Mobile
Operator network coverage and availability in many cases can easily turn the big investment into
something not usable.
2.6 Market Solutions
From the wide GPS commercial solutions on the market, GPSGate14 presents the most desirable
RTMS solution to LEAs. In fact, they claim to have many LEA costumers.
GPSGate Server is an advanced GPS tracking platform available both as a software download and a
service. They offer the possibility to host the GPS server (as web service) in their own IT-
infrastructures. However, it is not a suitable solution to LEAs due to security policies (data shall not go
out of LEA management domain). Nevertheless, they offer the solution to download and install the
GPS server locally on LEAs infrastructures. This server software is a bundle of a gateway solution
(software which handles all the data from tracking units), a database to store data (MySQL) and a web
server, which provides the User Interface (Apache + PHP+ Java scripts). Unfortunately, local server
solution is only available to Microsoft Windows OSs.
GPSGate provides many features within their initial solution, but it is possible to additionally extend
features by developing plugins based on the .NET API available.
From the fleet user perspective, GPSGate only provides a Windows OS software client solution.
Nevertheless, they also provide an open communication protocol to control/transmit data for the ones
who dare to customize their GPS units in order to take all features from GPSGate solution (e.g. mobile
app). The GPS client is prepared to support open and vendor USB protocols (e.g. Garmin binary) and
Bluetooth connectivity in order to capture the data into the GPSGate Client Windows Application,
which in turn can be transmitted through TCP/IP, UDP or HTTP for the respective tracking server. The
HTTP feature is valuable for LAEs since it allows the traffic to pass through firewalls/Web Proxies
without violating ongoing security policies, turning the solution easy to deploy. However, the use of
HTTP raise performance issues compared to the use of UDP or TCP raw sockets.
On the whole, GPSGate provides many features required for a typical RTMS, with the added value to
extend it through Plugins. However, due to the bigger dependency of Microsoft Windows OS, the
solution is barely closed for organizations who follow different paths, such as open-source (e.g. Linux).
Due to the limitation and complexity of the API, the development of plugins to fulfill specific LEAs
features can turn to be not only too challenging but timely expensive. Another issue from this solution
is the lack of data file sharing between tracking units and server. Additionally, the GPSGate does not
support security over the transmission of data between tracking units to server.
13 Source: http://www.london.gov.uk/mayor-assembly/london-assembly/investigations/met-police-technology last
accessed on May 27th, 2013 14 Source: www.gpsGate.com, last accessed on May 1st, 2013
30
2.7 Related Work
Muruganandham and P. Mukesh [20] have proposed a Real Time Web based Vehicle Tracking using
GPS.Where tracking units report over GSM (SMS/GPRS) the vehicle information to a tracking server
which is stored in a database. A Web Interface was developed to display the real-time location of the
vehicles. The proposed work shares similarities with this thesis regarding vehicle tracking.
Nevertheless, there are differences, specially in the tracking unit. They followed the classic (most
used) approach of design/build a customized unit, in contrast to the approach of using a Mobile market
device (Tablet or Smartphone) with all builtin. The design of a customized unit gives more space for a
better performance and efficient system. However it has some disadvantages such as the effort/time
cost to prototype an hardware solution, and the final price. The adoption of a well known market
device spares the time of hardware prototyping, providing a much more stable, lighter, portable and
thinner end device which was (presumably) designed and massively tested by many specialized
experts with a much more comfortable budget and knowhow supported by big manufactures (e.g.
Samsung). However some requirements raised by the work,such as the information of the vehicle
ignition (on/off) and door status (open/closed), complicates the Mobile device solution. Nevertheless, it
could be solved with a simple CAN-BUS to Bluetooth device15, assuming CAN-BUS is deployed in the
vehicle. The use of a mobile device, opens a new world to future applications that may run in
concurrency with the tracking Mobile App, and take advantage to all the hardware built in features
such as the camera, or software abstraction provided by the OS like face recognition. Another aspect
to take into account, is the long-term support of the system. In any specific point of time (and for
unexpected reasons) the hardware solution might get damaged and respective repair can turn to be
expensive or even impossible. The repairof mobile device can be easily done by just replacing it with a
new and compatible device. Most of the programming code of a customized solution is hard written to
specific components (eg. GSM Module) and these ones could no longer be found on the market,
forcing a new software development cycle, or even a redesign of the hardware solution.
K. Hasan et al. [21] have proposed a cost effective method of object tracking using GPS and GPRS
technology. The user can view the present location of the object as well as the past history of its
movement using Google Map and Internet. They take advantage of the IMEI number uniqueness to be
used on the authentication of the device. Hence, the Tracking server drops all the messages that do
not have a valid IMEI stored in the database. This is a simple security approach that resides in the
secrecy of the IMEI, which can be easily exploited by man in the middle attacks and spoofing. Similar
logic of use of the IMEI is applied on this thesis solution.
Another important aspect solution of the proposed work is the use of HTTP POST method to transmit
data between the tracking units and server. In that way, the implementation (e.g. validation, data
manipulation, etc.) of the tracking server is developed in PHP, which is not the best solution in terms
of performance. This choice represents a high cost of CPU and memory per vehicle, therefore is not
"Cost Effective" as the work title suggests. The development language selected for the solution of the
15 Source: http://www.case-gmbh.de/DS4113D.pdf last accessed on May 30th, 2013
31
thesis is Java. Despite Java being considered as low performance, it is still better compared with PHP
(interpreted language) and much easier to migrate to native code if required in comparison to a web
scripting language such as PHP. Nevertheless, the adoption of HTTP protocol along with PHP,
provides development flexibility to upgrade the solution to a secured data transmission channel,
HTTPS. However, HTTP or HTTPS is (once again) not "Cost Effective" desirable protocol, since it fails
on overhead against TCP raw socket (the underlying protocol). The same overhead issue applies to
TCP against UDP, and that is the reason UDP is mainly used on the thesis proposed solution. Another
argument from the authors is "most of the GPRS/GPS based tracking devices available in the market
use TCP or UDP protocol to connect with the server and send data. A dedicated server with a static IP
is required. This is more expensive compared to that of shared web hosting". The latter, explicitly
states that the cost-effectiveness of the authors’ work is reached not by following the cost-effective
GPS tracking best procedures, but by simply adopting a cost-effective business model for web - the
shared web hosting. Applying similar logic, shared tracking service business model shall be definitively
more cost-efficient than the tricky shared web hosting proposed. Shared tracking services follow the
growth of cloud computing usage and optimized elasticity of resources. GPSgate16 and GPS-Trace17
are examples of that.
16 Source: www.GPSgate.com last accessed on May 1st, 2013 17 Source: www.GPS-Trace.com last accessed on May 29st, 2013
32
3 Solution
3.1 Overall Solution
The overall solution is composed by a mobile app running on a tablet (in each vehicle), and a tracking
server along with a database and web server. The vehicles share a secret key with the tracking
server, and exchange data securely through mobile operator network and (possibly) third party
networks. The Central station(s) manage the fleet through a web-based solution secured by an
HyperText Transfer Protocol Secure (HTTPS) connection. This Web application (RTMS front-end) is
not included within the thesis (hence out of the scope), only referred for better solution understanding.
The following Figure 4 depicts the overall end-to-end solution.
Figure 4High-level solution architecture.
The solution proposed on this thesis is characterized by a set of features that enhance the LEAs daily
operational requirements. These features along with corresponding description are shown on the
following table.
3.2 Central Station (Tracking Server)
3.2.1 Architecture
The tracking server is coded in the Java programming language (JDK 718). The main argument behind
this choice is the high portability of the code to many other Operating Systems (OS). An important
aspect, since existing technological infrastructures may widely differ between LEAs. Therefore, this
approach will drastically mitigate the risk of incompatibility of the OS during solution deployment. The
server architecture solution is designed according with Figure 5.
18
Source: docs.oracle.com/javase/7/, last accessed on May 9th, 2014
33
Feature Description
Real-Time Monitoring
Central Station can monitor fleet status (e.g. location) in real time (up to the second).
Alarm Vehicles can trigger an SOS alarm in Central Station. This feature allows an immediate request for Central Station support containing vehicle location. Inefficient process like location description through voice is surpassed. (e.g. Request support within a zone without relevant descriptive references)
Points of Interest (POI)
Central Station can send multiple POI to Vehicles. This feature allows the fast transmission of multiple strategic locationpointsto vehicles. It also allows easy visualization of these POI onthe mobile app map. (e.g. Location points of the last appearances of a missing person).
Job Dispatcher
Central Station can dispatch a job containing specific location to vehicles. This feature allows the fast transmission of a mission to vehicles. It also allows easy visualization of the mission spot against the mobile App map. (e.g. Suspicions of domestic abuse within a rural zone).
File exchange File transmission between vehicles and Central-Station. This feature allows the exchange of files between vehicles and Central Station (and vice-versa). Central Station can easily broadcast dense information through multiple vehicles. (e.g. Unexpected escalation, which requires a fast broadcast of the contingency plan to all vehicles).
Report Vehicles can report events along with corresponding location. This feature will enable the population of database with important data, from criminal investigation analysis perspective to crime prevention (risk map). (e.g.Georeferenced report of domestic abuse can allow LEAs to predict where, and at what time, the next domestic abuse might happen).
Photo Vehicles can take photo directly to Central Station. This feature will allow Central Station to make better decisions based on more accurate information (picture). (e.g.the obstruction of a road due to natural disaster requires a high level of detail to make a decision for a partial roadblock or other transit deviation plan).
LEA data Vehicle terminal have local access to synchronized list of Person (suspects and lost) and Vehicles (suspects and robbed)
This feature will reduce the Central Station workload, and at the same time enables the access to the information within the vehicle, on a faster and more accurate way.
Risk Map Vehicles can easily see the representation of the risk over the map (layer). The layer is dynamic, it changes accordingly to the date and time of the day.
This feature will enable vehicles to perform an optimized patrol (better coverage of critical zones at the right time and weekday).
History All the information is stored on database, in order for LEA to be capable of representing previous fleet locations and corresponding events on the map.
Security All data exchanged is: o Confidential: Encrypted in a way that only the credentials owners can
retrieve the information. o Authenticated: Any valid data receiver is able to uniquely identify the
sender. o Incorruptible: Violation of original data between Central Station and
vehicles isdetectable and consequently discarded.
Network Tolerant to fault - Retransmission of data lost during network fault.
Performance - Low data traffic(e.g. smallersize of messages).
Table 2RTMS features and descriptions.
34
Figure 5 High-level architecture of tracking server.
DB Manager: This module is responsible for all operations in the server database. In order to improve
performance, functionalities that are likely to deal with large data sets make use of prepared
statements along with batch operations (e.g. Insertion of 100 rows per batch). The module uses the
MySQL database management systems (DBMS) driver, which limits the database compatibility to any
MySQL driver system.
File Manager: This module is responsible for all the local file system operations. In addition, it
features simple versioning of files, by concatenating a number to the header of the filename (e.g.
"23_RiskMap.geo"). This provides a simple manner to detect if the vehicle app has the latest version
of the file from Central Station during a file synchronization process.
Application Manager: This is the first module that the server loads. And the first task is loading the
DB Manager module, in order to fetch the server configuration and users information (e.g. credentials)
from database (see Figure 6, tables "Server_configuration" and "terminal_users") into memory. The
decision to load user information to memory is justified by the high rate of access for this information
(e.g. anytime a message arrives) against the performance of memory versus hard disk (assuming
database is on hard disk). Nevertheless, user information kept on memory needs to be updated
anytime a change on users accounts occurs (e.g. new users added). This update is not done
periodically by the server, but shall be asynchronously triggered by the front-end solution (tool
responsible to manage user accounts). Or in the worst case, rebooting the server. Once all data
required by the server is loaded, Application Manager loads the Operation Handler module.
Nevertheless, Application Manager remains on active cycle collecting and storing periodically all
RTMS relevant data from memory to database. The data storage is prioritized by the period of
verification and corresponding thread priority. For instance, real-time status messages needs to be
update on database with minimum delay. Therefore, it is verified for new status messages every
250ms by a maximum priority thread. In comparison to the update of the status history, that one is
checked every second and updated by the minimum priority thread.
Application Manager
Server Configuration
Resource management
Data prioritization
Operation Handler
Subscription
Receive File
Send File
Receive Offline Messages
Receive Reports
Sync People Data
Sync Vehicles Data
Sync Risk Map Data
File Manager
Write Local File
Read Local File
Message Handler
Receive status message updates
Send Control messages
Security
Encryption
Decryption
Message Validation
DB Manager
DB Connections
Write Operations
Read Operations
35
Another important task of Application manager, is the management of allocated resources that each
vehicle app demands from server after a successfully subscription operation (see 3.4.1). Resources
allocated on server that are not used for more than 24 hours, are released.
Operation Handler: This module is responsible to perform operations requested by the vehicles
applications. The module runs a main TCP socket open on the configured TCP operation port (Server
Configuration,Table 4) which is accordingly forked to the corresponding operation requested by the
app.
Security: This module is responsible for the encryption, decryption and validation of data all over the
solution. Due to the high rate of usage (e.g. anytime a message arrives), and possible low
computational resources on vehicle mobile devices, it was decided that only symmetric cryptographic
operations are performed. The security module was coded in a manner that could be used as much
flexible as possible. It uses the open-source "Bouncy Castle" lightweight cryptography library, which
provides an easy abstraction for many cryptographic algorithms. This library is included on the official
android OS (on4.2.2 version / Jelly bean). And this aspect mainly justifies itsadoption, since the
vehicle terminals are android mobile devices and transparent compatibility is highly desirable. In fact,
the server java class (security.java) that represents this module is equal to the vehicle app. Therefore,
a change on the level of security (e.g. encryption algorithm, message padding andMAC) can be
transparently done only within a file (on both sides, server and app). This approach is justified by the
assumption that the deployer of this solution is responsible to assess the risk exposure level, and
choose the best-fit security standards accordingly.
Message handler: This module is responsible to receive live status messages from vehicles apps,
and send control messages to corresponding vehicle app (e.g. Dispatch a job). The communication is
preferably done through UDP, but TCP is also supported. Both work in concurrency on the server and
the logic of decision is implemented on the client side (mobile app). Further details are discussed on
section 3.4.2.
3.2.2 Database Structure
The Database was designed to be simple and easily understood. The Unified Modeling Language
(UML) diagram of the database is depicted on following:
36
Figure 6 UML Database model.
No security measures are applied by the tracking server solution to the database content. The
database encryption is currently a feature supported natively by the most popular DBMSs.
Nevertheless, It is extremely advisable that shared secrets shall be generated by a machine during
terminal user creation procedure or in any other scenario that shared secret shall be reset (e.g. shared
secret expiration date). But these points shall be addressed during the design of the front-end solution
(out of the thesis scope).
In order to provide a deep level of the database and data representation, a Structured Query
Language (SQL) script for database creation can be found in annexA.1. Nevertheless, Table 3
describes briefly each of the database tables.
Terminal_Users
PK UserID
Secret
GroupID
Name
DateCreation
Description
Server_Config
MaxNumVehicles
TCP_Operation_Port
TCP_TimeOut
CMD_Timeout
UDP_Limit_Down
UDP_Limit_Up
TCP_Limit_Down
TCP_Limit_Up
Reports
PK UserID
Timestamp
Latitude
Longitude
v_Plate
Description
v_Brand
v_Model
v_Color
p_ID
p_Driverlicense
p_Name
terminal_groups
PK GroupID
Name
Description
RTstatus
PK UserID
Timestamp
Latitude
Longitude
SOS
STOP
GSPfix
Battery
History_status
PK UserID
Timestamp
Latitude
Longitude
SOS
STOP
GPSfix
Battery
History_Events
PK UserID
Timestamp
TypeEvent
Latitude
Longitude
Confirmed
data
* ... 1
* ... 1
1
...
*
1 ... 1
1 ... *
37
Table Name Description
Server_config Contains the parameters of tracking server configuration. See next chapter for further details.
Terminal_Users Contains all the mobile app users and corresponding data (e.g. shared secret).
Terminal_Groups Contains the list of groups that mobile users can belong to.
RTstatus Contains the latest status for each mobile app (vehicle). Due to performance, this table is kept only on memory.
History_Status Stores all the status received by the mobile apps.
History_Events Stores all the events performed within mobile apps. (e.g. Reception of photo or Job dispatch)
Reports Stores all the reports uploaded by mobile apps.
Table 3 Tracking server database tables.
3.2.3Server Configuration
All the tracking server configuration is done through the database table Server_Config (shown in
Figure 6 UML Database model.), where each row represents a configuration parameter. All the
parameters are loaded during the boot of the tracking server. The following table describes each one
of them:
Parameter Description Default Value
MaxNumVehicles The maximum number of total vehicles that tracking server will serve at the same time.
100 (vehicles)
TCP_Operation_Port Port used by the mobile apps to perform operations (e.g. Subscription).
1000 (TCP port)
TCP_TimeOut Maximum idle time (milliseconds) the tracking server waiting for a reply during a Operation. (faster release of resources)
5000 (5 seconds)
CMD_TimeOut Maximum time (milliseconds) the tracking server persist a command (e.g. Job Dispatch)
10000 (10 seconds)
UDP_Limit_Up, UDP_Limit_Down
Window of available UDP ports that tracking server may use to exchange live messages with mobile apps.
2000,4000 (UDP port)
TCP_Limit_Up, TCP_Limit_Down
Window of available TCP ports that tracking server may use to exchange live messages with mobile apps.
2000,4000 (TCP port)
Table 4 Tracking server configuration parameters.
3.3 Vehicle (Mobile App)
3.3.1 Architecture
The mobile app is coded in Java programming language for Android(API 1719), it was targeted to run
on Android devices, but it can also run through an emulator (Bluestacks20) on other OSs. Android is an
open-source OS, an important aspect to LEAs, since it provides a transparent level of trust on how the
data is internally used by the OS. Android counts with alarge list of manufacturers that produce a wide
range of devices with distinct prices, physical dimensions and hardware components. An important
aspect, since this enables LEAs to find the best-fit devices according to their specific requirements.
19
Source: developer.android.com/about/versions/android-4.2.html, last accessed on May 9th, 2014 20
Source: bluestacks.com, last accessed on May 9th, 2014
38
The architecture is designed accordingto the following Figure 7.
Figure 7 High-level architecture of mobile app.
File Manager: Same as File Manager of tracking server (see section 3.2.1 ).
Security:Same as Security of tracking server (see section 3.2.1).
Operation Handler:This module is responsible to perform operations. All the operations start with a
TCP socket connection originated by the mobile app to the tracking server (TCP Operation port, see
Table 4).
Application Manager: This module is responsible for all the user interface of the mobile app. It
enables the user to trigger operations through the mobile app (e.g. SOS alarm, Report.), visualize
current location or Central Station data against the map (e.g. Risk Map), and even visualize data (e.g.
missing persons). The first operation performed by this module is the subscription. Once successfully,
it will load the Message Handler.Subscription operation is further detailed in section 3.4.1.
Message handler: This module is responsible to fetch data from GPS (e.g. location) and Battery
device modules, and send it as status messages updates to the tracking server. The module also
receives control messages, which are commands originated by the tracking server (e.g. Job dispatch).
The communication is preferably done through UDP, but TCP is also supported(when the device is
behind a NAT/firewall). The detection of NAT/Firewall happens when a local IP is assigned to the
network device. If the assigned IP is no longer local, it automatically switches (again) to UDP.
3.3.2 User Interface (UI)
The mobile app user interface was designed to be as simple and intuitive as possible. As Figure 8
Mobile App, Dashboardshows, only three buttons exist on the dashboard. The "Auto View" which
automatically centers the vehicle position in the screen. The high accessible SOS button triggers an
immediate support request on Central Station. And at last, the Risk Map feature, which provides an
over layer (the risk) on the map (see Figure 9).
Application Manager
User Interface Control
Map Visualization
Data Visualization
Operation Handler
Subscription
Receive File
Send File
Send Offline Messages
Send Reports
Sync People Data
Sync Vehicles Data
Sync Risk Map Data
File Manager
Write Local File
Read Local File
Message Handler
Fetch device data (GPS and Battery)
Send status message updates
Receive Control messages
Security
Encryption
Decryption
Message Validation
39
Google Maps Android API v221 is the system of maps employed. It provides good level of detail/map
information, long-term support and easy integration with the app code.
Figure 8 Mobile App, Dashboard
Figure 9 Mobile App, Risk Map
As soon as the app is running (for the first time), it starts to prompt the user for server information and
corresponding user credentials (see Figure 10 Mobile App, Subscription (Login)). This is mandatory, in
order to perform the subscription process (see 3.4.1). After the successfully subscription, the app is
connected to the tracking server and therefore, it becomes able to exchange live status messages and
receive commands from tracking server. Commands such as dispatch a job or send a POI, are
automatically represented on the map, without any interaction from user (see Figure 11), POI are
represented by yellow markers, and dispatched Job by a red marker).
Figure 10 Mobile App, Subscription (Login)
Figure 11 Mobile App, Job dispatch and POI
Nevertheless, the mobile app user can perform many operations, through the mobile app menu (see
Figure 12) directly accessed by the android mobile device settings button. As examples, it can make a
report (Figure 13), send a file, and update or access LEA data (e.g. missing people). The possibility to
lock the app is another feature which avoids the user to accidently trigger operations, and at the same
time reduces the band width consumption, since it stops immediately to fetch data from Google Maps.
However, live message status exchange is not interrupted by this feature.
21
Source: developer.android.com/google/play-services/maps.html, last accessed on May 9th, 2014
40
Figure 12 Mobile App, Menu
Figure 13 Mobile App, Report
3.4 Technical Implementation
This section presents technical details behind the solution features. Diagrams and corresponding
illustrated sequence of steps were used to provide an easier level of understanding (e.g.Figure 14
Subscription operation). Even thoughthe diagrams show granularity finer to the TCP segment like the
SYN TCP segment during TCP connection establishment, it shall not be assumed that all the
numbered steps are performed through a single TCP segment.
3.4.1Subscription
The subscription operationis always started by the mobile app, and it is the first operation performed
as soon as the App starts. The goal of this operation, is to enable the exchange of live message status
from vehicles to tracking server (Real-Time Monitoring). The following picture depicts the Subscription
process:
41
Figure 14 Subscription operation
As Figure 14 Subscription operation shows, the operation starts by the authenticity of the user through
shared secret validation. In order to mitigate plain-text attack, random bytes are included during the
operation (steps 5 and 9). After user authentication, the tracking server replies with all data required
for the load of the mobile app Message handler module. It starts by transmitting the timestamp, which
will enable the mobile app to synchronize the internal clock with the tracking server time, critical to
avoid replay attacks (see next section.3.4.2). The UDP and TCP ports are also provided; these will be
used by the Message Module (on both sides) and unique for each user. These ports are randomly
generated by the tracking server, turning an attack more complex to achieve, assuming the attack is
not a man-in-the-middle and the port-scan does not retrieve any details (TCP weakness). It requires
much more computational and network resources to target the tracking server through all the possible
65535 socket ports, in comparison to the single shared port for all the mobile apps.
Another security measure is the generation of a random session key (step 7). The session key
provided by the tracking server will be used for all the upcoming message exchange through the
Message Handler (on both sides). Thus, every time a subscription operation is performed, a new
session key is generated. This way, the amount of data processed using a particular key is
significantly reduced, which turns the prediction of the shared key more unlikely.
TCP
Connection
Establishment
(TCP_Operation_Port)
1
2
3
4
5
6
7
8
TCP
Connection
Termination
9
10
TCP
Connection
Establishment
(TCP_Operation_Port)
TCP
Connection
Termination
Mobile App Tracking server
SYN
ACK
SYN - ACK
Operation
Handler
Operation
Handler
ACK
ACK
42
It is important to highlight that step 9 denies a possible replay attack on step 5.Thus, If step 9 were
suppressed from the subscription operation, the tracking server would be an easy target of DoS
through the replay of steps 1 to 5. The attack would be easier, due to the significant resources that
subscription operation consumes.
At the end of subscription operation, the mobile app and the tracking server instantiates Message
Handler accordingly to the parameters exchanged through Subscription operation.
3.4.2 Monitoring
3.4.2.1 Real-Time status messages
The tracking server monitors the fleet through live messages status sent by mobile app. The
messages are sent with a fixed update ratio of one per second, and the module responsible for the
message exchange is the "Message Handler", present on both sides (tracking server and mobile app).
Central Station is only able to monitor a vehicle, after the corresponding mobile App performed a
successful subscription operation within the tracking Server. Once it is done,thelive message status
exchange starts.
All the messages exchanged, have exactly the same format (on both sides, Mobile app and the
tracking server). The following picture depicts the data format of the status message:
Figure 15Live status message format.
As Figure 15Live status message format. shows, the raw message data size is notably small (18
Bytes). In fact, is smaller than the minimum possible size of TCP header (20 bytes)[22] . As analyzed
previously (see section 2.3) the data size is an important aspect regarding communication
performance that was taken into account. Nevertheless, the overall size of the data significantly
depends on the combination of MAC and encryption algorithm used. Another aspect is the missing
mobile app user identification in the messages, possibly due to the dedicated ports for each user on
tracking server (randomly generated during Subscription Operation). This way, there is a reduction of
the data size, along with a security enhancement: No vehicle identification can be directly retrieved
from the message, or even device information such as IMEI (used as identification in many RTMS
Systems) in case of violation of message confidentiality.
Timestamp - Time when the status message is created by the mobile app. This value is synchronized
with the tracking server system clock (during Subscription). In case of Message handler is working
over UDP, the field is used as sequence number, allowing tracking server to sort/identify the latest
Timestamp Latitude LongitudeStatus Control
SOS | GPS | Battery | STOP Job | POI | Clear | File
Flags Flags
8 Bytes 4 Bytes 4 Bytes 1 Byte 1 Byte
18 Bytes
MACMessage Authentication Code
Encrypted
43
vehicle status. At the same time, every message status replied by the tracking server has the same
Timestamp of the original message status sent by the mobile app. This way, themobile app is able to
identify which message status were lost or successfully delivered.
In addition, Timestamp field is used as anti-replay attack measure. Tracking server only processes
messages containing Timestamps with no more than 5 seconds of difference. Therefore, the sum of
the network delay with clock drift (between mobile app and tracking server) must be less than 5
seconds; otherwise the message will be treated as lost (see next section 3.4.2.2).
Latitude/Longitude - Mobile app always populate these fields with the current location of the vehicle. In
case of tracking server, these fields may contain specific location of a job (dispatch job feature) or
location of point of interest (POI).
Status - Populated by mobile app to notify follow status to tracking server:
SOS - The flag is set, if request for support was triggered on mobile app.
GPS - The flag is set, when the GPS module is locked (see GPS, section 2.2.2).
Battery -The flag is set, if the battery of mobile device is lower than 30%.
STOP - The flag is set, if the vehicle is stopped (detection by GPS module).
Control - Populatedby tracking server to send the following commands to the mobile app:
Job - When flag is set, the message contains a job dispatch to the mobile app.
POI - When flag is set, the message contains a POI to the mobile app shown on map.
Clear - When a message with this flag is received, the mobile app automatically cleans the map (user
interface). Thus, all the POI and/or Jobs information displayed on the user interface disappear.
File - Tracking server sets this flag anytime it is required to send a file. This flag allows the mobile app
to take initiative and establish the TCP connection with tracking server and consequently perform the
file reception (see section 3.4.3).
3.4.2.2 Lost status messages
The delivery of live status messages may not always succeed, especially in scenarios of poor or
inexistent network signal. Under these circumstances, the mobile app piles up all the lost messages
and attempts to send them as soon as the network signal recovers. In case of the UDP protocol being
used, every message sent is automatically piled into the lost messages. And anytime a valid reply
arrives from tracking server, it is removed accordingly from that pile. This way, only the lost messages
will remain on the pile. The same applies to TCP. But since TCP is a connection-oriented protocol,
anytime a message is prepared to be sent, and no connection is established, it automatically goes to
the pile of lost messages.
44
Lost messages are sent to the tracking server through an operation, as Figure 16 depicts. The
verification for network recovery is done once per second. Nevertheless, the recovery operation is only
triggered in case the pile of lost messages is bigger than 15 messages. This way, the number of
recovery operations is significantly reduced (especially in scenarios where network intermittence
exists, and the chance of a drop of TCP connection during the operation is very likely). As such, there
is a buffer with an equivalent tolerance of 15 seconds (one message per second) during an
intermittence scenario. It is important to highlight that recovery operation works in parallel to real-time
status messaging exchange, and the respective reduction reflects into extended battery life on
tracking unit and lower computational resources usage on tracking server.
Figure 16 Lost status message recovery operation.
It should be noticed that, in Figures 16-18 and Figures 20-21, all messages denoted as encrypted are
assumed to:
- being cyphered using a key as described on the graph message
- containing a timestamp (not represented on graphs), or a combination of a sequence number
and a nounce
- containing an authentication code (HMAC, consisting of an hash of: the original text to be
ciphered, the secret, and the timestamp)
1
2
3
4
5
6
7
8
TCP
Connection
Termnation
9
10
TCP
Connection
Establishment
(TCP_Operatiom_Port)
TCP
Connection
Termination
SYN
ACK
SYN - ACK
ACK
Mobile App Tracking server
ACK
Operation
Handler
Operation
Handler
TCP
Connection
Establishment
(TCP_Operatiom_Port)
...
45
3.4.3 File exchange
The solution proposed by this thesis allows the secure exchange of files between vehicles and the
Central Station. The file transmission process has two possible scenarios, depending on which system
is taking the initiative. For instance, after a photo is taken by the mobile device, it is transmitted to the
tracking server. Thus, the process is initiated by the mobile app. Figure 17 File transmission operation
(from mobile app to tracking server). , depicts the file transmission process initiated by the mobile app.
Figure 17 File transmission operation (from mobile app to tracking server).
As Figure 17 File transmission operation (from mobile app to tracking server). shows, the operation
starts withuser authentication through shared secret validation along with the generation of a session
key, valid until the end of this operation.It is important to highlight that, all files sent by the mobile app
are stored in the tracking server along with the corresponding time and location (step 7) - This feature
populates the database with richer and critical information for posterior investigations, such as criminal
analysis or internal LEA auditions.
The transmission of a file from tracking server to the mobile app, requires a different approach to
establish the TCP connection. This is justified by the possibility of the mobile app be behind a
1
2
3
4
5
6
7
8
TCP
Connection
Termnation
9
10
TCP
Connection
Establishment
(TCP_Operatiom_Port)
TCP
Connection
Termination
SYN
ACK
SYN - ACK
ACK
Mobile App Tracking server
11
12
ACK
Operation
Handler
Operation
Handler
TCP
Connection
Establishment
(TCP_Operatiom_Port)
...
46
NAT/Firewall.The corresponding scenario solution is depicted by Figure 18 File transmission operation
(from tracking server to mobile app).
Figure 18 File transmission operation (from tracking server to mobile app).
As Figure 18 File transmission operation (from tracking server to mobile app). shows, the tracking
server starts to notify the mobile app of a file exchange request through the live message status
response - Using the File flag of the Control field (see message structure, 3.4.2 Monitoring
). Since the protocol used might be UDP (no successful delivery of data is guaranteed), the flag is kept
settled until an acknowledge from mobile app is received. This is explicitly done through the same flag
(File flag, control field) of the message.The file notification mechanism is described from step one to
seven. As soon as the mobile app receives the notification, automatically establish a TCP connection
TCP
Connection
Termination
TCP
Connection
Establishment
(TCP_Operation_Port)
TCP
Connection
Termination
SYN
ACK
SYN - ACK
ACK
Mobile App Tracking server
ACK
Message HandlerMessage Handler
Message (Control → File = 1)
Message (Control → File = 1)
Message (Control → File = 1)xMessage (Control → File = 1)
...
Message (Control → File = 0)
Message (Control → File = 0)
Message (Control → File = 0)
...
Operation
Handler
Operation
Handler
TCP
Connection
Establishment
(TCP_Operation_Port)
8
9
10
11
12
13
14
15
16
17
18
19
1
3
2
45
6 7
...
47
with the tracking server, and an analogous process as described previously is performed (Figure 17
File transmission operation (from mobile app to tracking server).
3.4.7 Report
Reports enable vehicles to populate certain events within LEA database. An event is generally
described as a situation of interest happening at a location and involving actors, such as people and
vehicles. The following picture depicts the internal data model of a report:
Figure 19 Report internal data representation.
The data size of a report is undefined, since it contains a free text field (Report Description) along with
optional fields (Person and Vehicle). The location of the event (Latitude/Longitude) is automatically
assigned to the report (transparently to the end-user). In case the GPS module of the mobile device is
not in the lock mode, the mobile app assigns the last location retrieved from the device over the last
minute, and a zero value in any other condition. The Tag field, is used to the assign multiple tags on a
single report. This enables the creation of correlation between reports (linked by same tag). For
instance, the insertion of the mission codenames into tag field, may easily expose the complex
relationship of certain suspects in distinct missions.
Reports are created through mobile app user interface, therefore the transmission of the reports are
always started by the mobile app. When a report is created and ready to submit, an attempt to
establish a connection and transmit the corresponding data to the tracking server is performed. In
case the network is not available, it starts to pile the reports and periodically (every second) tries to
establish the connection with the tracking server, until eventually the network is reachable. Figure 20
Reports transmission operation.,depicts the successful submission of the reports.
UserID Latitude Longitude
Report
Timestamp Tag
Report Description
Person VehiclePlate | Brand | Model | Color Name | ID No | Driving Licence No
48
Figure 20 Reports transmission operation.
As shown in Figure 20 Reports transmission operation., reports are not sent as a whole. Instead, they
are submitted iteratively (one per step), and removed accordingly. This makes the process more
resilient to network fluctuation. An eventual TCP disconnection during the operation does not
compromise the successfull delivery of some reports. Thus, there is no need to re-send from the
beginning all the data as the network signal eventually recovers.
1
2
3
4
5
6
7
8
TCP
Connection
Termnation
9
10
TCP
Connection
Establishment
(TCP_Operatiom_Port)
TCP
Connection
Termination
SYN
ACK
SYN - ACK
ACK
Mobile App Tracking server
ACK
Operation
Handler
Operation
Handler
TCP
Connection
Establishment
(TCP_Operatiom_Port)
...
49
3.4.8 LEA data synchronization (people, vehicles and risk map)
People (suspects and missing),vehicles (suspects and robbed) and Risk map data is strictly required
to be accessible anytime through mobile app. Therefore, a mechanism to keep the data up to date
(synchronized) within Central Station is a critical aspect for the day-to-day operation of an LEA. The
following picture depicts the implemented process of data synchronization between mobile app and
tracking server:
Figure 21 LEA data synchronization operation.
As shown in Figure 21 LEA data synchronization operation., the process of data synchronization is the
same for all the LEA data, except the first step which identifies what data synchronization will take
place during the operation. For instance, the request for operation '5' will trigger the tracking server to
update the mobile app with the latest file (up to date version) containing the list of missing and suspect
persons. The version verification is performed on step 7. After the validation of the user and
corresponding shared key,the mobile app submits the actual version it owns (represented as a
number). If the version number submitted is inferior to the version on behalf of tracking Server, the
latest file is automatically sent to the mobile app. Otherwise, tracking server automatically closes TCP
connection. The versioning algorithm is implemented by the File Manager module (see File Manager
module, section 3.2.1). LEA data synchronization is manually triggered by mobile appat the end-user
(user interface). The non-implementation of a periodic mechanism to check for new updates is justified
1
2
3
4
5
6
7
8
TCP
Connection
Termnation
9
10
TCP
Connection
Establishment
(TCP_Operatiom_Port)
TCP
Connection
Termination
SYN
ACK
SYN - ACK
ACK
Mobile App Tracking server
ACK
Operation
Handler
Operation
Handler
TCP
Connection
Establishment
(TCP_Operatiom_Port)
...
11
12
13
14
50
by the network resources that these operations can potentially consume (depending on the size of
data files). Since vehicles are constantly in contact with the Central Station via radio (voice channel),
they can use the same channel to notify vehicles of a new version, and consequently trigger the
update within a known place where the network allows an update in a significant fraction of the time
required (e.g. inside LEA facilities, using Wi-Fi).
The data containing people and vehicles information is open to any file format. Thus, LEAs have total
flexibility to use the most suitable or existing licensed application for own data manipulation - LEA may
use Microsoft Office within desktop LEA facilities (Central Station) and Android Office in mobile
devices. When visualization of data is requested by the mobile app user, it will automatically open the
file through a third party app chosen (e.g. Android Office).
Unlike people and vehicle data, risk map data have a specific data structure for which the tracking
server must comply, otherwise, the mobile app will not be able to parse the file and consequently will
fail to display the corresponding risk layer over the map. The following figure depicts the risk map data
structure:
Figure 22 Risk map file data structure.
Risk map is a file that contains a set of locations and corresponding radius (circles), assigned to a
specific window of time and date (day of the week). When risk map layer is activated (user-interface),
circles with different radius start to appear and disappearas the time passes. Thus, for a specific point
in time, personal in a vehicle can easily see in the map the zones which shall be more actively scout.
A sample of this file can be found in annex A.2.
!<WeekDay 1>
<HHMM> <Latitude 1> | <Longitude 1> | <Radius 1> | ... | <Latitude N> | <Longitude N> | <Radius N>
<HHMM> <Latitude 1> | <Longitude 1> | <Radius 1> | ... | <Latitude N> | <Longitude N> | <Radius N>
...
!<WeekDay 7>
<HHMM> <Latitude 1> | <Longitude 1> | <Radius 1> | ... | <Latitude N> | <Longitude N> | <Radius N>
<HHMM> <Latitude 1> | <Longitude 1> | <Radius 1> | ... | <Latitude N> | <Longitude N> | <Radius N>
RiskMap
51
4 Evaluation
This chapter will not concern individual component functional tests, thus assuming that all these tests
have already been carried out, guaranteeing that all the functional features are working properly.
Under these circumstances, it is required to measure, and quantify accordingly, the solution against
specific metrics.For each experiment described, 5 tests will be performed. Final statistical results were
calculated as an average, and respective standard deviation derived accordingly from the measured
values. A graphical representation of these results and corresponding analysis, can be found in
section 4.4..
4.1 Metrics
This section lists and describes the metrics used to measure quantitatively the solution behavior. The
following metrics were chosen:
CPU consumption (Percentage) - Percentage of CPU used by the overall tracking server
solution. This metric is measured through bash shell scripting (see performance script, annex A.3).
Memory consumption (Megabyte) - Numeric value of computer memory consumed by the
overall tracking server solution. This metric is measured through Linux bash shell script (see
performance script, annex A.3).
Message lost rate (Percentage)- Percentage of the messages that were not acknowledged (lost)
by tracking server. This metric is performed on the tracking unit app, and isonly measured on UDP
(since TCP is reliable).
Maximum status delay measured (Milliseconds) - The maximum measured time that a status
message takes from the mobile app status fetching process, to the successfully introduction of the
data into the tracking server database. This metric is measured using the timestamp of the status
message against the current timestamp of the database. The measurement of this metric
assumes that both (tracking server and tracking units) clocks are synchronized. Further details are
provided in the next section.
Network Traffic (Kilobytes) - The total sum of Bytes in and out of tracking server network
interface. This metric is measured through bash shell scripting (see performance script, annex
A.3).
52
4.2 Testbed
Mobile Network coverage and GPS signal strength are two uncontrollable variables with critical impact
on the test scenario. In order to eliminate these dependencies, the tests are run in a controllable local
area network (LAN), and the GPS coordinates are generated internally by the App code. Another
challenge for the execution of scalability tests is the replication of many Android mobile devices
(tracking units). Since it is not feasible to test the tracking server against many real devices, the mobile
device app core (without user interface) was migrated to a single application, which can launch and
destroy multiple instances of mobile apps (tracking units) over specific time intervals.
The tracking server machine and the tracking units machine are connected by a 100Mbps Ethernet
link, using a 2 meters crossover Ethernet cable. Figure 23 depicts the network topology and
corresponding configuration.
Figure 23 Testbed network topology
Both machines are different, in terms of hardware and software. Tables 5 and 6 provide a description
of the relevant hardware characteristics (Table 5) and corresponding software installed (Table 6).
Hardware
Tracking server machine Tracking units machine
Type: Laptop Model: DELL Latitude D630
Type: Laptop Model: HP Envy 14-1040ep
CPU: Core 2 Duo CPU T7300 @ 2.00GHz Cores:2
CPU: Intel i7 CPU Q720 @ 1.60Ghz Cores: 8
RAM:4GB RAM: 6GB
Disk: Toshiba MK1237GSX 120GB 5400RPM, SATA
Disk:HitachiHTS725050A9A364500GB 7200RPM, SATA II
Table 5 Testbed Hardware
192.168.1.1/24 192.168.1.2/24
Ethernet – 100Mbps
Tracking server Tracking units
53
Software
Tracking server machine Tracking units machine
OS:Ubuntu Server 12.04.4 LTS Kernel: 3.11.0-15-generic
OS:LinuxMint 13 Maya Kernel: 3.2.0-4-generic
Java: SE RuntimeEnvironment 1.7.0_51 Java: OpenJDKRuntimeEnvironment 1.7.0_21
NTP Server: ntpd [email protected] NTP Client: ntpdate [email protected]
DBMS: Mysql14.14 Dist 5.5.35 N/A
Table 6 Testbed Software
Network latency between both machines was measured, through transmission of a ping command
during one minute. The maximum measured value for latency was less than a millisecond (see annex,
A.4). This low latency value, enables the clock synchronization (through Network Time Protocol, NTP)
between machines with a much higher accuracy (lower offsets) [22] . In order to perform the
synchronization, the tracking server machine was configured as NTP server. And for each test
conducted, the tracking units machine was previously synchronized with the NTP server. The
maximum time offset between machines was always set above the 50 milliseconds limit (see annex
A.5 as an example).
4.3 Experimental Tests
All experimental tests are run on the previously described testbed, and aim to evaluate the Tracking
server. Every test starts by the reboot of the tracking server machine, following a NTP sync of the
tracking units machine with the Tracking server, until a minor offset (less than 50 milliseconds) is
achieved. Once the system clock machines are properly synchronized, the performance script (annex
A.3) is manually launched on the tracking server machine. The script runs on the background, and it
writes periodically (5 seconds) on the database the following information: CPU, memory and the total
traffic generated on the tracking server network device. It is important to highlight, that the script resets
(subtracts) the values previously used by the OS: The network traffic, CPU and memory. The same
script is responsible to create the database table where values will be written, along with the
generation of the 100 test users and corresponding credentials. Once the script is properly running,
the tracking server solution is manually launched. After that, the tracking units (clients) start to connect
to the tracking server through the launch of tracking units multiple instance software - Responsible to
(iteratively) create a tracking unit client instance and launch it accordingly (initial subscription and
consecutive live status message exchange).
The logic of the tests are implemented on the tracking units machine: A new client is created and
consequently connected to tracking server every 30 seconds. Test ends when the last client (100th) is
already connected for 30 seconds. Thus, every test takes 50 minutes (30 seconds x 100 clients).At the
end of each test, the test values are extracted from the database using a data extraction script (see
Annex A.6), with exception of the message lost rate data, which is manually fetched through the
output of the number of lost messages that every tracking unit client ends up with.
54
Even though all tests have the same logic, the evaluation is performed over the following scenarios:
1. All live status messages exchange is done over TCP, without any security function applied (no
encryption or addition of MAC, see annex A.7 No security (Security.java)).
2. All the live status messages exchange is done over UDP, without any security function applied
(no encryption or addition of MAC, see annexA.7 No security (Security.java)).
3. All the live status messages exchange is done overUDP. Only encryption (DES algorithm) is
applied to the raw message (no MAC, see annex A.8 Encryption only (Security.java)).
4. All the live status messages exchange is done over UDP. Encryption (DES algorithm) is
applied over the raw message and corresponding MAC (see annex A.9 Encryption + Mac
(Security.java)
Due to the default preference of UDP over TCP (see 3.3.1, Message Handler module), test scenarios
which involve security functions are only performed on UDP. Nevertheless, analogous results are
expected on TCP.
Regarding security, the choice for using DES as encryption algorithm for testing, is justified by the
notable distinct performance against the majority of many other possibilities [23] , turning the result
values as a good baseline (starting point for comparison) - It is important to highlight that DES
algorithm was only used for test purposes. The usage of DES algorithm is not recommended from a
security point of view since it can be broken with relatively low effort [24] .
4.4 Experimental Results
This section presents the experimental results obtained from testing (setup detailed on previous
section). The results are organized per metrics.Each metric contains a graphical representation of the
result for all tests, except message lost rate metric, which resulted in 0% for all the tests (section
4.4.3). All the sections end with a reference for the source of the corresponding data.
55
4.4.1 CPU
Figure 24 CPU consumption
As shown in Figure 24 CPU consumption, not only the average CPU usage increases with the number
of clients, but also the value of the CPU spikes. As expected, the addition of security functions
corresponds to additional CPU consumption. CPU average use increases 4,7% whenever encryption
(DES) is added to UDP, and 6,92% with the addition of encryption along with MAC.
The values that generated this graphical representation can be found in annex A.10 CPU values,
together with standard deviation values.
4.4.2 Memory
Figure 25 Memory consumption
As shown in Figure 25 Memory consumption, the memory usage increases with the number of clients.
As expected, the addition of security functions corresponds to additional memory consumption. The
average memory in use increases 53,92%, when encryption (DES) is added to UDP, and 75,18% with
the addition of encryption along with MAC. Nevertheless, It is important to highlight that the values do
56
not represent real memory in usage, but the memory allocated to the server application. The release
of the memory allocated butnotinuse, is managed by JVM (garbage collector) and corresponding
machine OS.
The values that generated this graphical representation can be found in annex A.11 Memory values,
together with standard deviation values.
4.4.3 Message lost rate
The message lost rate resulted in 0% for all the tests. A result justified by the high reliability of the
testbed network (eg. low signal degradation), non-congestion of the Ethernet channel and non-
overload of tracking server machine (e.g. CPU usage have never surpassed 70%). Under these
circumstances, the measurement of the message lost rate confirms that the tests ran flawless, with all
live status messages being successfully delivered.
4.4.4 Maximum status delay
Figure 26 Maximum status delay
As shown in Figure 26 Maximum status delay, the maximum status delay has similar values for all the
tests, assuming a minimum of 50 milliseconds offset. The values converge into the 250 milliseconds
value, which is the frequency that the tracking server writes the live status messages into database
(see section 3.2.1, Application Manager module). Under these circumstances, it is possible to state
that there is room (750 milliseconds) for the mobile app to fetch data, and to be represented in Central
Station (tracking server front-end), in less than a second, making it a real-time application to human
senses.
The values that generated this graphical representation can be found in annex A.12, together with
standard deviation values.
57
4.4.5 Network Traffic
Figure 27 Network Traffic
As shown in Figure 27 Network Traffic, TCP is notably the top traffic generator. This is mostly justified
by the larger header size compared to UDP, since the combination of the testbed network and tracking
server overload is relatively low (so that the probability of a network segment to be retransmitted is
very low). Another fact that makes TCP to generate more traffic, is the fact of being a connection
oriented protocol with corresponding features such as reliability, which requires the acknowledge of
successful delivery of data segments. All together, makes TCP generate more 35,96% traffic than
UDP (averaged over the last 10 values).
Another aspect is the fact that single encryption, and encryption with MAC have similar values. This is
simply justified by the fact that both have the same message size (24 Bytes). The single encryption of
the raw message results in a block of 24bytes message, where last 6 bytes are not used (padded).
The addition of MAC uses 4 of the 6 not used bytes, leaving only 2 bytes for padding.This highlights
the importance of a good combination design between the message size, the encryption algorithm and
respective block size, along with the proper MAC algorithm - It is possible to state that, the extension
of security by the addition of the MAC did not have any impact regarding the network traffic.
The values that generated this graphical representation can be found in annex A.13 Network traffic
values, together with standard deviation values.
58
5 Conclusions and future work
5.1 Conclusions
The complexity of criminal activities is increasing, and that reflects on an increasing challenge to LEAs
way of operation. An improvement on reaction speeds,as well asa better workforce management
capability over the territory, are increasingly being required, and that can be solved through the
adoption of a RTMS specifically designed for LEAs. Currently, some LEAs are adopting it 22, which
proves the existence of a demand for this type of solutions. However, it represents a significant
investment 23 in tailor-made solutions and eventual dedicated communication infra-structures (e.g.
TETRA) for that purpose. An unrealistic scenario for the majority of the countries, which struggle with
tight budgets (e.g. underdeveloped countries). This thesis concludes that it is possible to develop:
specific RTMS that meet LEAs daily requirements with an extremely low budget; and an affordable
solution that benefits from the higher trend for the improvementof the existing mobile network
coverage and corresponding terminal devices (e.g. Tablets) affordability. The solution of this thesis
shows that it is feasible to trade computational resources for enhanced security on third-party
networks such as mobile operators. In contrast to the creation of dedicated secure communication
infra-structures such as TETRA, which come out to be too expensive and inadequate to meet LEAs
requirement space (e.g. data throughput).
Within the scope of fulfilling LEAs requirements, the solution proposed opens the doors for disruptive
LEAs methodologies, like an optimized prevention strategy supported by the increasing efficiency of
the patrol over spots that represent more probability of crime on a dynamic (changing over the day)
and automated way.
Despite the many scientific studies that are widely available over the internet, there were significant
efforts to find scientific LEAs related work. LEAs IT solutions tend to follow a non-disclosed information
policy. This security approach based on secrecy of information made the overall state-of-art analysis
more difficult. On the other hand, according to our analysis, it is important to highlight the possibility
that scientific community is not giving enough attention to LEA field.
22Source: http://crackberry.com/uk-police-get-blackberry-playbook, last accessed on May 9th, 2014 23 Source: http://content.met.police.uk/News/Total-Technology-strategy-
201417/1400022464491/1257246741786, last accessed on May 9th, 2014
59
5.2 Future work
The resulted work from this thesis is far from a turnkey (off-the-shelf) solution. The development of the
tracking server front-endand an Android abstraction layer that mitigate GPS threats, are interesting
topics to address in the near future.
In addition, the solution should be improved with concerns to security. Further efforts should be taken
to analyze, together with LEA officers, security requirements, in order to create a security policy for the
system, and then to apply and test off-the-shelf security mechanisms that implement that policy on the
solution.
This work can be used as the base for the development of new features and services, benefiting from
the integration of specific LAE accessories, such as automatic license plate recognition24 devices (for
example, to make the match against LEAs database, and consequent instant notification to the
nearest patrol), or the automatic launch of an unmanned aerial vehicles25,thus making the chase even
safer for citizens. The adoption of new wearables are also very promising to LEAs workforce, such as
augmented reality glasses26 capable of recognizing criminals through a builtin camera, to wristbands27
that automatically issue an SOS alarm in central station when an heart rate rampage is detected.
6 References
[1] P. Vitor, Rede SIRESP –Tecnologia de emergência e segurança do futuro, ComSoc/POSTIT
Conference, 2010
[2] E. Qayyum, Z. Mohsin and J. Malik, Real-time Vehicle Tracking System Using GPS & GSM, Lap
Lambert Academic Publishing, 2013
[3] L. Varandas, B. Vaidya and J. Rodrigues , mTracker: A Mobile Tracking Application for Pervasive
Environment, IEEE 24th International Conference on Advanced Information Networking and
Applications Workshops, 2010
[4] S. Chen, J. Wang and Y. Wei, The Implementation of Real-time On-line Vehicle Diagnostics and
Early Fault Estimation System, Fifth International Conference on Genetic and Evolutionary
Computing, 2011
[5] D. DeWitt and J. Gray, Parallel Database systems: The future of the high performance database
systems, Communication of the ACM, Vol.35, No6, 1992
[6] National Research Council (U.S.) - Committee on the Future of the Global Positioning System,
The global positioning system: a shared national asset: recommendations for technical
improvements and enhancements, National Academies Press. Chapter 1, p. 16. ISBN 0-309-
05283-1, 1995
24Source: elsag.com/fixed.htm, last accessed on May 9th, 2014 25Source: avinc.com/public-safety/applications/law-enforcement, last accessed on May 9th, 2014 26 Source: spaceglasses.com, last accessed on May 9th, 2014 27Source: sonymobile.com/pt/products/smartwear/smartband-swr10, last accessed on May 9th, 2014
60
[7] US Departament of Defense, Global Positioning System Standard Positioning Service Perfomance
Standard 4th Edition, 2008
[8] D. Hayes, Status of Galileo and EGNOS, European Commission, 2012
[9] R. Prasad and M. Ruggieri , Applied satellite navigation using GPS GALILEO and augmentation
systems, Artech House ISBN 9781580538145, 2005
[10] M. Wildemeersch, E. Pons, A. Rabbachin and J. Guasch, Impact Study of Unintentional
Interference on GNSS Receivers, JRC Scientific and Technical Reports, ISBN 978-92-79-19523-
5, 2010
[11] S. Jon et al., GPS Spoofing Countermeasures, Los Alamos Research Paper LAUR-03-6163,
2003
[12] S. Mondal, Improving performance of TCP over mobile wireless networks, Springer
Science+Business Media, Published online: 4 August 2007
[13] J. Korhonen and Y. Wang, Effect of Packet Size on Loss Rate and Delay in Wireless Links, IEEE
Communications Society / WCNC 2005
[14] Y. Chen and W. Jia, Challenge and solutions of NAT traversal for ubiquitous and pervasive
applications on the Internet, The Journal of Systems and Software 82, 1620–1626, 2009
[15] P. Perugu, An Innovative Method using GPS Tracking, WINS Technologies for Border Security
and Tracking of Vehicles, Recent Advances in Space Technology Services and Climate Change
(RSTSCC) Conference, ISBN 978-1-4244-9184, 2010
[16] C. Kaufmann, P. Radia, M. Speciner, Network Security: Private Communications in a Public
World, Prentice Hall, 2002
[17] T. Hardjono, Security In Wireless LANS and MANS, International Journal of Network vol.10,
No.3, PP.213–219, Security Artech House Publishers, 2010
[18] W. Stallings, Cryptography and network security, Prentice Hall, 2006
[19] P. Koopman and C. Szilagyi, Security & Privacy, IEEE Volume: 11 Issue: 3 pages 61 - 63, ISSN
1540-7993, 2013
[20] Muruganandham and P. Mukesh, Real Time Web based Vehicle Tracking using GPS, World
Academy of Science, Engineering and Technology 37, 2010
[21] K. Hasan, M. Rahman, A. Haque, A. Rahman, T. Rahman and M. Rasheed, Cost Effective GPS-
GPRS Based Object Tracking System, Lecture Notes in Engineering and Computer Science,
Vol.2174(1), 2009
[22] L. Tomaciello, L. Vito and S. Rapuano , One-Way Delay Measurement: State of Art,
Instrumentation and Measurement Technology Conference, 2006. Proceedings of the IEEE,
ISSN:1091-5281, 24-27, 2006
[23] A. Elminaam and A. Kader, Performance Evaluation of Symmetric Encryption Algorithms,
Communications of the IBIMA Volume 8, ISSN: 1943-7765, 2009
[24] E. Biham and A. Biryukov, An improvement of Davies attack on DES, Journal Of Cryptology
Vol.10(3), pp.195-205, 1997
61
62
A. Annexes
A.1 Tracking Server database script
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
CREATE DATABASE IF NOT EXISTS `geocop_db` DEFAULT CHARACTER SET latin1 COLLATE
latin1_swedish_ci;
USE `geocop_db`;
CREATE TABLE IF NOT EXISTS `historyevents` (
`UserID` int(11) NOT NULL COMMENT 'Target/trigger of event',
`TimeStamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`TypeEvent` int(11) NOT NULL COMMENT '1ClearMap,2Mission,3Point,4FileIn,5FileOut',
`Latitude` int(11) NOT NULL,
`Longitude` int(11) NOT NULL,
`Confirmed` bit(1) NOT NULL COMMENT '1 if Terminal Received',
`data` varchar(200) DEFAULT NULL COMMENT 'store additional data for the event. eg: File,
filepath where it was stored',
KEY `UserID` (`UserID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Contains all events, georeferenced';
CREATE TABLE IF NOT EXISTS `historystatus` (
`UserID` int(11) NOT NULL,
`Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT
'Timestamp from the packet received (not local timestamp from server)',
`Latitude` int(11) NOT NULL,
`Longitude` int(11) NOT NULL,
`SOS` bit(1) NOT NULL,
`STOP` bit(1) NOT NULL,
`GPSfix` bit(1) NOT NULL,
`Battery` bit(1) NOT NULL,
KEY `UserID` (`UserID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Storage of terminal status along the time..';
CREATE TABLE IF NOT EXISTS `reports` (
`UserID` int(11) NOT NULL COMMENT 'UserID who submitted',
`Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT
'when happenned',
`Latitude` int(11) NOT NULL COMMENT 'where happenned (0 if not georeference)',
`Longitude` int(11) NOT NULL COMMENT 'where happenned (0 if not georeference)',
`v_plate` varchar(10) DEFAULT NULL COMMENT 'Vehicle plate',
`v_brand` varchar(20) DEFAULT NULL COMMENT 'vehicle brand (eg. toyota)',
`v_model` varchar(20) DEFAULT NULL COMMENT 'vehicle model (eg. corolla)',
`v_color` varchar(50) DEFAULT NULL COMMENT 'Color description of vehicle (eg. light blue
with black windows)',
`p_id` varchar(20) DEFAULT NULL COMMENT 'national ID of person',
`p_driverlicense` varchar(20) DEFAULT NULL COMMENT 'DrivelicenseNumber person',
`p_name` varchar(50) DEFAULT NULL COMMENT 'Name of person',
`Description` varchar(1000) DEFAULT NULL COMMENT 'Description of the report/event'
63
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS `rtstatus` (
`UserID` int(11) NOT NULL,
`Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`Latitude` int(11) NOT NULL,
`Longitude` int(11) NOT NULL,
`SOS` bit(1) NOT NULL,
`STOP` bit(1) NOT NULL,
`GPSfix` bit(1) NOT NULL,
`Battery` bit(1) NOT NULL,
PRIMARY KEY (`UserID`)
) ENGINE=MEMORY DEFAULT CHARSET=latin1 COMMENT='Real-Time Status of terminals (onMemmory)';
CREATE TABLE IF NOT EXISTS `server_config` (
`MaxNumVehicles` int(11) NOT NULL DEFAULT '100' COMMENT 'Max number of vehicles/terminals',
`TCP_subscription_port` int(11) NOT NULL DEFAULT '1000' COMMENT 'Subcription TCP port',
`UDP_limit_down` int(11) NOT NULL DEFAULT '2000' COMMENT 'minimum UDP port range',
`UDP_limit_up` int(11) NOT NULL DEFAULT '4000' COMMENT 'maximum UDP port range',
`TCP_limit_down` int(11) NOT NULL DEFAULT '2000' COMMENT 'minimum TCP port range',
`TCP_limit_up` int(11) NOT NULL DEFAULT '4000' COMMENT 'maximum TCP port range',
`TCP_timeOut` int(11) NOT NULL DEFAULT '5000' COMMENT 'Subscription TCP session timeout',
`cmd_Timeout` int(11) NOT NULL DEFAULT '10000' COMMENT 'Timeout for command (eg. Dispatch
mission, clearMap..)'
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Configuration of the GeocopServer';
CREATE TABLE IF NOT EXISTS `terminal_groups` (
`GroupID` int(11) NOT NULL,
`Name` varchar(20) NOT NULL,
`Description` varchar(50) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS `terminal_users` (
`UserID` int(11) NOT NULL,
`Secret` varchar(20) NOT NULL,
`GroupID` int(10) unsigned NOT NULL COMMENT 'ID of the group which user belongs to..
(terminal only belong to 1 group)',
`Name` varchar(20) NOT NULL COMMENT 'Name identifier for terminal',
`DateCreation` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Date(TiMEstamp) of
creation of the user',
`Description` varchar(500) NOT NULL COMMENT 'Description of the terminal (who belong to..,
the scope.. etc..)',
PRIMARY KEY (`UserID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT COMMENT='Terminal user/secret';
64
A.2 Risk map file (sample)
!1 Sunday
0030 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
0130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
1830 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
!2 Monday
0030 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
!3 Tuesday
0030 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
1330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
!4 Wednesday
1630 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
1830 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
!5 Thursday
1530 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
1630 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
1830 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
!6 Friday
2130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
!7 Saturday
0030 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
0130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
1630 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
1830 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2130 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
2330 40522757|-7276275|300|40531543|-7274387|500|40536762|7278378|150|40541980|-7281468|600
65
A.3 Performance bash script
#!/bin/bash
clear
printf "\n############################################################"
printf "\n## PERFOMANCE SCRIPT - IST 52860, Jose Almeida ##"
printf "\n############################################################\n"
printf "\n# Create TestDB<test_geocop_db>"
dbms=`mysql -u root -ptoor<test_geocop_db.sql&> /dev/null`
dbms=`mysql -u root -ptoor -e "show databases" | greptest_geocop_db`
sleep 1
if [ "$dbms" == "test_geocop_db" ]; then
printf "\t[OK]"
else
printf "[FAIL] \n#ERROR: No database detected...\n\n"
exit 0
fi
#create table...
printf "\n# Creating table PERFORMANCE on test_geocop_db"
dbms=`mysql -u root -ptoor<performance.sql`
sleep 1
if [ "$dbms" == "" ]; then
printf "\t[OK]"
else
printf "[FAIL] \n#ERROR: Creating PERFORMANCE table...\n\n"
exit 0
fi
#Config Server
printf "\n# Configuring server.... "
sql="INSERT INTO \`test_geocop_db\`.\`server_config\` (\`MaxNumVehicles\`,
\`TCP_subscription_port\`, \`UDP_limit_down\`, \`UDP_limit_up\`, \`TCP_limit_down\`,
\`TCP_limit_up\`, \`TCP_timeOut\`, \`cmd_Timeout\`) VALUES ('200', '1000', '2000', '60000',
'2000', '60000', '5000', '10000');"
`mysql -uroot -ptoor -e "$sql" &> /dev/null`
printf "\t[OK]"
#Generate 100 Test users
printf "\n# Generating 100 users. ID: 1-100 Pwd:Secret "
count=1
while [ $count -le 100 ]
do
sql="INSERT INTO \`test_geocop_db\`.\`terminal_users\` (\`UserID\`, \`Secret\`, \`GroupID\`,
\`Name\`, \`DateCreation\`, \`Description\`) VALUES ('$count', 'secret', '1', '1',
CURRENT_TIMESTAMP, '');"
`mysql -uroot -ptoor -e "$sql" &> /dev/null`
66
count=`expr $count + 1`
done
printf "\t[OK]"
printf "\n# Capturing resources consummed by OS on idle..."
count_init=0
mem_init=0
cpu_init=0
count_init=0
sum_mem_init=0
sum_cpu_init=0
#calmdown the system after DB operations...
sleep 5
while [ $count_init -lt 1 ]
do
#MEM
mem_init=`free | grepMem: | awk '{ print $3 }'`
sum_mem_init=`expr $mem_init + $sum_mem_init`
#CPU
#read last line head(c+4)
cpu_init=`iostat -c 2| head -n 10| tail -1| awk '{ print int($6) }'`
cpu_init=`expr $cpu_init + 0`
cpu_init=`expr 100 - $cpu_init`
sum_cpu_init=`expr $cpu_init + $sum_cpu_init`
count_init=`expr $count_init + 1`
done
#Calculate avg...
mem_init=`expr $sum_mem_init / $count_init`
cpu_init=`expr $sum_cpu_init / $count_init`
#Network
rx_init=`ifconfig eth0 |grep "RX bytes" | cut -d: -f2 | awk '{ print $1 }'`
rx_init=`expr $rx_init + 0`
tx_init=`ifconfig eth0 |grep "TX bytes" | cut -d: -f3 | awk '{ print $1 }'`
tx_init=`expr $tx_init + 0`
network_init=`expr $rx_init + $tx_init`
printf "\t[OK] \n\tAVG USED Memory: $mem_init (Kilobytes) \n\tAVG USED CPU by System:
$cpu_init(percent) \n\tNetwork(eth0): $network_init (bytes)\n\n"
printf "\n# Writing every (5 seconds) CPU, MEM and Total Traffic(eth0) (Excludes used
resources by System)\n"
67
mem=0
cpu=0
traffic=0
rx=0
tx=0
count=0
while true
do
#MEM
mem=`free | grepMem: | awk '{ print $3 }'`
mem=`expr $mem - $mem_init`
#CPU head(c+4)
cpu=`iostat -c 2| head -n 10| tail -1| awk '{ print int($6) }'`
cpu=`expr $cpu + 0`
cpu=`expr 100 - $cpu`
#echo $cpu
cpu=`expr $cpu - $cpu_init`
#Network
rx=`ifconfig eth0 |grep "RX bytes" | cut -d: -f2 | awk '{ print $1 }'`
rx=`expr $rx + 0`
tx=`ifconfig eth0 |grep "TX bytes" | cut -d: -f3 | awk '{ print $1 }'`
tx=`expr $tx + 0`
traffic=`expr $rx + $tx`
traffic=`expr $traffic - $network_init`
count=`expr $count + 1`
sql="INSERT INTO \`test_geocop_db\`.\`performance\` (\`TimeStamp\`, \`cpu\`, \`mem\`,
\`traffic\`) VALUES (CURRENT_TIMESTAMP, '$cpu', '$mem', '$traffic');"
mysql -uroot -ptoor -e "$sql"
done
exit 0
68
A.4 Network latency (testbed)
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_req=1 ttl=128 time=0.433 ms
64 bytes from 192.168.1.2: icmp_req=2 ttl=128 time=0.409 ms
64 bytes from 192.168.1.2: icmp_req=3 ttl=128 time=0.393 ms
64 bytes from 192.168.1.2: icmp_req=4 ttl=128 time=0.421 ms
64 bytes from 192.168.1.2: icmp_req=5 ttl=128 time=0.505 ms
64 bytes from 192.168.1.2: icmp_req=6 ttl=128 time=0.342 ms
64 bytes from 192.168.1.2: icmp_req=7 ttl=128 time=0.393 ms
64 bytes from 192.168.1.2: icmp_req=8 ttl=128 time=0.454 ms
64 bytes from 192.168.1.2: icmp_req=9 ttl=128 time=0.442 ms
64 bytes from 192.168.1.2: icmp_req=10 ttl=128 time=0.430 ms
64 bytes from 192.168.1.2: icmp_req=11 ttl=128 time=0.376 ms
64 bytes from 192.168.1.2: icmp_req=12 ttl=128 time=0.437 ms
64 bytes from 192.168.1.2: icmp_req=13 ttl=128 time=0.306 ms
64 bytes from 192.168.1.2: icmp_req=14 ttl=128 time=0.440 ms
64 bytes from 192.168.1.2: icmp_req=15 ttl=128 time=0.351 ms
64 bytes from 192.168.1.2: icmp_req=16 ttl=128 time=0.418 ms
64 bytes from 192.168.1.2: icmp_req=17 ttl=128 time=0.258 ms
64 bytes from 192.168.1.2: icmp_req=18 ttl=128 time=0.277 ms
64 bytes from 192.168.1.2: icmp_req=19 ttl=128 time=0.283 ms
64 bytes from 192.168.1.2: icmp_req=20 ttl=128 time=0.294 ms
64 bytes from 192.168.1.2: icmp_req=21 ttl=128 time=0.406 ms
64 bytes from 192.168.1.2: icmp_req=22 ttl=128 time=0.294 ms
64 bytes from 192.168.1.2: icmp_req=23 ttl=128 time=0.223 ms
64 bytes from 192.168.1.2: icmp_req=24 ttl=128 time=0.429 ms
64 bytes from 192.168.1.2: icmp_req=25 ttl=128 time=0.415 ms
64 bytes from 192.168.1.2: icmp_req=26 ttl=128 time=0.444 ms
64 bytes from 192.168.1.2: icmp_req=27 ttl=128 time=0.379 ms
64 bytes from 192.168.1.2: icmp_req=28 ttl=128 time=0.448 ms
64 bytes from 192.168.1.2: icmp_req=29 ttl=128 time=0.431 ms
64 bytes from 192.168.1.2: icmp_req=30 ttl=128 time=0.444 ms
64 bytes from 192.168.1.2: icmp_req=31 ttl=128 time=0.417 ms
64 bytes from 192.168.1.2: icmp_req=32 ttl=128 time=0.430 ms
64 bytes from 192.168.1.2: icmp_req=33 ttl=128 time=0.447 ms
64 bytes from 192.168.1.2: icmp_req=34 ttl=128 time=0.451 ms
64 bytes from 192.168.1.2: icmp_req=35 ttl=128 time=0.334 ms
64 bytes from 192.168.1.2: icmp_req=36 ttl=128 time=0.427 ms
64 bytes from 192.168.1.2: icmp_req=37 ttl=128 time=0.432 ms
64 bytes from 192.168.1.2: icmp_req=38 ttl=128 time=0.438 ms
64 bytes from 192.168.1.2: icmp_req=39 ttl=128 time=0.271 ms
64 bytes from 192.168.1.2: icmp_req=40 ttl=128 time=0.407 ms
64 bytes from 192.168.1.2: icmp_req=41 ttl=128 time=0.265 ms
64 bytes from 192.168.1.2: icmp_req=42 ttl=128 time=0.372 ms
64 bytes from 192.168.1.2: icmp_req=43 ttl=128 time=0.307 ms
64 bytes from 192.168.1.2: icmp_req=44 ttl=128 time=0.224 ms
64 bytes from 192.168.1.2: icmp_req=45 ttl=128 time=0.372 ms
64 bytes from 192.168.1.2: icmp_req=46 ttl=128 time=0.400 ms
64 bytes from 192.168.1.2: icmp_req=47 ttl=128 time=0.365 ms
64 bytes from 192.168.1.2: icmp_req=48 ttl=128 time=0.431 ms
64 bytes from 192.168.1.2: icmp_req=49 ttl=128 time=0.428 ms
64 bytes from 192.168.1.2: icmp_req=50 ttl=128 time=0.434 ms
64 bytes from 192.168.1.2: icmp_req=51 ttl=128 time=0.428 ms
64 bytes from 192.168.1.2: icmp_req=52 ttl=128 time=0.420 ms
64 bytes from 192.168.1.2: icmp_req=53 ttl=128 time=0.427 ms
64 bytes from 192.168.1.2: icmp_req=54 ttl=128 time=0.444 ms
64 bytes from 192.168.1.2: icmp_req=55 ttl=128 time=0.424 ms
64 bytes from 192.168.1.2: icmp_req=56 ttl=128 time=0.424 ms
64 bytes from 192.168.1.2: icmp_req=57 ttl=128 time=0.433 ms
64 bytes from 192.168.1.2: icmp_req=58 ttl=128 time=0.432 ms
64 bytes from 192.168.1.2: icmp_req=59 ttl=128 time=0.285 ms
64 bytes from 192.168.1.2: icmp_req=60 ttl=128 time=0.399 ms
--- 192.168.1.2 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 58997ms
rtt min/avg/max/mdev = 0.223/0.389/0.505/0.065 ms
69
A.5 NTP offset
host hostname # ntpdate 192.168.1.1
18 Apr 22:11:06 ntpdate[4020]: adjust time server 192.168.1.1 offset -0.000268 sec
host hostname # ntpdate 192.168.1.1
18 Apr 22:11:29 ntpdate[4021]: adjust time server 192.168.1.1 offset -0.000150 sec
70
A.6 Data extraction shell script
#!/bin/bash
clear
printf "\n############################################################"
printf "\n## Xstract TEST data - IST 52860, Jose Almeida ##"
printf "\n############################################################\n"
if [ "$1" = "" ]; then
echo "ERORR: No Filename to extract data.... (usage example: $0 no_security_UDP_1)"
exit 0
fi
printf "\n# ATTENTION: test_performance.sh will be killed... in 3 seconds (Cr^c to abort)"
sleep 3
`killall -9 test_performance.sh`
sleep 3
printf "\n#1 Creating table $1 (CPU,MEM,Traffic, Delay)"
#1 Create table performance
myq="CREATE TABLE $1_raw AS (SELECT performance.*, rtstatus.Timediff FROM performance INNER
JOIN rtstatus ON performance.TimeStamp = rtstatus.test_Timestamp);"
#echo $myq
dbms=`mysql -u root -ptoortest_geocop_db -e "$myq"`
sleep 1
printf "\t[OK]\n"
#2 Agg data (put aggregate by 30s interval)
printf "\n#2 1 Agg Data... Time Interval (30seconds)"
myq="SELECT 0 INTO @x; CREATE TABLE $1 AS (SELECT (@x:=@x+1) as
clients,avg(cpu),avg(mem),avg(Timediff),traffic FROM $1_raw GROUP BY (TimeStamp div 50));"
dbms=`mysql -u root -ptoortest_geocop_db -e "$myq"`
sleep 1
printf "\t[OK]\n"
#3 Extracting file...
printf "\n# Extracting (CPU,MEM,Traffic and Delay) to $1.sql "
dump=`mysqldump -uroot -ptoortest_geocop_db $1_raw $1 > $1.sql`
sleep 1
printf "\t[OK]\n"
printf "\nFile created succefully -> $1.sql \t[DONE]\n"
exit 0
71
A.7 No security (Security.java)
public class Security {
private String secret;
private String IVsecret;
public Security(String secret, String IVsecret) throws Exception {
this.secret=secret;
this.IVsecret=IVsecret;
}
public static byte[] encrypt(byte[] input) throws Exception {
return input;
}
public static byte[] decrypt(byte[] cipherText) {
return cipherText;
}
}
72
A.8 Encryption only (Security.java)
public class Security {
private static final String ALGORITHM = "DES/CBC/PKCS5Padding";
private byte[] keyValue = new byte[] { '1', '2', '3', '4', '5', '6', '7','8' };
private byte[] IVkey = new byte[] { '1', '2', '3', '4', '5', '6', '7','8' };
static Key key =null;
static IvParameterSpecivSpec=null;
static Cipher cipher=null;
private String secret;
private String IVsecret;
public Security(String secret, String IVsecret) throws Exception {
java.security.Security.addProvider(new BouncyCastleProvider());
this.secret=secret;
this.IVsecret=IVsecret;
setSecret(keyValue, secret);
setSecret(IVkey, IVsecret);
cipher = Cipher.getInstance(ALGORITHM);
ivSpec = new IvParameterSpec(IVkey);
key = new SecretKeySpec(keyValue, ALGORITHM);
}
public static byte[] encrypt(byte[] input) throws Exception {
cipher.init(Cipher.ENCRYPT_MODE, key, ivSpec);
byte[] result = cipher.doFinal(input);
return result;
}
public static byte[] decrypt(byte[] cipherText) throws InvalidAlgorithmParameterException,
InvalidKeyException {
try {
cipher.init(Cipher.DECRYPT_MODE, key, ivSpec);
byte[] plainText = cipher.doFinal(cipherText);
return plainText;
} catch (IllegalBlockSizeException ex) {
return null;
} catch (BadPaddingException ex) {
73
return null;
}
}
public void setSecret(byte[] defaultkey,String secret) {
for(inti=0; i<defaultkey.length; i++) {
if(secret.length()>i) defaultkey[i] = (byte) secret.charAt(i);
}
}
}
74
A.9 Encryption + Mac (Security.java)
public class Security {
private static final String ALGORITHM = "DES/CBC/PKCS5Padding";
private byte[] keyValue = new byte[] { '1', '2', '3', '4', '5', '6', '7','8' };
private byte[] IVkey = new byte[] { '1', '2', '3', '4', '5', '6', '7','8' };
static Key key =null;
static IvParameterSpecivSpec=null;
static Cipher cipher=null;
private String secret;
private String IVsecret;
static Mac mac;
public Security(String secret, String IVsecret) throws Exception {
java.security.Security.addProvider(new BouncyCastleProvider());
this.secret=secret;
this.IVsecret=IVsecret;
setSecret(keyValue, secret);
setSecret(IVkey, IVsecret);
cipher = Cipher.getInstance(ALGORITHM);
ivSpec = new IvParameterSpec(IVkey); //createCtrIvForAES(1, random);
key = new SecretKeySpec(keyValue, ALGORITHM); //Key key = createKeyForAES(256, random);
//MAC
mac = Mac.getInstance("DES");
mac.init(key);
}
public static byte[] encrypt(byte[] input) throws Exception {
cipher.init(Cipher.ENCRYPT_MODE, key, ivSpec);
//MAC
byte[] dataHash;
dataHash = mac.doFinal(input);
byte[] inputFinal = new byte[input.length + dataHash.length];
System.arraycopy(input, 0, inputFinal, 0, input.length);
System.arraycopy(dataHash, 0, inputFinal, input.length, dataHash.length);
byte[] result = cipher.doFinal(inputFinal);
return result;
}
75
public static byte[] decrypt(byte[] cipherText) throws InvalidAlgorithmParameterException,
InvalidKeyException {
try {
cipher.init(Cipher.DECRYPT_MODE, key, ivSpec);
byte[] plainText = cipher.doFinal(cipherText);
intmessageLength = plainText.length - mac.getMacLength();
byte[] messageHash = new byte[mac.getMacLength()];
byte[] originalData=new byte[messageLength];
System.arraycopy(plainText, 0, originalData, 0, messageLength);
System.arraycopy(plainText, messageLength, messageHash, 0, messageHash.length);
byte[] localHash = new byte[mac.getMacLength()];
localHash = mac.doFinal(originalData);
if( Arrays.equals(localHash, messageHash) ) {
return originalData;
}
return null;
} catch (IllegalBlockSizeException ex) {
return null;
} catch (BadPaddingException ex) {
return null;
}
}
public void setSecret(byte[] defaultkey,String secret) {
for(inti=0; i<defaultkey.length; i++) {
if(secret.length()>i) defaultkey[i] = (byte) secret.charAt(i);
}
}
}
76
A.10 CPU values
TCP UDP UDP (DES) UDP(DES+MAC)
AVG DEV AVG DEV AVG DEV AVG DEV #Clients
3.75 0.26 4.38 0.29 5.60 0.09 6.85 0.70 1
3.56 0.29 5.20 0.30 6.48 0.44 8.29 0.76 2
3.10 0.29 3.70 0.26 4.59 0.45 5.60 0.52 3
2.60 0.57 3.55 0.36 4.53 0.79 5.42 0.50 4
2.59 0.34 3.44 0.19 4.50 0.46 5.13 0.48 5
2.34 0.45 3.37 0.07 3.88 0.38 5.24 0.24 6
2.41 0.40 3.48 0.18 4.09 0.37 4.70 0.35 7
2.65 0.30 3.30 0.48 3.52 0.31 4.24 0.35 8
2.55 0.16 2.90 0.40 3.93 0.17 4.27 0.18 9
3.64 0.59 4.85 0.66 4.28 0.35 8.50 0.60 10
3.18 0.86 4.05 0.67 4.07 0.48 5.44 0.38 11
3.03 0.84 3.60 0.35 3.84 0.24 5.07 0.24 12
3.11 0.50 4.21 0.57 4.76 0.34 5.79 0.60 13
3.91 0.31 5.78 0.75 5.60 1.71 7.78 0.62 14
3.47 0.50 4.34 0.48 5.93 0.63 7.36 0.21 15
4.00 0.32 6.20 0.97 7.10 1.22 8.58 0.79 16
4.41 0.39 6.80 0.29 8.62 0.70 9.90 0.38 17
5.39 0.87 6.17 0.22 7.72 0.37 8.87 0.73 18
4.38 0.38 6.92 0.55 8.33 0.91 10.34 0.51 19
4.24 0.59 6.31 0.91 6.66 0.30 6.75 0.31 20
5.01 0.86 6.72 0.78 9.16 0.96 10.15 0.36 21
5.07 0.86 6.61 0.79 7.45 0.54 7.58 0.95 22
5.50 0.55 7.75 1.04 10.05 0.79 10.73 1.35 23
5.62 1.08 6.16 0.14 8.53 1.38 9.75 0.78 24
5.93 0.71 7.14 1.11 9.44 0.41 10.68 0.26 25
6.49 1.76 9.43 1.06 13.43 1.76 15.16 0.48 26
6.62 1.27 8.47 1.03 11.97 0.95 14.02 1.04 27
6.62 0.78 9.15 0.73 12.09 0.82 13.03 0.86 28
6.28 1.24 9.74 1.13 11.76 1.61 14.41 0.38 29
7.43 1.25 10.91 1.65 14.37 0.26 18.39 0.96 30
6.92 1.76 9.72 0.70 12.55 0.97 18.38 0.46 31
7.35 0.69 10.20 1.22 12.06 0.87 13.06 1.95 32
8.37 0.80 10.35 0.86 14.31 2.11 17.36 2.56 33
6.54 1.41 11.14 0.99 12.81 1.32 14.90 0.65 34
7.82 0.62 10.08 0.85 13.68 2.48 19.48 0.87 35
6.67 0.67 10.33 0.76 12.50 1.25 14.48 1.29 36
6.74 1.16 10.23 1.03 13.51 0.94 18.09 0.39 37
8.79 0.62 13.07 2.39 13.01 1.33 21.93 4.79 38
8.26 0.60 11.83 1.54 13.03 0.84 15.69 0.36 39
9.24 0.73 13.26 1.06 17.40 1.48 17.95 0.94 40
10.09 0.49 13.73 1.52 16.78 0.59 21.49 2.12 41
9.51 0.68 14.22 0.55 17.97 1.20 17.71 3.34 42
8.19 0.71 12.92 0.92 15.65 1.61 17.75 2.69 43
8.40 0.69 12.23 0.67 15.38 1.33 15.89 0.86 44
8.61 0.65 11.31 1.37 15.17 1.14 18.23 1.46 45
9.32 0.86 15.23 1.22 20.14 1.30 24.15 0.98 46
9.40 1.17 14.17 2.01 17.88 2.42 18.83 1.79 47
8.29 1.09 12.68 0.59 15.81 1.73 16.90 2.49 48
10.73 0.89 14.01 1.09 17.84 1.88 20.70 2.90 49
9.81 1.79 12.83 0.85 14.99 2.38 17.25 1.15 50
9.97 0.70 13.87 0.96 17.55 1.47 16.32 1.28 51
8.49 1.55 13.44 2.14 15.00 0.72 16.62 1.03 52
11.35 1.05 15.88 0.74 19.71 1.34 23.22 0.72 53
10.47 1.10 16.46 0.18 19.77 2.12 28.59 2.28 54
10.33 1.70 16.08 1.09 19.36 1.46 23.30 1.92 55
13.81 2.19 20.00 1.37 24.26 3.04 22.96 1.22 56
11.57 1.93 16.95 0.97 22.58 2.25 26.43 0.88 57
13.95 1.14 19.68 2.18 26.46 3.62 31.42 3.55 58
11.98 0.79 17.05 1.13 20.81 2.20 20.60 1.19 59
11.58 1.44 17.85 1.07 21.46 3.05 26.34 0.59 60
14.34 1.80 18.47 0.42 24.25 2.94 33.51 0.75 61
12.79 2.35 18.64 1.01 22.46 2.63 23.76 1.66 62
13.53 1.85 18.39 1.63 22.43 2.87 25.90 1.90 63
12.87 2.46 15.95 1.74 20.42 1.49 25.99 2.77 64
13.55 1.52 18.56 1.64 24.11 3.92 33.70 3.81 65
16.18 1.38 19.70 1.32 25.30 1.91 30.56 5.40 66
14.15 2.67 19.67 2.35 23.11 1.29 26.19 4.43 67
16.62 1.65 19.16 1.17 32.71 2.84 38.78 1.73 68
15.49 3.70 20.19 1.35 26.07 0.82 30.92 0.41 69
17.88 2.54 24.47 1.70 26.63 2.04 29.43 1.50 70
16.15 3.59 22.62 1.00 25.42 3.41 28.32 2.27 71
77
16.20 1.42 21.82 1.39 25.01 2.17 28.99 2.04 72
13.88 3.27 22.29 1.12 26.43 3.44 33.41 1.47 73
15.38 1.62 22.11 1.19 27.09 3.27 39.25 3.62 74
14.57 3.29 23.01 1.60 29.12 4.61 31.34 2.21 75
16.48 1.24 23.54 0.89 28.97 4.30 34.69 4.78 76
16.01 2.60 23.68 1.01 27.87 3.41 38.54 2.18 77
15.08 2.79 23.54 2.47 30.11 1.03 29.06 4.04 78
17.21 1.64 24.95 2.38 27.11 2.03 29.35 3.94 79
14.14 2.41 20.16 1.89 26.40 1.82 29.13 2.10 80
15.99 2.67 22.28 1.11 29.96 3.63 28.95 4.32 81
18.20 2.22 25.25 1.73 34.59 2.20 35.00 1.00 82
16.51 3.55 24.55 2.38 31.57 3.35 36.73 4.98 83
19.37 1.72 28.07 2.14 37.27 3.16 41.44 4.14 84
16.18 4.34 25.16 0.79 37.92 3.37 36.75 3.53 85
16.37 1.55 24.46 1.85 27.44 2.31 31.50 3.19 86
20.18 2.10 25.71 2.31 32.89 3.69 37.39 1.96 87
20.67 1.74 26.75 2.46 36.71 3.95 30.69 1.74 88
18.57 2.28 25.69 2.53 29.45 1.46 41.84 3.44 89
20.31 3.84 30.56 2.94 36.95 1.07 42.15 0.75 90
19.53 3.16 25.98 1.53 29.76 2.06 37.77 2.53 91
22.94 1.44 29.88 1.18 36.84 4.32 36.86 3.11 92
19.88 3.32 27.94 1.02 33.17 3.96 39.16 2.87 93
22.34 1.84 26.43 0.94 34.21 1.81 39.03 2.44 94
23.19 2.32 26.79 1.92 29.81 3.92 43.91 3.50 95
24.07 0.98 28.38 0.62 35.23 2.91 38.90 1.91 96
21.64 3.71 27.94 1.61 36.53 1.82 40.27 4.09 97
22.34 3.28 28.04 1.53 34.33 2.57 39.58 3.50 98
23.11 1.44 30.87 1.75 36.49 3.96 45.24 5.43 99
24.90 1.26 32.73 2.52 40.93 6.00 43.70 11.99 100
78
A.11 Memory values
TCP UDP UDP (DES) UDP(DES+MAC)
AVG DEV AVG DEV AVG DEV AVG DEV #Clients
64742 5531 61834 2567 80977 6975 77735 7556 1
67835 3427 66971 2719 86168 4960 84530 3643 2
69461 1735 68486 1029 89638 6660 86738 4934 3
70222 1700 69052 933 92291 6465 92021 5553 4
70897 1689 69456 812 97140 3379 98359 7821 5
71636 1845 69879 842 100141 3395 101690 4259 6
72445 1851 70482 721 100017 2228 100093 3733 7
73112 2146 71083 552 102222 3865 101304 4557 8
73809 2245 71431 681 102177 2833 102075 4522 9
74569 1993 71904 794 104250 5189 104955 5560 10
75050 1958 73303 1317 105594 3816 105543 5250 11
75372 1942 74848 1125 108181 2421 107681 7034 12
76109 1520 75724 491 111336 3002 110457 5173 13
77086 1810 76304 372 114667 4778 110788 5144 14
78080 2228 76874 630 114493 4455 112738 4179 15
78847 2539 77455 803 116620 2577 117265 7381 16
79824 2523 79709 1683 120317 3755 119203 5631 17
81283 3720 81459 1225 123307 5542 119216 5053 18
81739 3564 82593 1330 125807 6305 121003 6130 19
83276 3578 85233 1534 131051 9554 124966 7378 20
84560 3507 86464 838 136735 9014 129705 8088 21
86447 4261 87344 608 144417 10604 136263 7892 22
87521 4230 88614 727 149141 6297 142064 8429 23
88404 4443 90903 1575 155250 6249 155773 9746 24
89606 4476 92618 861 157159 5621 162235 5874 25
90454 4679 93876 739 158292 5363 164188 7389 26
91496 3854 96009 1532 157803 3125 165641 5236 27
92481 3970 97393 1751 158576 3564 167386 7893 28
93694 4120 98369 1590 160466 4569 168724 6341 29
95757 4300 99934 982 162604 6158 168218 6517 30
96614 4212 100916 1034 162166 4501 171707 6875 31
97516 4416 102029 1043 164681 5895 172239 4199 32
98888 4184 103006 1024 164829 5390 174576 6732 33
100111 4350 104236 1092 166773 5312 177869 4299 34
100895 4823 105349 1023 168784 6015 180703 4721 35
102119 4975 106627 1112 168475 4446 181964 4312 36
103144 4579 107675 1070 171371 7339 183184 6462 37
104422 5164 108888 1058 170215 5494 187951 8177 38
105475 5444 110040 1132 173595 8174 187799 6796 39
106600 5415 111250 1124 174392 6493 190824 8220 40
108075 6242 112550 1343 175651 6827 191292 5161 41
108389 5494 113929 1369 176893 7885 199460 6575 42
109202 5658 115221 1259 178984 8993 203841 9048 43
110183 5953 116502 1515 183719 9555 207384 12796 44
110908 4097 117851 1207 187809 11407 211633 16918 45
111597 3564 119148 1126 191489 12888 217387 22465 46
113032 4156 120623 1307 196948 15802 222778 25837 47
114637 4631 122104 1257 203684 19718 225620 28858 48
115422 5153 123292 1323 208699 23500 230758 30558 49
116560 5613 124529 1345 213946 26100 233784 33282 50
117571 5848 125917 1394 218728 29944 235369 32321 51
118834 6300 127274 1582 224722 33725 239117 33460 52
119676 6684 128386 1516 224721 32465 240800 32907 53
120819 7400 129759 1377 226522 33745 244534 34553 54
121589 7430 130770 1596 227963 31906 246097 34259 55
122439 7180 131842 1149 227181 32624 249773 32064 56
122896 6614 133384 1431 230208 31744 251947 31375 57
123871 6892 134748 1479 229882 30364 256264 34856 58
123898 6378 136070 1452 232043 31703 257722 34113 59
124238 5188 137309 1357 232538 32323 262195 33376 60
125403 5934 138819 1475 229949 31430 266887 28992 61
126662 6367 140360 1327 231808 32608 266450 31440 62
127244 7214 141835 1578 232410 32572 270835 33385 63
128177 7870 143454 1391 235271 32537 271426 33682 64
129444 8452 144947 1443 234290 31724 274177 32179 65
130364 9193 146554 1371 236273 31012 276279 32916 66
131605 10288 148113 1432 236975 31186 281180 34439 67
132945 11256 149606 1436 236722 33217 281681 35667 68
133947 12202 151707 1501 239075 31866 285310 35054 69
135374 12756 153624 1404 237239 32538 289234 35848 70
136459 13480 155117 1652 238908 32648 289071 37737 71
79
137439 12872 157102 1474 240148 34665 294189 40946 72
138354 14056 158692 1571 241640 33334 296194 39617 73
140133 14691 160611 1522 240834 31757 301355 38155 74
139625 12722 162392 1696 241247 32030 304295 40793 75
140209 10961 164380 1950 242361 32543 304723 43174 76
141151 12129 166130 1700 243993 31082 309646 42344 77
142669 12936 168093 1672 244407 34428 311333 39572 78
143616 13915 169991 1412 247235 32752 314708 38564 79
145283 14745 171380 1400 246532 33219 318194 38876 80
146691 15916 172206 1198 246677 32784 321836 40810 81
148239 16425 172360 1037 248988 34268 321261 41656 82
149511 17300 173173 1285 249326 35263 328689 39981 83
150576 17439 173952 1234 249838 33648 326253 40746 84
151531 17750 174737 990 250346 35656 330987 42279 85
152857 17659 175466 999 250793 34241 334035 39773 86
153020 16538 176267 1085 252829 33296 337751 39986 87
154289 16065 177193 1163 254711 35954 343244 37828 88
154623 15235 177799 1464 255126 34535 342993 40982 89
155449 14028 178411 1424 254688 34350 350636 39185 90
156292 14398 179404 1358 252950 33626 350132 40964 91
157625 14526 180478 1350 255898 34089 351277 35999 92
158836 14893 181542 1286 253568 32784 353032 38349 93
160282 15184 182300 1089 254990 31550 353226 37171 94
161512 15855 183214 1254 256820 32502 355432 37447 95
162907 16510 184544 1240 257141 32401 359461 38631 96
163395 15367 185364 1452 256510 31784 361114 36091 97
164654 15746 186501 1438 258565 31594 360557 36025 98
164897 15642 187184 1424 258406 33016 366777 36008 99
171579 18712 187806 1477 258116 34400 363007 36192 100
80
A.12 Maximum status delay values
TCP UDP UDP (DES) UDP(DES+MAC)
AVG DEV AVG DEV AVG DEV AVG DEV #Clients
171.33 87.50 129.01 96.07 131.92 52.94 136.60 104.02 1
158.90 27.95 112.60 107.15 148.35 63.57 211.29 69.91 2
183.55 102.52 154.59 101.52 132.53 45.13 168.88 59.44 3
199.30 99.31 200.00 96.80 175.42 50.23 222.10 55.99 4
224.11 96.03 227.91 104.89 178.45 58.97 207.94 49.52 5
215.75 118.34 221.40 55.56 194.36 57.36 210.13 57.02 6
220.29 114.60 230.44 67.60 208.85 60.45 237.35 45.88 7
214.79 101.72 253.20 66.37 194.28 50.27 217.35 44.63 8
204.25 120.77 255.35 56.18 227.92 39.33 227.08 50.03 9
207.14 121.79 261.50 54.98 231.10 40.78 212.09 25.23 10
231.38 111.64 253.68 39.70 234.18 36.70 223.76 35.37 11
193.70 122.62 252.80 36.07 235.80 24.90 221.39 35.10 12
216.38 99.01 259.93 24.23 235.18 40.49 221.92 43.67 13
245.03 92.35 255.80 29.84 255.56 35.14 217.68 44.34 14
216.72 109.91 260.96 20.74 250.73 21.87 239.75 37.82 15
213.98 133.64 265.00 19.42 248.96 24.17 206.87 22.49 16
240.08 107.21 260.88 25.11 256.99 26.31 204.15 30.44 17
209.23 109.53 259.00 31.61 257.41 27.75 204.13 24.47 18
224.75 115.47 258.10 36.55 260.20 21.91 210.97 43.28 19
241.08 116.63 254.80 47.54 246.57 40.92 228.79 38.08 20
223.13 103.52 251.70 42.06 256.25 33.64 205.36 22.25 21
256.58 99.25 250.30 43.25 263.86 27.89 213.91 32.06 22
233.62 97.94 252.63 44.80 243.26 43.87 199.82 23.37 23
243.95 86.22 252.00 47.18 254.13 34.37 209.96 33.23 24
232.39 102.14 251.93 48.29 262.80 27.59 191.54 21.69 25
228.83 98.15 255.60 43.42 253.84 25.81 225.30 45.15 26
232.95 111.70 250.49 48.89 256.87 45.44 230.53 38.81 27
227.55 103.49 254.20 46.22 263.63 29.70 215.51 30.83 28
247.28 96.58 253.04 45.01 260.56 35.13 218.14 37.83 29
223.95 102.17 251.90 44.13 257.82 34.47 189.73 12.70 30
240.80 103.03 253.11 46.14 256.67 43.05 219.46 32.90 31
239.45 97.77 252.50 48.44 250.95 38.58 255.11 37.59 32
247.37 95.25 254.18 45.75 244.70 47.34 218.04 37.11 33
233.76 97.77 253.00 46.90 247.52 46.73 206.59 27.34 34
238.01 100.21 252.85 45.29 263.19 39.80 214.17 44.87 35
234.56 97.59 252.50 44.08 254.73 35.46 214.45 30.03 36
248.94 90.70 251.48 44.36 261.04 33.43 202.36 29.56 37
221.50 100.76 253.60 46.03 268.54 25.85 211.01 45.42 38
244.13 94.87 250.48 44.86 257.10 50.00 228.82 42.30 39
253.10 93.96 254.20 46.15 241.67 33.58 200.27 42.95 40
242.63 97.58 252.68 45.45 262.44 40.20 227.56 44.73 41
243.15 103.36 253.50 46.24 205.87 75.39 194.33 31.46 42
245.93 97.22 250.25 45.02 257.16 41.59 218.01 38.04 43
249.60 92.86 252.20 45.69 232.60 53.13 199.13 47.08 44
244.32 94.80 250.46 46.12 237.94 44.92 193.53 36.40 45
230.48 110.26 250.10 48.40 242.18 52.51 194.60 27.91 46
248.94 91.40 250.85 47.17 245.72 46.18 215.67 37.59 47
243.47 101.66 251.90 45.34 242.57 45.10 189.57 24.92 48
243.29 94.41 251.18 46.62 253.57 45.51 222.17 38.73 49
242.75 89.91 250.30 46.12 244.18 35.06 218.12 34.50 50
248.80 92.25 250.17 46.18 255.25 32.93 215.90 45.05 51
243.70 103.12 252.40 45.60 260.74 36.01 226.65 44.49 52
244.60 91.77 250.77 45.19 243.38 44.67 194.43 16.01 53
252.05 86.08 248.70 44.29 261.22 27.68 213.15 35.24 54
251.98 89.79 249.93 45.09 263.72 39.94 201.58 32.46 55
257.13 88.88 247.80 46.14 241.09 47.97 214.16 37.70 56
252.08 92.26 248.55 44.94 245.95 37.75 225.11 43.85 57
251.53 80.62 250.10 46.84 241.95 49.80 218.42 37.37 58
250.14 95.14 249.45 45.61 244.68 28.89 214.39 37.28 59
251.13 92.80 248.40 43.76 235.52 46.18 232.20 48.44 60
249.50 90.18 247.35 45.93 254.71 32.03 218.51 42.49 61
245.15 99.99 249.10 46.48 230.25 37.82 198.98 22.38 62
252.79 89.28 248.58 44.71 262.33 25.84 233.15 55.59 63
252.43 91.01 249.80 44.70 251.47 38.17 212.99 36.67 64
250.53 91.04 248.11 44.01 264.23 23.36 229.73 61.18 65
244.63 96.34 247.40 43.53 242.52 73.48 212.70 36.10 66
248.73 93.59 248.12 44.34 241.25 35.13 202.96 34.83 67
249.00 92.96 248.40 45.11 236.30 39.58 211.25 31.91 68
249.45 91.42 247.46 43.17 240.02 44.22 202.12 25.30 69
247.70 98.30 244.60 43.82 264.12 30.05 218.78 43.07 70
251.57 88.77 246.55 45.23 254.42 44.86 193.67 29.45 71
81
247.76 97.50 244.20 46.57 242.45 39.63 199.53 27.71 72
246.40 94.73 245.20 44.59 247.16 33.34 228.74 38.41 73
246.96 99.09 244.00 46.02 247.47 44.94 212.31 47.01 74
247.94 92.67 245.91 45.50 251.27 43.67 211.50 26.29 75
245.55 96.24 245.30 45.93 258.09 29.64 207.05 26.20 76
238.28 102.44 245.76 45.34 229.67 56.81 202.35 18.53 77
243.63 97.94 246.40 44.06 267.28 27.29 201.15 19.01 78
251.88 90.41 245.77 44.04 255.52 34.97 232.65 36.20 79
247.20 91.85 243.40 43.88 232.26 38.60 228.61 30.66 80
247.88 93.29 244.21 45.23 242.61 24.55 222.52 24.05 81
249.70 94.10 246.40 44.62 232.43 34.66 242.14 23.50 82
242.03 97.82 244.48 43.54 235.85 37.12 216.93 32.12 83
247.20 93.48 244.70 45.27 254.23 25.83 232.66 40.79 84
251.76 88.03 245.08 43.28 257.96 21.92 250.31 18.70 85
246.71 90.15 242.90 45.27 215.45 61.21 200.75 36.17 86
240.35 101.41 243.49 45.08 218.32 52.76 223.76 46.52 87
250.53 90.10 244.20 45.30 212.32 42.57 212.23 26.10 88
245.33 94.30 243.59 45.50 235.70 33.52 246.80 24.66 89
246.83 92.21 240.30 41.89 215.21 39.39 207.26 10.52 90
250.33 87.82 241.35 43.59 214.38 47.36 208.03 24.45 91
244.65 94.34 244.20 44.45 221.85 63.50 204.86 41.53 92
246.93 88.27 241.80 44.72 197.47 71.03 198.40 29.63 93
245.75 90.01 242.60 45.55 237.07 51.15 209.88 18.69 94
248.78 87.93 242.40 43.01 235.50 50.94 206.65 18.22 95
247.00 92.36 241.40 42.99 226.68 50.04 210.16 17.02 96
244.54 88.70 241.78 43.53 252.53 27.52 243.26 47.03 97
244.67 91.71 239.40 41.05 240.29 31.04 229.01 13.54 98
236.35 86.18 240.06 45.58 252.97 22.78 216.59 45.72 99
258.10 74.38 242.30 41.71 238.19 37.46 233.47 31.91 100
82
A.13 Network traffic values
TCP UDP UDP (DES) UDP(DES+MAC)
AVG DEV AVG DEV AVG DEV AVG DEV #Clients
20292 18784 2508 280 2346 6 2863 339 1
37661 36690 11810 3814 9581 37 5677 2046 2
46246 39685 15174 4604 12988 24 20483 4428 3
86158 53358 37434 7562 37145 119 27442 5040 4
97326 56594 43726 7722 40617 82 56374 9606 5
153958 67368 79121 10360 82368 138 67555 7645 6
175869 63339 88741 10875 87759 99 109190 13727 7
240451 84974 137072 13545 135807 300 124323 6809 8
267969 79302 149700 14095 152274 557 175250 17148 9
347837 105129 209340 16014 214241 602 198855 7977 10
377353 92127 226358 17082 234758 760 263624 21831 11
472844 126700 297926 19727 312056 941 294395 11269 12
510200 112498 316813 21712 333219 1015 365381 25663 13
614342 146161 402833 22835 427972 1182 405646 16309 14
664762 134318 416482 24840 451763 753 489082 31873 15
783464 173888 523689 25904 558248 1672 535129 22414 16
840504 162607 539669 27409 585319 1820 633281 42095 17
973416 206173 652313 32769 708963 2542 672839 30285 18
1034741 198341 675604 29617 723654 2177 797464 61648 19
1179471 238920 800675 33086 876515 2772 838658 34295 20
1247894 224846 829854 32820 891774 2989 956111 56894 21
1412181 272673 963746 34552 1040290 2608 1014034 37800 22
1475219 249157 1000015 36031 1076786 2987 1148858 64413 23
1657527 310642 1146579 37656 1239967 4680 1204834 38639 24
1731006 283364 1186049 39286 1282252 3047 1359990 78414 25
1925948 342511 1345131 40998 1462277 2137 1430468 43412 26
2011257 319549 1375318 48728 1503754 7117 1596857 92017 27
2213887 374527 1559388 44401 1697457 4404 1663254 69417 28
2312190 359232 1585940 47103 1742477 6671 1837479 110440 29
2528324 411916 1774462 54612 1948608 5240 1908836 71191 30
2634534 393195 1813512 48202 1970815 7351 2104298 123477 31
2863985 444005 2014384 53565 2211745 3933 2166065 77358 32
2961444 436958 2061011 51384 2238720 7989 2387055 137353 33
3210207 483734 2274967 56635 2476799 5775 2442188 82884 34
3313744 466089 2324086 54607 2530331 9805 2662089 158375 35
3577711 534839 2545593 57415 2767978 9568 2742414 98082 36
3687046 500396 2603111 57475 2830766 9407 2993431 175107 37
3956174 564838 2836419 61872 3083145 12016 3100637 135819 38
4078321 545155 2886257 61180 3156801 8421 3293451 156359 39
4360826 604260 3144192 64940 3419522 8184 3406335 102320 40
4498866 596088 3182802 69241 3496839 7927 3650954 185339 41
4795174 656621 3460731 74037 3952122 16273 3816149 156892 42
4939999 649533 3500610 69225 4118162 11128 4059735 117416 43
5251586 712484 3778656 73177 4165910 14773 4126021 136252 44
5392669 719924 3842163 71873 4497918 15109 4477174 152996 45
5724926 774699 4133113 76184 4532897 14481 4473613 137604 46
5856883 769998 4199104 75159 4847347 20174 4828226 211726 47
6217736 846335 4496811 77702 4932192 12953 4909948 188829 48
6352239 828387 4571788 78495 5241261 5833 5269930 196757 49
6707867 914572 4880886 79638 5355771 7252 5362554 200165 50
6869800 902853 4944328 80894 5671277 8475 5696317 217732 51
7249302 990881 5281971 82889 5765194 8951 5782413 274038 52
7419524 976818 5331446 88302 6127435 22676 6136767 229664 53
7804424 1057917 5698840 86129 6213236 17302 6215678 250990 54
7992381 1052700 5750762 92180 6589926 14819 6621132 261095 55
8392308 1133130 6097054 93398 6623726 20154 6676482 317860 56
8586491 1125592 6176921 92259 7055765 19391 7046708 217047 57
9005256 1205949 6544424 96874 7097653 18036 7155858 264159 58
9164643 1198395 6626879 94269 7498123 11019 7611947 298837 59
9631110 1284086 6998979 95975 7619869 18780 7676814 324187 60
9805260 1268918 7093834 98484 8004638 29423 8054290 360207 61
10273301 1380240 7477812 99573 8115913 19852 8146666 312757 62
10437245 1338988 7566370 110428 8512434 21730 8624804 354760 63
10915030 1433839 7972505 102691 8649042 19671 8693699 340829 64
11115482 1415627 8033448 109194 9040432 20909 9113007 388204 65
11595584 1504338 8483121 105991 9161630 28275 9242899 385808 66
11812068 1493812 8536220 108944 9596727 34463 9706763 349560 67
12299945 1588587 8967366 114048 9656083 37955 9771089 377279 68
12526076 1575307 9063974 112371 10204084 25483 10338415 465764 69
13031087 1673802 9507882 117329 10254979 18822 10420029 478599 70
13234760 1652151 9609124 114246 10734068 25703 10917101 431514 71
83
13770654 1764820 10054913 117639 10817506 26611 10989385 466237 72
13977102 1736087 10168766 116841 11272242 39481 11433486 523177 73
14541416 1852168 10627202 120459 11400398 40380 11527503 445543 74
14738837 1815383 10719610 119238 11891887 40093 12012044 411774 75
15286707 1933241 11214989 123765 12039586 4912 12237068 500474 76
15525133 1902828 11286708 127505 12500229 44110 12785427 550455 77
16085903 2014669 11796514 124472 12621398 38779 12832582 485244 78
16345433 1991258 11880986 126230 13167320 37436 13315733 541051 79
16922144 2109015 12391160 133868 13285482 32870 13624391 556288 80
17191081 2083435 12502745 129835 13836857 36414 14177434 660639 81
17782027 2207041 13025706 137138 13908495 48990 14176346 662630 82
18032215 2146016 13142168 135073 14522857 34755 14851342 671847 83
18657736 2308862 13663569 134928 14545362 40163 14931652 691063 84
18882350 2275978 13798066 140147 15161316 26942 15474070 676728 85
19536617 2425609 14331728 140599 15290301 40110 15590476 725261 86
19785986 2379592 14426463 127208 15837060 47711 16092174 623326 87
20402242 2521717 15013389 143707 15957810 33760 16490420 745490 88
20676928 2490221 15099193 152562 16564885 57808 16880296 693831 89
21341867 2637208 15671406 133801 16980549 47065 17095701 705979 90
21629666 2612841 15782821 150503 17335593 29603 17564265 750479 91
22288749 2751669 16369668 158073 17434474 33737 17806444 765277 92
22596546 2733347 16497648 153915 18067207 60432 18340711 759816 93
23266633 2873557 17085492 156614 18113090 54790 18570328 793384 94
23553704 2798941 17230779 157734 18861858 49388 19134788 808675 95
24245460 3009435 17828799 160369 18898808 77210 19180917 713574 96
24523242 2962582 17947127 159692 19458062 51877 19985446 892662 97
25087244 3083736 18588262 163525 19699711 52414 20018298 759884 98
25350806 3088899 18693673 147118 20276303 76251 20631131 874652 99
25743052 3302393 19332412 165823 20454074 40709 20980407 1069603 100