Generali

Introduzione

Tutanum è un'infrastruttura server sicura nata il 5 giugno 2023 per potere mitigare tutte le questioni relative alla sicurezza e sfruttate oggigiorno da utenti malintenzionati o da intelligence di livello militare e non per invadere la privacy e abbattere l'anonimato.

L'anonimato e la privacy esistono e sono importanti, non sono valori assoluti, ma misure di un sistema su cui potere mitigare rispetto a vulnerabilità più o meno note, sfruttabili da singoli o gruppi di individui.

Che cosa è Tutanum?

Tutanum deriva dal verbo latino tutare, ossia proteggere; il nome può pertanto essere tradotto come protezione o rifugio sicuro. È stato scelto questo nome per il progetto perché lo scopo riguarda la progettazione e la costruzione, sia fisica che virtuale, di un'infrastruttura informatica che possa offrire servizi decentralizzati, distribuiti o ridondati, su base volontaria e non a scopo di lucro, anonimi e sicuri, sia per chi "ospita" tali servizi, sia per chi li visita.
La piattaforma dovrebbe potere resistere ad attacchi militari, di intelligence o di utenti malevoli che vogliono sfruttare vulnerabilità, spesso lasciate inosservate per compromettere la privacy, l'anonimato e più in generale l'integrità informatica e telematica degli utenti.

Con questo progetto non si vuole fornire una manna dal cielo che possa risolvere o mitigare qualsiasi problema di anonimato, sicurezza o privacy, ma vuole essere una tecnologia non scalabile e messa a disposizione di tutti al fine di potere sfruttare i prodotti commerciali per potere sviluppare un canale di accesso ad una tecnologia sempre più libera e orientata alla difesa della propria proprietà.

Valori del progetto

Al di là delle scelte tecniche, Tutanum nasce attorno ad alcuni principi che ne guidano ogni decisione:

• Privacy, anonimato e sicurezza come diritti. Non sono valori assoluti né un interruttore acceso/spento, ma misure da difendere e mitigazioni da applicare contro vulnerabilità note e meno note.
• Decentralizzazione e distribuzione. Nessun punto di controllo o di guasto unico: servizi distribuiti, ridondati e indipendenti, per resistere a pressioni e attacchi.
• Volontariato e assenza di scopo di lucro. Tutanum è e resta un progetto copyleft (CC BY-NC-SA 4.0), volutamente non scalabile a fini commerciali: la conoscenza e l'infrastruttura sono un bene comune, non un prodotto.
• Software libero e hardware aperto. Si preferiscono sempre soluzioni libere e verificabili (coreboot/libreboot, sistemi BSD e GNU, niente blob o driver proprietari dove sono evitabili), perché ciò che non si può ispezionare non si può dire sicuro.
• Semplicità (KISS). La complessità è un costo e una superficie d'attacco: si aggiunge solo quando è strettamente necessaria.
• Accessibilità e riuso. Hardware economico, autoprodotto o recuperato (la versione "Lieve"): la sicurezza non deve essere un privilegio per chi può spendere.
• Trasparenza e conoscenza. La documentazione è aperta e pensata per insegnare a capire e a mitigare, non per fornire soluzioni preconfezionate da seguire alla cieca.
• Resistenza alla sorveglianza di massa e alla censura. L'obiettivo di fondo è sottrarsi alla profilazione e alla censura, restituendo alle persone il controllo sui propri dati e sulle proprie comunicazioni.
• Antiscalabilità. La scalabilità implica ottimizzazione e, oltre una certa dimensione, centralizzazione e delega: per questo Tutanum è volutamente non scalabile e si compone di piccoli nodi indipendenti su rete distribuita, così che ogni parte resti gestibile e comprensibile da una singola persona.

Antiscalabilità

La scalabilità è la capacità di un sistema di crescere con la domanda o le dimensioni senza degradare le prestazioni. Ha però un prezzo: punta all'ottimizzazione e, oltre una certa soglia, alla centralizzazione. Un progetto abbastanza grande richiede sempre una gestione centrale, a meno di non scomporlo in sottoprogetti piccoli gestiti a rete distribuita.

