Physical Security for Fleet Management Systems

Abstract

Fleet Management (FM) deals with the management of transport, distribution, and logistics of national and international goods exchange, in which many operators worldwide are involved. Fleet management involves many security-relevant participating entities, such as vehicles, FM mobile clients, smart trackers with goods, drivers, etc. Existing automated fleet management systems are basically vulnerable to physical replacement attacks when managed by mass-produced electronic identities. Analog Physical Unclonable Functions (PUFs) failed to serve as unclonable electronic identities due to being costly, unstable and inefficient for such mass-usage. We propose in this paper to deploy the Secret Unknown Ciphers (SUCs) techniques introduced a decade ago as digital low-cost clone-resistant identities to be embedded in selected participating electronic Fleet Management System (FMS) units. SUCs, as stable self-created digital modules to be embedded in future smart non-volatile (NV)-FPGA devices, are expected to cover all emerging FMS physical security requirements. Such information-retaining units (when switched-off) are emerging to become widely used as ultra-low-power mass-products in automotive environment. We propose a new FMS security architecture based on embedding SUC modules in each security-relevant entity in the FMS such as vehicles, mobile clients, smart trackers and goods. This paper investigates the expected technical impacts when using SUCs technology as physical security anchors in a standard FMS configuration. Several SUC-related generic security protocols adapted to the FM environment show how to securely-link tracing of goods, tracks routing, and personnel in such FM system. It is also shown how to combine other biometric fingerprints to simplify personal liability and enhance the security management in such globally-operating automated procedures. The presented security analysis of the resulting FMS shows that the major security concerns in existing FMSs can be resolved. One major advantage of SUC technique, is that device-manufacturers can be largely-excluded as security players. The FPGA technology required for the SUC solution is currently not available and is thought for future use. The concept is ultimately applicable if the future electronic mass products would deploy self-reconfiguring non-volatile (flash-based) System on Chip smart units. Such units are expected to dominate future Internet of Things (IoT) ultra-low-energy applications, as power-off does not lose any information. The proposed SUC strategy is highly flexible, scalable, and applicable to cover a large class of globally operating protection mechanisms similar to those of the addressed FMS scenarios.

1. Introduction

Nowadays, the need to monitor goods transport and deployed vehicles during their activities is growing as globalized goods exchange is growing worldwide. Fleet operators require secured and precise information about their vehicles and goods traffic such as compliance reporting, International Fuel Tax Agreement (IFTA), International Registration Plan (IRP), and pre/post-inspections reports [1]. Vehicles can operate globally in various locations in large numbers and for different purposes. On the client side, much information is required in real time between Fleet Management System (FMS) operators’ clients, drivers, etc. to fulfill the technology requirements of a distribution process correctly. Contemporary Fleet Management (FM) systems are deploying the global positioning system (GPS) and global system for mobile communication (GSM) technology as standard network services usable for FMSs. Utilizing GSM technology has become popular due to its low cost, and it is an easy way of transferring data with high reliability on existing infrastructure [2]. The Global Positioning System (GPS) is commonly used as a global navigation satellite system to provide location and time information anywhere on Earth. Both systems are very efficient means for tracking, routing, and real-time FM [3,4].

Recently, several security solutions and tracking systems were designed to assist corporations deploying large number of vehicles [5,6]. A Fleet Management System (FMS) is required to optimize the cost and effort required from employees and infrastructure to accomplish the whole process efficiently within minimal times. Additionally, assignments can be scheduled in advance based on tracing vehicles locations. Therefore, central fleet management is essential for large enterprises to meet the varying and growing requirements of customers and to improve productivity. However, the current solutions [5,6] do not secure all FMS entities (driver, vehicle, mobile, goods) sufficiently, and the open communication paths are making the system vulnerable to wide spectrum of attacks [7]. Such geographically distributed system offers large areas of security gaps like the injection of falsified data and especially, faking position information of vehicles and goods. Misbehavior in terms of wrong position information is very likely to disturb the whole system [8]. For example, displacement of operation-relevant mobile device to wrong vehicles by an adversary may disturb the FM process and abuse the whole system. In addition, even by adding an authentication process to the FM mobile, it is still possible to fake the vehicle identification number. Recently, a new FMS era begins with the use of smart pallets [9], low-cost tracker which can detect its own position, as well as being able to track any movements, impacts, and operational condition. For example, networked waterproof sensor detects impacts, inclination, and the acceleration forces on each pallet to improve the quality of transport and tracking [9].

However, all the above solutions suffer from the missing unclonability of the deployed electronic units as GPS and GSM units. Our work focuses on converting electronic units into hard to clone (non-replaceable) entities to act as physical security anchors in a solid fashion. We propose to embed a low-cost and consistent digital clone-resistant technology, coined as Secret Unknown Ciphers (SUC), in some future FMS entities as unclonable structures to serve as security anchors for the FMSs operating on open and global networks. Additionally, we propose to combine SUC with some biometric fingerprint to enhance serving personal identification and liability as in [10]. Combining both technologies allows to build strong authentication mechanisms and attain undeniable transactions for liability issues in FMS processes. The proposed security levels are scalable and even capable to cope with future post-quantum security requirements.

