Generazione di certificati X.509 deterministici?

Al momento, non vedo alcun grosso problema qui, almeno, dal PoV dell'algoritmo stesso.

1. Sementi un PRNG con ad es. un hash della frase chiave.
2. Utilizza il PRNG per generare la coppia di chiavi RSA.
3. Utilizza una libreria per generare il certificato, inserendo il materiale della chiave in esso.

Il determinismo è ottenuto attraverso l'uso di PRNG seminato con la stessa frase chiave (probabilmente salato e inserito ad esempio SHA-256), quindi l'output è lo stesso per lo stesso input. Tutti gli algoritmi richiesti possono essere facilmente implementati in Python, oppure il codice esistente può essere riutilizzato, ad es. Python-RSA . L'unico aggiustamento richiesto sarebbe utilizzare il tuo PRNG invece di quello che sta usando ora.

Il punto 3 è la parte più difficile in quanto non sono un grande esperto di librerie, ma questo sembra essere parte di un altro problema (generare un certificato dal materiale chiave esistente). Questo rientra nella categoria "Qual è la migliore libreria per ...".

Come al solito: frustare la tua cripto è generalmente scoraggiato e disapprovato, a meno che tu non sia Bruce Schneier. ; -)

Come indica @Dmitry, ciò che prevedi è fattibile. Generazione di coppie di chiavi RSA, in realtà qualsiasi coppia di coppie , si nutre di un PRNG ; il PRNG stesso è un algoritmo deterministico che "estende" un seme casuale iniziale in una sequenza arbitrariamente lunga di byte pseudocasuali. È possibile utilizzare una funzione di hashing della password complessa e utilizzare il valore hash risultante come seme per un PRNG.

Tuttavia, ci sono alcuni problemi collaterali che possono essere fastidiosi. Ad esempio:

• L'hashing della password funziona meglio quando c'è un salt , che non è segreto ma deve essere memorizzato da qualche parte.
• La modifica della password implica la modifica della chiave privata, che di solito è piuttosto scomoda.
• La chiave pubblica (che è pubblica) può essere utilizzata come test per un attacco del dizionario offline : gli aggressori possono provare le password "a casa" finché non viene trovata una corrispondenza con la chiave pubblica conosciuta.

Ho ampliato ulteriormente l'argomento in questa risposta .

Ricordare che il certificato (che contiene la chiave pubblica) deve essere memorizzato da qualche parte, poiché non è possibile ricrearlo dalla password (il certificato è firmato dalla CA e non è possibile ricalcolare tale firma, dal momento che non sei il tuo CA). È possibile generare la chiave privata "normalmente", crittografarla con un sistema di crittografia basato su password e archiviarla insieme al certificato; questo sarebbe equivalente, dal punto di vista della sicurezza, alla derivazione password-to-RSA-key; ma almeno funzionerebbe con i formati e gli strumenti esistenti (potresti usare PKCS # 12, detto anche "pfx", come formato di archivio protetto da password sia per il certificato che per la chiave privata).

Il certificato X509 è costituito fondamentalmente da diversi tipi di informazioni:

• I dati dichiarativi del certificato che includono tutto ciò che i certificati rivendicano sul proprietario della chiave (principalmente ciò che si trova nei campi dell'oggetto del certificato ma anche comunemente OID mi piace)
• I dati dell'ambito del certificato (ad esempio: utilizzo delle chiavi, periodo di validità, ecc.)
• La metà pubblica della coppia di chiavi associata al certificato.
• Le informazioni sulla catena di attendibilità del certificato (che garantiscono che i dati dichiarativi e relativi all'ambito siano corretti) e i dati di revoca
• Alcuni campi tecnici (quale algoritmo viene utilizzato, qual è il numero di serie del certificato, ecc.)

Puoi mettere tutto ciò che vuoi sia nei dati dichiarativi che in quelli di scoping e puoi controllare cosa c'è nei campi tecnici (principalmente) finché la CA accetta di convalidare il tuo cert come lo invii (o finché sei utilizzando certificati autofirmati).

La parte chiave pubblica del certificato è dettata da qualunque algoritmo chiave tu abbia deciso di utilizzare. È possibile utilizzare la stessa chiave per tutti i certificati, anche se non suggerirei di farlo: non esiste un valido motivo per farlo in pratica e potrebbe minacciare la sicurezza dell'intero sistema a seconda di come vengono utilizzati i tasti.

Infine, le informazioni sulla fiducia includono principalmente il riferimento dell'emittente (che in genere puoi decidere o, almeno, sapere in anticipo nella maggior parte dei casi) e la firma digitale dell'intero certificato (che non hai modo di conoscere o controllare ). L'uso di un certificato autofirmato non ti aiuterà, in questo caso, dal momento che l'unico modo per le due firme di essere identiche al 100% sarebbe che ogni parte dei dati della firma fosse identica: potresti anche fare una copia del certificato originale invece di firmarlo due volte.

La buona notizia, tuttavia, è che mentre non si dovrebbe usare la stessa chiave per diversi certificati, non è necessario. È sufficiente creare la propria CA e fare in modo che l'applicazione verifichi tutti i certificati rispetto alla CA radice: ciò consentirà a tutti gli utenti di verificare le chiavi che si stanno distribuendo, comprese le chiavi future, senza che sia necessario indebolire l'infrastruttura riutilizzando una set fisso di chiavi.

Il blocco dell'autorità di certificazione, anziché il certificato foglia, è un po 'più complesso da implementare, ma è anche più flessibile e consente scenari di utilizzo più complessi.