Se il modello di minaccia include "processi dannosi in esecuzione come lo stesso utente del processo legittimo che richiede la chiave", è necessario tornare al tavolo da disegno e riprogettare. Non è possibile proteggersi da questo. I processi all'interno di una singola sessione utente non sono, e non dovrebbero essere previsti, sicuri l'uno dell'altro.
La preoccupazione che esprimi sulle pipe, ad esempio, si estende a qualsiasi altro tipo di meccanismo IPC. Socket TLS con autenticazione reciproca? Qualsiasi processo che può connettersi al socket può essere impersonato da un altro processo nello stesso contesto utente, leggendo gli stessi dati chiave e spoofando il processo legit. Anche se si potesse stabilire in modo sicuro l'IPC, non è possibile garantire che i dati siano sicuri. Ad esempio, alcuni sistemi operativi (Windows in particolare, ma penso anche alcuni Unix-like) consentono a qualsiasi processo in esecuzione con un determinato utilizzo di eseguire il debug di qualsiasi altro processo sotto lo stesso utente, in modo che il processo dannoso possa solo leggere il segreto direttamente dal processo legittimo 'spazio indirizzo.
OK, parliamo di scenari in cui non si presume che un altro processo sia nello stesso contesto utente di cui si è malintenzionati. Forse è perché hai (ri) ideato l'intera cosa in modo che venga eseguita in un contesto utente speciale utilizzato solo per lo scopo specifico del tuo software. Forse è perché stai lavorando su un dispositivo incorporato in cui controlli tutto il codice che viene eseguito. Forse è solo perché hai accettato di provare a difendere contro il codice malevolo con gli stessi privilegi di cui sei privo di speranza e senza senso (se i malintenzionati stanno eseguendo il codice nel tuo contesto utente, è già game over, uomo).
Non hai specificato il sistema operativo su cui è necessario eseguire il software. Tuttavia, in generale, ci sono alcune scelte decenti qui per il segreto che non vuoi mai impegnare per l'archiviazione persistente.
Su sistemi di tipo Unix:
- socket di dominio Unix (locali). Veloce e abbastanza semplice. Supporta la comunicazione bidirezionale, se questo è importante. Per sicurezza, devi solo crearli in una posizione che non è né leggibile né scrivibile da nessun altro utente (qualcosa sotto il profilo utente è una scelta popolare). D'altra parte, hai detto che non puoi ospitare un socket di ascolto sul Master (perché no?), Quindi potrebbe non funzionare.
- Una named pipe, detta anche FIFO. Veloce e diretto, ma solo unidirezionale (se si desidera bidirezionale, è necessario creare un paio di tubi). Come con il socket locale, assicurati che la FIFO sia creata dove nessun altro utente può accedere.
Su Windows:
- Una named pipe. A differenza delle pipe denominate da Unix, le pipe di Windows non vanno nel file system standard; c'è uno speciale "named pipe file system" per loro. Ciò significa che è necessario assicurarsi di creare il tubo con l'elenco di controllo di accesso (ACL) corretto. Una volta creato, però, l'uso della pipe è veloce e semplice.
- Una mappatura della memoria con nome. L'API
CreateFileMapping può essere utilizzata per creare una mappatura della memoria che non sia supportata da alcun file normale, ma dal file di paging del sistema. Mentre il file di paging è supportato da dati persistenti e quindi potrebbe portare al segreto che viene memorizzato su disco, questo è un rischio con qualsiasi processo; non si può garantire che il segreto non verrà mai cancellato dalla memoria di lavoro a meno che la piattaforma non offra (e si usi) una sorta di buffer protetto dal kernel. Nel frattempo, un utente malintenzionato non saprebbe dove cercare il segreto nel file di paging, quindi probabilmente sei al sicuro. I mapping di memoria con nome, come i named pipe, devono essere protetti utilizzando un ACL che impedisca ai processi in esecuzione con altri utenti di aprire il mapping. Una volta che entrambe le parti hanno aperto la mappatura, tuttavia, è molto veloce.
- Accesso diretto alla memoria (leggi, molto probabilmente) tra i processi. Il processo client legge semplicemente il segreto dallo spazio degli indirizzi virtuali del genitore. Ciò richiede un modo per passare l'indirizzo rilevante all'altro processo, ma è OK se tale indirizzo è esposto; gli altri utenti non possono accedere alla memoria del processo, anche se sanno dove cercare, perché i processi hanno sempre un ACL che impedisce ad altri utenti di leggere la loro memoria.