Contributions: this work has the following three contributions, (1) we introduce a new secured Fleet Management System security architecture which deploys clone-resistant physical entities as security anchors in future non-volatile smart electronic units. All relevant fleet management entities should become physically hard to clone/replace. For example, FM involved mobiles, vehicle, and goods-carriers are made physically unique using a new concept of the digital Secret Unknown Ciphers (SUCs) embedded in the participating units. (2) Related generic security protocols to cope with the SUCs in FMS environment are introduced to show the impact of SUC usage on the FM system operation. (3) The techniques are shown to efficiently prohibit any replacement attacks on FMSs at adequate cost and complexity. A security analysis is provided to shows that the resulting system is highly secure and resilient.

The remainder of this paper is organized as follows. In Section 2, we investigate related works that have been introduced on vehicular networks security and current FMS architecture. Current FMS system architecture, possible attacks on that system, and our proposed enhancing security requirements are presented in Section 3. In Section 4, the targeted secured necessary FMS architecture is presented. Generic new identity creation using SUC technology together with the corresponding protocols are presented in Section 5. Multi-Realm Operational Capability are presented in Section 6. Security analysis of the proposed FMS against a variety of attack scenarios is presented in Section 7. Section 8 concludes the attained results and presents possible future works.

2. Related Work on the Security of FM Systems

Vehicle tracking systems are widely used in different sectors such as smart traffic management systems, vehicle location tracking systems, anti-theft vehicle tracking systems, parking management systems, fleet management, and in the field of Intelligent Transportation Systems (ITS) or Smart Transportation Systems (STS). This section presents some selected state of the art FMS systems from the open literature.

In [11] the authors proposes a cloud-based fleet management platform through integrating the advantages of Internet of Things (IoT) and cloud technology but the security and privacy issues have not been well addressed. In [12], an Automatic Vehicle Monitoring (AVM) platform was proposed, it manage multiple heterogeneous devices for fleet management, monitors street traffic and supplies high-level services. This platform provides a monitoring service for several properties in the vehicle, which can be read over an On-Board Equipment (OBE) device. However, the authors choose GPRS as a communication network that has great limitations of range, data rate, and availability. In [13], authors proposed a dynamic FMS with an event-based architecture. The system changes the task management workflow of the fleet entities. They applied this architecture to the coordination of a fleet of ambulances in a medical emergency scenario and show experimentally that the proposal outperforms a nondynamic approach. In [14], Gowda et al. proposed a system to provide effective vehicle tracking, real-time monitoring. The real-time vehicle fleet management and Security System has an in-vehicle system in which all the hardware is interfaced to a Cubie Truck board. This in-vehicle system is placed in the vehicle. A remote server used for data acquisition in real-time and graphical user interface is created for user interface and dynamic plotting. However, the authors do not provide any security analysis for their security system. Malekian et al. described the design and development of a wireless On-Board Diagnostic II (OBD II) fleet management system. The system measures vehicle speed, distance, and fuel for tracking and analysis purposes [15]. The use of the OBD II port to obtain vehicle operation data was an important aspect of this work because this port is featured in the vast majority of current vehicles.

Recently, many FMSs have been proposed, designed, and implemented with smart services. The FMS tracking services and other functionalities are provided to users [5]. Other systems provide additional functionalities besides tracking such as allowing users to search for addresses and directions, and historical playback for vehicles’ movement [6]. Other services provide a desktop application which provides distance calculations in addition to the basic tracking system [16].

All the currently provided solutions use just basic user password authentication mechanism to access the web portal or the mobile application. Therefore, all these systems suffer from being very weak in clonability resistance leading to be easily exposed to many replacement-attacks and abuse scenarios especially in future automated globally operating smart FMSs.

3. Modern Operational FMS Architectures

Transport and logistics companies maintaining a fleet of vehicles and trailers for transport of goods need efficient management for their vehicles using fleet management information systems. In the following, a standard sample FMS architecture is depicted as a model to project our proposed security architectures on-to it.

3.1. Sample Modern FM Functional System Architecture

Figure 1 describes a sample modern FMS architecture; a vehicle with an integrated GPS receiver for routing and tracking, a mobile device with installed Fleet Management Client (FMC) application connects to the vehicle Electronic Control Unit (ECU) via ODB II [15], the FMC reads vehicle data like speed, fuel, Mass Air Flow (MAF) and sends the data wirelessly to the fleet management backend server, where the data is stored and processed in various components.

Drivers use the FMC application on their mobile device to login into the FMS, and authenticate themselves with username and password. In the case of successful authentication, the login session will open. The FMC application automatically calculates IRP and IFTA miles-per-state using the GPS data. Drivers can enter information into the FMC application for supporting documents such as fuel purchases, tolls, and meals as well as their pre- and post-trip inspections. This data, along with the duty log, IFTA, IRP, and inspection data, creates a complete trip record that can be viewed, audited, archived, and printed from Fleet Manager (FM). In the truck box or trailer, the low-cost Smart Tracker (ST) enables load carriers (pallets) to connect to the FMS; an ST contains a GPS receiver and is connected to the mobile data network using SIM cards. Each ST sends the current position to the FMS frequently [17,18].

3.2. Threat Models and FM-Adversary Types

Securing the FMS requires first identifying possible attacks scenarios, their nature, and their capacity to damage the system. The possible attacker types could be categorized into [19]:

• Insider and Outsider: insiders are the authenticated users of FMS, whereas outsiders have a limited capacity to attack.
• Malicious and Rational: malicious attackers have no personal benefits to gain from an attack; they just harm the functionality of the network. Rational attackers have a personal profit motive.
• Active and Passive: active attackers generate or modify messages, whereas passive attackers only read the traffic.

3.3. Assumed Attack Scenarios on Existing FMS

Due to the open wireless nature of FMS and route information efficiency requirements from source to destination, there are many types of attacks that can hamper the successful deployment and execution of FMSs [20]:

