Passaggio delle chiavi generate a un altro processo

2

Sto facendo un progetto in cui un processo genera una chiave usando un algoritmo distribuito. Devo passare questa chiave al processo o alla procedura di chiamata. In generale, è possibile farlo nei seguenti modi (o più):

1) Come valore di ritorno

2) Scrivi su un file, che può essere letto dal chiamante

3) Criptare la chiave e rilasciarla in un socket, per essere ricevuta dal chiamante

4) Usa comunicazione di processo

La mia domanda è: quale di questi metodi è il modo migliore o più sicuro per ottenere la funzione richiesta? La scrittura della chiave in un file aumenta la sicurezza, se la chiave è crittografata per la sessione?

Se ci sono altri modi, metodi migliori per ottenere quanto sopra, per favore aggiungilo alla tua risposta.

    
posta Ajoy 12.01.2013 - 10:07
fonte

1 risposta

7

Il tuo problema è la trasmissione di un dato segreto; che il pezzo di dati è una chiave crittografica è per lo più irrilevante (significa solo che è veramente segreto). Quindi, quello che vuoi si riduce a essere sicuro di chi ottiene.

Dato che parli di processi, presumo tu stia parlando di un trasferimento all'interno di una singola macchina . "Chi" dipende quindi dal modello di sicurezza del proprio sistema operativo. Il sistema operativo comune utilizza un modello con "account", ciascun processo essendo collegato a uno di tali account e con i privilegi associati a tale account. C'è un "account principale" (root su Unix, Amministratore su Windows) che ha tutti i diritti e non puoi difenderci da questo.

Detto questo, vediamo le tue proposte:

  1. " Come valore di ritorno ": questo non può essere applicato. Un "valore di ritorno" è ciò che viene inviato da una funzione al relativo chiamante all'interno di un singolo processo. Nel tuo caso, ci sono due processi.
  2. " Scritto su un file ": vorrei sconsigliarlo. Un file lascia tracce. Una volta che i dati sono passati a un supporto fisico, devi mantenere i controlli di accesso su questo mezzo per sempre . Sembra meglio mantenere il tutto nella RAM il più possibile.
  3. " Crittografia e socket ": la crittografia va bene finché hai già distribuito le chiavi, quindi stai risolvendo il problema dell'uovo e della gallina affermando che hai già un altro uovo / pollo , che non risolve le cose. D'altra parte, per un socket che è local su una macchina, potresti avere il modo di assicurarti che il processo all'altra estremità del socket sia di proprietà dell'account previsto; si chiama getpeereid() su sistemi di tipo Unix.
  4. " Comunicazioni tra processi ": questo è un nome generico per i modi in cui due processi possono comunicare tra loro e include socket locali. La scelta è ampia (e molto dipendente dal sistema operativo); il punto importante è che puoi ottenere l'ID utente effettivo dell'altro processo, come getpeereid() .

Su un sistema simile a Unix, puoi usare un socket locale, anonimo (creato con socketpair() ) o named (un "dominio dominio Unix", così com'è); una coppia di socket anonimi è possibile se i due processi hanno una relazione padre-figlio che consente loro di scambiare i descrittori di file. Puoi anche usare pipe, di nuovo anonimo, o attraverso un punto di rendez-vous basato su file (una "named pipe"), in cui il filesystem contiene l'area della riunione, ma i dati rimangono puramente nella RAM. Memoria condivisa SysV, mmap() con MAP_SHARED su /dev/zero , ... ci sono molte possibilità, ciascuna con i propri metodi per i controlli di accesso.

Su un sistema Windows, le possibilità sono ancora più varie, a causa della lunga storia dei successivi livelli di inventiva in questo sistema operativo (non lasciano mai nulla - sono compatibili con la retrocompatibilità - ma riprogettano anche interi sottosistemi ogni due anni, quindi i metodi IPC tendono ad accumularsi: nel 2003, ho contato non meno di 9 metodi per questo, e sono sicuro che ora ce ne sono altri).

    
risposta data 12.01.2013 - 15:30
fonte

Leggi altre domande sui tag