Ci sono problemi seri con questo metodo per generare token monouso?

Naviga le tue risposte
3

Ho bisogno del tuo consiglio sulla sicurezza di questo design.

Ho uno scenario in cui un'applicazione server e un'applicazione smart card devono condividere un valore, ad es. 52, che è stato codificato in un token decimale lungo ma non esiste una connessione di rete diretta tra le due applicazioni.

Il token ha una lunghezza di 20 cifre e viene trasmesso via SMS a un destinatario che lo inserisce in un terminale, che lo inoltra alla smart card.

La domanda è qual è il modo migliore per autenticare il token.

Ecco cosa mi è venuto in mente:

  1. Creiamo una chiave simmetrica univoca (K) e la memorizziamo in modo sicuro nel server e l'elemento sicuro della smart card.
  2. Generiamo 10000 numeri casuali a 32 cifre e li memorizziamo in modo sicuro nel server e nell'elemento sicuro della smart card.
  3. Per generare un token, il server seleziona un indice (n) tra i 10000 numeri casuali, ad esempio 4821
  4. Associa il suo valore (v) a 7 indici separati (x0, x1 ... x6) nel formato base64 della chiave simmetrica (K).
  5. Infine, crea il token aggiungendo
    • le forme base 10 dei 7 caratteri (K [x0], K [x1] ... K [x6]),
    • l'indice (n) e
    • il valore originale a due cifre, ovvero 52

Ad esempio, se i 7 caratteri nel passaggio 5 sono rappresentati da "19-24-45-22-34-99-45", il token finale sarà "19-24-45-22-34-99- 45-48-21-52"

La smart card autentica il token eseguendo i passaggi 3-5 usando 4821 come valore per n, quindi confrontando il suo token con il token in entrata.

Nota: per evitare replay, sia il server che la smart card indicheranno null 4821 in modo che il set di caratteri mappati ad esso non possa essere selezionato o utilizzato di nuovo.

Essenzialmente ciò che ritengo di aver raggiunto è la possibilità di trasferire un token monouso autenticato di 20 cifre.

Supponendo che i dati memorizzati sul server e nell'elemento sicuro della smart card siano entrambi sicuri, ci sono dei nodi nell'armatura di cui devo essere a conoscenza?

Qualche consiglio sarà benvenuto.

Grazie

- - - EDIT (24-Apr-2013 14:45 GMT) - - -

Dev'essere stato un lungo giorno e una notte tarda e dopo aver letto tutte le grandi risposte (cioè i controlli di sanità mentale) di seguito, mi sembra di essere tornato in me e di aver gettato via l'idea criptata, pensata male e fatta in casa. :)

Come sfondo, questa soluzione è pensata per essere utilizzata in aree rurali con copertura di rete GPRS o 3G minima o nulla, e praticamente tutti hanno telefoni cellulari economici che supportano solo GSM e SMS (al contrario degli smartphone) ). Inoltre, le reti sono molto inaffidabili.

Ad ogni modo, ecco quello che ho ora:

Impostazioni

  1. Genera una chiave simmetrica condivisa univoca (K)
  2. Genera un file TAN (numero di autenticazione della transazione) (S)
  3. Copia K e S nel database del server e l'elemento sicuro della smart card

transazione

Se un server deve inviare un importo (v) a una smart card,

  1. Carica il file S e seleziona un nonce (n), cioè n = S[0]
  2. Invalida il nonce eliminandolo dal file S (previene attacchi di replay)
  3. Crea un messaggio concatenando l'importo e il nonce, ad esempio m = v || n
  4. Crea un testo cifrato (e1) cioè e1 = H(K,m) dove H="HMAC-SHA-1" o "CBC-MAC-Y" i.e ISO / IEC 9791-1 Algoritmo 3
  5. Converte il testo cifrato in base 10 e lo invia (via SMS) al cellulare dell'utente
  6. Detrae l'importo dal saldo lato server dell'utente

Quando l'utente "riceve il codice tramite SMS, digita la quantità (v) e il codice nel terminale che la trasmette all'app della smart card, che a sua volta esegue quanto segue:

  1. Carica il file S e seleziona un nonce (n), cioè n = S[i] , dove i = 0
  2. Crea un messaggio concatenando l'importo e il nonce, ad esempio m = v || n
  3. Crea un testo cifrato (e2) cioè e2 = H(K,m) dove H="HMAC-SHA-1" o "CBC-MAC-Y" i.e ISO / IEC 9791-1 Algoritmo 3
  4. Se e1 != e2 , ripete i passaggi (1) - (3) mentre incrementa (i) fino a 20 volte (per consentire la deriva). Se una corrispondenza non esiste, genera un messaggio di errore ed esce
  5. Se e1 == e2 , accetta il valore come credito sul saldo lato client dell'utente
  6. Infine, invalida tutti i nonces provati nel passaggio (1) eliminandoli dal file S

