Come verificare il motore di crittografia?

5

Se ho capito bene, quando uso un motore crittografico (hardware), devo fidarmi di esso. Esistono algoritmi crittografici con proprietà che mi consentono di verificare la correttezza di un motore in un modo computazionalmente più economico rispetto allo stesso lavoro?

Modifica
Nella mia realtà paranoica, presumo che il motore sia stato appositamente realizzato per restituire risultati corretti, ad eccezione dei testi in chiaro con determinate parole chiave per le quali si costruisce in una backdoor. Quello che sto cercando è un modo generale per verificare la correttezza dell'output per l'input arbitrario senza conoscere l'output corretto (anche se non sono sicuro che ciò sia matematicamente possibile).

    
posta flacs 04.06.2012 - 02:21
fonte

3 risposte

4

No. Non esiste un buon modo per rilevare backdoor nell'hardware crittografico. Ci sono troppi modi per nascondere le backdoor in modo che non vengano rilevate.

Il test non è un modo efficace per rilevare backdoor deliberatamente introdotti. Un attaccante può facilmente organizzare l'attivazione della backdoor solo per un particolare testo, o solo dopo aver ricevuto uno speciale "bussare criptico". Ad esempio, il motore hardware potrebbe contenere un valore segreto a 64 bit nascosto. Inizialmente, la backdoor è disabilitata. Tuttavia, se riceve un testo cifrato che inizia con il segreto a 64 bit, allora questo è il "criptico bussare"; quando viene ricevuto il "criptico bussare", il motore hardware può accendere la backdoor. Ciò consente a un utente malintenzionato di abilitare la backdoor qualche tempo dopo che il sistema è entrato in produzione. Un mezzo simile potrebbe anche essere utilizzato per consentire a un utente malintenzionato di indirizzare dinamicamente comunicazioni specifiche o di eludere in altro modo il rilevamento.

Ci sono molti modi in cui un motore di crittografia dannoso potrebbe sovvertire la tua sicurezza. Se lo si utilizza per generare numeri casuali o chiavi crittografiche, potrebbe "aumentare" l'origine del numero casuale e generare chiavi che saranno ritenute ipotetiche per l'autore dell'attacco. Se lo si utilizza per verificare l'integrità del messaggio firmato, potrebbe potenzialmente accettare in modo falso determinati messaggi dannosi segnalati dall'attaccante. Se lo si utilizza per crittografare i dati riservati, potrebbe potenzialmente divulgare i dati riservati al resto del mondo in diversi modi. Se ha accesso diretto alla rete, potrebbe perdere dati e chiavi riservati semplicemente inviandoli sulla rete. Se non ha accesso diretto alla rete, potrebbe comunque nascondere dati confidenziali o segreti crittografici nei testi cifrati e diffondere queste informazioni su un canale subliminale (ad esempio, sfruttando il grado di libertà nella scelta di un nonce, IV , o altri valori casuali per nascondere i dati segreti in essi contenuti.

E anche se non può fare nulla di tutto ciò, un motore criptato malevolo potrebbe ancora perdere dati riservati o materiale chiave crittografico utilizzando un canale temporale. Vedi Jitterbug per un esempio di un componente hardware dannoso che esalta i dati riservati regolando i tempi di pacchetti di rete. Un motore crittografico dannoso potrebbe utilizzare un meccanismo simile: ad esempio, quando viene richiesto di crittografare qualcosa, ritarda la risposta alla richiesta finché il bit di ordine inferiore del tempo corrente in millisecondi corrisponde al bit che desidera inviare. Pertanto, il momento in cui i pacchetti di testo cifrato vengono inviati sulla rete genererà informazioni sull'ora in cui il motore di crittografia ha risposto, il che a sua volta nasconde un messaggio subliminale che il motore di crittografia dannoso ha voluto estrarre.

In conclusione: se non ti fidi dell'hardware crittografico, non c'è praticamente alcun modo di vincere. Quindi dovresti utilizzare solo l'hardware crittografico di cui ti fidi.

    
risposta data 04.06.2012 - 04:57
fonte
4

