Lightweight Tamper-Evident Log Integrity Verification for IoT Edge Environments: A Merkle Tree Pipeline with Adaptive Chunking

1. Probleemstelling

De integriteit van auditlogs gegenereerd door Internet-of-Things (IoT)-apparaten is cruciaal voor forensisch onderzoek na incidenten, naleving van regelgeving en operationele verantwoordingsplicht. Bestaande oplossingen lopen echter tegen aanzienlijke barrières aan bij implementatie aan de IoT-edge:

• Blockchain-gebaseerde benaderingen: Hoewel ze sterke non-repudiatie bieden, leggen ze hoge overhead voor consensus, netwerkafhankelijkheden en implementatiecomplexiteit op die de resourcebeperkingen (sub-GHz-processors, beperkt RAM, onderbroken connectiviteit) van edge-apparaten overstijgen.
• Sleutel-evolutie- en signatuur-gebaseerde schema's: Deze vereisen vaak sequentiële verificatie ($O(n)$ complexiteit) of cryptografische ondertekening per invoer, wat rekenkundig duur is en geen random-access mogelijkheden biedt.
• Hardware-gebaseerd vertrouwen: Oplossingen die vertrouwen op Trusted Platform Modules (TPM's) zijn niet universeel beschikbaar op standaard IoT-hardware.

Er is een gat voor een lichtgewicht, resource-bewuste, gedistribueerde-ledger-vrije oplossing die integriteitsbewijs biedt met lage latentie en een minimaal geheugengebruik.

2. Methodologie

De auteurs stellen een pijplijnarchitectuur in drie fasen voor die specifiek is ontworpen voor resource-beperkte omgevingen:

A. Adaptieve Chunking (Fase 1)

Om het geheugengebruik en de doorvoer in evenwicht te brengen, neemt het systeem logs niet monolithisch of één voor één op. In plaats daarvan maakt het gebruik van een resource-bewuste chunking-mechanisme:

• Dynamische Grootte: De chunkgrootte ($C$) wordt dynamisch aangepast op basis van het beschikbare systeemgeheugen ($M_{avail}$) en de geheugendruk ($P$).
• Beleid: Als de geheugendruk hoog is, neemt de chunkgrootte af om toewijzingsfouten te voorkomen; als de druk laag is, neemt deze toe om de doorvoer te maximaliseren.
• Doel: Dit zorgt voor een gratieuze degradatie onder geheugenbeperkingen in plaats van een abrupte systeemstoring, wat cruciaal is voor apparaten zonder swap-ruimte.

B. Merkle-boom Constructie (Fase 2)

• Structuur: Log-invoeren worden gehasht (met SHA-256 of BLAKE2b) om bladknopen te vormen. Er wordt een binaire hash-boom geconstrueerd waarbij interne knopen hashes zijn van hun kinderen ($H(h_{left} || h_{right})$).
• Optimalisatie: Het systeem herbouwt de boom eenmaal per batch nadat alle nieuwe bladen zijn toegevoegd, waardoor overbodige volledige boomherbouwingen voor elke enkele invoer worden vermeden.
• Commitment: Alleen de root-hash ($R$) wordt opgeslagen in een vertrouwd anker (bijvoorbeeld een hardware-beveiligingsmodule, TPM of een externe append-only opslag).

C. Verificatie (Fase 3)

• Opnamebewijzen: Om een specifieke log-invoer $L_i$ te verifiëren, genereert het systeem een opnamebewijs bestaande uit de broer-hash-waarden langs het pad van het blad naar de root.
• Complexiteit: De bewijsgrootte en verificatiekosten zijn $O(\log n)$, wat random-access verificatie mogelijk maakt zonder voorgaande invoeren te hoeven verwerken.
• Proces: De verificateur herberekent de root met behulp van de invoer en het bewijspad en vergelijkt deze met het vertrouwde anker $R$.

3. Belangrijkste Bijdragen

Het artikel levert vier onderscheidende bijdragen:

1. Geauditeerde Implementatie en Correctheid:
   • De auteurs hebben een rigoureuze code-audit uitgevoerd die twee kritieke evaluatiefouten in hun initiële prototype identificeerde en corrigeerde:
     • Dubbel-tel bug: Een logische fout in manipulatiemetrics die onmogelijke nauwkeurigheidswaarden (>1,0) opleverde.
     • Overbodige herbouw-bug: Een inefficiëntie die de volledige boom herbouwde na elke enkele log-invoeging binnen een batch ($O(bn)$), wat werd gecorrigeerd tot een herbouw per batch ($O(n)$).
2. Adaptieve Merkle-pijplijn:
   • Een innovatieve architectuur die adaptieve opname combineert met Merkle-bomen, met een doorvoer van >130.000 logs/s en <5 MB piekgeheugen op een standaard werkstation, met bewijsgroottes van $O(\log n)$.
3. Formele Veiligheidsanalyse:
   • Bewijsschetsen geboden onder standaard aannames voor hash-functies (botsings- en tweede-preimage-resistentie).
   • Analyse van resistentie tegen modificatie, verwijdering (truncatie), injectie en replay-aanvallen.
   • Aangetoond dat adaptieve chunking de cryptografische beveiligingseigenschappen niet verzwakt.
4. Systematische Comparatieve Positionering:
   • Een meerdimensionale vergelijking met sleutel-evolutie-, signatuur-gebaseerde, geauthenticeerde-structuur- en blockchain-systemen, waarbij de afwegingen in vertrouwensmodellen, verificatiecomplexiteit en geschiktheid voor de edge worden benadrukt.

4. Experimentele Resultaten

Experimenten werden uitgevoerd op een enkel werkstation (Intel Core i7, 32 GB RAM) met synthetische IoT-logs.

• Doorvoer:
  • Bij 100.000 records handhaafde het systeem een doorvoer van 134.242 logs/s (adaptief) en 138.850 logs/s (vaste chunking).
  • Beide modi stabiliseerden boven de 130.000 logs/s voor grote datasets.
• Verificatie en Bewijsgeneratie:
  • Enkel-invoer verificatie: ~22 ms.
  • Bewijsgeneratie: ~22 ms.
  • Bewijsgrootte: Gemiddeld 1.006 bytes (14 broer-hash-waarden voor 10.000 invoeren), wat $O(\log n)$ schaling bevestigt.
• Geheugengebruik:
  • Het piekgeheugengebruik bleef onder de 5 MB (specifiek ~4,23 MB) zelfs bij 100.000 invoeren, wat het haalbaar maakt voor beperkte edge-apparaten.
• Manipulatiedetectie:
  • Bereikte Precisie, Recall en F1-scores van 1,0 over corruptieratio's van 1% tot 50%.
  • Detectie was deterministisch; elke wijziging in een blad-hash propageerde met overweldigende waarschijnlijkheid naar de root.
• Vergelijking Hash-algoritmen:
  • BLAKE2b bood een 7,2% hogere opname-doorvoer in vergelijking met SHA-256 met vergelijkbare verificatielatenie, wat het suggereert als de voorkeursoptie voor scenario's met doorvoerbeperkingen.

5. Betekenis

Dit werk adresseert een kritiek gat in IoT-beveiliging door een praktisch, lichtgewicht alternatief voor blockchain te bieden voor log-integriteit.

• Edge-klaar: Het elimineert de noodzaak voor gedistribueerde consensus en zware netwerkafhankelijkheden, waardoor het implementeerbaar is op single-device edge-gateways met beperkte resources.
• Forensische bruikbaarheid: De $O(\log n)$ random-access mogelijkheid stelt onderzoekers in staat om specifieke gebeurtenissen te verifiëren zonder de volledige loggeschiedenis opnieuw te hoeven verwerken, een significant voordeel ten opzichte van sequentiële sleutel-evolutie-schema's.
• Wetenschappelijke strengheid: Het artikel stelt een hoge standaard voor veiligheidsresearch door implementatiebugs expliciet te documenteren en te corrigeren die anders de prestatie- en nauwkeurigheidsclaims ongeldig hadden gemaakt.
• Reproduceerbaarheid: De auteurs leveren volledige broncode, synthetische log-generatoren en benchmark-scripts, waarmee een reproduceerbare basislijn wordt vastgesteld voor toekomstig onderzoek naar edge-log-integriteit.

Concluderend biedt de voorgestelde pijplijn een robuuste, hoog-doorvoer en laag-latente oplossing voor het waarborgen van de integriteit van IoT-auditlogs, waarbij cryptografische beveiliging in evenwicht wordt gebracht met de strikte resourcebeperkingen van edge-computing-omgevingen.