# Securing IoT: Mitigating Sybil Flood Attacks with Bloom Filters and Hash Chains
## 4 Overview of the Proposed Solution
### Verification Process  
The verification process, see Algorithm 1, begins with a check against a Bloom filter. The receiving node extracts the root hash \(h^{0}\) from the incoming message and compares it to the entries within the Bloom filter. Because the Bloom filter is probabilistic, a positive result (presence of the root hash) suggests a high likelihood of the message originating from a legitimate device; however, this is not a definitive confirmation. If the Bloom filter indicates a potentially legitimate message, then the packet is allowed to proceed to further verification steps. Messages that do not pass the Bloom filter check are discarded to conserve resources. ```
1:procedureInitialize:
2:Set\(drop\_counter=0\)
3:procedurePacketReception:
4:Set\(drop\_flag=0\)
5:Retrieve\(type\)\(from\)\(packet\)\(header\). 6:procedurePacketProcessing:
7:if\(type\
eq 155\)then
8:Log\(Message\)\( arrived\)\(ttcpip\_input\)
9:Call\(Bloom\)\(filter\)
10:procedureReturn from BloomFilter:
11:if\(drop\_flag=1\)then
12:\(Drop\)\(Packet\)
13:\(drop\_counter++\)
14:if\(drop\_counter>3\)then
15:LogPacket\(dropped\)\(more\)\(than\)\(3\)\(times\). 16:procedureTimeCheck:
17:if\(drop\_flag=0\)then
18:Extract\(timestamp\)
19:if\(timestamp\
eq current\)\(period\)then
20:\(Drop\)\(Packet\)
21:procedureRootComparison:
22:Extract\(root\)
23:Extract\(chain\)
24:Set\(loop\_counter=0\)
25:while\(loop\_counter<x\)do\(\triangleright\) x = # Iterations
26:if\(hash(chain)==root\)then
27:break
28:else
29:\(hash(chain)\) = chain
30:\(loop\_counter++\)
31:if\(loop\_counter==x\)then
32:\(Drop\)\(Packet\)
```  
**Algorithm 1** Verification Process  
After the Bloom filter check, the receiving node extracts the timestamp \(t_{s}\) embedded within the message. This timestamp is compared against the current timestamp maintained by the node. If the comparison reveals that the message timestamp falls within an acceptable time window (not too old), the node can be confident that the message is fresh and not a replay attack attempting to resend an old message. To ensure that the timestamp within the message has not been tampered with, the receiving node performs an additional verification. This involves combining the next hash value \(h^{y+1}\) from the message's chain with the included timestamp \(t_{s}\). A cryptographic hash function is then applied to the combined data \(h^{y+1}||t_{s}\) and the resulting hash value is compared to the message's V value. Any alteration to the timestamp would change the combined data, and consequently the resulting hash value. As the final verification post-Bloom filter, the receiving node performs a final hash comparison check. This involves extracting the hash chain value \(h^{y+1}\) from the message's MAT. The node then iteratively hashes this value (no more than \(x\)) used by the sending device to create its original hash chain. After each hashing iteration, the resulting hash value is compared to the message's root hash \(h^{0}\). Because the root hash is created by iteratively hashing an initial value \(h(k)\) a specific number of times \(x\), any mismatch during this verification process indicates that the message has been tampered with. The Bloom filter acts as the first line of defense, filtering out potentially illegitimate messages. Following this initial screening, a robust three-step verification process safe guards network integrity. This process effectively filters out messages that appear legitimate but are not (false positives) and thwarts attempts to reuse old messages (replay attacks). Any message failing even one step of this verification is deemed unreliable and potentially compromised. Consequently, such messages are dropped before reaching the LBR. The network's integration of new nodes and removal of inactive ones are facilitated by leveraging the global repair mechanism in the RPL protocol at periodic intervals. This approach additionally reduces the number of stored hashes required by each node, leading to lower memory usage and potentially improved performance.