• Impersonation Attack: in this attack, an adversary takes over the identity and privileges of an authorized FMS entity. Active adversaries perform this type of attack. They may be insiders or outsiders. This attack is a multilayer attack, i.e., an attacker can exploit either network layer, application layer or transport layer vulnerabilities. An attacker steals property of the legitimate user; the attacker can claim that it is a genuine user. By using this type of attack, a fake mobile can claim that it is an FMS mobile to send wrong positions to the FMS. Figure 2 shows four sample different types of impersonation attacks on FMS:
  • Attack 1: an adversary impersonates the mobile
  • Attack 2: an adversary impersonates the vehicle
  • Attack 3: an adversary impersonates the ST.
  • Attack 4: an adversary impersonates the driver.
  As FMS entities do not currently have physically secured identities, an adversary may basically counterfeit the identities of the vehicle and mobile. Also, the adversary can replace real goods with fake goods, and can exchange corrupted data such as the GEO Location, speeds, etc. with the FMS.
• Location Tracking Attacks: the current FMS entity position or the path followed along a period can be used to track the vehicle, mobile, smart tracker, and obtain information about drivers.
• Eavesdropping Attacks: this attack belongs to the network layer attack and passive categories. The main goal of this attack is to access confidential FMS data.
• Denial of Service (DoS) Attacks: in DoS attacks, the main objective of the attacker is to disturb the communication channel or overwhelm the FMS’s services available to legitimate users and entities. This attack makes the system useless. In this way, critical information cannot be conveyed to vehicles on time. Moreover, it can cause or increase the danger to the driver if she/he depends on the application’s information to make decisions. For example, an attacker floods the gateway service with traffic (wrong messages) in order to overwhelm the victim’s resources and make it difficult or impossible for legitimate users to access them. The gateway service is the point of standardized public communications; this makes it a perfect target for a DoS attack.

In all known state-of-the-art treatments, no physical security is involved in making physical units unreplaceable. Hence, there is a need for a solution that can securely identify clone-resistant vehicles, mobiles, goods, and drivers. This identification should be made in real-time to attain stable security anchors for contemporary FMSs. More security requirements are therefore necessary.

3.4. Proposed Enhanced Security Requirements for Future FMS

In this Section, we propose new and additional set of security requirements to counteract expected future threats:

• Individual physical entity authentication: each security-relevant entity such as mobile, vehicle, smart tracker, and driver should become individually identifiable to the FMS backend at any time.
• Jointly physically clone-resistant entities: in order to counteract the significant severe attacks on fleet management, all relevant entities should be capable of being jointly unreplaceable. For example, an inseparable secured individual pairing of “mobile/vehicle is necessary. Under this requirement, no replacements or impersonation attacks such as attack 1 and attack 2 would be possible.
• Location certainty: the FM entities are required to deliver strictly authentic and unclonable geo-positioning to the FMS to counteract false or fake routing.
• Unclonable time scale: one of the primary system requirements is that the FMS should process all real-time information which is consistent and not possible to fake.
• Non-repudiation: requirement assures that it will be impossible for an entity to deny having sent or received a message.
• Exclusive confidentiality of relevant information: the FM communications should only allow information to reach the dedicated authorized parties.
• Availability: implies that every mobile/vehicle or any relevant entity should be capable of delivering information and acting authentically at any necessary time. The Denial-of-Service (DoS) attack should be prevented or at least securely detected.
• Data integrity and authenticity: delivered data messages should not be modifiable and, more importantly, should be authentic; this also implies that the received information is fresh. False or modified data should not lead to potential system crashes, bottlenecks, and other problems.

4. Proposed New Low Energy Highly Secured FM Structures

One fundamental primitive remedy for the majority of the above requirements is the deployment of clone-resistant functions or identities for all relevant entities including mobile, vehicle, driver, goods, etc. The FMS is required to integrate unclonable and tamperproof identities into each entity and linking them with the FMS security architecture such that any attempt to abuse/fake any physical or geographical information would be securely identified in real-time by the FMS management.

4.1. Proposed New Clone-Resistant Modules for FMS Components

To fulfill the security requirements described above, each FMS component (vehicle, mobile device, and smart tracker) should embed its unique clone-resistant functions. In addition to that, drivers will be identified by their unique biometric keys. In this way, strong authentication between the FMS components would be ensured.

4.1.1. Clone-Resistant Module for FM Electronic Entities

Physical Unclonable Functions (PUF) have been proposed as unclonable structures to make electronic units physically non-replaceable in the last two decades [21,22,23]. PUFs deploy many intrinsic device properties to extract provable devices DNA-like identities. Due to the PUFs analog nature, PUFs have inconsistent responses when challenged under different environmental conditions or in different times because of aging effect. Fuzzy extractors were proposed to stabilize PUFs behavior [24,25]. However, such error correction mechanisms have high hardware/software complexity and reduce the system entropy.

To overcome PUFs limitations, new digital (non-analog) clone-resistant function coined as Secret Unknown Cipher (SUC) was proposed in [26,27,28,29]. SUC is a random, unpredictable, and unknown internally self-generated cipher created inside each chip, such that no other party, even the manufacturer, may back trace the generated cipher inside the chip. As digital structure, each resulting SUC inside a chip is robust and consistent during the whole chip’s lifetime.

