# IoT Group Membership Management Using Decentralized Identifiers and Verifiable Credentials
## 4 Implementation and Evaluation
### Security Properties  
Assuming that the DNSSEC resolution processes is secured, our solution has the following security-related properties:  
**The integrity of the CoAP response payload is protected**. A digest of the CoAP response payload is recorded in the _attestation_ option. Since the attestation option also includes the CoAP request token, an attacker cannot replace the payload using an old, valid one. On the other hand, an attacker can replace a payload (and the attestation) with the corresponding fields of a CoAP response generated by another endpoint but for the same request. In that case, the CoAP client will receive twice the same response, signed by the same key; hence, the attack will be detected. **The authenticity of the CoAP response is protected**. The authenticity of a CoAP response, i.e., the verification of the \"binding\" between the response payload and the requested CoAP URI, is achieved by including the CoAP URI in the attestation field. If the CoAP URI was not included in the attestation, an attacker could send a CoAP request to a different CoAP URI using the same token as a legitimate request, and then replace a legitimate response with the response it received to his request. Furthermore, the attestation is signed by an endpoint authorized by the publisher to make attestation for that particular URI. Hence, a malicious but authorized endpoint cannot generate responses for URIs other than those for which it has been authorized. **Authorized endpoints can easily rotate keys**. An endpoint can replace its authentication key with a new one by generating a new DID document; apart from that, no more actions are required, e.g., the endpoint does not have to receive a new membership VC. In a certificate-based solution, on the other hand, an endpoint would have to receive a new certificate from the group administrator. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Operation** & **Time (ms) Using RPi** & **Time (ms) Using ESP32** \\ \hline Ed22519 pair generation & 46 & 452 \\ DID document and proof & 2.7 & 293 \\ generation using COSE & 2.7 & 293 \\ Attestation generation using & 0.7 & 82 \\ DID document verification & 1.5 & 160 \\ Membership VC verification & 1.5 & 160 \\ Attestation verification & 1.5 & 160 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Cryptographic operations and their overhead. Resilience to Attacks  
A _did:self_ DID is associated with a private key, which is used for signing the proofs of the corresponding DID documents. In our system, we have two important _did:self_ DIDs: the \(Group_{DID}\) and the \(Owner_{DID}\). If the private key that corresponds to \(Group_{DID}\) is breached (or lost), then the \(Group_{DID}\) must change. This means that the corresponding DNS record must be updated, all generated membership VCs must be revoked, and new membership VCs must be generated. If the private key that corresponds to an \(Owner_{DID}\) is breached (or lost), then the corresponding endpoint owner must generate a new DID and receive new membership VCs. Old VCs must be revoked, and the IoT devices must be re-configured with the new VCs and DID documents. The most risky component of our system is the private key of the IoT endpoints, since IoT endpoints are usually exposed to attackers. A breached private key can be used for signing fake CoAP responses. In order to mitigate this attack, we take advantage of the key id uniqueness property of _did:self_. In particular, in order for attackers to use a breached key, they must include in the generated responses a valid DID document. However, since DID documents are signed by the endpoint owner, the attacker can only use the same DID document as the victim endpoint. This means that a CoAP client will receive two responses signed by the same key. The simplest strategy in that case is to ignore both these responses. In order to evaluate the effectiveness of this countermeasure, we emulated an attack scenario. In particular, we consider a group of 100 endpoints.