Memorizza un segreto su un computer Windows in modo che anche un amministratore non possa accedervi

1

Sto cercando un modo per memorizzare un segreto su un computer Windows in modo che anche l'amministratore non possa accedervi.

Ma gli eseguibili firmati con un certificato di firma del codice specifico dovrebbero poter accedere a quel segreto senza l'interazione dell'utente.

Stavo pensando di utilizzare il seguente approccio:

  • Crea un nuovo utente Windows "SecretKeeper" con una password casuale che non è nota a nessun utente.
  • Installa un servizio Windows in esecuzione con l'account utente SecretKeeper. (Il servizio può essere avviato automaticamente da Windows senza che nessun altro conosca la password di SecretKeeper)
  • Dai il segreto a quel servizio, fallo archiviare il file sul file system e crittografalo utilizzando l'API di crittografia file di Windows (in modo che solo l'utente specifico SecretKeeper possa leggere il file)
  • Quando un'applicazione ha bisogno del segreto, può comunicare con il servizio in modo tale che il servizio possa controllare la firma del codice dell'eseguibile prima di inviare il segreto.

Il problema con questo approccio è che un amministratore può scambiare il servizio eseguibile con il proprio eseguibile che viene quindi avviato come SecretKeeper e può decrittografarlo.

C'è un modo per assicurarti che l'eseguibile per un servizio Windows installato non venga scambiato nemmeno dall'amministratore o esiste forse un approccio completamente diverso per raggiungere l'obiettivo di nascondere un segreto anche dall'amministratore?

Nota: sono consapevole che un amministratore locale di un computer Windows ha altri mezzi per accedere alla memoria di processo dei processi in esecuzione o controllare la comunicazione tra i processi e che ci dovrebbero essere altri meccanismi per impedirlo.

Questa domanda è simile alle seguenti domande:

posta NineBerry 15.02.2018 - 11:46
fonte

2 risposte

1

Per essere onesti, probabilmente non è nemmeno il punto più debole del tuo schema. Se fossi l'amministratore che cercava di ottenere il segreto, tutto ciò che farei è decompilare l'app che richiede il segreto (per vedere come funziona), e basta creare un veloce .exe che chiede educatamente il tuo servizio per il segreto. Voglio dire, il tuo segretario non ha alcun modo di sapere se l'app che richiede il segreto è autorizzata ad averla.

Penso che la risposta breve sia: davvero non puoi fare quello che stai chiedendo.

    
risposta data 15.02.2018 - 16:07
fonte
0

Password seme

L'approccio che utilizzerei (dato il know-how appropriato) sarebbe quello di crittografare i tuoi dati utilizzando un valore seme che conosci personalmente e mai scrivere.

Essenzialmente, dovresti conoscere la parola, la frase o la sequenza casuale di valori / caratteri che sono stati originariamente usati per codificare i dati per decodificarli, quindi la tua applicazione segreta è completamente inutile senza quei dati, anche se l'amministratore ha accesso completo al codice e può decompilare e ricompilare a volontà.

Questo è sostanzialmente diverso da un sistema protetto da password in quanto la codifica non è comune tra i file protetti e la password non deve essere memorizzata da nessuna parte eccetto la propria testa. Questo non è un sistema di autorizzazione, questo è letteralmente una parte integrante del processo di decodifica dei tuoi dati.

L'unico modo per aggirarlo sarebbe la forza bruta che decodifica i dati grezzi (buona fortuna con quello!) o key-log l'input del valore seme quando è in uso.

Per sicurezza dannatamente perfetta, mantenere l'applicazione di codifica su un dispositivo esterno sicuro in modo che lo strumento non sia facilmente accessibile all'amministratore, solo i file crittografati prodotti.
Dovresti collegarlo, il dispositivo esterno accetterebbe il tuo file di input e lo codificherà / decodificherà usando un seme di crittografia digitato in una tastiera (che non comunica con il computer compromesso) prima di sputare il file crittografato o decrittografato su la macchina hosting.

Questo approccio è praticamente vulnerabile solo agli attacchi di social engineering / fisici in cui l'attaccante guadagna fisicamente il controllo del dispositivo di crittografia e ti obbliga a dirgli la password.

    
risposta data 30.08.2018 - 13:49
fonte

Leggi altre domande sui tag