In this work, we propose to deploy such SUCs as clone-resistant modules without participating the device manufacturer in all future security-relevant FMS electronic component. Our solution is to integrate unclonable and tamperproof identities into each individual entity and link them such that any attempt of physical or geographical separation would be securely identified in real-time by the FMS. FM entities (mobile, vehicle ECU, smart tracker) are produced by different manufacturers.

The Concept of SUC: As SUC concept is not well known in the public literature, we introduce the concept again to make the paper self-contained. Figure 3 describes the concept for embedding SUC in System on Chip (SoC) units that are based on self-reconfiguring non-volatile SoC FPGAs. The SoC FPGA should reside in the main chip/unit of each FMS component (mobile, vehicle ECU, smart tracker). The Trusted Authority TA responsible for triggering the creation of the SUCs could be even the FMS manager without participating the device manufacturers.

Notice:We assume that such smart non-volatile devices would dominate the future electronic IoT devices for many reasons. The major reason is that non-volatile technology is an essential requirement for ultra-low-power systems as full power-off do not lose any processed information.

The personalization process by TA on each SoC FPGA may proceeds as follows:

• Step 1: TA injects a software package called “GENIE” into each unit that contains an algorithm for creating internally unpredictable and unknown random secure ciphers. The TA injects the GENIE for a short time into each SoC unit to run just one time and never again.
• Step 2: The GENIE creates then a permanent (non-volatile) and unpredictable random cipher by deploying random bit’s string from an internal and unpredictable True Random Number Generator (TRNG).
• Step 3: When the GENIE completes the creation of the SUC, it will be fully deleted and the SoC unit ends up with its unique and unpredictable SUC.
• Step 4: The TA challenges the SUC_A using a set of clear text challenges $X_A=\left\{X_{A,0},X_{A,1},\dots ,X_{A,t-1}\right\}$ and receives the corresponding cipher text responses $Y_A=\left\{Y_{A,0},Y_{A,1},\dots ,Y_{A,t-1}\right\}$. It stores them on the corresponding area in its secure “Units Individual Records” (UIR) defined by the Serial Number of the device (SN_A). In [26], an efficient mythology to manage X/Y pairs was proposed; the set of challenges $X_A$ can be generated by deploying a seed S₀ such that: $X_{A,i}=S_0+i$ for $0\le i\le t-1$. This reduces the memory complexity required to store X/Y pairs in the participating devices of the FMS.

Notice:TA may be any trusted authority assigned by the FMS or the FM administrator himself. The device manufacturer is just offering devices and has no information about the GENIE or the personalization process. The devices can be irreversibly locked after the above 4 step personalization process and may never be changed again.

Generic Physical Identification Protocol for SUC Units: a fleet manager having unit A’s set of X/Y individual records can authenticate unit A according to the sample following protocol.

In reference to Figure 4, a two-way protocol can be used by an FMS to identify a physical unit A (SN_A), having $SU{C}_A$ and $SU{C}_A^{-1}$ structures as follows:

• TA selects randomly one of the $X_{A,i}/Y_{A,i}$ pairs and challenges unit A with $Y_{A,i}$. Unit A uses its $SU{C}_A^{-1}$ to decrypt $Y_{A,i}$ resulting with the corresponding cleartext $X_{A,i}^{\prime }=SU{C}_A^{-1}(Y_{A,i})$ and sends $X_{A,i}^{\prime }$ to TA.
• If $X_{A,i}=X_{A,i}^{\prime }$, then the unit is deemed to be authentic and can be accepted. Otherwise, unit A is not authentic and should be rejected. The pair $X_{A,i}/Y_{A,i}$ is marked as consumed and should not be used later for highest security performance.

Compared to PUFs, SUC has the advantage that it is capable to recover X from Y by using the inverse function $SU{C}^{-1}$. This property allows low-complexity and very efficient management of the consumed X/Y-pairs. The property was also used in [30] to build a physical chain of trust for a secured over the air vehicular software update.

4.1.2. Combining Biometric Fingerprints as Additional Security Enhancement

The biometric fingerprint is a personal authentication technique based on an individual’s polar fingerprint. Fingerprint authentication techniques have little possibility of being attacked by someone who does not have access to privacy data. It allows people to verify themselves using a simple process, by putting their fingerprint into the fingerprint scanner. This technique is assumed to be better than authentication technologies such as passwords, PIN, or tokens that require people to remember multiple words and numbers but still vulnerable. Various biometric-based systems for remote user authentication have been suggested as summarized in [31,32,33] summarize a good representative selection.

To ensure the security of the driver’s fingerprint in the FMS, we propose a combination of SUC technology (unclonable mobile physical identity) and the operating system Fingerprint API (mobile fingerprints reflecting driver identity) for FMS authentication process.

4.2. Proposed FMS Security Architecture

Figure 5 illustrates a sample embodiment of the SUC security enhancement scenario in the mobile, vehicle and smart trackers to create an identity which cannot be faked or replaced without the strict knowledge and administration of the FMS. Vehicle ECU provides a gateway for the smart trackers, which frequently sends its position over the gateway to the mobile device FMS backend. In this way, the ECU builds a low energy wireless local network area for all STs so that STs never use GSM communication during a trip. The mobile fingerprint sensor for user identification will be used to build a biometric identity to identify drivers. Biometrics verifies that the person boarding the vehicle is a verified driver that is trying to access the FMS mobile application by comparing the entered characteristic inputs and registered characteristic inputs which are extracted from unique and highly discriminatory characteristics. To fulfill the location certainty requirement, the FMS determines the current position of the vehicle, mobile, and loaded STs. On the FMS backend, a position agent analyses the trip location data, which contains mobile, vehicle, and ST position data and generates violation events if different positions are detected for the three entities.

