Perché alcune API del linguaggio di programmazione non supportano le password delle chiavi private?

Question

Perché alcune API del linguaggio di programmazione non supportano le password delle chiavi private?

#1 da (3 voti)
#2 da (0 voti)

1

Due domande:

Ho recentemente iniziato a creare un web server Go di base e ho notato che l'API per l'avvio di un server Web TLS non supporta una chiave RSA privata simmetricamente crittografata. L'API è inclusa di seguito e collegata qui :

func (srv *Server) ListenAndServeTLS(certFile, keyFile string) error

1) Dato che Go è un nuovo linguaggio di programmazione e scritto con il beneficio dell'esperienza, mi chiedo perché sia così. I creatori non vorrebbero incoraggiare l'uso di file chiave crittografati e alcuni pattern di pseudo-codice come questo:

var decryptKey = secureNetworkSource.getDecryptionKey();
ListenAndServeTLS(certFile, keyFile, decryptKey);

Ho frainteso i vantaggi in termini di sicurezza dell'utilizzo di un file di chiave privata crittografato, ovvero è possibile che lo schema precedente non sia più sicuro del semplice file chiave non crittografato sul disco.

2) Mi chiedo anche perché molte di queste librerie di server tra lingue (essendo Java l'altro esempio che mi viene in mente) spesso si affidano al certificato che viene archiviato localmente sul server; per esempio, l'API Go richiede un percorso per un file. Perché non supportare alcun attrezzo a distanza, in modo da poter acquisire una chiave privata da un'altra fonte e ridurre il raggio di esplosione di perdere il disco rigido su un server?

tls

posta uforic 30.06.2015 - 20:49

fonte

2 risposte

Leggi altre domande sui tag tls

Determinazione e decifrazione di un'unità crittografata (conoscenza della password) Quanto è efficace il software antivirus? [duplicare]

score 3 · Answer 1

I file chiave crittografati hanno un certo valore, ma generalmente il valore è limitato perché la praticità di servire un'operazione 24 ore su 24, 7 giorni su 7, impone che la chiave debba essere memorizzata sul filesystem da qualche parte in forma non criptata. L'alternativa della password digitata da un amministratore ogni volta che viene riavviato un server è terribilmente poco pratica e crea il rischio che il server si arresti se la password non può essere ricordata o l'amministratore non lo sa.

Essere quel Go è un nuovo linguaggio, naturalmente sarà limitato alle funzionalità. Non supportare i file di chiavi crittografate sembra una naturale omissione su un nuovo server web.

score 0 · Answer 2

Non mi è chiaro se Java è parte della tua domanda oppure no.

L' API Java Crypto può caricare un keystore da qualsiasi flusso di input (e memorizzarne uno nuovo / modificato su qualsiasi flusso di output), ma molte applicazioni e librerie (e l'utilità keytool ) supporta solo i file. Vedi per es. link . Se il tuo codice utilizza la fabbrica predefinita di default SSL configurata con le proprietà di sistema, anche questo è per lo più limitato a un file. Tuttavia molti (più?) Sistemi operativi supportano file che sono effettivamente remoti e potrebbero anche essere qualcosa che imita solo un file, come Windows SMB, Unix NFS o Linux FUSE.

I flussi di archivi di chiavi Java sono sempre crittografati con password , anche se come noto questo di solito significa che la password viene semplicemente inserita nella configurazione del server o JRE, il che non aggiunge realmente sicurezza.

Anche alcuni "provider" hanno i propri dati ; JCA può utilizzare un modulo PKCS # 11 "hardware", che può essere qualsiasi cosa, da un vero modulo hardware o smartcard a una libreria software con i propri file o database o altro. Analogamente su Windows JCA può utilizzare l'archivio "certificato" (e chiave) di Windows, che viene archiviato da qualche parte in cui Microsoft cerca di rimanere ben nascosto e protetto. Spetta a ciascun modulo PKCS # 11 se o quando richiede password (s); L'archivio di Windows utilizza implicitamente l'accesso a Windows.

Java SSL (JSSE) stesso non richiede affatto un archivio preesistente; è felice di farti creare una nuova chiave in-memory e usarla. Ovviamente i client SSL / TLS configurati correttamente non si connetteranno a utilizzando tale chiave fino a quando non invierete un CSR a una CA e riceverete un certificato per questo, che in genere è scomodo.