La scalabilità viene prima della delega. Quando un'attività supera la scala individuale servono altre persone per portarla avanti (escludendo la pigrizia come fattore), e con loro arriva la delega, con i suoi problemi organizzativi, gestionali e di sicurezza. Un progetto che punta alla dimensione e all'ottimizzazione tende quindi inevitabilmente alla centralizzazione e, in questo senso, non è anarchico: è l'antiscalabilità, non la scalabilità, a preservare una gestione individuale e distribuita, senza un'autorità centrale.

In informatica questo si traduce in una scelta netta: i sistemi operativi e i software moderni, pensati per crescere e integrare tutto, tolgono all'individuo il controllo pieno della propria macchina. Il software minimale e comprensibile (la filosofia suckless), che una sola persona può leggere, modificare e mantenere, è quello coerente con un modello individuale, insieme ai sistemi BSD e GNU e all'assenza di blob proprietari.

Tutanum applica tutto questo: non un'infrastruttura unica da far crescere, ma tanti piccoli nodi autonomi e ridondati su rete distribuita, costruiti con strumenti che chi li gestisce può capire fino in fondo. Sul piano del metodo questo corrisponde a un approccio AGILE adattato al contesto individuale: ruoli flessibili (cross-role), gestione dell'intero ciclo di vita dei prodotti (product intelligence) e tracciamento anche informale delle attività (backlogging).

Su un piano più teorico, questa preferenza nasce dall'idea che il generale emerga dall'aggregazione dei particolari (particolare → generale) invece di essere imposto dall'alto: una struttura si costituisce dai suoi componenti, non viceversa. È il fondamento logico-ontologico sviluppato nei progetti Onto e TheoryFlow (nel portfolio).

Modello di minaccia

Prima di difendersi bisogna sapere da chi. Tutanum assume avversari di potenza crescente e si difende in profondità, strato su strato: se uno cede, gli altri reggono ancora.

Gli avversari considerati, dal più comune al più potente:

• Ladro o accesso fisico opportunistico: vuole il dispositivo o i dati su di esso. Si contrasta con la cifratura dell'intero disco e la tamper-evidence.
• Avversario locale e vicinato: sfrutta la prossimità fisica e radio (sensing WiFi, emissioni elettromagnetiche). Si contrasta con schermatura e riduzione delle emissioni.
• ISP e operatore di rete: vede i metadati, fa DPI e può bloccare. Si contrasta con reti anonime (I2P, Tor) e controllo del DNS.
• Forze dell'ordine e richieste legali: sequestro, mandati, obblighi di log. Si contrasta con la minimizzazione dei log, la scelta della giurisdizione, la cifratura e, dove possibile, un warrant canary.
• Intelligence e avversario statale: catena di fornitura, impianti hardware e firmware, 0day, correlazione su larga scala, risorse quasi illimitate. Si contrasta con hardware aperto, isolamento fisico (air-gap) per i nodi sensibili e difesa in profondità, consapevoli che qui nessuna singola misura basta.
• Avversario globale passivo: osserva contemporaneamente ampie porzioni della rete. È il limite teorico: né Tor né I2P proteggono pienamente da chi vede entrambi i capi di una comunicazione.

Cosa Tutanum protegge e cosa no

Da paranoici si è onesti sul rischio residuo. Tutanum riduce drasticamente l'esposizione a sorveglianza di massa, profilazione, blocchi e deanonimizzazione opportunistica. Non protegge, o protegge solo in parte, da: un avversario globale passivo che correli i due estremi di un flusso; gli errori dell'operatore (vedi la sezione OPSEC); le vulnerabilità 0day ancora sconosciute; la compromissione del silicio stesso; e la coercizione fisica diretta sull'operatore (il cosiddetto attacco "con la chiave inglese da 5 dollari", contro cui valgono solo deniability e chiavi distruggibili). La sicurezza resta un insieme di mitigazioni, non un valore assoluto.

Scenari di attacco

Il modello di minaccia dice da chi; qui si vede come si svolgono gli attacchi tipici e come i vari strati rispondono. Il filo conduttore è sempre lo stesso: Tutanum raramente impedisce l'evento iniziale, ma fa in modo che non si propaghi: il codice ostile non si esegue, non esce, viene notato e isolato, e i segreti restano fuori portata. Nessuna singola misura basta: conta la somma.

