Abstract
Introduction
A Long with the rapid development of Internet of things (IoT) technique, this method has been involved in various fields such as medical, industrial, transportation, and finance. The society relies more and more on IoT, extra attentions also need to be paid on its security risk. Usually, IoT networks are deployed in remote and distributed places, and network gateways communicate with these devices and report relevant information to administrator. 1 In normal conditions, all the data reported to administrator are assumed to be trusted. However, with potential security risks like system vulnerabilities and intrusion, the data collected and sent by IoT gateways could be forged and tampered. It may be too late for the administrator to find out the abnormity and make reaction. In extreme cases, the merge of attack flow of IoT network could cause large-scale Internet security incidents, like Dyn DDoS Attack 2 and Mirai DDoS Attack. 3
The deep reason of these attacks is because IoT network is vulnerable and all the IoT network flow is converged without any supervision and autonomic reaction. Intrinsic security thought brings new ideas to IoT network security. This concept is different to the hardware-based intrinsic security like. 4 Nili et al. 4 focused on hardware technique like nonlinear conductance variation to prevent electron component from cloning, which is not related to our topic. In this article, we would like to create a new network system which is built with trust and security autonomy. This security architecture prevents IoT attacks from or near the source. As a consequence, scale of DDoS attack will be reduced dramatically. Intrinsic security insists that network needs to be born or designed with security features. More specifically, trusted is the basic, and security autonomy is network’s organization form. By this way, security incidents in IoT network can be handled inside the IoT network domain and prevent the spread of attacks. Figure 1 shows the difference between normal IoT security architecture and intrinsic security architecture. Intrinsic security changes the security topology of the existing system which has a vulnerable center node, embeds security capability to every domain in IoT network. In these domains, network gateways have security information process ability and trusted root. In intrinsic security network there is no central node with absolute authority, every gateway needs to communicate with each other to make comprehensive security decisions. Also, changes of security status of gateways during lifecycle will also be dynamically detected and evaluated.

