Dimostrazione di come la sicurezza attraverso l'oscurità non funziona

3

Devo dimostrare che la sicurezza attraverso l'oscurità fallisce due volte nel seguente scenario.

Ho una CHIAVE segreta.

L'utente A ottiene MessageX = SecretTransformation (KEY, SecretValue1);

L'utente B ottiene MessageY = SecretTransformation (KEY, SecretValue2);

SecretTransformation () non è una funzione crittografica standard.

Ora, la sicurezza attraverso l'oscurità è in contrasto con il principio dell'open design e la massima di shannon. Sappiamo anche che questa sicurezza fallirà non appena un hacker riuscirà a recuperare uno dei "segreti"

ciò che in aggiunta si pensa possa essere dimostrato, è questo:

se un utente malintenzionato riesce a recuperare, MessageX e MessageY senza conoscere alcun segreto, può eseguire un attacco di crittanalisi e recuperare il KEY o comprendere il funzionamento di SecretTransformation.

Questo dovrebbe essere vero e diventare più strong con il numero di messaggi che l'attaccante è in grado di raccogliere. messageX messageY ... messageN Spero di aver spiegato a me stesso di aver bisogno di essere indicato per alcuni esempi come il one time pad, in cui se si XOR con la chiave più di un messaggio si può tornare indietro e recuperare il segreto.

qui c'è un'immagine per lo schema suggerito link

Grazie!

    
posta NoobTom 29.03.2012 - 14:07
fonte

4 risposte

7

Non esiste tale legge. Dici che pensi che un sacco di cose siano vere, ma non credo che quelle cose siano effettivamente vere, quindi penso che devi riesaminare le tue premesse.

"Sicurezza attraverso l'oscurità" non significa che un sistema sia necessariamente insicuro. È una cattiva strategia e una cattiva idea per la sicurezza del tuo sistema di affidarsi alla segretezza del tuo sistema. Storicamente, la maggior parte dei sistemi che hanno fatto affidamento sulla sicurezza attraverso l'oscurità hanno dimostrato di fornire scarsa sicurezza.

Ma nascondere i dettagli del sistema non trasforma magicamente in qualche modo un sistema sicuro in un sistema insicuro. Se si cripta con PGP, ma non dire a nessuno che lo stai facendo, questo non rende in qualche modo PGP insicuro. Non esiste una legge che dice che tutti i sistemi che non rivelano i loro dettagli sono necessariamente insicuri.

    
risposta data 29.03.2012 - 21:34
fonte
2

Guarderei il caso dell'Enigma (Enigma navale in particolare) nella Seconda Guerra Mondiale per una dimostrazione di come un sistema crittograficamente insicuro è stato rotto in gran parte perché gli aggressori sono stati in grado di ottenere un gran numero di messaggi crittografati e sfruttare i bit non casuali di quei messaggi per capire come funziona il sistema.

Durante la seconda guerra mondiale, la Germania utilizzò una macchina chiamata Enigma per crittografare i messaggi ai sottomarini e alle truppe sul campo usando quello che era essenzialmente un cifrario di sostituzione squisitamente complicato. Gli Alleati, lavorando a Bletchley Park, sono stati in grado di intercettare la maggior parte di questi messaggi da quando sono stati trasmessi alla radio. Nel corso degli anni, sono stati in grado di sfruttare il fatto che avevano un corpus piuttosto grande di messaggi crittografati per cercare modelli nell'output che potrebbero essere utilizzati per elaborare altri bit dell'algoritmo fino a quando non sono stati in grado di rompere il cifra. Con solo computer di base, questo è stato un processo meticoloso - c'è una decadenza decente di come Enigma è stato suddiviso in passaggi in una lezione di Tony Sale Bigrams, Trigrams e Enigma Navale .

