Domanda:
Perché non si dovrebbe utilizzare la stessa chiave asimmetrica per la crittografia utilizzata per la firma?
Iszi
2011-01-22 02:06:42 UTC
view on stackexchange narkive permalink

In una risposta a una domanda su RSA e PGP, PulpSpy ha notato questo:

È possibile generare una coppia di chiavi RSA utilizzando GPG (sia per la crittografia e firma: non utilizzare la stessa chiave per entrambi).

Qual è il ragionamento alla base di questo?

Forse la mia comprensione della crittografia a chiave pubblica è viziata, ma pensavo che le operazioni fossero simili a questo:

  • Quando Bob vuole crittografare un messaggio ad Alice, usa la chiave pubblica di Alice per la crittografia. Alice utilizza quindi la sua chiave privata per decrittografare il messaggio.
  • Quando Alice vuole firmare digitalmente un messaggio a Bob, usa la sua chiave privata per firmarlo. Bob utilizza quindi la chiave pubblica di Alice per verificare la firma.

Perché è importante utilizzare chiavi diverse per la crittografia e la firma? Questo non significherebbe anche che devi distribuire due chiavi pubbliche a tutti coloro con cui desideri comunicare? Immagino che questo possa facilmente portare a una certa confusione e all'uso improprio delle chiavi.

Sei risposte:
#1
+69
nealmcb
2011-01-22 02:13:26 UTC
view on stackexchange narkive permalink

È principalmente che gli approcci di gestione e i tempi differiscono per l'uso delle chiavi di firma e di crittografia.

Per non ripudio, non vuoi mai che qualcun altro abbia il controllo della tua chiave di firma poiché potrebbe impersonare tu. Ma il tuo posto di lavoro potrebbe voler depositare la tua chiave di crittografia in modo che gli altri che ne hanno bisogno possano accedere alle informazioni che hai crittografato.

Potresti anche volere che una chiave di firma sia valida per molto tempo in modo che le persone intorno il mondo può controllare le firme del passato, ma con una chiave di crittografia, spesso si desidera eseguire il rollover prima ed essere in grado di revocare quelle vecchie senza tanti problemi.

