Memorizzare la chiave privata asimmetrica nel binario dell'applicazione?

Questo si trasforma rapidamente in un problema di "tartarughe fino in fondo". Devi solo decidere a che punto smettere di crittografare le cose e fare affidamento su un altro metodo. Penso che l'obiettivo dovrebbe essere quello di fermare gli utenti occasionali, ma non determinati hacker, per ottenere facilmente i dati protetti.

Ho combattuto con un metodo simile in un'applicazione web che doveva memorizzare la password del DB e la password del certificato SSL. Quello che ho finito è stato crittografare quelle password in un file di configurazione per l'app utilizzando una diversa password principale. La password principale è stata memorizzata come variabile di ambiente impostata dallo script di avvio dell'applicazione. Poiché la password principale è stata impostata solo nello script di avvio, è stato abbastanza semplice consentire a un singolo utente di accedere allo script insieme alla possibilità di eseguirlo utilizzando le autorizzazioni standard dei file UNIX.

Il mio pensiero era che per ottenere l'accesso a questo script in caso contrario, era necessario essere già root, a quel punto, non importa. Se non ti puoi fidare di root (o il server è stato violato) probabilmente hai altri problemi.

Inoltre, c'è un po 'di sicurezza attraverso l'oscurità qui in quanto tutti i dettagli di come funziona non sono documentati molto bene di proposito. Dovresti eseguire il backtrace su come funziona lo script di avvio, quindi capire quale algoritmo è utilizzato, come viene formattato il sale + plantext, ecc. Se vuoi ottenere la password del DB e arrivare così lontano, immagino che probabilmente potresti già avere solo suddiviso direttamente nel server DB.

Come al solito, il miglior punto di partenza è ponendoti alcune domande: qual è il tuo modello di minaccia? Cosa stai cercando di proteggere? Con chi stai cercando di proteggerlo? Perché stai usando Crypto in primo luogo? Nessuno di questi è chiaro dalla domanda. (Crypto non è una polvere magica da folletto.) E senza risposte a queste domande, non possiamo darti una soluzione: la soluzione giusta dipenderà da ciò che stai cercando di ottenere.

In generale non ci sarà una grande soluzione a questo problema. La chiave privata avrà un testo in chiaro da qualche parte sul disco (o in equivalente in chiaro), se si desidera essere in grado di avviare il sistema senza il coinvolgimento dell'utente. Colpisci rapidamente "tartarughe fino in fondo", come altri hanno suggerito.

Un passo che puoi fare è assicurarti che la chiave privata sia protetta dai controlli di accesso al filesystem: ad es., è leggibile da root ma non dagli utenti ordinari.

Nota a margine: esistono approcci sofisticati, ma probabilmente non sono adatti al tuo ambiente a basso costo. (1) Un altro approccio sicuro è quello di memorizzare la chiave privata in un modulo di sicurezza hardware collegato al server. Se il server viene compromesso, il software non può rubare la chiave privata (ma può ancora istruire il modulo di sicurezza hardware per firmare / decrittografare messaggi arbitrari). (2) Un approccio più sofisticato consiste nell'utilizzare un TPM e nel bloccare la chiave privata in un particolare software. Sfortunatamente gli attuali SO non forniscono un buon supporto per questo, quindi sarebbe molto impegnativo fare te stesso come amministratore di sistema: richiederebbe un supporto significativo per gli sviluppatori.

Non c'è un portachiavi disponibile per l'account per il demone?

Per completezza, la soluzione che abbiamo scelto era una combinazione delle risposte di @SteveSyfuhs e @ AngerClown. Su OS X, stiamo facendo uso del portachiavi di sistema ( /Library/Keychains/System.keychain ). Su Linux, stiamo memorizzando la chiave di crittografia in un file con i bit di autorizzazione 400 (cioè di sola lettura solo dal proprietario), di proprietà di root.

Barry, mi piace la tua soluzione e ho un'idea per fare un ulteriore passo avanti. Che ne dici di mantenere l'immagine della macchina che usi per creare nuove macchine impostate automaticamente sull'utilizzo di 400 sul file chiave, quindi all'avvio avvia il software del server come root, leggi la chiave in memoria, elimina la chiave, quindi cambia utente che esegue il software del server su un account non di root.