Vedi questa risposta.

Il punto principale è che facciamo una netta distinzione tra oscurità e segretezza ; se dobbiamo restringere la differenza a una singola proprietà, allora quella 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 tale che tutte le 2 ¹²⁸ sequenze possibili avrebbero la stessa probabilità di essere utilizzate, quindi l'aggressore che cerca di indovinare tale chiave deve provane, in media, almeno 2 ¹²⁷ prima di premere quello giusto. Questo è quantitativo . Possiamo fare calcoli, aggiungere cifre e calcolare il costo di attacco .

Lo stesso si applicherebbe a una chiave privata RSA. La matematica è più complessa perché i metodi conosciuti più efficaci si basano sulla fattorizzazione di interi e gli algoritmi coinvolti non sono facili da quantificare come la forza bruta su una chiave simmetrica (ci sono molti dettagli sull'utilizzo della RAM e parallelismo o mancanza di ciò). Ma è ancora segreto.

Al contrario, un algoritmo oscuro è "segreto" solo fintanto che l'aggressore non elabora i dettagli dell'algoritmo e ciò dipende da molti fattori: accessibilità all'hardware che implementa l'algoritmo, capacità di reverse engineering e intelligenza . Non abbiamo un modo utile per misurare quanto qualcuno possa essere intelligente. 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 è la 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 riusciti e possiamo quindi bilanciare i costi per prendere una decisione informata. Questo può funzionare solo perché possiamo attribuire numeri ai rischi di attacchi riusciti e questo può essere fatto solo con la segretezza, non con l'oscurità.

Penso che il termine "sicurezza attraverso l'oscurità" venga usato in modo improprio abbastanza spesso.

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

Non deve essere richiesto che sia segreto e deve essere in grado di cadere nelle mani del nemico senza inconvenienti;

La sicurezza attraverso l'oscurità si riferisce al fare affidamento sul mantenimento del progetto e dell ' implementazione di un sistema di sicurezza protetto nascondendo i dettagli a un aggressore. Questo non è molto affidabile in quanto i sistemi e i protocolli possono essere decodificati e smontati con un tempo sufficiente. Inoltre, un sistema che si basa sul nascondere la sua implementazione non può dipendere da esperti che lo esaminano per individuare i punti deboli, il che probabilmente porta a più falle di sicurezza rispetto a un sistema che è stato esaminato, ha i bug resi noti e corretti. RSA per esempio. Tutti nel mondo sanno come funziona. Bene, tutti quelli che hanno una buona conoscenza della matematica coinvolti comunque. È ben studiato e si basa su difficili problemi matematici. Tuttavia, dato ciò che sappiamo sulla 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.

Confronta questo con un algoritmo di crittografia che non aderisce 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ò decrittografare qualsiasi dato crittografato con l'algoritmo. Questo è molto difficile da proteggere poiché l'algoritmo sarà quasi impossibile da tenere fuori dalle mani di un nemico. Vedi la macchina Enigma per un buon esempio di questo.

La differenza fondamentale sta 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 (la matematica è vecchia di quasi mezzo millennio). Ci vuole più immaginazione ed esperienza per capire come sfruttare tutto ciò per la sicurezza, ma è stato fatto in modo indipendente almeno due volte (da Rivest, Shamir e Adleman e alcuni anni prima da Clifford Cocks) . Se progetti qualcosa come RSA e lo mantieni segreto, ci sono buone probabilità che qualcun altro sia abbastanza intelligente da capirlo.

D'altra parte, una chiave privata viene generata a caso. Se eseguita correttamente, la generazione casuale garantisce che sia impossibile ricostruire il segreto con la potenza di calcolo disponibile all'uomo. Nessuna intelligenza consentirà a nessuno 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 largamente condivisi (proteggere alcuni dati, implementare l'algoritmo in modo economico, ...). Ci sono buone possibilità che le persone intelligenti convergeranno sullo 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 progetti il ​​tuo algoritmo, ci sono buone probabilità che il tuo vicino crei lo stesso. E se condividi il tuo algoritmo con il tuo amico e poi vuoi comunicare in privato da lui, avrai bisogno di un nuovo algoritmo. Ma se generi una chiave segreta, sarà distinta da quella del tuo vicino e del tuo amico. C'è sicuramente un potenziale valore nel mantenere un segreto di chiave casuale, il che non è il caso di mantenere segreto un algoritmo.

Un punto secondario sulla segretezza delle chiavi è che può essere misurata. Con un buon generatore casuale, se generi una stringa casuale di n bit e la mantieni segreta, c'è una probabilità di 1/2 ^ n che qualcun altro la trovi in ​​un tentativo. 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 una praticamente indovinabile. (Per quanto riguarda le chiavi RSA che sono praticamente impossibili da ricostruire da una chiave pubblica e un mucchio 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. Ma questo è un'altra storia.)

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

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

¹ _{Sebbene questo non sia vero matematicamente parlando, puoi letteralmente scommetterci.}

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

E in particolare, i migliori protocolli di sicurezza sono costruiti attorno al principio di scomporre il segreto dal progetto, in modo che il tuo segreto possa essere mantenuto senza dover mantenere segreto anche il design. Ciò è particolarmente importante perché i progetti di sistema sono notoriamente impossibili da mantenere segreti. Questo è il nucleo del principio di Kerckhoffs , che risale alla progettazione di vecchie macchine di crittografia militare.

In altre parole, se l'algoritmo è il tuo segreto, quindi chiunque veda un'implementazione del tuo algoritmo - chiunque abbia il tuo hardware, chiunque abbia il tuo software, chiunque utilizzi il tuo servizio - ha visto il tuo segreto. L'algoritmo è un posto terribile per 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 segreto chiave o password: il tuo sistema rimarrà sicuro anche dopo che il dispositivo sarà stato esaminato dai tuoi nemici, hacker, clienti, ecc. rotto senza di esso.

La sicurezza attraverso l'oscurità si riferisce generalmente al principio di Kerchoff, che afferma che il sistema deve essere sicuro anche se tutto tranne la chiave è di dominio pubblico. Questo non si applica solo alla crittografia o alla generazione di testi cifrati. Significa anche che non dovresti contare sulla generazione di URL, password, hash, indirizzi di memoria e persino sull'architettura di sistema per essere segreti. Il motivo è che qualcosa nel sistema deve essere segreto e isolare la parte segreta a un solo numero grande lo rende molto più facile da usare.

I motivi per proteggere la chiave, non l'algoritmo, è la maggiore possibilità che l'algoritmo venga fuoriuscito, un maggior numero di possibili chiavi rispetto ai possibili algoritmi e il maggior costo di una perdita. L'algoritmo è molto facile da perdere. Presumibilmente algoritmi classificati e segreti hardware vengono trapelati ogni giorno, ad esempio da:

• Un hacker che ruba il tuo codice sorgente
• Metti a disposizione il tuo algoritmo per la revisione o per i ricercatori.
• Reverse engineering del tuo algoritmo da parte di chiunque ottenga il software / hardware
• Reverse engineering del tuo algoritmo da chiunque utilizzi anche l'algoritmo
• Scontento o dannoso ex dipendenti che perdono l'algoritmo
• Indovinare la forza bruta poiché di solito è molto più facile indovinare un algoritmo insicuro che indovinare una chiave a 256 bit.

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

Una perdita o una nuova chiave è anche molto costosa quando l'algoritmo fa parte del segreto. Per stare al passo con gli aggressori è necessario riprogettare e aggiornare ogni utilizzo dell'algoritmo con qualcosa di nuovo. Potrebbe anche essere necessario modificare il "segreto" ogni pochi mesi se si utilizza un sistema molto sicuro. È molto più facile sostituire la chiave in un algoritmo sicuro che sostituire l'intero algoritmo , soprattutto quando sono coinvolti hardware, compatibilità con le versioni precedenti o invio di aggiornamenti ai client.

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

1. Rendere la conoscenza segreta facile 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 prende un numero e ne sputa un altro (o prende un seme e sputa valori "casuali", ecc.), Poi qualcuno costruisce una scatola identica, ora devo cambiare la mia scatola. Se tutto ciò che devo cambiare sulla mia scatola è cambiare un numero a 256 bit, mi fa risparmiare molto 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 ridicolmente pessimo.

Infine, vale la pena capire che la sicurezza attraverso l'oscurità e il "roll your own crypto" sono spesso trovati insieme. Non lanciare la tua crittografia. Modificando segretamente la tua crittografia, il guadagno in segretezza è compromesso da una perdita di sicurezza. Lanciando la tua criptovaluta stai molto probabilmente rendendo il tuo sistema trilioni o anche 2 ^ (numero elevato) volte più economico da crackare, e ti garantisco che un attaccante non farà un trilione di tentativi per scoprire come hai rotolato 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 che mi assicuro che nessun altro conosce l'algoritmo che sto utilizzando. Infine, spetta a me determinare quanto sia crackabile l'algoritmo.

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

Un protocollo che si basa sulla sicurezza per oscurità di solito sarà eventualmente crackabile anche analizzando l'output. (Ovviamente, si possono progettare algoritmi che non sono inclini a questo: la cosa più semplice da fare è prendere l'algoritmo RSA e le coppie di chiavi hardcode, creando banalmente un algoritmo di "sicurezza per oscurità".) Non ci si dovrebbe fidare che l'algoritmo alla fine non sarà indovinato.

