it-swarm.dev

Tutta la sicurezza non è "attraverso l'oscurità"?

So che non si dovrebbe fare affidamento su "oscurità" per la loro sicurezza. Ad esempio, scegliere una porta non standard non è davvero sicurezza, ma di solito non fa male farlo (e può aiutare a mitigare alcuni degli attacchi più banali).

Hashing e crittografia si basano su una forte randomizzazione e chiavi segrete. RSA, ad esempio, si basa sulla segretezza di d e, per estensione, p, q e ϕ(N). Dal momento che quelli devono essere tenuti segreti, non è tutta la sicurezza della crittografia (e hashing, se conosci il vettore di randomizzazione) attraverso l'oscurità? In caso contrario, qual è la differenza tra oscurare la salsa segreta e mantenere segreta la roba segreta? Il motivo per cui chiamiamo la crittografia (corretta) è perché la matematica è irrefutabile: è computazionalmente difficile, ad esempio, il fattore N per capire p e q (come per quanto ne sappiamo). Ma questo è vero solo perché p e q non sono noti. Sono sostanzialmente oscurato.

Ho letto Il ruolo valido dell'oscurità e A che punto qualcosa conta come "sicurezza attraverso l'oscurità"? , e la mia domanda è diversa perché non mi sto chiedendo quanto l'oscurità è valida o quando nello spettro uno schema diventa oscuro, ma piuttosto, sto chiedendo se nascondere tutta la nostra roba segreta non sia essa stessa oscurità, anche se definiamo la nostra sicurezza essere raggiunto attraverso tali meccanismi. Per chiarire cosa intendo, le risposte di quest'ultima domanda (eccellente, tra l'altro) sembrano fermarsi a "... hanno ancora bisogno di decifrare la password" - il che significa che la password è ancora oscurata dall'aggressore.

44
Matt

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 deve essere misurabilità. È segreto ciò che non è noto agli estranei, e sappiamo quanto non è noto a questi estranei. Ad esempio, una chiave simmetrica a 128 bit è una sequenza di 128 bit, in modo tale che tutti e 2128 le possibili sequenze avrebbero la stessa probabilità di essere utilizzate, quindi l'attaccante che cerca di indovinare una tale chiave deve provare, in media, almeno 2127 di loro prima di colpire quello giusto. Quello è quantitativo. Possiamo fare matematica, aggiungere figure e calcolare costo di attacco.

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

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

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

62
Tom Leek

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 .

Non deve essere richiesto per essere segreto, e deve poter cadere nelle mani del nemico senza inconvenienti;

La sicurezza attraverso l'oscurità si riferisce al fare affidamento sul mantenimento della progettazione e implementazione di un sistema di sicurezza sicuro nascondendo i dettagli di un aggressore. Questo non è molto affidabile in quanto i sistemi e i protocolli possono essere retroingegnerizzati 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 maggiori difetti di sicurezza rispetto a un sistema che è stato esaminato, i bug sono resi noti e corretti.

Prendi RSA per esempio. Tutti nel mondo sanno come funziona. Bene, tutti quelli che hanno una buona conoscenza della matematica sono comunque coinvolti. È ben studiato e si basa su difficili problemi matematici. Tuttavia, dato ciò che sappiamo della matematica in questione, è sicuro a condizione che i valori di p e q siano tenuti segreti. Questo è essenzialmente concentrando il lavoro di spezzare (e proteggere) il sistema in un segreto che può essere protetto.

Confronta questo con un algoritmo di crittografia che non è conforme al principio di Kerckhoffs. Invece di utilizzare uno schema noto pubblicamente che utilizza una chiave segreta, questo algoritmo di crittografia è segreto. Chiunque conosca l'algoritmo può decrittografare tutti i dati crittografati con l'algoritmo. Questo è molto difficile da proteggere poiché l'algoritmo sarà quasi impossibile da tenere lontano dalle mani di un nemico. Vedi Enigma machine per un buon esempio di questo.

15
user10211

La differenza fondamentale sta in ciò che è 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 poterlo sfruttare per la sicurezza, ma è stato fatto in modo indipendente almeno due volte (da Rivest, Shamir e Adleman, e qualche anno prima da Clifford Cocks ) . Se progetti qualcosa come RSA e lo tieni segreto, ci sono buone probabilità che qualcun altro sia abbastanza intelligente da capirlo.

