In che modo le chiavi generate da openvpn / easy-rsa sono mappate alle variabili dell'algoritmo RSA?

0

Stavo leggendo un po 'su openvpn e pki infra e sono confuso da alcune delle domande poste dal mio collega. :) Questa risposta mi ha aiutato a capire di più: link

Ma sono ancora bloccato da alcune domande. La ricerca non ha aiutato molto.

1.1. Nella openvpn con il processo pki, prima creiamo il ca, che ci dà il crt e il cakey; ancora più importante, otteniamo un dh2048.pem e un crl.pem.

1.2. Quindi andiamo a creare file (.keys e .crts) per le entità (qui entity significa openvpn client o server; in pratica, un 'client' per il ca)

PKI usa RSA che è la seguente (copiata da: link )

2,1 n = pq; p, q = big primes

2.2 phi = (p-1) (q-1)

2.3 e < n, tale che gcd (e, d) = 1

2.4 d = e ^ (- 1) mod phi

2,5 (n, d) è la chiave privata

2.6 (n, e) è la chiave pubblica

Vedo che la chiave è una chiave, dh2048.pem è una chiave, client.crt è un testo e client.key è di nuovo una chiave. Come fanno queste mappe alle variabili dell'algoritmo sopra? Grazie.

Edit1:

Un addendum alla domanda.

Il manuale di openvpn dice che sia il server openvpn che il client openvpn si autenticano a vicenda. Ho anche letto che la CA può essere completamente offline per motivi di sicurezza. Quindi, come contattano la CA, se necessario? Basato su RSA (e poiché implica computazione) presumo che non contattino mai la CA. Allora come funziona la soluzione? Grazie.

EDIT2:

Se RSA è ciò che viene seguito in PKI, in che modo un servizio di orario di fiducia è un requisito in infra PKI? Grazie.

    
posta krish7919 13.01.2015 - 07:21
fonte

2 risposte

0

Sto postando questa risposta come risposta perché è troppo lungo per entrare come commento. :)

Il seguente processo descritto è relativo a openvpn & PKI.

Il client ha i seguenti file: ca.crt, client.crt, client.key

Il server ha i seguenti file: ca.crt, server.crt, server.key, dh2048.pem, crl.pem

Il processo secondo la mia comprensione:

  1. Scambio di chiavi ( riferimento ): il server invia dh2048 al client in chiaro. Il client seleziona un modulo radice primitivo relativo al primo dh2048 e condivide una chiave di sessione segreta utilizzando Diffie-Hellman Key Exchange. Fondamentalmente hanno un canale di comunicazione sicuro ora. Comunque il server & il cliente sono ancora 2 entità che hanno deciso di parlare tra loro. Non hanno nulla in comune (cioè nessuna fiducia). EDIT: In realtà dopo aver letto link , ritengo che dh2048 non sia inviato come testo in chiaro. Vedi anche RFC5246.

  2. CA li rende comuni. Come verificano che ognuno di loro provenga dalla stessa CA? Il ruolo principale della CA è di firmare e pubblicare digitalmente la chiave pubblica associata a un determinato utente. Questo viene fatto usando la chiave privata della CA, in modo che la fiducia nella chiave utente si basi sulla fiducia nella validità della chiave della CA (dall'articolo di PKI di wikipedia) .

  3. Quindi scambiano le loro chiavi pubbliche (firmate / criptate) tra loro. L'altra estremità ha la chiave pubblica CA e può decodificare la chiave firmata per ottenere la chiave pubblica effettiva. Ciò verifica che avessero la stessa CA. Usando ora la chiave pubblica non firmata / effettiva, scambiano i loro dati (iniziano con una stretta di mano e stabiliscono un'altra chiave di sessione, o aumentano il timeout per la chiave di sessione stabilita in precedenza, non lo so per certo).

  4. Una volta arrivati a questo punto, possono crittografare i messaggi utilizzando la chiave di sessione (nuova / vecchia) e l'altra estremità può decodificarla.

  5. Il passo in più è che il sever in openvpn controlla anche la voce client in crl.pem (che è solo una lista di firme che sono state revocate, e ora che ci penso, penso che ha la chiave originale non firmata / non cifrata! Devi verificarlo però).

  6. Il file ca.crt è testo in chiaro e quindi non possono scambiare le chiavi pubbliche in testo in chiaro e hanno bisogno di una chiave di sessione per farlo, e quindi del DHKE.

