Prevenzione di un attacco DoS computazionale nei crittosistemi a chiave pubblica

Question

Prevenzione di un attacco DoS computazionale nei crittosistemi a chiave pubblica

#1 da (1 voti)
#2 da (1 voti)

1

Sto progettando un server che accetta messaggi anonimi usando ECIES: come in, gli utenti anonimi inviano al server una chiave pubblica EC effimera, e il server usa ECDH per ricavare un segreto condiviso, e alcuni KDF per ottenere una chiave simmetrica condivisa per decifrare il messaggio reale. Il problema è ECDH, che è uno degli scambi di chiavi più veloci disponibili, è molto lento. Da alcuni test rapidi, il mio computer può gestire solo circa 3000 scambi di chiavi al secondo.

Un utente malintenzionato potrebbe costantemente calcolare gli scambi di chiavi e inviarli al server. Non sono troppo preoccupato per questo se l'attaccante ha effettivamente effettuato gli scambi di chiavi. Almeno in questo modo, l'attaccante farà tutto il lavoro (un po 'di più con ECDH) come server. Il problema è che un utente malintenzionato può inviare una chiave di immondizia e fare in modo che il server esegua molto lavoro eseguendo lo scambio di chiavi su garbage. La mia prima domanda è, in un'implementazione ragionevole come OpenSSL, che lo scambio di chiavi ritorni rapidamente con un errore, o impieghi molto tempo a fare calcoli inutili?

Supponendo che quanto sopra sia corretto, ci sono altri due problemi: un utente malintenzionato potrebbe usare la stessa chiave effimera più e più volte, mantenendo il segreto condiviso ma facendo ripetutamente il cambio di chiave del server; e un utente malintenzionato potrebbe precedere preventivamente molte chiavi effimere e inviarle tutte in una volta.

Un tentativo di soluzione a entrambi i problemi è che il server mantenga la propria coppia di chiavi effimera che cambia ogni ~ 10 minuti. Può pubblicare la sua chiave pubblica effimera firmata con la sua chiave privata permanente. Quindi non sarebbe irragionevole per il server ricordare le chiavi e i segreti corrispondenti ricevuti durante questo periodo. Tuttavia, questo non risolve realmente l'attacco precomputazione perché le chiavi EC generate correttamente funzioneranno ancora con uno scambio di chiavi, ma produrranno solo dati inutili. C'è un modo veloce per un server di sapere che una determinata chiave decodificherà il messaggio?

Ci scusiamo per il post lungo e grazie in anticipo a qualsiasi commento.

denial-of-service key-exchange

posta tomKPZ 30.07.2014 - 07:47

fonte

2 risposte

1

Ci vorrà molto tempo a fare calcoli inutili.
Si potrebbe concepibilmente usare un verificatore designato non interattivo a livello computazionale
argomento a conoscenza zero che il resto del messaggio è ben formato.

Più utile, usa prove di lavoro e PKE con decrittazione veloce .

risposta data 30.07.2014 - 08:02

fonte

Leggi altre domande sui tag denial-of-service key-exchange

Come garantire che solo la mia app per singola pagina possa effettuare richieste a un'API Rischio di sicurezza derivante dai dati trasmessi in $ _GET superglobal

score 1 · Accepted Answer

Il tuo benchmark è probabilmente incompleto. Ho un server che presenta una CPU riportata come: "Intel (R) Xeon (R) CPU E3-1220 V2 @ 3.10GHz". Ha quattro core. Su quella macchina, i report OpenSSL 1.0.1f (con openssl speed ecdhp224 ) che possono eseguire 9096 istanze ECDH al secondo, utilizzando la curva NIST P-224 (una curva fine, di sicurezza nominale a "112 bit", paragonabile a RSA- 2048). Questo è su un singolo core : la macchina ha quattro core, quindi può fare 36000 ECDH al secondo, 12 volte tanto quanto i numeri che segnali.

In realtà ricevere 36000 messaggi singoli al secondo può essere difficile. Un normale server simile a Unix può incontrare problemi di I / O molto prima di accettare 36000 connessioni TCP al secondo. Anche con UDP, è del tutto possibile che i costi di I / O domineranno, non la crittografia. Ciò richiede benchmark.

Si può notare che queste cifre implicano un costo elementare di circa 340000 cicli per moltiplicazione dei punti EC. Altre curve con implementazioni ottimizzate possono fare meglio. Questo articolo segnala una velocità di calcolo fino a 55000 cicli di clock per la curva K-233 (che offre sicurezza simile a P-224), che si tradurrebbe in più di 225000 ECDH al secondo sul mio server (penso di aver visto un articolo più recente che lo ottimizzò ulteriormente, fino a circa 40000 cicli di clock, ma non lo trovo al momento ). Ciò che mostrano queste cifre è che dovresti essere in grado di ottenere prestazioni molto migliori attenendosi allo standard ECIES (con curve standard).

Pertanto, suggerisco di investire ulteriormente la "strada di implementazione ottimizzata" piuttosto che ricorrere alle modifiche del protocollo: sembra probabile che si possa portare il costo relativo alla crittografia molto al di sotto dei costi di I / O.