Architecture of regular IoT network and intrinsic IoT network.
Compared with normal IoT security model, advantages of intrinsic security are listed in the following:
Trusted: every domain in IoT network has trusted root to execute security actions. Security risks can be limited inside domain without spreading out.
Decentralization: Intrinsic security does not require specific centralized node to manage system’s security. The decentralized structure reduced security risk from single node’s compromise.
Easy to deploy: It is easy to deploy without any central security management node.
The specific sections of this article are structured as follows. Section “Related work” describes the related work of decentralized autonomy and trusted computing. Section “Architecture of trusted autonomy security system” describes the architecture of trusted autonomy security system. Section “Trust anchor” describes the design of trust anchor and its implementation in TASS. Section “Autonomy” focuses on how to implement decentralized autonomy architecture in TASS. In section “Evaluation of TASS,” the security and performance of the prototype are discussed. In the end, we make a conclusion and discuss the future work.
Related work
Trust and decentralization are TASS’s basic features. Relevant research and technologies have been studied for a while and approached certain achievements.
Decentralized autonomy
In decentralized autonomy field, blockchain 5 is an emerging technology, through which decentralized consensus and storage can be approached. Blockchain is composed by a series of functions like decentralized networking, data tamper-proofing, consensus-based trust construction, and the mechanism of automatic execution of contracts. These provide a distributed autonomy platform and establish connections between multiple partners. Blockchain technology changed the traditional network structure from “series” to “parallel.” For example, in the architecture of Dapp, 6 applications run in a decentralized way in different terminals. Blockchain is also widely used in IoT area, such as blockchain-based identity authentication, 7 tracing of hardware, 8 and threat intelligence sharing. 9 In our thought of intrinsic security, Blockchain could be used as the decentralized platform and make security autonomy practicable.
Typical distributed consensus algorithms include KAFKA, 10 PBFT, 11 POW, 12 and RAFT. 13 Among which, POW relies on workload proof to realize decentralized computing and consensus. For reaching consensus, the mining function’s computing scale need to be large enough which is unacceptable by IoT devices with limited computing resources. Like Bitcoin 14 who uses POW to mine coin prize can barely cover electric charge right now. In IoT, the feasible choice should be the limited-scale decentralized algorithm such as RAFT and PBFT. Normally, RAFT is used in private chains which only have malfunctioning nodes such as power off or offline. But in security situations, we have to assume that there may have evil nodes in distributed system. That means we need to use consortium chains to construct consensus in IoT network, in which PBFT is the appropriate choice. From the principle of PBFT, when less than 1/3 nodes failed, it still can be considered that the distributed consensus mechanism is effective, and the data in the block chain is complete and not tampered.
Trusted computing
Trust is the basis of TASS, trust computing techniques like TPM, 15 SGX, 16 , DICE, 17 and Trust Zone 18 provide trusted roots in hardware. In IoT gateways, lack of trust in IoT will lead to the freedom of selecting untrusted or even malicious data to upload to chains. And without trust, the perception layer, transportation layer and application layer of IoT network will also be affected. 19 Distributed consensus algorithm guarantees that data after uploaded to chains can reach consensus and keep integrity, but it cannot guarantee whether the device have chosen the real data to upload to chains. If one device is malicious, the data it chose to upload cannot be trusted even the consensus mechanism is valid. When PBFT, RAFT, and other private chain algorithms are used for decentralized IoT system, malicious IoT nodes can upload fake information to puzzle decentralized system without any security restrictions.
As far as we know, several studies have tried to solve this problem in different ways. Urien 20 tries to provide security of distributed system by TLS/DTLS stack, Link Key, and WPA. Khalifa et al. 21 presented trust requirement model of block chain system. Samaniego and Deters 22 attempts to settle trust problem in blockchain IoT system by means of Zero-Trust. 23 This theory was first proposed by Google Beyond Corp, which is featured with context aware and dynamic access control. It evaluates device by its dynamic behaviors instead of static certificates. Chen et al. 24 attempted to secure block chain information between communication terminals in form of encryption. Although these schemes have adopted different methods to address a security decentralized system, yet they have not addressed the question that the contents before uploaded to decentralized platform cannot be trusted.
Architecture of trusted autonomy security system
The diversity of IoT devices’ architectures and computing resources make them almost impossible to apply a unified security framework. Fortunately, IoT gateways construct network domains for IoT devices to access, and they are also the direct manager to manage IoT devices. IoT gateways could have functions such as network mandatory access control and device status detection. In TASS architecture, all IoT devices gains access to network by gateways. And gateways could connect to each other by means of flexible network protocol like Mesh 25 or wired network. In traditional network topology, IoT gateways need to use centralized management center to manage their security. But in TASS, IoT gateways connected with each other in a decentralized way. In this network, each IoT gateway manages and evaluates IoT devices that have accessed to it. And security information will be shared among gateways in the whole decentralized system. In Figure 2, we presented the specific architecture of TASS in gateways.

Architecture of trusted decentralized security system.
In our design, TASS is composed of two components. The first component is trust anchor, which provides trusted endorsement for TASS both in booting time and runtime. The concept of trust anchor is derived from trusted computing technique, but with different details. In TASS, trust anchor not only provide root of trust for measurement and storage, but also provide root of trust for transfer. In decentralized systems, trust information need to be shared in all trust nodes to compose a “trust alliance.” This function makes trust anchor a unified logic domain that can be relied by decentralized system like TASS.
The second component is decentralized security autonomy platform, which is used to provide decentralized architecture and security management. Decentralized security autonomy system is in application level, it maintains blockchain subsystem and security management subsystem. Blockchain maintains a consortium chain to store and distribute security information during TASS’s lifecycle. Security management focuses on access devices that attached to each gateway. IoT devices’ network status and behaviors also will be detected and reported by security management subsystem in real time.
Trust anchor
We chose the concept of TPM to construct trust anchor. TPM was first provided by TCG group. It uses a hardware chip as trusted root, and insures system’s booting integrity by trusted measurement, trusted encryption, trusted report and trusted connection. However, TPM has its defect that it cannot meet the security needs of TASS. For example, TASS need runtime trust and transfer trust in gateways to build an entire lifecycle trust system, which cannot be provided by TPM.
In order to fit IoT network’s security requirements, we use trust anchor to replace traditional TPM concept. Trust anchor is not only part of trust chain, but also an intrinsic structure designed in TASS. In trust anchor, boot anchor replaces the original TPM + BIOS trusted root, and runtime anchor make runtime integrity detection available. In addition, we designed trust transfer in trust anchor to make trust information flow in different IoT gateways. Figure 3 shows the logic location of trust anchor in TASS. Trust anchor makes TASS a trusted system with distributed trusted nodes.