D'altra parte, una chiave privata viene generata in modo casuale. Se eseguita correttamente, la generazione casuale garantisce l'impossibilità di ricostruire il segreto con la potenza di calcolo umanamente disponibile. 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 ampiamente condivisi (proteggere alcuni dati, implementare l'algoritmo a buon prezzo, ...). C'è una buona probabilità che persone intelligenti convergano nello stesso algoritmo. D'altra parte, le stringhe casuali di bit segreti sono abbondanti e per definizione le persone non escono con la stessa stringa casuale¹. Quindi, se progetti il ​​tuo algoritmo, c'è una buona probabilità che il tuo vicino progetterà lo stesso. E se condividi il tuo algoritmo con il tuo amico e poi vuoi comunicare da lui in privato, avrai bisogno di un nuovo algoritmo. Ma se generi una chiave segreta, sarà distinta da quella del tuo vicino e di quella del tuo amico. C'è sicuramente un potenziale valore nel mantenere segreta una chiave casuale, il che non è il caso di mantenere segreto un algoritmo.

Un punto secondario sulla segretezza chiave è che può essere misurato. Con un buon generatore casuale, se generi una stringa casuale di n-bit e la tieni 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 scoprirà 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 indistruttibile. (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, questo è qualcosa che non possiamo dimostrare matematicamente, ma crediamo che sia così perché molte persone intelligenti hanno provato e fallito. un'altra storia.)

Naturalmente 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 la piccola parte che è un gruppo casuale di bit. Principio di Kerckhoff non lo dice - afferma che la sicurezza del design non dovrebbe fare affidamento sulla segretezza del design. Mentre gli algoritmi crittografici sono meglio pubblicati (e dovresti aspettare circa un decennio prima di usarli per vedere se abbastanza persone non sono riusciti a romperli), ci sono altre misure di sicurezza che sono meglio tenute 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 offre protezione contro un utente malintenzionato che sa che le regole sarebbero inutili, poiché alla fine qualcuno le capirà.

¹ Sebbene ciò non sia matematicamente vero, puoi letteralmente scommettere su di esso.

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

E in particolare, i migliori protocolli di sicurezza si basano sul principio di prendere in considerazione il segreto dal design, in modo che il tuo segreto possa essere mantenuto senza dover mantenere segreto anche il design. Ciò è particolarmente importante perché i progetti di sistemi sono notoriamente impossibili da mantenere segreti. Questo è il nucleo del principio di Kerckhoffs , che risale al design delle vecchie macchine militari di crittografia.

In altre parole, se l'algoritmo è il tuo segreto, allora chiunque vede 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 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 cambiare l'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 - una chiave o una password segreta - il tuo sistema rimarrà sicuro anche dopo l'esame del dispositivo dai tuoi nemici, hacker, clienti, ecc. In questo modo puoi focalizzare la tua attenzione nel proteggere solo la password, rimanendo fiduciosi che il tuo sistema non può essere rotto senza di essa.

7
tylerl

La sicurezza attraverso l'oscurità generalmente si riferisce a principio di Kerchoff , che afferma che il sistema deve essere sicuro anche se tutto tranne la chiave è conoscenza comune. Questo non si applica solo alla crittografia o alla generazione di 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 con un solo numero elevato ne semplifica notevolmente l'utilizzo.

Le ragioni per proteggere la chiave, non l'algoritmo, sono le maggiori probabilità che l'algoritmo venga trapelato, un numero maggiore di chiavi possibili rispetto a possibili algoritmi e il maggior costo di una perdita. L'algoritmo è molto facile da perdere. Algoritmi e segreti hardware presumibilmente classificati vengono divulgati ogni giorno, ad esempio:

  • Un hacker che ruba il tuo codice sorgente
  • Rendere il tuo algoritmo disponibile per il pentesting o la revisione da parte dei ricercatori.
  • Reverse-engineering del tuo algoritmo da parte di chiunque ottenga il software/hardware
  • Reverse-engineering del tuo algoritmo da parte di chiunque utilizzi anche l'algoritmo
  • Ex dipendenti scontenti o maliziosi 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 ai ricercatori presenta un Catch-22. Non puoi sostenere che un metodo segreto sia sicuro senza rivelarlo , a quel punto non è più segreto o sicuro. Ecco perché separiamo la parte segreta dei nostri algoritmi. can mostra che l'utilizzo del tuo metodo non rivela una chiave segreta.

Una perdita o una nuova chiave sono anche molto costose quando l'algoritmo fa parte del segreto. Per stare al passo con gli aggressori devi riprogettare e aggiornare ogni utilizzo dell'algoritmo con qualcosa di nuovo. Potrebbe anche essere necessario cambiare il "segreto" ogni pochi mesi se si utilizza un sistema molto sicuro. È molto più semplice sostituire la chiave in un algoritmo sicuro che sostituire l'intero algoritmo , specialmente 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 ingegneria:

  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 accetta 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 è cambiare un numero di 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 ridicolmente cattiva progettazione.

Infine, vale la pena capire che la sicurezza attraverso l'oscurità e "roll your own crypto" si trovano spesso insieme. Non lanciare la tua criptovaluta. Modificando segretamente la tua criptovaluta, il guadagno in segreto viene compromesso da una perdita di sicurezza. Con il lancio della tua criptovaluta, molto probabilmente stai rendendo il tuo sistema trilioni o addirittura 2 ^ (gran numero) volte più economico da decifrare, e garantisco che un attaccante non prenderà un trilione di ipotesi per scoprire come hai fatto a rotolare il tuo sistema.

3
Cody P

La sicurezza attraverso l'oscurità significa che i cardini di sicurezza sull'algoritmo vengono mantenuti segreti.

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, spetta a me determinare quanto sia fragile l'algoritmo.

Un grosso problema è che non riesco a distribuire questo sistema, perché chiunque può semplicemente decodificare l'algoritmo e usarlo per interrompere la mia crittografia. Inoltre, se il codice è compromesso, lo è anche tutto il resto.

Un protocollo che si affida alla sicurezza per oscurità di solito sarà eventualmente crackabile analizzando anche l'output. (Naturalmente, si possono progettare algoritmi che non sono inclini a questo - la cosa più semplice da fare è prendere l'algoritmo RSA e le chiavi di sicurezza hardcode, creando banalmente un algoritmo di "sicurezza per oscurità".) Non ci si dovrebbe fidare che l'algoritmo alla fine non verrà 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 hanno la possibilità di sputare la chiave. Inoltre, essendo un protocollo noto pubblicamente, molte, molte persone hanno analizzato il protocollo per falle di sicurezza; Posso fidarmi che i messaggi crittografati non possono 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, esiste solo un "segreto" (la chiave) che viene tenuto segreto.

2
Manishearth

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

Lasciami fare un esempio. Supponiamo che tu e il tuo partner abbiate una libbra di pepite d'oro nella vostra casa che desiderate proteggere, ma non siete d'accordo su come ...

Uno di voi ha un genio, che è possibile ordinare per incenerire chiunque si trovi 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 precedenti e non è ancora fallito.

Sia la password che la posizione sono "segrete" ma la posizione dipende dal fatto che non guardano lì, mentre la password, anche se la riutilizzi ovunque, si affida a loro che non la conoscono.

1
jmoreno

Prendi una scala mobile da 1 a 10, 10 essendo "sicurezza conforme IEEE" e 1 essendo "volta a prova di coltello fatto 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 si chiede 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 completamente soggettiva di quanto sia vicina una norma di sicurezza, dal momento che nessuno può conoscere la differenza tra i rischi, durante un exploit zero-day, a un piano di sicurezza standard rispetto a un non standard .

1
orokusaki

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

Hai una porta che si sblocca ruotando la manopola della porta in senso orario completo anziché antiorario. Fornisci un buco della serratura sulla maniglia della porta per oscurare il fatto che non richiede una chiave per sbloccare.

Tradotto in informatica, penso che sia simile all'implementazione di una funzione di sicurezza in un modo insolito per scacciare qualsiasi aggressore. Ad esempio, mascherando un server Web come IIS quando in realtà è Nginx.

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

1

Molto testo, per una grande 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 oscurità".

Osserva una porta, suggerirò che ci sono 3 modi per fissare una porta. 1. Nascondi la maniglia (oscurità, nessuna sicurezza) 2. Bloccala con una chiave (sicurezza) 3. Nascondi la maniglia e bloccala con una chiave (sicurezza e oscurità)

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

Qualunque cosa si pensi è che si sappia che la porta ha bisogno di una chiave, non sappiamo quale, che sia segretezza o sicurezza. Tutti sanno che una maniglia sulla porta viene utilizzata per aprirla, nascondere la maniglia è solo oscurità.

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

0
Pedro Rodrigues

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 cambiare le porte, la porta da utilizzare è il vero mezzo di protezione ed è anche facilmente ottenibile osservando il comportamento. Quando si utilizza un algoritmo di origine chiuso e si fa affidamento sulla natura di origine chiusa 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 conoscendo una particolare password non si rompe il sistema, si rompe l'utente. La sicurezza del sistema funziona perfettamente anche se nota. Riesce ancora a consentire solo agli utenti che possiedono tale conoscenza e ogni utente è in grado di utilizzare un segreto diverso o modificarne il segreto per consentire l'accesso.

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

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

0
AJ Henderson