D'altra parte, se uso RSA per la crittografia, posso fare in modo che ogni istanza generi la propria coppia di chiavi, e quindi il programma può essere distribuito senza paura. Posso proteggere le chiavi dall'essere compromesse da speciali dispositivi hardware che contengono la chiave e possono crittografare i messaggi ma non ho la possibilità di sputare la chiave. Inoltre, essendo un protocollo pubblicamente noto, molte, molte persone hanno analizzato il protocollo per falle di sicurezza; Posso fidarmi che i messaggi crittografati 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 mantenuto segreto.

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

Faccio un esempio. Supponiamo che tu e il tuo partner abbiate una libbra di pepite d'oro in casa che desiderate mettere al sicuro, ma non siete d'accordo su come ...

Uno di voi ha un genio, che potete ordinare di incenerire chiunque si avvicini a un raggio di 1,5 metri 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 penserebbe mai di guardare lì . Questo metodo è stato utilizzato con tutti i partner precedenti e non ha ancora fallito.

Sia la password che la posizione sono "segrete" ma la posizione si basa sul fatto che non guardino lì, mentre la password, anche se la riutilizzi ovunque, dipende dal fatto che non lo sappiano.

Prendi una scala mobile da 1 a 10, dove 10 indica "sicurezza conforme IEEE" e 1 "caveau a prova di coltello realizzato con 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 del giorno della settimana, nonché dell'attuale livello stimato di espulsione di massa coronale da Betelgeuse.