Trust anchor in trusted autonomy security system.
Boot anchor
In traditional concept, a static trust chain generated by TPM can represent the trust of system. But in IoT network, there has been a flaw for static trust chain. In TPM, system’s trusted root is derived from CRTM (Core Root of Trust for Measurement), which is composed of TPM and first part of BIOS. IoT system usually uses Uboot as the initial boot program, which can be easily programmed or tampered through serial port in motherboard. Hence, for a higher security purpose, we use TPCM (Trusted Platform Control Module) as trusted root to instead TPM. TPCM changes IoT device motherboard’s start-up sequence to make sure the hardware trusted computing chip is the first equipment to be powered up. It avoids software like BIOS as part of CRTM, make booting period totally depend on trusted computing chip.
We use TPCM to store HASH of Uboot, and based on electronic encryption, this digest cannot be modified by serial port or other programming methods. Also, TPCM have a control module to prevent CPU from powering up at the beginning. When IoT device is powered up, TPCM will execute self-test first.
Specific steps of boot anchor’s establishment are shown in Figure 4. In step 1, reference value of Uboot will be loaded to TPCM’s nonvolatile store. Then, IoT gateway can powered up. Step 2, controller of TPCM, makes CPU keep power-off status. TPCM verifies the image of Uboot in NOR Flash. Step 3, if the measurement result of Uboot equals to reference value, TPCM will handle its control right to CPU of this device, which is step 4. In step 5, CPU acquires control of motherboard and launches Uboot image. Next, steps of measurement will be executed in sequence.

Start-up sequence of boot anchor.
In boot anchor, we constructed a strict trust chain of IoT gateway. In IoT environment, there is a possibility that IoT gateway can be accessed by hacker in physical. If there is no security mechanism to protect gateway’s storage like Uboot and kernel image, trusted root in it can be tampered easily. But boot anchor guaranteed that even in physical contact or under other advanced attacks, trusted root of gateway can still be trusted. As a consequence, all the data generated by gateways can be uploaded to blockchain as real information.
Runtime anchor
Another reason we use trust anchor is that TPM only guarantees system’s integrity in start-up stage, the runtime stage of system cannot be guaranteed or detected properly. Boot anchor only settled the problem of trusted booting, runtime security of gateway also needs to be protected. Runtime anchor focuses on files change when system is running. It makes sure that during the runtime files like elf, so, and ko will not be tampered.
Runtime anchor is based on IMA (Integrity Measurement Architecture). In the design of IMA (Integrity Measurement Architecture), it records every change of files and upload it to a list called ML (Measurement List). At the same time, IMA provides appraise mode as its control module to prevent files from unauthorized change. However, IMA has no limitations to users with root authority. If gateway leaks its root authority or user privilege escalation attack, the protection of IMA will be inefficient. In order to solve this potential issue, we changed the logic of IMA appraise mode. We modified the judgment logic of IMA to deny file write request from root user. After our modification, any overwrite of ko, elf, config, so, and sh are not available. Files under this decision can also be updated, but the only way is rewriting OS image in motherboard.
In runtime anchor, in order to evaluate every gateway’s runtime security status, we also monitored the runtime information of processes in system. We set hooks in runtime anchor to collect process information in OS kernel. And this information is listed in the following:
process creation log
process running list
file access log
file update log
AS an IoT device with settled application scenario, gateway in TASS should not have any unexpected behaviors. The process list and file operation log should follow certain rules that can be predicted to all gateways in the same network.
Trust transfer
Figure 5 shows the logic path of trust transfer. Logically, trust is originated from trusted computing chip. Then trust is transferred to boot anchor, then to the runtime anchor, then to the decentralized platform, and finally to the IoT network.

