Sintesi Tecnica: Non-Assemblaggio Semantico (Semantic Non-Assembly)

1. Definizione del Problema

Gli attuali framework di privacy (confidenzialità, controllo degli accessi, controllo del flusso di informazioni e limitazione della divulgazione statistica) si concentrano sulla restrizione dell'accesso a informazioni sensibili esistenti all'interno di un sistema. Questi modelli presuppongono un "deposito" da proteggere e un "flusso" da restringere. Tuttavia, in un ambiente di minacce in cui la compromissione di un componente (furto di credenziali, accesso interno, violazione delle infrastrutture) è probabile piuttosto che eccezionale, questi framework falliscono. Se un singolo componente detiene informazioni sufficienti per eseguire una funzione di identificazione del target (ad esempio, collegare un dispositivo di acquisizione specifico a un contenuto specifico), la compromissione di quel singolo componente fa crollare l'intera garanzia di privacy.

Il documento identifica una lacuna: non esiste una classe di sistemi che non conceda nulla in caso di esposizione del componente perché non c'è nulla da concedere. La sfida è progettare un sistema in cui l'esposizione completa e decriptata di qualsiasi singolo componente non fornisca alcun dato azionabile riguardo alla funzione di identificazione del target.

2. Metodologia: Non-Assemblaggio Semantico (SNA)

Il documento introduce il Non-Assemblaggio Semantico (SNA), una classe di garanzia di privacy definita non dalla difficoltà di ottenere l'esposizione, ma dallo yield informativo dell'esposizione quando essa avviene.

Definizione Core

