The available devices equipped in the networks are essential to confirm whether a proposed system can work with existing facilities. This section presents our assessment on the attack model and the important assumption to understand our proposed approach in the next section.
3.2.1 Assumption
TrioSys was developed for the next-generation networks in mind such as 5G. Besides the connectivity, we also assume that MEC-based servers are supposed to support in the network by default. More importantly, these servers can offer their processing capacity to the client requests without a significant effort, i.e., the server is accessible from any Internet-connected endpoint. Also, since TrioSys can deal with various applications in different slices of IoT, the network protocol is supposed to a fixed type, e.g., IP. Indeed, several applications such as V2X road-safety applications use their own protocols, e.g., Wave Short Message Protocol (WSMP), instead of IP. This difference may influence the attack model and thus the deployment location of the framework components. We clarify the protocols in the implementation of TrioSys for each specific case in the next chapters.
In addition, we denote the identity for the network layer as the unique information we
can get to reveal partially or fully about the user. Following the definition, the identity can be an IP address or a “node ID,” depending on the considered applications.
In terms of the collaboration, TrioSys is oriented towards both local detection and the global handling, in which the detectors in a distributed area can share the results through synchronization and a proactive ask-request scheme within a calculable delay. For simplicity, we combine the time into a unified measurement metric, the response time to the attacks. Also, due to the importance of sharing the learning among the detectors, data integrity is a must. As the popularity of secure communication protocols in networking, e.g., TLS, we assume that the data exchange among the components of TrioSys is trustable and not intervened by the third-party partners (for example, replay attacks). In terms of privacy requirements, we follow the provisions covered in 5G technical specifications. For example, the 5G-supported end-users can be granted with anonymous temporary identities such as pseudonyms, which will be valid for a reasonable period (e.g., up to 30 minutes).
Also, in practice, the network operators must often have a legal responsibility to preserve the client’s privacy under the law; therefore, an extensive assumption to protect the data against the network operators may be unnecessary. For the other assumptions related to specific applications, we will reveal them at the implementation of the framework in specific cases in the next chapters.
3.2.2 Adversary model
In IoT, an attack can be internal or external in terms of its position. An external (or outsider) attack such as jamming refers to an attack type against IoT devices without any special privilege (possessing no secret key) to access the network/device. In contrast, an internal (also namely insider) attack implies that a device is compromised and allowed to freely access the network or communicate with other devices with the keys. Note that external attacks such as physical attacks can be used to gain necessary access for internal attacks. Intuitively, the insider is much harder to detect. As we stated in Chapter 1, in this work, we focus on the attacks towards two targets (network availability and data authentication), which typically represent two attack types: DDoS (outside) and data falsification dissemination (insider).
The first target attracts variants of attacks such as DoS and energy-depletion to shut down the devices, even the whole network, or significantly worsen the service quality, e.g., slowly responding to the legitimate client’s requests. So far, few thorough system
can defeat this kind of volume attacks. Seriously, more variants of such attacks (e.g., Mirai-based DDoS) come out to headline every day. The volume attacks mostly come from the outside attackers.
IoT Gateway IoT Network model
Internet
Applications IoT Local-access protocols TCP/IP-based protocols (support TLS)
Spoofing attacks using network vulnerabilities
Compromised devices falsifies data
DoS Attacks
DoS Attacks
Figure 3.2.1: The position of the attacks in the structure of three layers (Things/Devices, Edge and Cloud). Most of the broadcast false data come from the Things/Devices layer or physical/MAClayer, while the spoofing and volume attacks such as DoS/DDoS target the network layer or application layer.
In contrast, the second attack type indicates a typical insider attack, in which an attacker may intentionally disseminate false data to the receivers. While the source authenticity and message integrity can be protected via cryptographic schemes such as digital signatures and certificates, ensuring the validity of data content is much more complicated and cannot be merely done in this way. An insider attack can simply use valid/multiple stolen identities to pass the message authentication in the public key infrastructure (PKI), and thus broadcast the false data without special efforts. Moreover, in another case of this attack type, namely collusion, several nearby users, e.g., vehicles, may collaborate to report false data. This collusion aims at evading detection by trusting a majority of honest users and thus even mislead many existing detectors.
The insider or outsider attacks can happen at any layer in the network model. Fig. 3.2.1 illustrates the attacks within the case of targeting network availability and data authenticity.
Most of the broadcast false data come from the Things/Devices layer or physical/MAC
or application layer. Finally, we assume that the attacker can be any in the network.
Therefore, we do not use a simple majority rule of surrounding honest nodes to enforce the security to build this system.