The following sample added SUC embodiments are proposed to be integrated in some FMS units to fulfill the enhanced security requirements in the proposed FMS security architecture:

4.2.1. Clone-Resitant Vehicle ECU

The SUC is embedded in a customized Electronic Control Unit (ECU) in the vehicle. ECU captures rich data on vehicle position, speed, fuel use, idling, and more, and communicates directly with the FM mobile device over the ODB II interface. Integrating SUC into the vehicle increases vehicle security and makes ECU clone resistant. A mutually hard-to-clone authentication between vehicle and mobile device can be strictly and securely achieved.

4.2.2. Clone-Resistant Mobile Device

The FM mobile application runs on the mobile device with integrated SUC; The FM mobile application security module provides the necessary security-relevant functions such as encryption, decryption, generation, and verification of cryptographic keys. Clearly, a hardware solution provides higher performance and a far higher security level. In this proposal, security protocols described in Section 5 will be implemented in the FM mobile application. The FM mobile application is added as a form of Software Developer Kit (SDK) that is installed in the mobile device. It is the communication interface with the Fleet Management backend services. It encapsulates the implementation of the transfer protocol to the FM backend system. All known fleet management processes like driver management, vehicle management, map functionalities, compliance, dispatch and order, messaging, etc. are to be implemented in the FM mobile application.

4.2.3. Clone-Resitant Smart Tracker and Goods

The state of the art Smart Tracker (ST) [9] presents an alternative goods tracking system based on GSM networks. A complete GPS receiver was integrated and latitude and longitude coordinates were sent to the FMS via SIM card. The device can detect its position and it is able to track any movements, impacts, and changes in temperature and weight. The ST reports its status whenever there is a deviation from the plan, e.g., if it senses an unexpected shaking or temperature fluctuations. ST passes its data updates automatically back to the FMS backend. Our solution is proposing to integrate a SUC into each ST offering a very efficient clone-resistant identification and management capabilities and makes the STs less vulnerable to cloning attacks. A physically hard-to-clone authenticated chain between ST and the vehicle’s ECU or possibly other units can be strictly and securely established.

4.2.4. FM Backend Server with Physical SUC Security

The FMS Backend Server with embedded SUC provides necessary services for client applications. These services help to distinguish between the different types of component tasks, making it easier to create a design that supports component reusability. Each service contains several discrete component types grouped into sub-layers, with each sub-layer performing a specific task. The core services are “fleet management service, user services, platform service, compliance service, gateway service, and trusted authority service. Trusted authority service is introduced to the FMS Backend with the primary task identification of FMS entities (driver, vehicle, mobile, and smart tracker) and controlling their access to the fleet management Backend Services. The trusted authority service stores encrypted secret records for each entity for later usage. Each SUC has its pair records, as shown in Figure 5. Trusted authority service uses backend server SUC-Hard-Token (SUC_BE) with the key K_FMS to physically secure the encryption and decryption of FMS messages.

5. SUC-Related Security Enhancement Protocols

This section addresses basic sample generic protocols to conduct the required operations in the SUC-based proposed FMS.The following notations are used in the protocols below:

• Smart tracker $T_t$ possesses $SU{C}_{T,t}$ and has a position $P_T$ with its timestamp $T{S}_T$
• Vehicle $V_v$ possesses $SU{C}_{V,v}$ and has a position $P_V$ with its timestamp $T{S}_V$.
• Mobile $M_m$ possesses $SU{C}_{M,m}$ and has a position $P_M$ with its timestamp $T{S}_M$.

5.1. Overview on the System Security Workflow

The fleet manager manages all FMS entities (vehicle, mobile, smart tracker, and driver). When a fleet manager inserts a new entity in the FMS, the enrollment process for this entity should be executed as follows: The FMS requests an entity possessing $SU{C}_X$ to generate challenge-response pairs, then the FMS encrypts the challenge-response pairs using its own $SU{C}_{BE}$ and private key $K_{FMS}$ and stores them in the FMS entity table.

To manage trips in the FMS, the fleet manager must first assign a mobile phone to the driver, then assign a driver to a vehicle and assign at least one load to the vehicle. Each load includes a minimum of one pallet with integrated smart tracker. Figure 6 shows a sample system workflow.

The system workflow scenarios may proceed as follows:

• Action 1: The FMS backend server personalizes all FMS entities: a mobile $M_m$ having $SU{C}_{M,m}$, a vehicle $V_v$ having $SU{C}_{V,v}$, a smart tracker $T_t$ having $SU{C}_{T,t}$, and a driver d having a biometric identity $B{K}_d$. All records are encrypted by using SUC_BE and the personal private key K_FMS of the backend operator, that is the records are only accessible if both the physical token SUC_BE and the private key K_FMS are available.
• Action 2: Driver $B{K}_d$ logs in via fingerprint to start using the FMS client application on the mobile $M_m$. Mobile $M_m$ sends $I_m$ to FMS.
• Action 3: Mutually authenticated $M_m$ and $V_v$ are imitated and presented authentically to FMS backend server. Both $M_m$ and $V_v$ confirm to the server that the other party is not fake.
• Action 4: The vehicle $V_v$ sends information $I_v$ via mobile, including an unclonable source-authentication signature for the vehicle and mobile.
• Action 5: Smart trackers (ST) $T_t$ sends information $I_s$ via mobile including an unclonable source-authentication signature for the smart tracker, vehicle, and mobile.
• Action 6: The FMS requests information about the current trip by sending a message to the FM mobile app.