1. Vulnerabilità applicativa di un sito (XSS, upload di file malevolo)

Un difetto dell'applicazione web (es. un XSS) permette di piazzare un file ostile sul server. Tutanum non previene il difetto applicativo, che richiede lavoro sull'app (CSP, encoding dell'output, upload trattati come dati inerti), ma ne contiene l'esito: le aree scrivibili della jail sono noexec,nosuid e quelle di codice in sola lettura (blinda-jail), quindi il file non si esegue; la jail web non ha uscita in rete (pf default-deny: escono solo le jail Tor/I2P), quindi il payload non telefona a casa; l'EDR, l'integrità mtree e gli honeytoken lo notano, e la jail finisce in quarantena e si ricostruisce dalla base firmata. I segreti non sono nella jail.

2. Esecuzione di codice da remoto in un servizio esposto

Un 0day in Tor, i2pd o nginx dà all'attaccante una shell dentro una jail. L'isolamento (una jail, un indirizzo, nessuna visibilità sulle altre), l'assenza di uscita per le jail che non sono Tor/I2P e l'honeypot interno limitano ciò che può fare; la sigillatura (securelevel 2, flag schg) gli impedisce di persistere nei file di avvio. Il contenimento è automatico: al verdetto dell'EDR la jail finisce in quarantena (tabella ipfw), in modo reversibile, così un falso positivo non fa danni permanenti; la ricostruzione resta una decisione umana. Limite: resta la finestra tra la compromissione e il momento in cui l'EDR se ne accorge, che l'automazione accorcia ma non azzera.

3. Catena di fornitura: dipendenza o pacchetto malevolo

Il male entra attraverso un aggiornamento o una libreria. È il mestiere dell'officina: la catena di scanner (Gitleaks, Trivy, Semgrep, Bearer, Grype, osv-scanner) con una soglia che blocca la compilazione (fail-closed), la build in una jail effimera senza rete (poudriere), e la re-firma sul nodo. Il nodo non installa mai direttamente da Internet: gli aggiornamenti passano da Tor. Limite: uno 0day mai visto passa comunque gli scanner basati su firme note.

4. Officina compromessa

L'officina analizza codice ostile per mestiere, quindi si assume che possa cadere. Non ha rotta verso il nodo né credenziali per raggiungerlo: è il nodo a interrogarla, in SSH a comando imposto, e ciò che riceve è dato validato, mai eseguito. Esce solo dal Tor del nodo, e la chiave di firma non sta mai sull'officina: un'officina compromessa non firma pacchetti fidati né tocca i segreti.

5. Movimento laterale tra jail

Preso un servizio, l'attaccante prova a saltare agli altri. pf isola le jail tra loro (solo le eccezioni dichiarate passano) e ogni jail ha un indirizzo proprio; l'esca interna è una trappola: una jail che la tocca si tradisce e viene congelata. L'host non offre servizi propri, quindi non è un ponte.

6. Persistenza e manomissione dell'avvio

L'intruso vuole sopravvivere al riavvio modificando uno script di avvio o il bootloader. Al securelevel 2 i file eseguiti all'avvio portano il flag schg e non si possono cambiare se non in modalità utente singolo (che chiede la password di root); il codice di avvio sta fuori dal disco cifrato ma è coperto da una base mtree firmata controllata prima di ogni riavvio.

7. Esfiltrazione dei dati

Rubare dati significa mandarli fuori. La pf è default-deny anche in uscita: verso Internet escono solo le jail Tor e I2P, l'host solo con dnscrypt (a sua volta via Tor). Ogni tentativo da una jail che non deve uscire finisce nel block log all ed è visibile in pflog. Non c'è un canale in chiaro verso cui dirottare.

8. Deanonimizzazione e correlazione di rete (ISP)

L'operatore di rete vuole sapere che usi Tor/I2P, o correlare i flussi. I servizi vivono su I2P, l'uscita passa da bridge obfs4 che nascondono l'uso di Tor, non c'è NTP né DNS in chiaro, e sono spenti i timestamp TCP/ICMP che esporrebbero un orologio. Limite dichiarato: un avversario globale passivo che vede entrambi i capi può comunque correlare.

9. Forza bruta e scansione da Internet

Tentativi di accesso in massa. L'sshd ascolta solo sulla LAN e accetta solo chiavi (niente password); sshguard e la tabella di overload di pf bandiscono chi insiste, con il computer di amministrazione escluso per non chiudersi fuori da soli. Chi arriva dall'esterno sulla porta 22 trova l'esca, non il servizio vero.

10. Il tempo come vettore

Un orologio sbagliato rompe Tor e le chiavi di I2P, o diventa un dato che identifica. Niente NTP in chiaro: l'ora si prende da Tor (ora-da-tor, mediana di tre onion indipendenti), e dal securelevel 2 il kernel la sposta solo a piccoli passi e mai indietro.

11. Sequestro fisico o furto del dispositivo

L'avversario mette le mani sulla macchina. Il disco è cifrato per intero (GELI); la tamper-evidence rivela l'apertura del case; la minimizzazione dei log riduce ciò che si trova a sistema spento. Limite onesto: contro la coercizione diretta sull'operatore valgono solo deniability e chiavi distruggibili.

12. Canali laterali del processore

Spectre/Meltdown e simili, più la deduplicazione della memoria tra ospiti. Si applicano le mitigazioni del kernel (sysctl/loader), si spegne la condivisione di memoria (KSM) e l'hyper-threading sui nodi sensibili. Limite: contro un difetto 0day del silicio stesso nessuna misura software basta: per questo i nodi più esposti vanno isolati fisicamente.

13. Perdita del nodo o delle chiavi

Un guasto, un errore o un sequestro distruggono il nodo. I dati di reperibilità (chiavi onion e destinazioni I2P, la cui perdita cambierebbe gli indirizzi) sono nel backup cifrato e append-only fuori dal nodo: chi compromette il nodo può aggiungere backup, non cancellare i vecchi. Un nodo perso si ricostruisce; le sue credenziali vanno però revocate ovunque.

OPSEC: il livello umano

Il sistema più robusto cade per un errore umano. L'OPSEC (operational security) consiste nel proteggere le informazioni che, innocue da sole ma combinate, rivelano identità e attività. È un processo continuo, non una checklist da spuntare una volta.

• Compartimentazione: tenere separate identità, ruoli e dispositivi. Nessun riuso di pseudonimi, email, password o numeri di telefono tra il contesto del progetto e la vita reale.
• Niente correlazione: non collegare mai l'identità reale a quella del progetto, né tramite acquisti, login, orari di attività, rete usata o dispositivi condivisi.
• Igiene dei metadati: rimuovere i metadati dai file (EXIF, autore), non pubblicare orari e pattern ricorrenti, fare attenzione a fuso orario, lingua e stile di scrittura (la stilometria identifica gli autori).
• Comunicazioni: per l'amministrazione usare canali cifrati end-to-end e, dove serve, deniable; tenere un canale fuori banda per gli allarmi.
• Need-to-know verso sé stessi: non conservare ciò che non serve. Ogni dato tenuto è un dato che può essere sequestrato o rubato.
• Disciplina: fare sempre le stesse operazioni nello stesso modo sicuro. Fretta, stanchezza e abitudine sono i veri alleati dell'avversario.
• Coercizione: prevedere lo scenario peggiore (accesso fisico, costrizione) con chiavi distruggibili, dead-man switch e deniability, temi ripresi nelle difese dall'accesso fisico.

Nessuna tecnologia compensa un'OPSEC sciatta: è il livello su cui l'avversario statale punta per primo, proprio perché è il più economico da attaccare. Prima ancora dei metadati, l'anello debole è la mente dell'operatore: pressione, inganno e manipolazione psicologica aggirano qualsiasi cifratura. Su questo livello umano si innesta la psicologia ontologica (psychsecurity), che tratta la sicurezza del soggetto come parte integrante del modello di minaccia.

La guida di Whonix Tips on Remaining Anonymous aggiunge alcune abitudini concrete, che per chi amministra un nodo diventano regole:

• Anonimo e pseudonimo non sono la stessa cosa: uno pseudonimo accumula storia, e la storia si correla. I contesti non si mescolano mai nella stessa sessione, e si usa un solo pseudonimo per volta.
• Mai pubblicare log o configurazioni intere: contengono nomi host, percorsi, versioni, orari e indirizzi. Quando si chiede aiuto o si documenta, si riporta solo il frammento necessario, dopo averlo ripulito.
• Niente verifiche telefoniche: un numero di telefono lega per sempre un account a una persona e a una posizione.
• Dati sensibili solo con cifratura end-to-end: ciò che passa in chiaro da un servizio di terzi va considerato letto.

Livello legale e giurisdizione

Una parte del modello di minaccia non si combatte con la tecnica ma con il diritto. Chi ospita un servizio può essere raggiunto da richieste legali, obblighi di conservazione dei log, ordini di consegna delle chiavi e, in alcuni ordinamenti, dall'obbligo di non rivelare di averli ricevuti. Da paranoici questo scenario va previsto, non subito.

• Giurisdizione: dove vivono fisicamente i dati e l'operatore determina quali leggi si applicano. Conviene conoscere gli obblighi di log, i poteri di sequestro e i trattati di cooperazione dei paesi coinvolti, ricordando che il traffico attraversa comunque più giurisdizioni.
• Minimizzazione come difesa legale: non si può consegnare ciò che non si possiede. Log assenti o ridotti al minimo e cifratura dei dati a riposo limitano ciò che un ordine può ottenere.
• Consegna delle chiavi: in alcuni ordinamenti è possibile essere obbligati a fornire le chiavi. Qui valgono la forward secrecy (le chiavi di sessione passate non esistono più) e le chiavi distruggibili viste tra le misure contro la coercizione.
• Warrant canary: una dichiarazione pubblica, aggiornata e firmata periodicamente, che attesta di non aver ancora ricevuto richieste segrete. La sua sparizione o il mancato aggiornamento segnalano indirettamente che qualcosa è successo, aggirando in parte il divieto di parlarne. È uno strumento fragile e dagli effetti giuridici discussi, da intendere come indizio e non come garanzia.

Il diritto cambia nel tempo e da luogo a luogo: queste sono considerazioni generali di modellazione del rischio, non consulenza legale.

Quali sono le versioni di Tutanum?

Esistono due versioni principali: la versione "Classico", che richiede hardware più specifico, e la versione "Lieve", pensata per riutilizzare vecchi dispositivi o computer di cui si ha già la proprietà ma che non dispongono dei requisiti di sicurezza tali da potere certificare il nodo Tutanum come nodo sicuro.
Ciò non vuol dire che Tutanum "Lieve" è un'infrastruttura insicura, vuol dire che persistono delle mitigazioni aggiuntive e differenti che possono portare a pezzi "nascosti" che potrebbero compromettere la sicurezza e l'integrità del sistema.

Quali sono le caratteristiche di Tutanum?

Le caratteristiche hardware dell'infrastruttura, che può essere replicata su più nodi indipendenti, comprendono quanto segue:

• CPU/SOC supportato da FreeBSD o OpenBSD.
• Economico.
• Almeno 4 core, l'ideale sarebbe averne 8.
• Almeno 4GB di RAM.
• Rispetto della filosofia KISS: il principio KISS, acronimo per "Keep It Simple, Stupid" (Tienilo Semplice, Stupido), è un principio di design che suggerisce che la semplicità è un obiettivo desiderabile e che la complessità dovrebbe essere evitata quando possibile. Questo principio si applica a una vasta gamma di campi, tra cui progettazione di software, comunicazione, ingegneria, e altro ancora. In sostanza, il principio KISS promuove l'idea che le soluzioni più semplici sono spesso le migliori e che la complessità non dovrebbe essere aggiunta a meno che non sia strettamente necessaria.
• Relativamente facile da implementare e da difendere.
• Bassi consumi come avviene con l'architettura ARM.
• Facile da acquistare o da autoprodurre.
• Non in fase di sviluppo e pertanto stabile.

Licenza

Tutanum è sotto licenza Copyleft Creative Commons: Attribution-NonCommercial-ShareAlike 4.0 International