File TAN

Un file TAN è un elenco di 1000 nonce casuali ognuno dei quali è un numero di autenticazione di transazione esadecimale di 8 caratteri (TAN). Verrà utilizzato per determinare il valore nonce che verrà aggiunto a un messaggio per garantirne l'univocità e quindi impedire attacchi di riproduzione.

    
posta Niyi 24.04.2013 - 02:55
fonte

2 risposte

2

Non conosco le ragioni del tuo design, ma ti suggerisco di dare un'occhiata a HMAC prima di implementare una soluzione personalizzata. Supponendo che il server e la smart card condividano una chiave strong, puoi generare un codice di autenticazione dei messaggi per il tuo valore (più un indice incrementale, per impedire i replay), quindi sia l'autenticità che l'integrità del messaggio essere assicurato Ciò non garantirà comunque alcuna riservatezza, ma nemmeno il tuo metodo proposto, quindi presumo che non sia un problema nel tuo caso.

Detto questo, ecco cosa devo dire sulla tua soluzione proposta:

Da quanto ho capito, ad ogni scambio verranno esposte alcune parti della tua chiave K , giusto? ( K[x0], K[x1], ... ) Dopo alcune iterazioni [1] un intercettatore avrà visto (con un'alta probabilità) tutte le parti della tua chiave, anche se: a) non il loro ordine, poiché gli indici ( x0, x1, ... ) saranno sconosciuti; b) non importa, dal momento che i numeri casuali a 32 bit sono ciò che rende il protocollo sicuro (dal momento che non vengono mai riutilizzati, è strong come una password monouso). Tuttavia, se la segretezza di K è importante, suggerirei semplicemente di inviare il numero a 32 bit (con il suo indice), dal momento che è sufficiente per autenticare il mittente.

Inoltre, mentre il tuo protocollo è resiliente contro gli attacchi di replay, man-in-the-middle è ancora una possibilità [2]: supponiamo che il server mandi Alice "19-24-45-22-34-99-45-48 -21-52 "(annullando 4821 ) ma Mallory lo intercetta (quindi la smart card accetta ancora 4821 ). Quindi Mallory invia Alice "19-24-45-22-34-99-45-48-21- 42 ", che la immette nel terminale. La smart card lo accetterà volentieri, ma è il valore di Mallory ( 42 ) che è stato immesso, non quello del server ( 52 ), sebbene entrambi concordino che l'indice 4821 sia stato utilizzato una sola volta.

[1] Quanti dipendono dalle dimensioni di K . Una chiave a 128 bit rivelerebbe tutte le sue parti dopo 12 iterazioni con > 97% di probabilità, e quelle parti possono essere ricombinate con lo stesso sforzo della forzatura bruta di una chiave a 65 bit. Una chiave a 512 bit OTOH rivelerebbe le sue parti dopo 50 iterazioni, ma il numero di permutazioni necessarie per ricombinare la chiave è così grande (più grande della forzatura bruta della chiave stessa) che non ha importanza.

[2] Supponendo che si possano eseguire attacchi MitM su SMS. Non sono abbastanza informato su questo protocollo per dire se può succedere o no, quindi giocherei al sicuro ...

    
risposta data 24.04.2013 - 05:07
fonte
3

Questo è molto MOLTO molto tuo e non è una buona idea. Perché lo standard esistente per l'utilizzo di un hash di una crittografia di un valore di timestamp derivato è sufficiente per le tue esigenze? Il primo attacco che viene in mente è semplicemente il masquerading come server per ottenere i codici dalla carta. La vittima non avrebbe avuto un buon modo per sapere che non era il server e il server non avrebbe avuto modo di sapere che il codice era stato compromesso. Dal momento che non è legato a una particolare finestra temporale, il token potrebbe essere riutilizzato in qualsiasi punto futuro.

    
risposta data 24.04.2013 - 05:04
fonte

Leggi altre domande sui tag

Posso eseguire la scansione con nmap dai servizi cloud? [chiuso] BEAST mitigation su un servizio di bilanciamento del carico Cisco ACE 4710