Any physical separation of $M_m$, $V_v$, and $T_t$ is securely forwarded to the FMS in real-time as will be shown in the security protocols in the following sections.

5.2. Owner Enrollment Setup Process for Clone-Resistant Entities

The enrollment process is divided into two parts: management of fleet entities (mobile, vehicle, smart-tracker) which can be done by the fleet manager on the FMS web portal, and driver registration, which can be done on the FM mobile application by the driver.

5.2.1. Enrolling Fleet Management Entities Using SUCs

The enrollment of the FM entities is conducted by a TA assigned by the FMS or the FM administrator himself. As stated before, the device manufacturer has no information about the GENIE or the personalization process. The TA collects challenge-response pairs from every unit (mobile, vehicle, smart-tracker) and adds these units to the system. Since a vehicle can be used by many drivers and transport different pallets with different smart-trackers, each time the FMS will assign a vehicle to the corresponding mobile, smart trackers, and driver in the trip management module.

5.2.2. Sample Driver Registration Protocol

During the driver registration on the FM mobile application, a driver biometric key will be extracted from the mobile fingerprint sensor using the operating system fingerprint API [34] and sent to the FM backend in combination with the mobile SUC. Trusted authority service stores the biometric key in the FMS driver table after checking the mobile authenticity. Figure 7 describes the executed steps when a driver tries to register (Protocol 1).

Protocol 1: Driver registration protocol

Objective Driver registration: The registration process for the driver can be done securely via FMS mobile application. The combination of physical security of the mobile and the driver biometric identity guarantees that the identity of the driver is linked to the identity of the used mobile.

Prerequisites Mobile device managed by FMS Driver already assigned to FMS mobile device FMS mobile application installed on FMS mobile device

Output: Successful registration message for registerd driver Registration failed message in case of error while register the driver

Steps: Mobile $M_m$ obtains the biometric identity of the driver d ($B{K}_d$) out of many drivers {1, 2 … d …D} using the operating system fingerprint API [34]. Mobile $M_m$ selects an unused $X_{m,i}/Y_{m,i}$ pair of its $SU{C}_{M,m}$, then it encrypts $B{K}_d$ together with $X_{m,i}$ using a standard cipher E, such as AES, and sends it concatenated with the serial number $S{N}_{M_m}$ of the mobile and $Y_{m,i}$ as: to the FMS. The FMS finds the corresponding challenge $Y_{m,i}$ for $X_{m,i}$ in the UIR corresponding to Mobile $M_m$; then it decrypts the received message as $E_{X_{m,i}}^{-1}\left(E_{X_{m,i}}\left(B{K}_d||X_{m,i}\right)\right)=B{K}_d||X_{m,i}^{\prime }$ to obtain the driver’s biometric identity. The FMS checks the integrity of the received message from mobile $M_m$ by checking if $X_{m,i}=X_{m,i}^{\prime }$. The FMS stores the biometric key and sends an acknowledgment ACK together with $X_{m,i}$ encrypted with the same key $X_{m,i}$ to the mobile. Mobile $M_m$ decrypts the received message from the FMS and checks its integrity. When ACK is valid for the FMS, mobile $M_m$ shows the driver a successful registration message.

5.3. Driver Login Protocol

Biometric identity is used to allow only genuine drivers to login to the FM mobile application. The login protocol proceeds similarly to the registration protocol above.

5.4. Driver Actions and System Events Protocol

Driver actions: FMS verifies the genuineness of received data from FMS mobile app.

After successful login, extended user actions are possible, e.g.,

• Set duty status: on-duty, off-duty, and driving
• Driver’s vehicle inspection report
• Upload documents such as fuel receipt or hotel receipt
• Reports of electrical or mechanical defects

The same protocol will be used for diagnostic events or violations, which is calculated by the FM mobile application. Figure 8 describes a driver actions and events protocol (Protocol 2).

Protocol 2: Driver actions and system events protocol

Objective: Driver actions and system events: Driver actions and system events should be sent securely and in real-time to the FMS backend server. Mobile is physically secured, which prohibits impersonation attack

Prerequisites: Driver is logged in the FMS mobile application.

Output: Successful message, mobile application show the driver action sent notification Action failed message in case of error

Steps: Mobile $M_m$ sends the encrypted action or event message Q as $S{N}_{M_m}$, $E_{X_{m,i}}\left(Q||X_{m,i}\right)||Y_{m,i}$ to the FMS. FMS decrypts the received message, checks its integrity, and if the message is valid, the FMS processes the action or event. FMS sends an encrypted ACK as $E_{X_{m,i}}\left(ACK||X_{m,i}\right)$ to the mobile.

5.5. FMS-Actions Protocol

The fleet manager monitors drivers, vehicles, and loads via the FMS Web interface; sends load and tours to the driver; and requests a current position from the FM mobile application. Figure 9 describes a protocol for managing FMS actions (Protocol 3).

Protocol 3: FMS actions protocol

Objective: FMS actions: Fleet manager or FMS actions should be sent securely and in real-time to the FMS mobile application.

Prerequisites: Driver is logged in the FMS mobile application.

Output: Mobile application response will be stored or shown if the action was triggered from FMS user interface.