La storia di Enigma indica anche il pericolo di affidarsi alla sicurezza attraverso l'oscurità in altri modi. Durante la guerra, gli Alleati furono in grado di rubare una manciata di macchine Enigma dai sottomarini tedeschi prima che affondassero, il che semplificò enormemente il lavoro svolto dagli spacciatori di codice. Allo stesso modo, quando i sistemi reali si affidano all'attaccante non sapendo come funziona il sistema, un determinato attaccante sarà sempre in grado di ottenere qualsiasi informazione di cui hanno bisogno per completare l'attacco attraverso altri canali (ingegneria sociale e fuga di informazioni generali quando le persone lasciano un compagnia per esempio).

    
risposta data 30.03.2012 - 01:39
fonte
2

"Security Through Obscurity" è un termine caricato che significa molto meno di quanto sembra. In un certo senso, quasi la tutta sicurezza viene acquisita attraverso l'oscurità. Ad esempio, la tua password è sicura solo nella misura in cui non è pubblicamente conosciuta. La chiave della vera sicurezza, però, è rendere i tuoi segreti facili da proteggere.

Certamente potrebbe rendere pubblica la tua password di crittografia e l'algoritmo segreto, e potresti goderti una certa quantità di sicurezza per un po 'di tempo. Tuttavia, gli algoritmi sono notoriamente facili da decodificare. Possono essere offuscati da trucchi del compilatore e tattiche intelligenti, ma un hacker decente con una moderata quantità di caffeina può solitamente affrontare qualsiasi sfida del genere in un solo giorno; due se si distrae.

Al contrario, i buoni algoritmi di crittografia sono costruiti non solo per proteggere il payload, ma anche la chiave, anche in condizioni estremamente avverse, come gli attacchi "plaintext" o "plaintext", e spesso prendono anche misure specifiche per proteggersi dagli attacchi dei canali laterali. Tutte queste misure sono intese a proteggere una specifica classe di segreti e hanno una comprovata esperienza di farlo.

Ora, certamente non c'è danno nel mantenere il tuo algoritmo segreto. Non può permettersi alcuna sicurezza aggiuntiva, ma non ha intenzione di danneggiare la tua sicurezza. E non ha senso rivelare più informazioni di quelle che devi Ma c'è un'enorme differenza tra mantenere l'algoritmo segreto perché puoi e tenerlo segreto perché la tua sicurezza dipende da esso . Di tutti i segreti che potresti mantenere, questo è uno dei più facili da ottenere per un attaccante. Quindi sarebbe saggio pianificare la tua sicurezza di conseguenza.

    
risposta data 30.03.2012 - 05:03
fonte
1

Considera un crittosistema e le sue vulnerabilità

Quando hai i seguenti componenti segreti del sistema:

  • KEY segreti (di solito uno per utente / utilizzo del sistema).
  • SecretTransformation (un solo segreto Singleton condiviso con tutti gli endpoint).

Confronta questi due scenari

  1. Sicurezza di una chiave segreta condivisa solo con le parti interessate.

  2. Sicurezza di SecretTransformation. Distribuito a TUTTE le parti, utenti, installatori, appaltatori, ISV, stampanti DVD, sviluppatori, revisori, addetti alle vendite, hacker che accedono a tutti i sistemi / backup in cui il codice è stato passato / presente / futuro.

Quindi confronta cosa succede se ognuno dei precedenti è compromesso.

  1. Una chiave segreta viene rigenerata e condivisa con le parti interessate.

  2. Il criptosistema completo deve essere nuovamente sviluppato e distribuito attraverso tutti gli stessi punti deboli.

Quindi succintamente:

  1. Un Cryptosystem con il solo segreto della chiave segreta ha un numero minimo di punti di vulnerabilità pari al numero di posti con la chiave. Tutte le parti hanno una buona comprensione e responsabilità per assicurare le chiavi segrete. L'ambito di ciascuna chiave è limitato dalla progettazione.
  2. Un criptosistema con SecretTransformation che è segreto ha letteralmente migliaia di potenziali punti deboli, ognuno dei quali richiede una grande quantità di lavoro da recuperare.

Quindi, scegli per sviluppare un sistema con così tanti punti deboli.

Un cryptosystem con SecretTransformation MAGGIO va bene fino alla rottura, ma un algoritmo aperto SEMPRE sarà migliore.

    
risposta data 16.04.2014 - 07:58
fonte

Leggi altre domande sui tag