Sì, questa è una buona ragione. Un altro motivo è che riutilizzare la stessa coppia di chiavi per entrambi gli scopi è ** potenzialmente insicuro **.
"Ma il tuo posto di lavoro potrebbe voler depositare la tua chiave di crittografia in modo che gli altri che ne hanno bisogno possano accedere alle informazioni che hai crittografato". - questo può essere rilevante per le chiavi simmetriche ma non per PKI.
@user93353 Se una chiave pubblica viene utilizzata solo per la crittografia, quale sarebbe la tua obiezione a depositarla in un ambiente di lavoro?
@nealmcb - Non avrei alcuna obiezione.
@user93353 C'è qualcosa nel tuo precedente commento sulle chiavi simmetriche e pubbliche che mi manca allora?
@nealmcb: la tua risposta dice che non dovresti usare la stessa coppia di chiavi per la crittografia e la firma. In PKI, usi la tua chiave privata per la firma e usi una chiave pubblica per la crittografia. Quindi qual è esattamente il problema con l'utilizzo della stessa coppia di chiavi per la crittografia e la firma?
@nealmcb e se il posto di lavoro vuole depositare la tua chiave pubblica, e allora? Non ottengo affatto la tua risposta.
@user93353 Se il tuo posto di lavoro conserva una chiave per la firma, allora possono impersonarti, firmare dichiarazioni per tuo conto, metterti nei guai, ecc. Non ho mai sentito parlare di un buon caso d'uso per questo. Quindi la tua coppia di chiavi di firma dovrebbe essere solo tua. Se è necessario l'escrow di una coppia di chiavi di crittografia (per fornire l'accesso ai dati creati da te ma di proprietà del tuo posto di lavoro, ad esempio), dovrebbe essere una coppia di chiavi separata.
@user93353 I luoghi di lavoro spesso depositano la tua chiave di crittografia * privata *. In questo modo, quando ti licenziano, vieni investito da un autobus o scappi con la figlia del capo, hanno ancora accesso ai tuoi file. Qualsiasi datore di lavoro che consenta di crittografare il prodotto di lavoro con una chiave che non detiene in deposito in garanzia sta cercando guai.
@nealmcb, Re "voglio rinnovarlo prima";perché?Perché non usarne uno con più stabilità?
@pacerier Più a lungo dura una chiave di crittografia, maggiori sono le possibilità di compromissione e maggiore è il contenuto crittografato, maggiori sono i problemi causati da una compromissione.Quindi il rollover frequente ha molti vantaggi.Quindi esistono schemi per consentire alle persone di avere solo bisogno di fidarsi di una chiave root, molto ben protetta, che a sua volta viene utilizzata per identificare chiavi di crittografia più effimere come autentiche.
#2
+34
D.W.
2011-03-09 11:35:46 UTC
view on stackexchange narkive permalink

È potenzialmente insicuro utilizzare la stessa coppia di chiavi sia per la firma che per la crittografia. Ciò potrebbe consentire attacchi, a seconda del particolare schema di chiave pubblica utilizzato. Questo tipo di utilizzo non è quello per cui il sistema è stato progettato, quindi utilizzare il sistema in un modo non progettato "invalida la garanzia".

Non farlo. Sta cercando guai.

Puoi fornire alcuni dettagli? Che tipo di attacchi interrompono questo utilizzo? (Anche se sono d'accordo indipendentemente dal fatto che il sistema non sia progettato per questo utilizzo ...)
Sicuro. In un sistema mal progettato, se puoi chiedere la decrittazione di qualsiasi testo cifrato C che desideri e ottenere il corrispondente Decrypt (C), potresti essere in grado di falsificare una firma sul messaggio M lasciando C = Hash (M) e poi chiedendo Decrypt (C). I sistemi moderni non sono vulnerabili a * quel * particolare attacco, ma è difficile sapere se possono esserci versioni più sofisticate di questo tipo di attacco su un sistema particolare. Se riutilizzi una chiave sia per la crittografia che per la firma, in genere invalida qualsiasi prova di sicurezza o altra verifica eseguita.
Vedo. Ha senso, grazie! Ma capisco che attualmente non ci sono attacchi pratici * noti *? (Oltre alle cattive pratiche e, cosa più importante, alla ** mancanza di garanzie **)
@AviD, Non lo so. Potrebbe essere. Non so se ci siano attacchi noti. Ciò richiederebbe un'attenta ricerca bibliografica, che non ho fatto. Anche se la risposta è "nessuno noto", non ci farei affidamento. Quando ogni crittografo sa che è un brutto modo di progettare sistemi, che viola le condizioni d'uso per un uso corretto di un crittosistema, non so se i crittoanalisti passeranno il loro tempo alla ricerca di attacchi pratici di questa forma, e anche se tu trovato attacchi, non so se sarebbero pubblicabili. Conclusione: non è consigliabile utilizzare una chiave per entrambi gli scopi.
Potrebbero esserci attacchi pratici, a seconda di dove (altro) vengono utilizzate le chiavi. Come dice DW, tutto ciò di cui hai bisogno è essere in grado di far decifrare qualsiasi C per te - questo potrebbe essere possibile negli handshake di autenticazione in cui vengono utilizzati nonces casuali, ad esempio. Sebbene sia probabilmente possibile progettarlo fuori dal protocollo di autenticazione, è più facile e sicuro renderlo semplicemente impossibile non utilizzando le chiavi per più scopi in primo luogo.
Sono d'accordo che sia una cattiva idea. Tuttavia, S / MIME sembra fornire entrambi (crittografia e firma) con un'unica coppia chiave / certificato, se non sbaglio.
#3
+12
Am1rr3zA
2011-01-23 04:51:04 UTC
view on stackexchange narkive permalink

Ci sono alcuni motivi per cui non dovremmo utilizzare la stessa chiave per la crittografia e la firma.

  1. Dobbiamo eseguire il backup della nostra chiave segreta per i dati crittografati. Successivamente si desidera decrittografare alcuni vecchi messaggi crittografati, ma non è necessario eseguire il backup della nostra chiave segreta per la firma. Se l'attaccante trova la chiave, possiamo dire alla nostra CA di revocarla e ottenere una nuova chiave segreta per la firma senza bisogno di backup.

  2. Ancora più importante: se utilizziamo la stessa chiave per la crittografia e la firma, l'attaccante può utilizzarla per decrittografare il nostro messaggio crittografato. Questo è ciò che farebbe:

    L'aggressore deve scegliere un numero casuale r , dove

    r deve avere GDC (N, r) = 1 ,
    e N è il numero utilizzato per creare la chiave privata e pubblica ( N = pq )

    Quindi l'attaccante sceglie un nuovo messaggio ( m ′ ) e lo invia per la firma al mittente:

    m ′ = m ^ er ^ e (qui (e, n) è la chiave pubblica)

    Quando il mittente firma m ′ otteniamo

    m ′ ^ d ≡ (m ^ er ^ e) ^ d ≡ mr (mod N)

    Ora solo l'attaccante deve "dividerlo" per r per ottenere m (il messaggio segreto).

Questo sembra specifico per RSA, piuttosto che applicabile a tutti i cifrari asimmetrici.
Inoltre, perché l'attaccante avrebbe accesso a N e simili?
@Avid Attacker per impostazione predefinita ha accesso a N, perché quando vuoi pubblicare la tua chiave pubblica devi pubblicare (N, e).
"quando il segno del mittente m ′ otteniamo m ′ ^ d" Perché? Per firmare qualcosa con RSA, non devi semplicemente applicare l'operazione di chiave privata. Lo hash e applichi il riempimento. Quindi il tuo attacco non funziona. (Ci sono eccezioni, l'uso di una chiave per la firma cieca e la crittografia sarebbe aperto a quell'attacco, ma la firma cieca è un'applicazione speciale e non la firma normale).
@CodesInChaos La descrizione del rischio derivante dall'utilizzo della stessa chiave sia per la firma che per la crittografia è eccessivamente semplificata. Ma nel campo della sicurezza un esempio semplificato del perché qualcosa potrebbe essere un problema dovrebbe essere preso sul serio. D'altra parte vuoi prove rigorose, prima che qualcosa sia considerato sicuro. Se tutto ciò che hai sono argomentazioni agitate a favore e contro la sicurezza di una pratica, devi sbagliare sul lato della cautela.
Il requisito GDC (N, r) = 1 non è molto importante. Se l'aggressore sceglie per caso una r per la quale non è così, ha comunque infranto la crittografia.
@kasperd "ha comunque rotto la crittografia" solo nel caso dei due primi. In linea di principio il modulo potrebbe contenere due fattori grandi e un mucchio di fattori piccoli. Sebbene in genere non sia il caso delle normali chiavi RSA, la generazione di chiavi dannose è un problema negli schemi di firma cieca.
@CodesInChaos Questo è interessante. Non ho provato a fare i calcoli per vedere se le informazioni sarebbero trapelate se N ha più di due fattori primi.
@kasperd Perdete informazioni se non vi assicurate che il messaggio (riempito) non divida il modulo. Questo può essere un problema se il modulo ha molti piccoli fattori.
Alcune fonti / collegamenti sarebbero fantastici qui ..
#4
+7
moo
2014-05-29 06:25:40 UTC
view on stackexchange narkive permalink

Motivi per utilizzare chiavi separate per la firma e la crittografia:

  1. Utile nell'organizzazione in cui la chiave di crittografia deve essere supportata o conservata in garanzia per decrittografare i dati quando un dipendente / utente dell'organizzazione non è presente disponibile più a lungo. A differenza della chiave di crittografia, la chiave di firma non deve mai essere utilizzata da nessun altro oltre al dipendente / utente e non deve e non deve essere tenuta in garanzia.
  2. Consente tempi di scadenza diversi per la firma di una chiave di crittografia.
  3. Dato che la matematica sottostante è la stessa per la crittografia e la firma, solo al contrario, se un utente malintenzionato può convincere / ingannare un detentore di chiavi a firmare un messaggio crittografato non formattato utilizzando la stessa chiave, l'attaccante ottiene l'originale.
  4. Riferimenti

    1. https://www.entrust.com/what-is -pki /

    2. https://www.gnupg.org/gph/en/manual/c235.html

    3. http://www.di-mgt.com.au/rsa_alg.html

Qualsiasi link / fonte per 3 disponibili per favore ...
@alfonx Potrei aver dimenticato i collegamenti originali da cui ho ottenuto quei punti, ma ho modificato i riferimenti in ordine. Spero che aiuti. Non sono sicuro che tutti questi siano i riferimenti più affidabili, ma i punti hanno senso se hai lavorato [PKI] (https://www.comodo.com/resources/small-business/digital-certificates1.php).
Il punto 3 di @moo è solo una buona osservazione sul concetto di chiave RSA asimmetrico.Tuttavia l'attacco non esiste nella pratica di firma di documenti del mondo reale (come PGP che questa domanda sta prendendo in considerazione).Questo perché PGP firma solo un digest del messaggio (noto anche come hash sicuro) del messaggio originale, invece di applicare la chiave privata all'intero messaggio.
@JohnnyWong ha convenuto che un attacco nel mondo reale utilizzando questo concetto dipenderà dall'implementazione.L'OP ha menzionato GPG / PGP come esempio, tuttavia mi sembra che l'OP volesse un ragionamento più generale per questa pratica.Dato che le implementazioni cambiano abbastanza spesso penso che questo punto sia molto importante per essere compreso per chiunque abbia a che fare con PKI e sto scegliendo di non rimuovere il punto 3. Forse avrei potuto mettere una nota su questo ma penso che i nostri commenti ora servono a questo scopo.Grazie.
#5
+5
David Bakker
2015-04-01 15:13:56 UTC
view on stackexchange narkive permalink

Per me, le ragioni principali sono legate alla gestione delle chiavi, piuttosto che alla sicurezza crittografica in sé.

Per la crittografia asimmetrica, in particolare il periodo durante il quale si desidera che una chiave pubblica sia valida può dipendere fortemente dall'uso previsto di quella chiave. Si consideri, ad esempio, un sistema in cui un componente deve autenticarsi con altri componenti. Oltre a ciò, quel componente deve anche creare regolarmente una firma su alcuni dati. In teoria, una singola chiave privata potrebbe essere utilizzata per entrambi gli scopi. Tuttavia, si supponga che l'autorità di certificazione PKI per motivi di sicurezza voglia limitare a due anni il periodo durante il quale può avvenire un'autenticazione corretta sulla base di un singolo certificato. Allo stesso tempo, le leggi sulla conservazione dei dati possono richiedere che i dati vengano conservati per cinque anni e che la firma su tali dati debba essere verificabile durante l'intero periodo. L'unico modo (valido) per risolvere questo problema è dare al componente due chiavi private: una per l'autenticazione e una per la firma. Il certificato della prima chiave scadrà dopo due anni, il certificato per la firma scadrà dopo cinque anni.

Ragionamenti simili possono essere applicati alla crittografia simmetrica: se usi chiavi diverse per scopi diversi, puoi decidere su tutte le questioni di gestione delle chiavi (ad esempio la frequenza del rinnovo della chiave master, il periodo per eseguire il backup delle chiavi, ecc.) in base ai requisiti di un unico scopo. Se utilizzi una singola chiave (principale) per più scopi, potresti trovarti con requisiti in conflitto.

#6
+2
Piquan
2019-07-29 13:59:16 UTC
view on stackexchange narkive permalink

La crittografia RSA si basa su una funzione trapdoor, vale a dire un paio di funzioni. Li chiamerò D e E . Le funzioni sono progettate in modo che D (E (x)) = x e E (D (x)) = x (per qualsiasi x ). In altre parole, D e E sono inversi. Ciò che la rende una funzione trapdoor è che se hai una chiave pubblica, puoi solo calcolare E (praticamente parlando). Se hai una chiave privata, puoi calcolare sia D che E.

Il modo in cui funziona la crittografia è abbastanza ovvio da questa descrizione. Se Bob vuole inviare ad Alice un messaggio crittografato, calcola ciphertext: = E (plaintext) . Quindi Bob invia ciphertext ad Alice. Alice calcola D (ciphertext) , che è D (E (plaintext)) , che è solo plaintext.

Ora parliamo di come funziona la firma. Se Alice vuole firmare message , allora calcola signature: = D (message) . Quindi invia sia messaggio e firma a Bob. Bob quindi calcola validation: = E (signature) . Poiché signature è D (message) , allora validation = E (D (message)) = message .

In altre parole: per firmare un messaggio, ti comporti come se lo stessi decrittando, e questa è la tua firma. Per verificare la tua firma, le persone possono crittografare la firma e assicurarsi di recuperare il tuo messaggio originale.

Lo ripeto: la firma è la stessa operazione della decrittografia.

Questa è la preoccupazione fondamentale sulla separazione delle chiavi di firma e di crittografia. Se qualcuno può farti firmare qualcosa, ti ha appena fatto decrittografare.

Supponi di gestire una società notaio. Se qualcuno ti dà $ 10 e un messaggio (ad esempio, testi di canzoni), firmerai quel messaggio e te lo rispedirai. Se in seguito qualcuno copia i testi delle tue canzoni, puoi produrre la firma della società notaio di fiducia per dimostrare che hai scritto quei testi delle canzoni.

Ora supponi che Eve abbia intercettato un messaggio crittografato alla tua società notarile. Come può sovvertire la crittografia? Ti manda lo stesso messaggio per l'autenticazione! Ora esegui l'operazione di firma (che, ricorda, è la stessa dell'operazione di decrittazione) e le restituisci il risultato. Ora ha il messaggio decrittografato.

In pratica, i protocolli hanno passaggi che rendono questo attacco più difficile. Ad esempio, PGP (con cui intendo il protocollo; gpg è l'implementazione più comune qui) non firma il messaggio originale; firma un hash del messaggio. Ma le prove di sicurezza sono le migliori in situazioni semplici. Non vuoi che la tua prova sulla sicurezza di RSA dipenda dalla funzione hash. (Ad esempio, molte persone hanno utilizzato MD5 come hash preferito per molto tempo, ma oggi MD5 è considerato piuttosto rotto.) Da solo, la sicurezza di RSA dipende dall'idea che non firmerai messaggi arbitrari con una chiave utilizzata per la crittografia. Mantenere questo requisito in vigore è il modo migliore per garantire la sicurezza di PGP. (Per quanto ricordo, questo è l'ammonimento più frequentemente ripetuto sulla crittografia asimmetrica nel libro di Bruce Scheier Applied Cryptography .)

Ora parliamo di un'altra domanda che hai posto: "Questo non significherebbe anche che devi distribuire due chiavi pubbliche a tutti coloro con cui desideri comunicare?"

Una "chiave" significa una cosa per gli utenti e un'altra per le implementazioni crittografiche. Devi solo comunicare una "chiave" a livello di utente, sebbene possa contenere molte chiavi pubbliche RSA.

PGP ha un concetto di sottochiavi. La mia chiave principale è una chiave di sola firma. Ho una sottochiave di crittografia separata. Quella sottochiave è firmata dalla mia chiave principale. Se importi la mia chiave PGP dai server delle chiavi o la scarichi dal mio sito web, otterrai la mia chiave principale e tutte le mie sottochiavi. Anche se potresti aver firmato solo la mia chiave principale, la mia chiave principale ha firmato la mia sottochiave di crittografia, quindi sai che appartiene anche a me. Ciò significa che scaricando la mia chiave PGP (che comprende molte chiavi pubbliche RSA), ora hai tutto ciò di cui hai bisogno sia per verificare le mie firme che per crittografare i messaggi.

Con le sottochiavi, la gestione delle chiavi è più complessa da un punto di vista crittografico (c'è un passaggio aggiuntivo di verifica della chiave da eseguire), ma non da un punto di vista pratico (la mia chiave PGP include la mia chiave principale, così come tutte le mie sottochiavi). La complessità extra è nascosta nell'implementazione e non è esposta all'utente.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...