# Collective Attestation for Manageable IoT Environments
## 5 Protocol Extension  
**Authenticating requests. ** Due to the characteristics of the swarm attestation, a request can incur a heavy overhead on communication and computation to a swarm network. Thus, as the Denial of Service (DoS) attack, the adversary can send a forged request to consume the energy of a swarm. To prevent the DoS attack in the swarm attestation, SANA [21] lets the verifier presents a request token, which can prove the legitimacy of the request by the devices. SeED [22] employs the non-interactive attestation, where the attestation is triggered by a timer preset by a seed-shared pseudo random number generator (PRNG), to eliminate the request itself. However, SANA adds more public key cryptography operation in authenticating the request token and SeED requires an additional Real Time Clock (RTC) hardware. To prevent the DoS attack in CAMIE and to make the swarm publicly verifiable, (SANA coined the feature in [21]. Anyone authorized for the attestation can verify the attestation results), We authorize the verifier and authenticate the request in a publicly accessible way. However, if we use the expensive public key cryptography operation to authenticate the request, it can be another DoS attack on the attestation initiator (the first device in the attestation tree) even if it is a false request. In addition, the approach of using the preshared key in the device to authenticate requests is not flexible for the public verifiability. Thus, we externalize the authentication by employing blockchain [35]. Recently, blockchain has been used to help with the authentication of IoT devices [36; 37]. In blockchain, every transaction is securely validated by voluntary validators, called \"miners.\" In addition, we can build an application-specific token system on top of the blockchain system. Since every execution and transaction is confirmed, the overlaid token transaction is also securely validated. That is, the token cannot be doubly spent or transferred. (One can refer to the ERC-20 token standard [38] for the explanations on the token architecture and its applications.) The network operator sets its own token for attestation on the blockchain. The devices store the address of the network operator in the protected storage at deployment. Then, when a candidate verifier asks the permission for attestation, the network operator gives a token to the address of the verifier if the candidate verifier is legitimate. To show that the verifier is authorized by the network operator and it consumes the request permit, it sends back the received token to the network operator. This token trip is represented as two separate transactions. If the transactions are validated by miners, they are recorded in the blockchain system. The verifier then presents the block addresses including the two transactions with the attestation requests. The attestation initiator device in a swarm checkswhether the token is transferred from the address of the network operator and it is used by sending it back. If the legitimate token is used, the initiator device starts the attestation request. This process requires at most two Internet access attempts (or an internal access attempt when private blockchain model is used) of the initiator, since the initiator itself is not involved in the token trip, which requires public key operations in generating transactions. Note that the token system only uses the basic features of the blockchain system; any generic blockchain system, such as Bitcoin [39] and Ethereum [40], can be used. To sum up, the authentication of requests can be performed in the following steps:  
1. A candidate verifier asks the permission for the attestation to network operator with its address on the blockchain system. 2. The network operator reviews the candidate verifier. If it is acceptable, the network operator transfers a token to the address of the verifier (tx1). 3.