Steps: $\mathrm{FMS}\mathrm{selects}\mathrm{an}\mathrm{unused}{X}_{m,i}/Y_{m,i}$ pair of $SU{C}_{M,m}$ embedded in a targeted mobile $M_m$, then it encrypts the request RE together with $X_{m,i}$ by using a standard cipher E keyed with $X_{m,i}$ and sends it concatenated with $Y_{m,i}$ as: $E_{X_{m,i}}\left(RE||X_{m,i}\right)||Y_{m,i}$ to Mobile $M_m$. The Mobile $M_m$ triggers its $SU{C}_{M,m}$ with $Y_{m,i}$ to get $X_{m,i}$ and decrypts the message received from FMS. If the decryption was successful, mobile $M_m$ processes the action. Otherwise, it rejects and aborts. FMS Mobile application sends an encrypted response RS to FMS.

5.6. Secured Unclonable and Undeniable Position Tracking

The FMS has always an updated assigning list for each set F = {vehicle, mobile, smart tracker}.

Each set F should send its position including timestamps frequently to the FMS. We assume here that the mobile is responsible for contacting the FMS to reduce the traffic and ensure low power consumption by the smart trackers. Figure 10 describes a secured unclonable and undeniable position tracking protocol (Protocol 4).

Protocol 4: Position tracking protocol

Objective: FMS entities: FMS entities send position and additional properties securely and in real-time to the FMS backend server. Genuineness of all fleet management entities: mobile $M_m$, vehicle $V_v$ and smart tracker $T_t$ are ensured by physical security.

Prerequisites: Driver is logged in the FMS mobile application.

Output: Mobile application’s response will be stored or shown if the action was triggered from FMS user interface.

Steps: The smart tracker $T_t$ selects randomly one of the unused tickets pointed to by an index $i$. Then, it encrypts its position $P_T$ with its timestamp $T{S}_T$ as $E_{Y_{t,i}}\left(P_T,T{S}_T\Vert X_{t,i}\right)$ and sends it concatenated with its serial number $S{N}_{T,t}$ and $i$. This would allow the fleet management system to check the integrity of the received message in addition to validating that it comes from a genuine smart tracker. $S{N}_{T,t}$ and $i$ allow the FMS to find directly the used CRP in the corresponding UIR of the smart tracker $T_t$. Vehicle $V_v$ selects randomly one of its unused tickets pointed to by an index $j$. It encrypts the received message from the smart tracker $T_t$(Q1), then it generates $Q_2=\{S{N}_{V,v},E_{Y_{v,j}}\left(P_V,T{S}_V\Vert Q_1\Vert X_{v,j}\right)||j\}$ and sends it to mobile $M_m$. $S{N}_{V,v}$ and $j$ allow the FMS to find the used CRP by vehicle $V_v$. Mobile $M_m$ selects randomly one of its unused tickets pointed to by an index $k$. It encrypts the message received from vehicle $V_v$(Q2), then it generates $Q_3=\{S{N}_{M,m},E_{Y_{m,k}}\left(P_M,T{S}_M\parallel Q_2\Vert X_{m,k}\right)||k\}$ and sends it to the FMS. $S{N}_{M,m}$ and $k$ allow the FMS to find precisely the used CRP by mobile $M_m$. The FMS picks the response with index $k$ ($Y_{m,k}$) from the UIR corresponding to Mobile $M_m$ serial number $S{N}_{M,m}$. Then it decrypts the message received from $M_m$ and checks its integrity by verifying that $X_{m,k}=X_{m,k}^{\prime }$, if not the FMS rejects and aborts the communication. Otherwise, it obtains picks the response with index $j$ ($Y_{v,j}$) from vehicle $V_v$ UIR and decrypts Q2. The FMS checks the integrity of this message by comparing $X_{v,j}$ to $X_{v,j}^{\prime }$, if not equal it rejects and aborts the communication. Otherwise, the FMS gets the response indexed with i $\left(Y_{s,i}\right)$ from the smart tracker $T_t$ UIR and decrypts Q1. The integrity check is passed if $X_{s,i}=X_{s,i}^{\prime }$. At this stage, it is proven to the FMS that the received query (Q3) from mobile $M_m$ passed all the chain starting from the smart tracker $T_t$, and no entity can deny its participation in building this query (Q3). The FMS can compare the received positions $P_T$, $P_V$ and $P_M$ from the smart tracker, vehicle and mobile respectively. If the positions are close to each other, then the FMS can be sure that all entities exist in the same place. The FMS sends back a success acknowledgement for receiving position data. The smart tracker $T_t$ verifies the acknowledgement.

This protocol can be used also to share other information with FMS such as vehicle events and violations (hard braking, vehicle speed limit, etc.). In some use-cases, there is only two participating fleet management entities with the FMS in the physical chain, such as vehicle and mobile, rather than three FM entities (ST, vehicle, and mobile) in the protocol above.

6. Multi-Realm Operational Capability

Sometimes companies must move FM entities to other globally serving operators/companies. Often, for business deals, the new company should be able to personalize these entities securely, and the home company should not have any access to these entities. Figure 11 describes a hand-over process for a visiting entity having $SU{C}_v$, moving from $FM{S}_2$ to $FM{S}_1$. $FM{S}_1$ requests a valid ticket (X_L/Y_L pair) from $FM{S}_2$ to start enrollment for the visiting entity.

Figure 12 describes a hand-over protocol (Protocol 5).

Protocol 5: Entity Handover Protocol

Objective Entity Handover: Fleet Manager $FM{S}_1$ requests control for a fleet entity from another $FM{S}_2$.

Prerequisites $FM{S}_2$ agreed to hand over the fleet entity to $FM{S}_1$

Output $FM{S}_1$ enrolls entity successfully

