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

1. Enunciazione del Problema

L'integrità dei log di audit generati dai dispositivi Internet of Things (IoT) è fondamentale per le indagini forensi post-incidente, la conformità normativa e la responsabilità operativa. Tuttavia, le soluzioni esistenti incontrano barriere significative quando vengono implementate all'edge IoT:

• Approcci basati su blockchain: Sebbene offrano una forte non ripudiabilità, impongono un elevato sovraccarico di consenso, dipendenze di rete e complessità di implementazione che superano i vincoli di risorse (processori sub-GHz, RAM limitata, connettività intermittente) dei dispositivi edge.
• Schemi basati su evoluzione delle chiavi e firme: Questi richiedono spesso una verifica sequenziale (complessità $O(n)$) o una firma crittografica per ogni voce, che è computazionalmente costosa e manca di capacità di accesso casuale.
• Fiducia radicata nell'hardware: Le soluzioni che si affidano ai Moduli di Piattaforma Fidati (TPM) non sono universalmente disponibili sull'hardware IoT commerciale.

Esiste un vuoto per una soluzione leggera, consapevole delle risorse e priva di registro distribuito che fornisca prove di manomissione con bassa latenza e un footprint di memoria minimo.

2. Metodologia

Gli autori propongono un'architettura a pipeline in tre fasi progettata specificamente per ambienti con risorse limitate:

A. Suddivisione Adattiva (Fase 1)

Per bilanciare l'utilizzo della memoria e il throughput, il sistema non ingerisce i log in modo monolitico o uno alla volta. Utilizza invece un meccanismo di suddivisione consapevole delle risorse:

• Dimensionamento Dinamico: La dimensione del blocco ($C$) viene regolata dinamicamente in base alla memoria di sistema disponibile ($M_{avail}$) e alla pressione sulla memoria ($P$).
• Politica: Se la pressione sulla memoria è alta, la dimensione del blocco diminuisce per prevenire errori di allocazione; se la pressione è bassa, aumenta per massimizzare il throughput.
• Obiettivo: Ciò garantisce un degrado graduale sotto vincoli di memoria piuttosto che un arresto improvviso del sistema, aspetto cruciale per i dispositivi senza spazio di swap.

B. Costruzione dell'Albero di Merkle (Fase 2)

• Struttura: Le voci di log vengono hashate (utilizzando SHA-256 o BLAKE2b) per formare i nodi foglia. Viene costruito un albero di hash binario in cui i nodi interni sono hash dei loro figli ($H(h_{sinistra} || h_{destra})$).
• Ottimizzazione: Il sistema ricostruisce l'albero una volta per batch dopo l'aggiunta di tutte le nuove foglie, evitando ricostruzioni ridondanti dell'intero albero per ogni singola voce.
• Impegno: Solo l'hash radice ($R$) viene memorizzato in un ancoraggio fidato (ad esempio, un modulo di sicurezza hardware, un TPM o un archivio remoto append-only).

C. Verifica (Fase 3)

• Prove di Inclusione: Per verificare una specifica voce di log $L_i$, il sistema genera una prova di inclusione composta dagli hash dei fratelli lungo il percorso dalla foglia alla radice.
• Complessità: La dimensione della prova e il costo di verifica sono $O(\log n)$, consentendo una verifica ad accesso casuale senza elaborare le voci precedenti.
• Processo: Il verificatore ricalcola la radice utilizzando la voce e il percorso di prova, confrontandola con l'ancoraggio fidato $R$.

3. Contributi Chiave

Il documento apporta quattro contributi distinti:

1. Implementazione Auditata e Correttezza:
   • Gli autori hanno condotto un audit rigoroso del codice che ha identificato e corretto due difetti critici di valutazione nel loro prototipo iniziale:
     • Bug del doppio conteggio: Un errore logico nelle metriche di manomissione che produceva valori di accuratezza impossibili (>1.0).
     • Bug della ricostruzione ridondante: Un'inefficienza che ricostruiva l'intero albero dopo ogni singola inserzione di log all'interno di un batch ($O(bn)$), corretta per ricostruire una volta per batch ($O(n)$).
