Non è tutta la sicurezza "attraverso l'oscurità"?

Vedi questa risposta .

Il punto principale è che facciamo una netta distinzione tra oscurità e segretezza ; se dobbiamo limitare la differenza a una singola proprietà, allora questa deve essere misurabilità . È segreto ciò che non è noto agli estranei, e sappiamo quanto è sconosciuto a questi estranei. Ad esempio, una chiave simmetrica a 128 bit è una sequenza di 128 bit, in modo che tutte le 2 sequenze possibili ¹²⁸ abbiano un'eguale probabilità di essere utilizzate, quindi l'utente malintenzionato cerca di indovinare una chiave del genere prova, in media, almeno 2 ¹²⁷ di loro prima di colpire quello giusto. Questo è quantitativo . Possiamo fare matematica, aggiungere figure e calcolare costo di attacco .

Lo stesso si applica a una chiave privata RSA. I calcoli matematici sono più complessi perché i metodi più efficaci conosciuti si basano sulla riduzione dei fattori interi e gli algoritmi coinvolti non sono così facili da quantificare come forza bruta su una chiave simmetrica (ci sono molti dettagli sull'uso della RAM e sul parallelismo o sulla sua mancanza). Ma questo è ancora segreto.

Al contrario, un algoritmo oscuro è "segreto" solo finché l'attaccante non elabora i dettagli dell'algoritmo e ciò dipende da molti fattori: accessibilità all'hardware che implementa l'algoritmo, abilità nel reverse-engineering e smartness . Non abbiamo un modo utile per misurare quanto possa essere intelligente qualcuno. Quindi un algoritmo segreto non può essere "segreto". Abbiamo un altro termine per questo, e questo è "oscuro".

Vogliamo fare sicurezza attraverso la segretezza perché la sicurezza è gestione del rischio: accettiamo il sovraccarico dell'utilizzo di un sistema di sicurezza perché possiamo misurare quanto ci costa usarlo e quanto si riduce il rischio di attacchi di successo, e possiamo quindi bilanciare i costi per prendere una decisione informata. Questo può funzionare solo perché possiamo mettere i numeri sui rischi di attacchi riusciti, e questo può essere fatto solo con segretezza, non con oscurità.

Penso che il termine "sicurezza attraverso l'oscurità" venga abusato abbastanza spesso.

La citazione più frequentemente citata quando si parla di sicurezza attraverso l'oscurità è principio di Kerckhoffs .

It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience;

La sicurezza attraverso l'oscurità si riferisce al fatto di mantenere il progetto e implementazione di un sistema di sicurezza protetto nascondendo i dettagli da un utente malintenzionato. Questo non è molto affidabile dato che i sistemi e i protocolli possono essere decodificati e smontati a tempo debito. Inoltre, un sistema che fa affidamento sulla sua implementazione non può dipendere da esperti che lo esaminano per punti deboli, il che probabilmente causa maggiori problemi di sicurezza rispetto a un sistema che è stato esaminato, i bug sono stati resi noti e risolti.

Ad esempio, prendi RSA. Tutti nel mondo sanno come funziona. Bene, tutti quelli che hanno una buona conoscenza della matematica sono coinvolti in ogni caso. È ben studiato e si basa su problemi matematici difficili. Tuttavia, dato ciò che sappiamo della matematica coinvolta, è sicuro a condizione che i valori di p e q siano tenuti segreti. Questo è essenzialmente concentrare il lavoro di rottura (e protezione) del sistema in un segreto che può essere protetto.

Confrontalo con un algoritmo di crittografia che non si abbona al principio di Kerckhoffs. Invece di utilizzare uno schema pubblicamente noto che utilizza una chiave segreta, questo algoritmo di crittografia è segreto. Chiunque conosca l'algoritmo può decodificare qualsiasi dato crittografato con l'algoritmo. Questo è molto difficile da proteggere in quanto l'algoritmo sarà quasi impossibile da tenere lontano dalle mani di un nemico. Vedi la macchina Enigma per un buon esempio di questo.

La sicurezza consiste nel mantenere segreti, ma una buona sicurezza sta nel sapere quali segreti si possono mantenere e quali no.

In particolare, i migliori protocolli di sicurezza si basano sul principio di eliminare il segreto dal design, in modo che il tuo segreto possa essere mantenuto senza dover mantenere anche il design segreto. Questo è particolarmente importante perché i disegni di sistema sono notoriamente impossibili da mantenere segreti. Questo è il nucleo del principio di Kerckhoffs , che risale alla progettazione di vecchie macchine militari di crittografia.

In altre parole, se l'algoritmo è il tuo segreto, allora chiunque veda un'implementazione del tuo algoritmo - chiunque abbia il tuo hardware, chiunque abbia il tuo software, chiunque usi il tuo servizio - - ha visto il tuo segreto. L'algoritmo è un terribile posto dove mettere i tuoi segreti, perché gli algoritmi sono così facili da esaminare. Inoltre, i segreti incorporati nei progetti non possono essere modificati senza modificare la tua implementazione. Sei bloccato con lo stesso segreto per sempre.

Ma se la tua macchina non ha bisogno di essere tenuta segreta, se hai progettato il tuo sistema in modo tale che il segreto sia indipendente dalla macchina - qualche chiave segreta o password - allora il tuo sistema rimarrà sicuro anche dopo il il dispositivo viene esaminato dai tuoi nemici, hacker, clienti, ecc. In questo modo puoi concentrare l'attenzione sulla protezione della sola password, pur rimanendo sicuro che il tuo sistema non può essere rotto senza di esso.

La differenza fondamentale è in ciò che viene tenuto segreto.

Prendi RSA come esempio. Il principio fondamentale di RSA è la matematica semplice. Chiunque abbia un po 'di conoscenza matematica può capire come funziona RSA funzionalmente (la matematica ha quasi mezzo millennio). Ci vuole più immaginazione ed esperienza per capire come sfruttare la sicurezza, ma è stato fatto indipendentemente almeno due volte (da Rivest, Shamir e Adleman, e alcuni anni prima da Clifford Cocks ). Se progetti qualcosa come RSA e tienilo segreto, ci sono buone probabilità che qualcun altro sia abbastanza intelligente da capirlo.

D'altra parte, una chiave privata viene generata casualmente. Una volta eseguita correttamente, la generazione casuale assicura che è impossibile ricostruire il segreto con la potenza di calcolo disponibile umanamente. Nessuna quantità di intelligenza consentirà a chiunque di ricostruire una stringa segreta di bit casuali, perché quella stringa non ha una struttura da intuire.

Gli algoritmi crittografici sono inventati per intelligenza, con obiettivi ampiamente condivisi (proteggere alcuni dati, implementare l'algoritmo in modo economico, ...). C'è una buona possibilità che le persone intelligenti convergeranno nello stesso algoritmo. D'altra parte, le stringhe casuali di bit segreti sono abbondanti e, per definizione, le persone non troveranno la stessa stringa casuale¹. Quindi, se si progetta il proprio algoritmo, ci sono buone probabilità che il vicino progetterà lo stesso. E se condividi il tuo algoritmo con il tuo amico e poi vuoi comunicarlo privatamente, avrai bisogno di un nuovo algoritmo. Ma se generi una chiave segreta, sarà diversa da quella del tuo vicino e del tuo amico. Esiste sicuramente un potenziale valore nel mantenere un segreto di chiave casuale, il che non è il caso di mantenere un algoritmo segreto.

Un punto secondario sulla segretezza della chiave è che può essere misurato. Con un buon generatore casuale, se generi una stringa a n bit casuale e la tenga segreta, c'è una probabilità di 1/2 ^ n che qualcun altro la troverà in una prova. Se si progetta un algoritmo, il rischio che qualcun altro lo capisca non può essere misurato.

Le chiavi private RSA non sono una semplice stringa casuale: hanno una struttura, essendo una coppia di numeri primi. Tuttavia, la quantità di entropia - il numero di possibili chiavi RSA di una certa dimensione - è abbastanza grande da renderne praticamente impossibile la guida. (Dal momento che le chiavi RSA sono praticamente impossibili da ricostruire da una chiave pubblica e da una serie di testi in chiaro e cifrati, è qualcosa che non possiamo provare matematicamente, ma crediamo che sia così perché molte persone intelligenti hanno provato e fallito. un'altra storia.)

Ovviamente questo si generalizza a qualsiasi algoritmo crittografico. Mantieni segrete le stringhe casuali. Pubblica progetti intelligenti.

Questo non vuol dire che tutto dovrebbe essere reso pubblico tranne che per la piccola parte che è un mucchio casuale di bit. Il principio di Kerckhoff non dice questo - dice che la sicurezza del design non dovrebbe basarsi sulla segretezza del design. Mentre gli algoritmi di crittografia sono pubblicati al meglio (e dovresti aspettare circa un decennio prima di usarli per vedere se un numero sufficiente di persone non riesce a romperli), ci sono altre misure di sicurezza che sono meglio tenere segrete, in particolare le misure di sicurezza che richiedono un sondaggio attivo risolvere. Ad esempio, alcune regole del firewall possono rientrare in questa categoria; tuttavia un firewall che non offre protezione contro un utente malintenzionato che conosce le regole sarebbe inutile, poiché alla fine qualcuno lo scoprirà.

¹ _{Anche se questo non è vero matematicamente parlando, puoi letteralmente scommettere su di esso.}

La sicurezza attraverso l'oscurità generalmente si riferisce al principio di Kerchoff , che afferma che il sistema deve essere sicuro anche se tutto < em> tranne la chiave è conoscenza comune. Questo non si applica solo alla crittografia o alla generazione di testi cifrati. Significa anche che non devi contare sulla generazione di URL, password, hash, indirizzi di memoria e persino architettura di sistema da nascondere. La ragione è che qualcosa nel sistema deve essere segreto, e isolare la parte segreta con un solo numero grande lo rende molto più facile da usare.

Le ragioni per proteggere la chiave, non l'algoritmo, sono le maggiori possibilità che l'algoritmo sia trapelato, un numero maggiore di possibili chiavi rispetto ai possibili algoritmi e il maggior costo di una perdita. L'algoritmo è molto facile da perdere. Gli algoritmi presumibilmente classificati e i segreti hardware sono trapelati ogni giorno, ad esempio da:

• Un hacker che ruba il tuo codice sorgente
• Rendere disponibile il tuo algoritmo per il pentesting o per i ricercatori da recensire.
• Reverse-engineering del tuo algoritmo da parte di chiunque ottenga il software / hardware
• Reverse-engineering del tuo algoritmo da parte di chiunque usi anche l'algoritmo
• Ex dipendenti insoddisfatti o malevoli che perdono l'algoritmo
• Ipotesi della forza bruta in quanto di solito è molto più facile indovinare un algoritmo insicuro piuttosto che indovinare una chiave a 256 bit.

Rivelare il tuo algoritmo ai ricercatori presenta un Catch-22. Non puoi sostenere che un metodo segreto è sicuro senza rivelarlo , a quel punto non è più segreto o sicuro. Ecco perché segregiamo la parte segreta dei nostri algoritmi. puoi mostrare che l'utilizzo del tuo metodo non rivela una chiave segreta.

Una perdita o una rekey sono anche molto costose quando l'algoritmo è parte del segreto. Per stare al passo con gli attaccanti, devi ridisegnare e aggiornare ogni utilizzo dell'algoritmo con qualcosa di completamente nuovo. Potresti anche dover cambiare il "segreto" ogni pochi mesi se gestisci un sistema molto sicuro. È molto più facile sostituire la chiave in un algoritmo sicuro piuttosto che sostituire l'intero algoritmo , soprattutto quando è coinvolto l'hardware, la compatibilità all'indietro o l'invio di aggiornamenti ai client.

L'idea qui è che ogni sistema sicuro ha un segreto. Ogni volta che si genera qualcosa che non si vuole che un hacker sia in grado di invertire o indovinare senza conoscere un segreto, è un buon metodo per:

1. Rendi le conoscenze segrete facili da modificare o sostituire.
2. Assicurati che il segreto stesso sia difficile da dedurre da input e output
3. Assicurati che il segreto sia abbastanza complesso da non poter essere indovinato

Se costruisco una scatola che contiene un numero e ne sputa un altro (o prende un seme e sputa valori "casuali", ecc.), allora qualcuno costruisce una scatola identica, ora devo cambiare la mia scatola. Se tutto quello che devo cambiare sulla mia scatola sta cambiando un numero a 256 bit, mi fa risparmiare un sacco di tempo e fatica. Allo stesso modo, se voglio vendere queste scatole, ognuna deve essere diversa. Cambiare l'algoritmo per ogni scatola che vendi, invece di cambiare una chiave casuale per ogni scatola, sarebbe un design ridicolo.

Infine, vale la pena capire che la sicurezza attraverso l'oscurità e la "rotazione della propria crittografia" si trovano spesso insieme. Non eseguire il rollover della tua crittografia. Cambiando segretamente la tua crittografia, il guadagno in segretezza è compromesso da una perdita di sicurezza. Ruotando la tua cripto tu stai probabilmente facendo crollare il tuo sistema o anche 2 ^ (numero elevato) volte meno costoso, e ti garantisco che un attaccante non farà trilioni di tentativi per scoprire come hai fatto il tuo sistema.

La sicurezza attraverso l'oscurità significa che la sicurezza dipende dal fatto che l'algoritmo viene tenuto segreto.

Ad esempio, se decido di utilizzare rot13 per la mia crittografia, la sicurezza del sistema dipende da me, assicurandomi che nessun altro conosca l'algoritmo che sto utilizzando. Infine, mi spetta decidere quale sia l'algoritmo fasullo.

Uno dei problemi principali è che non posso distribuire questo sistema, perché chiunque può semplicemente decodificare l'algoritmo e usarlo per interrompere la crittografia. Inoltre, se il codice è compromesso, lo è anche per tutto il resto.

Un protocollo che fa affidamento sulla sicurezza dall'oscurità di solito sarà alla fine scoppiettante analizzando anche l'output. (Naturalmente, si possono ingegnare algoritmi che non sono inclini a questo: la cosa più semplice da fare è prendere l'algoritmo RSA e i keypair dell'hardcode, creando banalmente un algoritmo "sicurezza per oscurità".) Non ci si deve fidare dell'algoritmo non sarà indovinato.

D'altra parte, se uso RSA per la crittografia, posso avere ciascuna istanza generare la propria coppia di chiavi, e quindi il programma può essere distribuito senza paura. Posso proteggere le chiavi dall'essere compromessa da dispositivi hardware speciali che contengono la chiave e possono crittografare i messaggi ma non hanno la possibilità di sputare la chiave. Inoltre, essendo un protocollo pubblicamente noto, molte persone hanno analizzato il protocollo per i buchi di sicurezza; Posso fidarmi che i messaggi criptati non possano essere violati. Sappiamo che le chiavi non possono essere indovinate perché la probabilità è dalla nostra parte.

Questa non è sicurezza per oscurità. Questa è sicurezza attraverso la segretezza. L'algoritmo è pubblico, c'è solo un "segreto" (la chiave) che viene tenuto segreto.

Come altri hanno già detto, l'oscurità si riferisce davvero all'implementazione.

Lasciatemi fare un esempio. Immagina che tu e il tuo partner possiate avere un chilo di pepite d'oro nella vostra casa che desiderate proteggere, ma non siete d'accordo su come ...

Uno di voi capita di avere un genio, che è possibile ordinare per incenerire chiunque entri a meno di 5 piedi senza fornire una password.

Uno di voi vuole nascondere le pepite nel tubo di scarico del lavello della cucina, dicendo che lo scarico funzionerà ancora e nessuno avrebbe mai pensato di guardare lì. Questo metodo è stato utilizzato con tutti i partner passati e non ha ancora fallito.

Sia la password che la posizione sono "segrete", ma la posizione si basa su di loro che non guardano lì, mentre la password, anche se la riutilizzate ovunque, dipende da loro che non la conoscono.

Prendi una scala scorrevole da 1 a 10, 10 come "sicurezza conforme IEEE" e 1 come "volta a prova di coltello fatta da strati di flanella". "Sicurezza attraverso l'oscurità" è una frase usata per descrivere un piano di sicurezza in cui il valore è compreso tra 1 e 8, a seconda di chi chiedi e il giorno della settimana, così come il livello attuale stimato di espulsione di massa coronale da Betelgeuse.

In altre parole, è il risultato di una misurazione interamente soggettiva di quanto sia vicino a una politica di sicurezza standard, dal momento che nessuno può forse conoscere la differenza tra i rischi, durante un exploit zero-day, a uno standard vs un non- piano di sicurezza standard.

Penso che la sicurezza attraverso l'oscurità possa essere vista in questo modo:

You have a door that unlocks by turning the door knob a full clockwise direction instead of anti-clockwise. You provide a keyhole on the door knob to obscure the fact that it doesn't require a key to unlock.

Tradotto in tecnologia dell'informazione, penso che questo sia simile all'implementazione di una funzionalità di sicurezza in un modo insolito per eliminare qualsiasi attaccante. Ad esempio, masquerading di un server Web come IIS quando è in realtà Nginx.

La sicurezza attraverso l'oscurità non è necessariamente cattiva sicurezza. La chiave sta nella sua implementazione. Ovvero, se sei in grado di eseguirlo in modo coerente senza inciampare a causa di questa funzione non convenzionale che hai implementato.

Un sacco di testo, per una bella domanda.

Consentitemi di semplificare la risposta a questo con un'analogia. L'oscurità può essere definita in molti modi, il tutto in accordo con un altro. 'Qualcosa di difficile da comprendere ha un'oscurità'.

Osserva una porta, ti suggerisco che ci sono 3 modi per proteggere una porta. 1. Nascondere la maniglia (oscurità, nessuna sicurezza) 2. Bloccalo con una chiave (sicurezza) 3. Nascondere la maniglia e bloccarla con una chiave (sicurezza e oscurità)

(Potresti anche nascondere il buco della serratura o il lucchetto, per quanto riguarda la mia analogia)

Che importa è anche se si pensa che la porta ha bisogno di una chiave, non sappiamo quale, che io abbia segretezza o sicurezza. Tutti sanno che una maniglia sulla porta viene utilizzata per aprirla, nascondere la maniglia è solo un'oscurità.

Combinati, questi approcci sono in realtà più sicuri di quanto non lo siano da soli.

L'oscurità si occupa di come le cose sono sicure, piuttosto che quali informazioni sono necessarie per ottenere l'accesso. Nel caso di qualcosa come cambiare le porte, la porta da usare è il mezzo effettivo di messa in sicurezza ed è anche facilmente ottenibile osservando il comportamento. Quando si utilizza un algoritmo closed source e si basa sulla natura closed source per renderlo difficile da capire, la sicurezza è la stessa per tutti coloro che utilizzano il sistema. Se la rompi una volta, la rompi per tutti perché stai lasciando un attacco all'intero sistema fino all'oscurità.

Per qualcosa come una password, è una chiave. Sì, quella chiave è un segreto "oscuro", ma conoscere una password particolare non infrange il sistema, ma interrompe l'utente. La sicurezza del sistema funziona perfettamente anche quando nota. Riesce ancora a consentire solo agli utenti che possiedono tale conoscenza e ciascun utente è in grado di utilizzare un segreto diverso o cambiare il proprio segreto per consentire l'accesso.

Quindi la differenza è se si ha a che fare con la segretezza del metodo o della segretezza della chiave. Se il metodo richiede la segretezza per essere sicuro, si interrompe, nella sua interezza, non appena il metodo viene compromesso. Se il metodo non richiede segretezza, ma solo informazioni per un particolare utilizzo di esso, fornisce sicurezza poiché lo scopo di un compromesso è limitato a una relazione 1: 1 tra segreto e oggetto a cui si accede.

Effettivamente, se puoi mappare il segreto a una cosa particolare che è protetta e la protezione di quel segreto è sufficiente se dovessi sostituire la cosa che protegge, allora il sistema è abbastanza sicuro.