Steps $FM{S}_1$ requests a ticket for the visiting entity with $SU{C}_v$ from FMS2 $FM{S}_2$ sends a valid pair $X_L/Y_L$ as a one-time-ticket to $FM{S}_1$, $FM{S}_1$ uses the ticket to enroll entity v, having $SU{C}_v$, by sending a set of challenges and receiving the corresponding set of responses from entity v. Then, it stores the CRPs in the FMS backend UIR table.

7. Security Analysis

In order to analyze the proposed authentication protocols, several attack scenarios are postulated, such as replay and impersonation attacks. However, an attacker may intercept the message between nodes A and B. Thereupon, the attacker cannot decrypt the transmitted messages without having SUC. Therefore, attacks on SUC and on protocols will be discussed in the following.

7.1. Cloning Complexity of FM Entities

To impersonate an FM entity, an adversary could try to reverse or clone the targeted FM entity. In our proposed security architecture, each FM entity embeds an SUC as a digital clone-resistant and unique function. An intruder aiming to impersonate an FM entity should clone its SUC. There are two types of possible cloning attack on SUCs: mathematical cloning and physical cloning.

• Mathematical cloning: SUCs are designed so that they are resistant against known mathematical attacks, such as in [27,28,29]. The attacks’ complexity on SUCs is greater than 2⁸⁰ which fulfills today’s security limits.
• Physical cloning: An adversary with physical access to FM entities could try to reverse the embedded SUCs by means of side channel attacks. It was shown, for instance in [28] that such an attack is infeasible since applying SCA requires knowledge of the SUC design structure with its mappings which are unknown to anybody.

We conclude that such attacks are infeasible on the proposed FMS.

7.2. Impersonation Attack on FM Entities

In the presented security protocols, the shared queries between two FM entities of an FM entity and the FM backend system have the form of: $E_X\left(Data\Vert X\right)||Y$ Where X/Y denotes the challenge/response pair of an FM entity.

To impersonate the targeted entity having SUC, an adversary should be able to reverse the corresponding X of Y. Since cloning SUC is infeasible (as described in the previous attack), an adversary should reverse the cipher E. E is a standard cipher such as AES and hence it is infeasible to apply such an attack. An invasive physical replacement attack was analyzed in previous work [35].

7.3. Location Tracking Attacks on FMS

In this attack, an adversary tries to get positions information about FM entities. In the proposed protocols in this work, FM entities positions can be shared with the FMS in Protocols 2, 3, and 4. Notice that in these protocols, all shared queries and responses are encrypted by using a standard cipher E keyed with X, which denotes an FM entity’s SUC^–1 response to a challenge Y. This type of adversary has two possible scenarios to get an FM entity position information: breaking the standard cipher E, which is assumed to be secure against known mathematical attacks, or the adversary could try to recover X from Y and then be able to decrypt the captured shared message between an FM entity and the FMS. The last attack requires breaking the deployed SUC, which is designed to be secure against mathematical and physical attacks. Hence, the proposed protocol in this work are secure against this type of attacks.

7.4. Eavesdropping Attacks on FMS Communication Links

Eavesdropping attack is known also as sniffing or snooping attack. In this attack, an adversary captures the network traffic between FM entities or an FM entity and the FMS backend system, then the adversary tries to gain information from the captured messages. Notice that all the network traffic in the proposed security architecture is encrypted by using a standard cipher keyed with X, which denotes an FM entity’s SUC^–1 response to a challenge Y. As shown also in the previous attack, gaining information from these encrypted packets is not possible because of the high attack complexity to break either the standard cipher E or an SUC (attack complexity greater than 2⁸⁰).

7.5. Replay Attack

In the replay attack, the adversary somehow collects signals from a device to re-send and reuse. The target of the adversary is fooling the legitimate devices that have completed the protocol run. Randomly selecting a value X from the list of pairs makes a replay attack difficult and the SUC’s one-time use pairs increase the security level of the FMS to be completely secure against a replay attack.

8. Conclusions

A novel security architecture mapped onto future Fleet Management System (FMS) is proposed. The new architecture is based on embedding digital SUCs in all FMS-security-relevant components such as vehicles, goods and mobiles to make them clone-resistant or unclonable. SUCs as clone-resistant identities can be embedded in all security relevant units in a “post-fabrication process” by the FMS-trusted-authority (TA) to keep device manufacturers out of the security process when necessary. This is often a fundamental requirement when low-cost “un-trustable” mass-production-manufacturers are involved. The proposed SUC structures as invertible ciphers, offer very efficient management of provable identities compared with the traditional PUF technology. The resulting system would make any physical replacement attacks on any security-relevant FMS entity very hard or impossible. Sample generic SUC-based protocols are presented to demonstrate how to protect the FMS against many types of attacks. The system is shown to be highly flexible (multi-realm capable), scalable, and extendable to cover virtually all severe attack scenarios. The proposed FMS security requirements are expected to become a “must-have” requirement in the future FMSs operating at open network with globalized smart vehicular infrastructure. The proposed digital clone-resistant SUC technique is highly resilient. It has no aging issues compared to traditional analog PUF technology, which tends to be very costly, inconsistent, and highly complex to manage. The involved SUC authentication protocols are much simpler and highly efficient and manageable when compared to the traditional PUF techniques, which are equivalent to unknown non-invertible hash functions. Finally, there is a crying need for highly secured FMSs and automated trustable goods exchange at low-cost and on secured basis. This would remarkably contribute to improve fair exchange of goods between nations and possibly leads to more peace and less international goods-exchange- criminalities in general.