Insidie ​​del codice crittografico

Question

Sto modificando il codice di sicurezza esistente. Le specifiche sono abbastanza chiare, c'è un codice di esempio, ma non sono un esperto di crittografia. In effetti, il codice di esempio ha un disclaimer che dice, in effetti, & Quot; Non usare questo codice alla lettera. & Quot;

Durante il controllo del codice che devo modificare (che presumibilmente è completo di funzionalità) mi sono imbattuto in questo piccolo gioiello che viene utilizzato per generare la sfida:

static uint16 randomSeed;

...

uint16 GetRandomValue(void)
{
  return randomSeed++;/* This is not a good example of very random generation :o) */
}

Ovviamente, la prima cosa che ho fatto immediatamente è stato passarlo in ufficio in modo che tutti potessimo ridere.

Il programmatore che ha prodotto questo codice sapeva che non era un buon algoritmo (come indicato dal commento), ma non credo che abbiano capito le implicazioni di sicurezza. Non si sono nemmeno preoccupati di chiamarlo nel circuito principale, così almeno si trasformerebbe in un contatore a corsa libera - ancora non è l'ideale, ma mondi oltre questo.

Tuttavia, so che il codice che produco farà allo stesso modo far ridere o tremare un vero guru della sicurezza.

• Quali sono i problemi di sicurezza più comuni, specifici della crittografia, che devo capire?
• Quali sono alcune buone risorse che mi daranno una conoscenza adeguata di ciò che dovrei sapere oltre gli errori comuni?

-Adam

Answer 1

Crittografia applicata è un libro eccellente per aiutarti a comprendere crittografia e codice. Esamina molti fondamenti, come il funzionamento dei cifrari a blocchi e perché scegliere una modalità di cifratura scadente renderà il tuo codice inutile anche se stai utilizzando una versione perfettamente implementata di AES.

Alcune cose a cui prestare attenzione:

• Fonti di casualità scadenti
• Prova di progettare il tuo algoritmo o protocollo: non farlo mai.
• Non riesaminare il codice. Preferibilmente pubblicandolo online.
• Non usare una libreria ben consolidata e provare a scriverla da soli.
• Crypto come una panacea - la crittografia dei dati non li rende magicamente sicuri
• Gestione chiavi. In questi giorni è spesso più facile rubare la chiave con un attacco del canale laterale che attaccare la criptovaluta.

Answer 2

Non provare a creare il tuo - usa una libreria standard se possibile. Lievi modifiche al codice di sicurezza possono avere un impatto enorme che non sono facili da individuare, ma possono aprire falle di sicurezza. Ad esempio, due righe modificate in una libreria ha aperto un buco che non era " prontamente evidente per un bel po 'di tempo.

Answer 3

La tua domanda mostra una delle più comuni: scarse fonti di casualità. Non importa se usi una chiave a 256 bit se i bit non sono abbastanza casuali.

Il numero 2 probabilmente suppone che tu possa progettare un sistema migliore degli esperti. Questo è un settore in cui un'implementazione di qualità di uno standard sarà quasi sicuramente migliore dell'innovazione. Ricorda, ci sono volute 3 versioni principali prima che SSL fosse davvero sicuro. Pensiamo.

Answer 4

IMHO, ci sono quattro livelli di attacchi di cui dovresti essere a conoscenza:

1. attacchi di ingegneria sociale. Dovresti addestrare i tuoi utenti a non fare cose stupide e scrivere il tuo software in modo che sia difficile per gli utenti fare cose stupide. Non conosco alcun riferimento su queste cose.

2. non esegue codice arbitrario (buffer overflow, exploit xss, iniezione sql sono tutti raggruppati qui). La cosa minima da fare per conoscere questo è leggere Scrivere codice sicuro da qualcuno in MS e guardare la discussione tecnica su Google come software Web How to Break. Questo dovrebbe anche insegnarti un po 'sulla difesa in profondità.

3. attacchi logici. Se il tuo codice sta manipolando testo semplice, certificati, firme, testi cifrati, chiavi pubbliche o altri oggetti crittografici, dovresti essere consapevole del fatto che gestirli in modi sbagliati può portare a cose cattive. Le cose minime di cui dovresti essere a conoscenza includono l'amplificatore & Offline; attacchi a dizionario online, attacchi replay, attacchi man-in-the-middle. Il punto di partenza per conoscere questo e generalmente un ottimo riferimento per te è http://www.soe.ucsc.edu/~abadi/Papers/gep-ieee.ps

4. attacchi crittografici. Le vulnerabilità crittografiche includono:

   • cose che puoi evitare: cattiva generazione di numeri casuali, utilizzo di una funzione hash non funzionante, implementazione non corretta della primitiva di sicurezza (ad es. un tecnico dimentica un -1 da qualche parte nel codice, il che rende reversibile la funzione di crittografia)
   • cose che non puoi evitare se non per essere il più aggiornato possibile: nuovo attacco contro una funzione hash o una funzione di crittografia (vedi ad esempio recenti discorsi MD5), nuova tecnica di attacco (vedi ad esempio recenti attacchi contro protocolli che inviano crittografati voice over the network)

Un buon riferimento in generale dovrebbe essere la crittografia applicata.

Inoltre, è molto preoccupante per me che le cose che vanno su un dispositivo mobile che è probabilmente bloccato e difficile da aggiornare sono scritte da qualcuno che sta chiedendo informazioni sulla sicurezza su StackOverflow. Credo che il tuo caso sarebbe uno dei pochi casi in cui hai bisogno di un consulente esterno (buono) che ti aiuti a ottenere i dettagli giusti. Anche se assumi un consulente per la sicurezza, che ti consiglio di fare, ti preghiamo di leggere anche i riferimenti (minimalisti) di cui sopra.

Answer 5

  

Quali sono i problemi di sicurezza più comuni, specifici della crittografia, che devo capire?

Facile - tu (1) non sei abbastanza intelligente da inventare il tuo algoritmo.

(1) E da parte tua intendo tu, io e tutti gli altri che leggiamo questo sito ... tranne forse Alan Kay e Jon Skeet .

Answer 6

Nemmeno io sono un tipo criptico, ma le S-box possono essere problematiche quando si scherza (e fanno la differenza). Hai anche bisogno di una vera fonte di entropia, non solo di un PRNG (non importa quanto sembri casuale). I PRNG sono inutili. Successivamente, dovresti assicurarti che la fonte dell'entropia non sia deterministica e che non possa essere manomessa.

Il mio modesto consiglio è: attenersi agli algoritmi crittografici noti, a meno che non siate esperti e comprendiate i rischi. Potresti stare meglio usando un codice open source / pubblico dominio testato e pubblicamente disponibile.