3.2. RFID Technology
In this section, we discuss IoT-based asset tracking systems based on RFID. We focus on RFID first because it is one of the most commonly used technologies. Anandhi et al. propose an authentication scheme for an RFID-based object tracking system [
11]. Anandhi et al. criticize tracking systems that use GPS, video cameras, and WI-Fi, and argue that the RFID tags with embedded sensors can provide better tracking. In the report, it is unclear which RFID tags and sensors they used. Moreover, they proposed a communication architecture consisting of four entities, tag, reader, user, and a cloud server. The role of these entities is not described in the protocol; for instance, it is unclear why the user was added to the system, and why the reader cannot authenticate the tags and send the data to the cloud server. In our example system (
Figure 2), we clearly defined the functionality of each entity. Our threat model covers the vulnerabilities and attacks for each of them.
Anandhi et al. present a performance evaluation in [
11] that is simulation based and does not represent their claim of lightweight operation since the encryption/decryption operations are not executed on the tags. Anandhi et al. criticize existing works on a number of parameters including the difficulty of deployment; however, they do not mention their deployment strategy, so it is not clear how the proposed scheme is better than the critiqued works.
Lie et al. [
12] propose an RFID-based asset tracking system for museums. The system uses passive RFID tags and readers to locate objects within a certain distance based on the received signal strength indicator (RSSI) value of the identification signal sent by the tags attached to the art works. Object localization based on RSSI is well established and often used for object tracking; however, the proposed model has several limitations. First, the passive RFID tags and readers can only cover a short range and are not suitable for museums with large collections stored in rooms spread across multiple floors. Second, the movement of assets in museums is portrayed in a rather simplistic way where the objects can only be at a single place storage/display and at a pre-defined distance. If they do not meet these conditions, the event is classified as theft. Third, the RFID tags can not report the condition of the art works. Museums are more concerned about the condition than theft as it is difficult to sell famous pieces of art. Fourth, the passive RFID tags do not support any security and privacy mechanisms as they do not have enough compute and energy resources. Overall, it seems that the model is proposed for object tracking in general rather than designed for the high-value assets in museums. Our proposed threat model is suitable for high-value assets in museums, is more flexible with respect to distance and supports condition monitoring.
Fan et al. [
13] propose a cloud-based mutual authentication protocol for IoT devices. The protocol is lightweight as it is based on bit-wise rotation and permutation operations and computationally heavy operations are off loaded to a cloud server. In the proposed protocol, authentication data are encrypted by permutation and updated by the use of a timestamp. However, the reliance on a cloud server for authentication might not always be practical as sometimes IoT devices used in assets tracking scenarios can become disconnected; for instance, when the items are on board a ship or transported in an aircraft. This protocol is not suitable for realistic and practical asset tracking systems. Our reference sensor system uses a reader that can provide authentication and secret key generation services for the piece of art it is attached to.
Masoumeh et al. [
14] propose an authentication protocol based on Authenticated Encryption systems. It addresses the security limitations of the SecLAP protocol which was designed for constrained devices. They designed two attacks to analyze the security of SecLAP: first, a passive attack that partially discloses secret parameters and second a full secret disclosure attack that can extract all secret parameters with the complexity of
. The improved protocol is designed for passive UHF RFID technologies and based on bitwise rotation and XOR operations. The proposed scheme needs to be extended to support encrypted communication of unicast and broadcast messages, authorization, and IAM systems. Additionally, the UHF RFID tags are not equipped with temperature, pressure, accelerometer, and gyroscope sensors to report condition monitoring data rendering this approach not suitable for the tracking of certain high-value assets such as paintings, etc.
Muller et al. [
15] propose the use of a distributed ledger (DLT) to monitor the handover management of high-value parcels. Sensors are deployed inside parcels to monitor their contents and log violations of service level agreements. The fact that the sensors are placed inside the packages allows the occurrence of logging during the package handover process (handover from one carrier to another, or from the carrier to the receiver) without the need to open the package, saving time and catching problems early. The sensors in the work are not provided with a physical security system, allowing potentially corrupt data flow from the sensors to the DLT. Our reference architecture includes physical sensor security.
3.3. Industry Practices
Now, we discuss IoT-based asset tracking solutions designed and/or used in different industries. We also highlight their limitations, and provide the rationale for them being unsuitable for tracking different types of assets. We discuss tracking solutions that cover transport and on-site use cases. Fortecho is a UK-based asset tracking solution provider. They design monitoring systems for high-value artworks in museums, private collections, and super yachts. The tracker employs active RFID tags equipped with sensors, namely temperature, humidity, pressure, vibration or a three-axis accelerometer to monitor the conditions of artwork. There is a security mechanism to detect whether the tags have been removed. Readers are interrogated at 200 Hz by the backend software to detect whether they have been compromised and/or RF jamming attacks are occurring. Fortecho’s tracking solution has some limitations as discussed below. First, it does not cover art transport meaning that their solutions are tailor-designed for display or storage use cases of super yachts. The dependence of its sensor readers on wired communication (Ethernet or serial) prevents its use for art transport. Second, we noted that the Fortecho sensors perform no edge computation and were limited to only one type of sensor per tag, temperature, humidity or vibration. Such trackers cannot be used in applications with the requirement of sensing multiple conditions simultaneously.
Next, we discuss a few solutions that cover transport. Azure IoT Hub by Microsoft provides a backend to a tracking solution with features to connect, monitor, and manage the IoT assets [
2]. It allows bidirectional communication between devices and the cloud with some security features like device authentication and over-the-air updates. Maersk uses Azure IoT Hub to track and monitor the IoT devices deployed on its refrigerated containers as they move around the planet. The condition monitoring data can be monitored so that shipments arrive safely. Recently, Michelin, Argon Consulting and Sigfox France partnered together to create a tracking solution called Safecube that provided real-time supply chain visibility based on condition monitoring [
16]. The solution was based on a 0 G network technology with intercontinental coverage in over 60 countries. Another important partnership is among Deutsche Post DHL, ALPS Electric Europe GmbH and Sigfox that aims to design a tracking solution to optimize the individual processes within DHL’s supply chain [
4]. The idea is to monitor roll cages with networked sensors to track them in real time with high visibility.
Post Luxembourg provides track and trace solutions for its postal services nationally and internationally. It covers Europe, New York, Hong Kong and Singapore. The tracking solution uses LTE-M tags for the machine to machine (M2M) communication over a proprietary, international LTE network. Hardware specifics for Post Luxembourg’s track and trace service have not been described. The tracking incurs some cost and provides 30 Mb and 50 SMS per month, meaning that at maximum two updates can be sent about the shipment. Thingfox provides asset tracking solutions for trucks, freight trains, cargo ships, and aeroplanes covering different modes of transport such as land, sea, and air. The tracker is of the size of a smart cell phone with a 6000 mAh battery. It is connected to a backend over BLE. It supports global connectivity with LTE and localization is achieved by GPS with Beidou or GLONASS. The Thingfox tracker cannot be used for tracking assets as it is difficult to put a device with such a large battery on many assets such as art as it can affect/damage the condition. Google Cloud also offers asset tracking via LTE and Wifi. Another solution is from Cloud Hawk that offers asset tracking via LTE. LTE is the most commonly used solution, but it becomes expensive for a large amount of communication wherein the tracker must report condition monitoring data very frequently. In all cases, communication security is the same as that provided by cellular communications in general.
3.5. Extant IoT for Logistics Threat Models and Studies
In this section, we review current, published threat models for Wireless Sensor Networks (WSN) and Internet of Things (IoT) systems. We show that there are no application-specific threat models that focus on the communication of IoT devices used for logistics, or address non-malicious threats that may disrupt the operation of the sensor system. We also discuss the threat categorizations and threat model methodologies to justify the categories chosen for our threat model.
The authors of [
20] provide a high-level overview of general IoT threats. This paper provides a lot of detail but does not relate the detail to an application. IoT devices, and embedded devices in general, have operational environments defined by their applications. These environments may add new threat vectors. We consider this in our work.
The threat model presented in [
21] follows a common pattern in the discussion of WSN/IoT threat classification, reducing attacks into two classes, active and passive. We do not see this categorization lend anything to the understanding of potential attacks, nor their countermeasures, so we do not adopt this approach.
Turakulovich et al. [
22] describe common communication layer attacks and specific security protocols for different communication technologies used in WSN. The paper compares the energy consumption of protocols to the number of mitigated threats. It does not provide suitable details to describe the flexibility of the communication protocols for different use cases nor the possibility of new or exacerbated threats due to the application.
Buntun et al. [
23] categorize threats by passive and active attacks. They further divide active attacks into a five-layer version of the OSI communication model. Unfortunately, Buntun et al. do not extend the communication model subdivision to the attacks in the passive category. They discuss countermeasures to different attacks offering either general advice or the names of specific research tools. Once again, there is no coupling between a specific IoT application environment and its specific threats.
Jadhav et al. [
24] provide less information or structure than the others reviewed here. The paper is notable as the only work to include a small section on environmental, or non-malicious, threats. We also include a taxonomy of such threats that occur in the logistics environment.
Dewal et al. [
25] classify protocols as high-level and application-based and describe defensive measures using a security framework. Mamdouh et al. [
26] provide a two-dimensional classification of potential threats based on the orientation of the attacks, active or passive, and the communication layer. This paper then offers an interesting introduction to the use of machine learning (ML) for security. We suggest an ML technique, anomaly detection, as a potential countermeasure given our application.
The work presented by Patel et al. [
27] is notable because it defines different types of IoT system networks and the different applications that would use these networks. It does not deeply examine the security considerations of each type of network nor applications, but does try and classify the different types of applications. We create a threat model that specifically targets application.
The work presented by Raja et al. [
20] outlines threats and attacks for a generic five-layered IoT architecture consisting of application, middleware, internet, access gateway, and edge technology. It further discusses IoT wireless communication technologies, operating systems, communication model, security requirements, etc. This work also highlights some application-based weaknesses, namely spoofing, repudiation, tampering, information disclosure, and DoS present in the OWASP framework. Additionally, some high-level attack surfaces for IoT are described with examples taken from different application use cases. The main issue with this threat model is that when it comes to a specific application use case, the system owners may not know the impact of these attacks, and the system entities that require most protection. Vulnerable system entities may change from one use case to another. For instance, the resources needed for designing a DoS attack on an edge device are different from the one designed for a sensor node. With different types of sensor and IoT devices being deployed in logistics, it is essential that customized threat models are designed for them.
Rizvi et al. [
28] highlight the attack surfaces for a user-centric IoT network. The network considered in this work is similar to a distributed computing environment where local users are feeding data into remote servers to be used by data analytics services. The threat model proposed in this work is not appropriate for IoT systems where machine-to-machine (M2M) communication between entities is the primary mode of communication, such as logistics, supply chains, smart industries, etc.
Anand et al. [
29] present a generic threat model for IoT systems. A notable contribution of this work is to map threats to attack surfaces and the vulnerabilities that have been exploited to design them. The work further presents the threats and vulnerabilities for two case studies of smart transportation and secure energy management systems. Rizvi et al. [
30] present a threat model for IoT devices deployed in healthcare, commerce, and homes. They pick up one or two devices in each domain, underline the threats and compute their vulnerability scores based on the NIST CVSS [
31] model. The scores are assigned based on the authors’ understanding and judgement of the likelihood of certain vulnerability to be exploited and the associated attack taking place. We believe it would have been better if the scores were computed from experiments. Our threat model is different from those of Anand et al. [
29] and Rizvi et al. [
30] because we mapped threats to a superset of the TCP/IP communication model. We believe this mapping is important to identify the security threats for resource constrained IoT devices and take appropriate countermeasures.
Wang et al. [
32] present a threat model for trigger-action IoT deployments. The authors argue that the system behaviors in these systems are modelled with complex rules that make it difficult to diagnose the faults and errors. They propose a methodology to infer trigger action rules using Natural Language Processing. This approach is novel but we believe this work is in its early stages and needs time to mature to be used for threat modeling of IoT systems.
Simonjan et al. [
33] present a threat model for visual sensor networks security attacks. The threat model is classified based on the STRIDE taxonomy, and security vulnerabilities are mapped to a common weakness enumeration list.
Threat taxonomies such as STRIDE, PASTA, DREAD, and OCTAVE cover the threats for general distributed systems [
34].
The main challenge with threat models that are based on the above-mentioned classifications is that they are not suitable for IoT systems with M2M communication.
Anand et al. [
35] take an interesting approach to threat modeling based on a machine learning methodology called Transfer Learning (TL). They argue that new threats with varying distributions emerge in different domains from time to time and signature-based anomaly detection algorithms are unable to detect these due to unavailability of labeled data. The learning-based threat model outlines the threats and attacks for a smart home. The authors also show that their proposed model detects unknown threats better than the state-of-the-art models.
The literature on existing IoT-based logistics solutions shows that IoT devices are being integrated into current logistics systems, and that no one technology or approach is suitable for all types of assets.
The most significant limitations are the lack of a security approach to the protection of logistics IoT systems against cyber attacks and the failure to address physical attacks and disruptive non-malicious threats. All of these potential threats need to be addressed in the design and implementation of a logistics sensor system that see use. The cyber security challenges related to logistics and supply chain have not been well studied by research or industry. In this section, we presented current security issues with the use of IoT/WSN systems in logistics.
From the literature review of the existing threat models, it is clear that there is a gap for application-specific threat modeling that includes the most obvious threats such as communication as well as other potential physical and environmental threats. To fill this gap, we propose a threat model designed for logistics and supply chains. In the next section, we present our system model, a generalization of the architecture presented in
Section 2; the organization of our threat model, including how we classify threats; and the categories that we include.