Se desideri verificare la funzionalità di base di un motore di crittografia, inserisci una buona selezione di input e verifica che restituisca risultati corretti su questi input. Se il tuo campione è ben scelto, puoi avere la certezza che il motore sia funzionalmente corretto.

Molti algoritmi crittografici basati su una struttura matematica (in genere algoritmi a chiave pubblica come RSA) hanno metodi per ottenere una certa sicurezza che il risultato sia corretto senza fare tutto il lavoro. Ad esempio, se si esegue un calcolo basato su operazioni modulo un numero intero di grandi dimensioni, è possibile eseguire il modulo di calcolo un piccolo numero intero e verificare che il risultato sia corretto modulo quel piccolo numero intero¹ - una generalizzazione del lancio dei nuli. Questa tecnica è conosciuta come wooping . Questi controlli possono funzionare contro le librerie bignum dannose se si esegue il test con numeri casuali sufficientemente piccoli. Tuttavia, non puoi sempre farlo; ad esempio, se esistesse un modo per controllare un digest crittografico più economico rispetto al calcolo lungo, l'algoritmo di digest sarebbe seriamente danneggiato. Non conosco nulla di analogo per gli algoritmi di crittografia simmetrica.

Se vuoi sapere se il motore di crittografia è sicuro , è una questione completamente diversa. Il motore potrebbe perdere dati attraverso i canali laterali e non è possibile notarlo testando. Lo si può notare solo con uno studio molto attento, preferibilmente con una scatola aperta. Allo stesso modo, la generazione di numeri casuali non può essere testata ed è difficile ottenerla; puoi guadagnare un po 'di confidenza con i test statistici, ma non tutti i generatori di numeri casuali staticamente validi sono abbastanza buoni per la crittografia, che richiede numeri casuali imprevedibili. Ecco alcuni esempi di vulnerabilità che possono essere molto difficili da rilevare e praticamente impossibile da rilevare se sono backdoor intenzionali:

  • Il generatore casuale ha una bassa entropia: restituisce numeri casuali prevedibili con una probabilità irragionevolmente alta. Esempio (accidentale): la vulnerabilità Debian OpenSSL .
  • Il motore perde informazioni riservate come l'output RNG o il materiale chiave attraverso il suo tempo di risposta. (Questo è un esempio di canale laterale , ci sono canali laterali diversi dal tempo: consumo di energia, emissioni radio, ecc. )
  • Il motore perde informazioni riservate attraverso i normali canali in modo non rilevabile, grazie a un canale subliminale . Ad esempio, ogni volta che il motore genera un nonce casuale (un IV per le modalità di crittografia a blocchi, il padding RSA, il parametro di firma k in DSA, ecc.), n - il valore casuale del bit è in realtà un valore casuale ( n -1) -bit più un bit della chiave crittografato con una chiave segreta.

I motori crittografici possono essere certificati per essere conformi agli standard di sicurezza come Common Criteria e < a href="http://en.wikipedia.org/wiki/FIPS_140"> FIPS 140 . Escludendo certificazioni "banali" come FIPS 140-2 livello 1 che non dicono nulla sulla sicurezza, una certificazione richiede diversi mesi di manodopera ed è eseguita da esperti. Anche se il tuo motore di crittografia è certificato, leggi attentamente la certificazione: la maggior parte delle certificazioni garantisce il motore solo se viene utilizzato in condizioni molto precise e solo contro i malintenzionati con mezzi limitati. E ovviamente in fine la certificazione è solo l'opinione di un professionista; i prodotti certificati possono essere stati danneggiati.

¹ Sto semplificando un bel po '. Leggi in lezione di Sami Vaarala o in Bruce Schneier et al Ingegneria della crittografia o Jurjen Bos's thesis .

    
risposta data 04.06.2012 - 03:01
fonte
0

Sembra un lavoro per Test unitario . Penso che questi test siano altamente specifici per la tua piattaforma, ma guarderebbero qualcosa del genere .

    
risposta data 04.06.2012 - 02:30
fonte

Leggi altre domande sui tag