# Approaches and Challenges in Internet of Robotic Things
## 4 IoRT Security  
Security is a major concern in the connectivity of robotic things [46]. IoRT has significant challenges in terms of security and protection to enable effective collaboration with networks, sensors, and robots. Companies that collect data from robotic systems face the biggest risk from IoRT. Because IoRT networks are still connected to the Internet, new sorts of data breach attacks can be launched against them [3]. There is always a need for communication protocols for data transmission and processing. Therefore, the communication between robotic things must be encrypted, which often does not occur. The Dieffie-Hellman concept is also used for data encryption for the security of a system's communication [24]. To address security concerns, a secure method has been developed that includes a requirement to register IoRT devices using a digital certificate, as well as a user to the cloud server. For a cloud-based IoRT network, we need a three-way (CIA triad) security architecture [76]. To convey information in a secure approach accumulated by robots, secure frameworks are needed with respect to integrity and confidentiality. The IoRT system should be encompassed with physical access security frameworks for verifying data, maintaining trust and privacy, and keeping the data confidential [6; 19]. A security taxonomy is given in Figure 10, which describes the generic security threats and threats at the architecture level of IoRT. In addition, the Internet is the basic source of threats and vulnerabilities to robotic things because it is the basic building block of the IoRT device's communication and connection. Non-standardization of IoT technologies has increasedthe frequency of security breaches daily, which has increased the vulnerabilities. Some machinery or physical and boot process vulnerabilities are generic issues that apply to the whole IoRT system. Security assaults are also a result of the HRI. IoRT companies supply some security and data protection mechanisms for the safety of user data. However, the effectiveness of protection against vulnerabilities is uncertain and may or may not be guaranteed. Phishing and security breaches are also caused by users' and employees' lack of awareness. IoRT devices are also responsible for a large percentage of denial-of-service assaults (96%) [77]. Threats to the IoRT architectural layers exist as well. Eavesdropping, battery exhaustion, hardware crashes, data breaches, and unauthorized access to IoRT systems are all possible threats to the physical layer. Spoofing, node replication, and fraudulent message bombardment to gateways for denial-of-service assaults are all threats at the network layer. Because this layer connects numerous private LANs, the MAC or network layer is extremely vulnerable to attacks. The risks of brute-force attacks on encrypted data and malicious code at the application layer are also risks to IoRT devices. Thus, there is a necessity for a dependable data transfer service for IoRT [76,78, 79, 80]. There are several well-known attacks on ad hoc wireless networks, as listed below, including network attacks (a to d) and the trust model itself (e to g) [33]. Packet dropping or modification attacks--black hole and gray hole,  
Wormhole attack,  
Sybil attacks,  
Newcomer attacks,  
Badmouthing attacks,  
On-off attacks,  
Collusion attacks. IoRT makes use of trust-based techniques to protect the system from vulnerabilities and threats. One of the trust-based mechanisms is threat modeling, which is used to launch  
Figure 10: A taxonomy of security threats in data exchange. data-sharing security attacks. A threat model is similar to assumptions about an intruder. The threat model's mechanism ensures that the data policy (data should have confidentiality, integrity, and availability) is followed as long as the intruder follows the threat model, which means that, if the threat model is right, it should be able to follow the policy. When security fails, the threat model mechanism is usually to blame.