L'SNA impedisce l'evaluazione di un predicato designato $f$ (ad esempio, l'attribuzione dispositivo-contenuto) assicurando che nessuna coalizione di meno di una soglia definita di $t+1$ componenti possa assemblare un assegnamento sufficiente al dominio di input di $f$.

• Semantico: Si riferisce al livello di significato dell'informazione (ciò che i dati abilitano rispetto a $f$), distinto dalla sicurezza semantica crittografica.
• Non-Assemblaggio: Lo stato sufficiente (la combinazione di campi informativi richiesti per eseguire $f$) è strutturalmente impedito dall'esistere in un singolo componente o in una coalizione inferiore alla soglia.
• Inerzia Architetturale: La garanzia è strutturale, non procedurale. È ottenuta per design, garantendo che la co-localizzazione di informazioni sufficienti sia strutturalmente impossibile al di sotto della soglia di compromissione, anziché fare affidamento su policy o fiducia.

Distinzione dai Meccanismi Esistenti

• Vs. Confidenzialità: La confidenzialità restringe l'accesso a dati che esistono in un unico luogo; l'SNA impedisce che l'insieme di dati sufficienti esista in un unico luogo.
• Vs. Controllo degli Accessi: Il controllo degli accessi media le operazioni su depositi esistenti; l'SNA elimina il deposito.
• Vs. Controllo del Flusso di Informazioni (IFC): L'IFC restringe i percorsi di propagazione per dati esistenti; l'SNA assicura che lo stato target sia assente per architettura, in modo che non esista alcun flusso da restringere.
• Vs. Limitazione della Divulgazione Statistica (SDL): La SDL limita l'inferenza dai dati rilasciati; l'SNA impedisce che l'insieme informativo sufficiente esista in qualsiasi componente sub-soglia, lasciando nessun dataset su cui applicare l'inferenza.

Istanza di Riferimento: Architettura di Provenance a Due Canali

Il documento istanzia l'SNA in un sistema di provenienza dei media (lo Standard Birthmark) progettato per collegare i dispositivi di acquisizione a contenuti autenticati senza consentire l'attribuzione passiva. L'architettura separa le sottomissioni in due canali indipendenti:

1. Canale del Contenuto: Trasporta un hash del contenuto media ($H_{content}$) e metadati opzionali hashati. Viene instradato a un Registro pubblico (blockchain di consorzio).
2. Canale delle Credenziali: Trasporta un token del dispositivo criptato (criptato sotto la chiave pubblica del Validatore delle Credenziali) e un riferimento di chiave. Viene instradato a un Validatore delle Credenziali.

Flusso Operativo:

• Il Server di Sottomissione riceve entrambi i canali ma li separa. Inoltra la credenziale criptata al Validatore e l'hash del contenuto al Registro.
• Il Validatore delle Credenziali decripta il token, verifica l'appartenenza al dispositivo e restituisce un'approvazione firmata. Non vede mai l'hash del contenuto.
• Il Registro memorizza l'hash del contenuto e la firma di approvazione. Non vede mai l'identità del dispositivo.
• Risultato: Nessuna parte detiene sia un identificatore di dispositivo che un hash di contenuto. Lo stato sufficiente per l'attribuzione è strutturalmente assente.

Estensione Forense (Back-Lookup) e Meccanismo di Rete di Sicurezza

Per scenari che richiedono la revoca del dispositivo, il documento propone un percorso forense a quattro parti (Governing Server, Submission Server 1, Submission Server 2, Credential Validator). Questo percorso richiede la traversata sequenziale di tutte e quattro le parti per ricostruire l'attribuzione.

• Difesa Attiva (Rete di Sicurezza): Include un meccanismo di "Rete di Sicurezza" basato su fili di sicurezza (tripwires) sui dati rubati. Se viene rilevata una traversata forense non autorizzata o una compromissione, questi fili di sicurezza attivano un allarme che avvisa gli altri repository di purgare il contesto associato prima che possano essere hackerati. Questa azione preventiva rende i dati target permanentemente inaccessibili, interrompendo la catena di attribuzione.
• Scadenza Temporale: Tutti i dati della catena forense vengono eliminati automaticamente dopo tre anni, recidendo permanentemente la catena di attribuzione.

3. Contributi Chiave

1. Formalizzazione del Non-Assemblaggio Semantico: Una nuova classe di garanzia di privacy caratterizzata dallo yield informativo dell'esposizione del componente, distinta dalla confidenzialità e dal controllo degli accessi.
2. Architettura di Provenance a Due Canali: Un'istanza strutturale di SNA con prove ProVerif eseguibili che stabiliscono:
   • Proprietà A (Non-Correlazione del Dispositivo): Il validatore apprende l'identità del dispositivo ma non l'hash del contenuto.
   • Proprietà B (Non-Identificazione dell'Osservatore del Registro): Gli osservatori vedono gli hash del contenuto ma non possono identificare i dispositivi.
   • Proprietà C (Cecità del Server di Sottomissione): Il server instrada i dati ma non può decriptare le credenziali per identificare i dispositivi.
   • Proprietà D (Gate di Difesa Attiva): Verifica formale della corrispondenza del gate, della segretezza dello stato di purga e dell'integrità della catena.
3. Costo di Privacy Limitato della Forensics: Una caratterizzazione formale che mostra come l'aggiunta di capacità forensi (back-lookup) richieda la compromissione coordinata di quattro confini organizzativi indipendenti, limitando il costo della privacy.
4. Lo Standard Birthmark: Un'istanza di riferimento che dimostra la deployabilità su hardware di acquisizione vincolato (es. ISP di telecamere) dove gli approcci basati su Zero-Knowledge (ZK) sono computazionalmente impraticabili.

4. Risultati e Verifica

• Verifica Formale: Il documento stabilisce quattro proprietà verificate da ProVerif. Il modello utilizza ECIES (asimmetrico IND-CCA2) per la criptazione delle credenziali, con il modello ProVerif che riflette direttamente questo deployment.
• Fattibilità Computazionale: Le operazioni lato dispositivo (incapsulamento ECIES, AES-256-GCM, SHA-256) sono testate per operare entro un budget di 100ms nel percorso di acquisizione su processori embedded di classe ARM comuni. Ciò contrasta con gli approcci ZK, che richiedono secondi o minuti per ogni prova su hardware simile.
• Efficienza di Archiviazione: I record del Registro sono compatti (153 byte on-chain), consentendo un funzionamento a basso costo del validatore.
• Divulgazione Limitata: La Tabella 3 nel documento dettaglia che la compromissione di un singolo componente produce solo "frammenti di superficie di attribuzione". Anche con l'estensione di back-lookup, l'attribuzione massiva passiva è impossibile; lo scenario peggiore per un avversario coordinato è il test di ipotesi mirato su media che già possiede.

5. Significato e Rivendicazioni

Il documento sostiene che il Non-Assemblaggio Semantico offre un approccio distinto e necessario alla privacy in un ambiente di minacce in cui l'esposizione dei componenti è inevitabile.

• Strutturale vs. Procedurale: La principale significatività è il passaggio da una separazione basata su policy (che fallisce sotto la minaccia interna) a una separazione strutturale (che fallisce solo sotto la compromissione coordinata di più componenti).
• Deployability: L'architettura affronta il "gap di deployment" dove gli approcci basati su ZK sono troppo pesanti dal punto di vista computazionale per l'hardware di acquisizione in tempo reale, mentre i sistemi di provenienza standard (come C2PA) falliscono quando i metadati vengono rimossi durante la distribuzione.
• Degradazione Prevedibile: A differenza dei sistemi che crollano interamente dopo una singola violazione, l'SNA degrada in modo prevedibile. La garanzia di privacy si mantiene finché l'avversario non controlla il numero di soglia di componenti ($t+1$).
• Governance come Sicurezza: Il documento sottolinea che l'architettura si affida a vincoli organizzativi auditati (ad esempio, limiti di proprietà del validatore, distribuzione giurisdizionale) per mantenere l'indipendenza strutturale. Il livello di governance è trattato come un componente di sicurezza portante, non come un semplice overlay amministrativo.

Il documento conclude che in un mondo in cui le perdite sono inevitabili, progettare per le conseguenze del fallimento (assicurandosi che non ci sia nulla da concedere) è critico quanto progettare contro il fallimento stesso. Lo Standard Birthmark fornisce un percorso concreto e verificabile per raggiungere questo obiettivo per la provenienza dei media.