2. Pipeline Adattiva di Merkle:
   • Un'architettura innovativa che combina l'ingestione adattiva con gli alberi di Merkle, raggiungendo un throughput di >130.000 log/s e un picco di memoria <5 MB su una workstation standard, con dimensioni delle prove di $O(\log n)$.
3. Analisi di Sicurezza Formale:
   • Fornisce schizzi di prova sotto ipotesi standard di funzioni hash (resistenza alle collisioni e alle preimmagini seconde).
   • Analizza la resistenza contro modifiche, cancellazioni (troncamento), iniezioni e attacchi di replay.
   • Dimostra che la suddivisione adattiva non indebolisce le proprietà di sicurezza crittografica.
4. Posizionamento Comparativo Sistematico:
   • Un confronto multidimensionale rispetto a schemi di evoluzione delle chiavi, basati su firme, strutture autenticate e sistemi blockchain, evidenziando i compromessi nei modelli di fiducia, nella complessità di verifica e nell'idoneità per l'edge.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su una singola workstation (Intel Core i7, 32 GB di RAM) utilizzando log IoT sintetici.

• Throughput:
  • A 100.000 record, il sistema ha sostenuto 134.242 log/s (adattivo) e 138.850 log/s (suddivisione fissa).
  • Entrambe le modalità si sono stabilizzate sopra i 130.000 log/s per grandi dataset.
• Verifica e Generazione di Prove:
  • Verifica singola voce: ~22 ms.
  • Generazione di prove: ~22 ms.
  • Dimensione della prova: Media di 1.006 byte (14 hash di fratelli per 10.000 voci), confermando la scalabilità $O(\log n)$.
• Footprint di Memoria:
  • L'utilizzo di memoria in picco è rimasto al di sotto di 5 MB (specificamente ~4,23 MB) anche a 100.000 voci, rendendolo fattibile per dispositivi edge vincolati.
• Rilevamento di Manomissioni:
  • Ha raggiunto Precisione, Recall e punteggi F1 di 1,0 su rapporti di corruzione dal 1% al 50%.
  • Il rilevamento è stato deterministico; qualsiasi modifica a un hash foglia si propagava alla radice con probabilità schiacciante.
• Confronto degli Algoritmi di Hash:
  • BLAKE2b ha offerto un throughput di ingestione superiore del 7,2% rispetto a SHA-256 con latenza di verifica comparabile, suggerendolo come opzione preferita per scenari vincolati dal throughput.

5. Significato

Questo lavoro affronta un vuoto critico nella sicurezza IoT fornendo un'alternativa pratica e leggera alla blockchain per l'integrità dei log.

• Pronto per l'Edge: Elimina la necessità di consenso distribuito e pesanti dipendenze di rete, rendendolo implementabile su gateway edge a dispositivo singolo con risorse limitate.
• Utilità Forense: La capacità di accesso casuale $O(\log n)$ consente agli investigatori di verificare eventi specifici senza riesaminare l'intera cronologia dei log, un vantaggio significativo rispetto agli schemi sequenziali di evoluzione delle chiavi.
• Rigor Scientifico: Il documento stabilisce un alto standard per la ricerca sulla sicurezza documentando e correggendo esplicitamente bug di implementazione che avrebbero altrimenti invalidato le affermazioni su prestazioni e accuratezza.
• Riproducibilità: Gli autori forniscono il codice sorgente completo, generatori di log sintetici e script di benchmark, stabilendo una linea di base riproducibile per la futura ricerca sull'integrità dei log edge.

In conclusione, la pipeline proposta offre una soluzione robusta, ad alto throughput e a bassa latenza per garantire l'integrità dei log di audit IoT, bilanciando la sicurezza crittografica con i vincoli di risorse rigorosi degli ambienti di edge computing.