In altre parole, è il risultato di una misurazione del tutto soggettiva di quanto sia vicina allo standard una politica di sicurezza, poiché nessuno può conoscere la differenza tra i rischi, durante un exploit zero-day, rispetto a uno standard vs un piano di sicurezza non standard.

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

Hai una porta che si sblocca ruotando il pomello della porta completamente in senso orario invece che antiorario. Fornisci un buco della serratura sul pomello della porta per nascondere il fatto che non è necessaria una chiave per sbloccare.

Tradotto nella tecnologia informatica, penso che questo sia simile all'implementazione di una funzione di sicurezza in un modo insolito per gettare fuori strada qualsiasi attaccante. Ad esempio, mascherare un server web come IIS quando in realtà è Nginx.

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

Tanto testo, per una grande domanda.

Consentitemi di semplificare la risposta a questa domanda con un'analogia. L'oscurità può essere definita in molti modi, tutti in accordo con un altro. "Qualcosa di difficile da comprendere è oscuro".

Osserva una porta, ti suggerirò che ci sono 3 modi per mettere in sicurezza una porta. Nascondi la maniglia (oscurità, nessuna sicurezza) 2. Bloccalo con una chiave (sicurezza) 3. Nascondi la maniglia e bloccala con una chiave (sicurezza e oscurità)

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

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

Combinato , 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 di quali informazioni sono necessarie per ottenere l'accesso. Nel caso di qualcosa come la modifica delle porte, la porta da utilizzare è il mezzo effettivo di protezione ed è anche facilmente ottenibile osservando il comportamento. Quando si utilizza un algoritmo closed source e ci si affida alla natura closed source per renderlo difficile da capire, la sicurezza è la stessa per tutti coloro che utilizzano il sistema. Se lo rompi una volta, lo 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 interrompe il sistema, infrange l'utente. La sicurezza del sistema funziona perfettamente anche quando è nota. Riesce ancora a consentire l'accesso solo agli utenti che possiedono quella conoscenza e ogni utente è in grado di utilizzare un segreto diverso o modificare il proprio segreto per consentire l'accesso.

Quindi la differenza è se hai a che fare con la segretezza del metodo o segretezza della chiave. Se il metodo richiede la segretezza per essere protetto, si rompe, nella sua interezza, non appena il metodo viene compromesso. Se il metodo non richiede la segretezza, ma solo informazioni per un particolare utilizzo di esso, allora fornisce sicurezza poiché l'ambito di una compromissione è limitato a una relazione 1: 1 tra segreto e cosa a cui si accede.

In effetti, se puoi mappare il segreto su una particolare cosa da proteggere e la protezione di quel segreto è sufficiente se sostituisci la cosa che protegge, allora il sistema è abbastanza sicuro.