Logic trust chain of security autonomy.
While the physical path of trust transfer in TASS is shown in Figure 6. In this figure, trust anchor is first created by gateways respectively. Then, gateways pass the trust information to decentralized platform. In this platform, trust information like ML and process log need to reach consensus between different gateways. When a gateway tries to participate in TASS, it first needs to use password configured by administrator to join the LAN. Second, it needs to upload its AIK (Attestation Identity Key) pub key to let other anchors know its identity. Then the new gateway will upload its trust information like ML and process information signed by AIK private key to let other anchors evaluate its trust status. If the number of agreement nodes is equal or greater than f + 1 and 3f + 1 <= N, then a trust consensus is reached. Here N is the number of total nodes in LAN, f is the maximum evil node number in LAN. The consensus process is listed below.

Physical path of security autonomy.
In single trusted computing model, we assume the probability of trust failure is p. In TASS, we use PBFT as decentralized consensus algorithm. This algorithm will be invalid when 1/3 or more nodes are compromised. This means only one-third or more gateways in TASS invalid could cause compromise of TASS. AS a consequence, the probability of trust failure in TASS is
It is obvious that TASS is more secure and stable than single trust model because the risk is separated by decentralized system. The combination of trusted computing and decentralization could form a complete trusted chain from device to decentralized platform and IoT network. This benefit ensures that contents in IoT network are trusted and could map IoT status directly. However, decentralized architecture can also reduce the influence of single trusted node’s invalidation. Based on this analysis, TASS can not only have the flexibility of networking and deployment but also has higher security and credibility.
Autonomy
Autonomy system in TASS has two modules: blockchain platform and security management. In which, security management is in charge of access side device management, and blockchain is used to provide decentralized platform and consensus algorithm. These two parts make IoT gateways achieve the function to manage IoT devices in a distributed way.
Blockchain to decentralize
Block chain is the mechanism to realize decentralized management and consensus. In section “Trust transfer,” we already introduced blockchain to run trust transfer. From the perspective of TASS system, blockchain is application layer software. All the gateways in TASS maintain this consortium blockchain system. Gateways use blockchain system to reach consensus and transfer trust information and security management information.
In Figure 7, there are two kinds of transactions: trust anchor transaction and security management transaction. Local data of trust information and security management information in IoT gateways will be uploaded to blockchain. And chain code will also monitor blockchain to accept information from other gateways. In blockchain system, every transaction of trust and security will be recorded in blocks. Gateways in TASS could use these blocks to evaluate IoT network and devices’ security status. With the advantage of decentralized consensus of blockchain, these blocks cannot be tampered by any single node.

Architecture of blockchain system.
Security management
Since the purpose of TASS is to form an IoT network and manage IoT devices, it is necessary to address how to monitor IoT devices that have accessed to TASS. Usually, hardware information like MAC and certificates are the features to evaluate access side device’s identity and security status. But without trust anchor in access side devices, this information may be tampered or at least untrusted. In addition, the heterogeneous of access side devices makes it difficult to deploy unified security architecture inside.
An appropriate way to manage access side device is dynamic awareness, which could evaluates device by its dynamic network behaviors. In TASS, dynamic awareness evaluation can be implemented by analyzing access device’s network flow. And according to security strategy requirements, there are two way to implement this dynamic analysis: enforce evaluation and flex evaluation. Enforce evaluation is similar to whitelist mode. In this mode, only flows in which target addresses and URLs have been permitted by TASS are allowed to access and transmit in gateways. This mode is simple to deploy that administrator only need to list out whitelist behavior. Also this mode is too strict to forbid any unexpected behavior.
Flex evaluation is similar to blacklist mode, it only estimate if an action or access is forbidden by blacklist in TASS. Obviously, it is impossible to enumerate all malicious addresses in one local blacklist file. A feasible method is to create a network behavior analysis model to estimate if the behavior of access side device is legal, and machine learning is an appropriate method. 26 For example, KNN, 27 SVM, 28 and LOF 29 can be used to train a behavior model to judge whether the access side device is abnormal and infer the security state of the device later. This approach reduced the scale of blacklist in TASS and is feasible in lightweight IoT gateways. The disadvantage is that the application scenarios and network behavior of access side device need to be pre-collected and trained. When application scenario changes, network behavior analysis model needs to be updated to fit new network behavior. Also, precision of flex model is not as accurate as traditional blacklist model.
Evaluation of TASS
Based on the description above in this article, we made a prototype of TASS as shown in Figure 8. In our system, TASS gateway is based on the hardware of MTK7621, the detail parameter of which is shown in Table 1. Meanwhile, the start-up sequence of this motherboard is modified to deploy TPCM module to support trust anchor. As for blockchain system, we use hyperledger fabric 30 and PBFT algorithm to realize decentralization and consensus. And security management is set up as enforce mode. Also, we simulated several virtual gateways to communicate with the physical one to evaluate the performance of TASS.