risposta data 11.03.2015 - 14:52
fonte
1

Creazione di un'autorità di certificazione

Quando crei i certificati dell'autorità di certificazione otterrai ca.crt e ca.key file . Il file .crt è la chiave pubblica autofirmata e il file .key è il file della chiave privata. Non è così semplice come questo. Entrambi i file sono codificati in base64 e i dati sottostanti sono codificati DER . Poiché è probabile che generi X.509 certificati.

In realtà tutto ciò che devi capire è che hai un certificato autofirmato la cui porzione pubblica è memorizzata in ca.crt e la porzione privata è memorizzata in ca.key . Ricorda che devi mantenere ca.key secret tutti i primi grandi, le operazioni GCD e ciò che non è tutto a posto con qualsiasi cosa tu stia utilizzando per generare il certificato.

Il dh2048.pem non è una chiave, sono i parametri Diffie Hellman per il server. Questi non hanno nulla a che fare con le tue chiavi RSA e sono usate solo quando Diffie Hellman è usato per connettersi al tuo server piuttosto che a RSA. La differenza tra i due può essere trovata nella sezione Scambio chiave di Come funziona SSL / TLS? Questi non dovrebbero avere nulla a che fare con PKI.

Viene generato crl.pem come elenco di revoche di certificati. A questo file vengono aggiunti tutti i certificati revocati che sono stati firmati con la CA. Nella configurazione di OpenSSL (presumo che tu stia configurando OpenSSL, ma l'idea si applica a qualsiasi configurazione) questo file CRL verrà indirizzato. In questo modo saprà dove controllare i certificati revocati.

Firma dei certificati

Ora che hai un'Autorità di certificazione puoi iniziare a firmare certificati di utenti per il tuo sistema. Gli utenti lo fanno generando le proprie chiavi RSA client.crt e client.key . Queste chiavi dovrebbero essere generate ogni volta che un nuovo utente viene introdotto nel sistema. Ancora una volta, il .crt è la parte pubblica della chiave e il .key è la parte privata. Il client.key deve essere tenuto segreto dal nuovo utente. .

Per firmare il certificato di un nuovo utente viene creata una richiesta di firma del certificato (CSR). C'è un comando in OpenSSL per farlo. La richiesta contiene la chiave pubblica dell'utente da aggiungere e alcune altre informazioni pubbliche necessarie alla richiesta. Il certificato del cliente verrà aggiunto agli elenchi autorizzati appropriati sul server e verrà prodotto un nuovo certificato firmato. Questo è ciò che l'utente dovrà importare nel proprio browser per visitare le pagine PKI abilitate.

C'è un ottimo tutorial sull'infrastruttura a chiave pubblica sul sito di OpenSSL per riferimento futuro.

Spero che questo chiarisca alcune cose. Ogni variabile che hai menzionato nell'algoritmo RSA viene generata quando crei un certificato. I certificati pubblici non li contengono tutti, ma generalmente le porzioni private lo fanno. Ai fini dell'implementazione non dovrai preoccuparti di loro. Ricorda solo che esiste una coppia di chiavi pubblica e privata.

Per rispondere alla tua st modifica

Lo scambio di CSR e il certificato risultante viene generalmente eseguito utilizzando un certo tipo di copia sicura (scp). Il server e il client devono essere in comunicazione tra loro. La dichiarazione che "il client e il server si autenticano a vicenda" non è propriamente corretta. Il cliente desidera essere parte dell'infrastruttura in modo che debba dimostrare la propria identità al server di firma. Come Autorità di certificazione, è sua responsabilità verificare l'identità del cliente prima di elaborare il CSR. La stessa CSR dovrebbe avere tutte le informazioni necessarie per verificare l'identità del cliente da aggiungere.

Per rispondere alla tua 2 nd modifica

RSA è solo l'algoritmo a chiave pubblica utilizzato per la generazione di chiavi, la crittografia / decrittografia e la firma. Public Key Infrastructure è una raccolta di standard e servizi necessari per implementare un'infrastruttura sicura. Un servizio di cronometraggio affidabile è probabilmente uno dei molti requisiti. Molto simile a un'autorità di certificazione è un requisito.

    
risposta data 13.01.2015 - 14:13
fonte

Leggi altre domande sui tag