Quali rischi esisterebbero nella trasmissione di una PKCS12 crittografata tramite Https

Invece di generare una prima coppia di chiavi nel tuo client (che a quanto pare ti scartare dopo questa procedura) e generare un'altra coppia di chiavi nel server per produrre il certificato, potresti:

• genera una singola coppia di chiavi nel client,
• trasforma la sua chiave pubblica in una richiesta di certificazione,
• inviarlo tramite HTTPS con le informazioni di registrazione al servizio emittente,
• fa in modo che il servizio rilasci il certificato e lo rispedisca,
• il client associa il certificato con la chiave privata.

Tutto questo può essere fatto direttamente all'interno di un browser, ad esempio, ma può anche essere eseguito da altri client, come il client basato su SOAP personalizzato. Ha il vantaggio che la chiave privata non lascia mai il partito intenzionato a mantenerla: il cliente non ha nemmeno bisogno di fidarsi del fatto che il servizio dell'emittente non abbia conservato una copia.

A patto che tu abbia fiducia nella connessione HTTPS per essere certo che le informazioni di registrazione siano state effettivamente inviate con questa particolare richiesta di certificazione, il tuo meccanismo di verifica iniziale andrà bene.

Modifica

Dopo i commenti, sembra che tu non voglia che le tue chiavi private siano conservate per l'impegno sul server di emissione comunque. In questo caso, non ha senso correre il rischio di trasmettere la chiave privata a tutti. Non stai guadagnando nulla generando la coppia di chiavi del certificato sul server; semmai, stai aumentando il rischio (anche se limitato dal fatto che stai trasmettendo quella chiave privata su HTTPS comunque).

Quando si emette un certificato, il punto che conta davvero è l'associazione tra le informazioni del richiedente e la chiave pubblica che finirà nel certificato, proprio perché la parte emittente è firma l'asserzione di quel legame quando si forma un certificato .

Ciò che si vuole veramente accertare è che la chiave pubblica utilizzata per il certificato e la chiave di registrazione condivisa da bande appartengano alla stessa persona. Da quel punto di vista, se danno la tua chiave pubblica, o se la generi e la restituisci (con la chiave privata) è la stessa cosa. La trasmissione della chiave privata in un modo o nell'altro in questo schema non è necessaria.

Tutto quello che devi fare è ottenere la chiave pubblica dalla richiesta / applicazione (nel senso che l'utente richiede / applica per il certificato), controlla che sia giunta con il segreto di registrazione giusto ed emetta il certificato. Puoi ottenere questa chiave pubblica da un CSR o semplicemente come una semplice chiave pubblica, se vuoi. (I dettagli di ciò che il candidato può aver inserito nella CSR sono appena rilevanti, qualsiasi buona CA dovrebbe scartarla e metterà comunque in pratica solo ciò che è stato verificato dalle bande nel cert.)

Se il client ha verificato che la connessione HTTPS al server è configurata correttamente: suite di crittografia sufficientemente potenti, disattivazione della compressione TLS e una corretta verifica del certificato, dovresti garantire che le informazioni sulla registrazione segreta e la chiave pubblica siano state unite.

Questo è un metodo accettato. Ad esempio, SecureWorks emette certificati client su SSL in seguito a un processo di registrazione. Il profilo dei rischi è principalmente il seguente:

1. Garantire che la registrazione non possa essere eseguita da una persona diversa dalla parte interessata; questo è generico con altri processi di registrazione e può essere il più grande rischio da affrontare.
2. Il trasferimento della chiave tramite HTTPS non è particolarmente rischioso.
3. Confidando che l'utente gestisca correttamente la propria chiave una volta ricevuta. Nulla di ciò che puoi fare a riguardo non importa come ottieni la chiave per loro.
4. Garantire la protezione delle chiavi dei clienti da parte tua. Hai intenzione di escrow loro così le persone possono ri-scaricarli? O cancellarli non appena il cliente li ha e generarne uno nuovo in futuro, se necessario? La preferenza tradizionale "genera chiave sul cliente" ha in gran parte a che fare con una sfiducia ben fondata sulla capacità degli altri sistemi di dimenticare le chiavi se mai le conoscessero.

La procedura sembra soddisfacente, ma devi decidere un formato per la crittografia del file PKCS # 12 con la chiave asimmetrica generata al punto 4. Non è così facile come sembra e dovresti attenersi a un formato standard.

A quel punto, notate che PKCS # 12 ha una capacità intrinseca di eseguire la crittografia simmetrica, normalmente con una "password" ma la password può essere lunga e casuale. La procedura può essere semplificata se si utilizza la "chiave di registrazione" come password per crittografare il file PKCS # 12. Ciò eviterebbe di dover generare una coppia di chiavi in memoria sul lato client.

In realtà, poiché la coppia di chiavi in memoria generata dal client viene autenticata solo in virtù dell'invio nel tunnel HTTPS insieme al codice di registrazione, si presuppone già che HTTPS offra sicurezza sufficiente e impedisca a un utente malintenzionato di sostituire il proprio propria coppia di chiavi in quel punto. Si potrebbe anche andare alla fine di quella logica e affidarsi semplicemente al tunnel HTTPS: basta inviare il certificato e la chiave privata così come sono. Imballandoli come un file PKCS # 12, crittografato con il codice di registrazione (poiché si presume che il codice sia abbastanza segreto), può facilitare l'integrazione (ad esempio l'utente potrebbe ottenere PKCS # 12 come file e importarlo nel suo SO "manualmente").