Prototype of TASS gateway.
Information of MTK7621.
TPCM: Trusted Platform Control Module.
Trust anchor performance
Trust anchor is the fundamental of TASS’s security. When gateway is installed with trust anchor, both its booting time and response time will be affected. Figure 9 shows the comparison of booting time between boot anchor and regular motherboard. The average booting time of motherboard with trust anchor is 153 s, which is 60 s longer than regular architecture. The main reason of this delay is that the trusted computing module needs to measure the image of Uboot and establish an integrated trusted chain. Fortunately, gateway is not a device that need to boot frequently, which eased the impact of this delay.

Booting time comparison.
The influence of runtime anchor is another factor that may reduce gateway’s performance. In this customized gateway, we use applications in BusyBox to test the latency of runtime anchor. The result shows that the average delay of runtime anchor is about 3%, which is a slight amount in overall performance. We also compared CPU and memory usage between original gateway and customized gateway. The original CPU usage rate is 10%, and TASS increased 1% of CPU usage rate. At the same time, memory usage increased 12 MB on the basis of 80MB. To sum up, the influence of trust anchor is limited for gateway.
Decentralized security autonomy platform performance
In order to reach consensus by PBFT, there are five steps need to be executed: request, pre-prepare, prepare, commit, and reply. Once transaction is triggered, it will be uploaded to blockchain after consensus is reached. We use one TASS prototype and certain QEMU virtual machines to measure the autonomy performance. The QEMU virtual machines load TASS image and run as virtual gateways in host OS. In order to improve the accuracy of performance evaluation, the configurations of QEMU virtual machines are the same as our prototype. And the monitoring point of transaction time is set in TASS prototype to record the time span from request to replay. The specific results of consensus time are shown in Figure 10.

Consensus time in different node. (a) Node Num: 5. (b) Node Num: 7. (c) Node Num: 9.
When there are five gateways in TASS, the average time of consensus is 322 ms, and the standard deviation is 174 ms. When there are seven gateways in TASS, the average time of consensus is 342 ms, and the standard deviation is 155 ms. When there are nine gateways in TASS, the average time of consensus is 413 ms, and the standard deviation is 185 ms. The comparison result shows that the consensus time grows along with the node number. In fact, the time complexity of PBFT is O(N2). 31 Based on this time complexity and data fitting process, we can make an estimate of performance trend. The detail is shown in Figure 11. And data fitting function is listed in the following

Consensus time data fitting result.
It indicates that the consensus time of TASS will increase to almost 60 s when there are 100 nodes inside. This delay cannot be accepted in most IoT security systems. This also suggests that in PBFT algorithm there should better have less than 100 nodes. Fortunately, this defect could be solved by the architecture of hierarchy. Hierarchy could separate nodes in different levels like multi-way tree to downsize the consensus scale, and we will research this issue in our future work. To sum up, when nodes number is in a relative small number like 20, the hardware of MTK7621 could form an IoT LAN featured by TASS appropriately.
Conclusion
In this work, we proposed the concept of intrinsic security of IoT network. In order to resist network attacks like DDoS and system intrusion, this concept insists that security system must be trusted and autonomous. And based on this idea, we designed a decentralized security architecture TASS, which uses trusted computing technique to create security anchor and establish trust basis, uses decentralized algorithm to transmit security information and operate security management. It is obvious that TASS has certain advantages compared to traditional system: trusted, decentralization, easy to deploy.
Based on this prototype of TASS, we will conduct more research about the theory like hierarchical consensus and application of intrinsic security, like in the NFV network, 32 deterministic network, 33 and industrial Internet. 34 We believe that this security concept and architecture will have more progress and application in the near future.
