Protezione della chiave di decodifica sul server

5

Qual è il modo più adatto per crittografare e decodificare i dati sensibili su un disco del server cloud pubblico senza archiviare la chiave di decrittazione sul server in testo semplice?

REQUISITI

Nella nostra app web / mobile SaaS, dopo il login dell'utente, un utente può caricare file PDF contenenti dati sensibili dei clienti su un server cloud pubblico fisicamente ospitato da un fornitore di terze parti (ad esempio Amazon / Rackspace). Vorrei proteggere i dati sul disco crittografandolo prima di scriverlo su disco e decrittografarlo quando viene letto dal disco.

Una soluzione comune è utilizzare la crittografia simmetrica, ad es. AES e per memorizzare la chiave di decodifica sul filesystem del server. Voglio evitare di memorizzare la chiave di decrittografia in chiaro insieme ai dati al fine di proteggere l'accesso ai dati su disco ovunque si trovi all'interno dell'infrastruttura di terze parti - ad es. potenzialmente su più server e dischi fisici (dischi del server, non crittografati su array di dischi di backup di immagine giornalieri) ecc.

Condizioni:   Un utente dovrebbe essere in grado di scaricare i PDF che ha precedentemente caricato.   Un utente amministratore dovrebbe essere in grado di visualizzare i PDF caricati da qualsiasi utente.

Sto considerando l'utilizzo della password di accesso dell'utente per proteggere le chiavi di decrittografia.

SOLUZIONE POTENZIALE

Durante ogni registrazione utente, una coppia di chiavi pubbliche / private RSA sarebbe stata generata e memorizzata sul disco del server. La chiave privata verrà archiviata AES crittografata con la password dell'utente (in realtà la chiave derivata PBKDF2 in base alla password dell'utente).

Crittografia:

  • PDF in testo semplice viene caricato sul server (su SSL)
  • Il server genera una stringa casuale (R) per la crittografia AES.
  • RSA codifica R utilizzando la chiave pubblica dell'utente. RSA cripta R usando la chiave pubblica dell'utente Admin. # Permette all'utente amministratore di decifrare qualsiasi cosa AES cripta il PDF con R e
  • Archivia queste tre parti crittografate nel filesystem.

Decodifica:

  • Decrittografa la chiave privata dell'utente utilizzando la propria password di accesso (tramite PBKDF2)
  • RSA Decrypt R utilizzando la chiave privata dell'utente.
  • AES Decifra PDF usando R e restituiscilo all'utente

In questo modo, se qualcuno ha accesso completo ai dati completi del filesystem, non può decifrare i file PDF a meno che non conoscano anche una password.

D: Questa è una soluzione sicura? Vedi difetti in questo? Esistono alternative adatte che dovrei prendere in considerazione?

    
posta taz 08.12.2014 - 16:04
fonte

3 risposte

1

Sei certamente sulla buona strada, ma è possibile che tu lo stia rendendo un po 'più complicato del necessario. Hai identificato correttamente che un sistema di crittografia simmetrica crea il problema significativo della chiave di decodifica presente sul sistema.

Se si sceglie di generare chiavi pubbliche / private per ogni parte di dati, potrebbe rendere la vita inutilmente difficile oltre a "gestire" le chiavi private in una posizione non ottimale. Se sei sposato con i dati che vengono crittografati con la chiave pubblica dell'utente, è possibile modificare quanto segue per memorizzare due copie della chiave simmetrica crittografata. In questo caso sarebbe meglio consentire all'utente di generare un custode e fornirti la chiave pubblica piuttosto che generare la coppia di chiavi per l'utente. (In altre parole, non vuoi veramente gestire la chiave privata)

  1. In una posizione attendibile, generare una coppia di chiavi pubblica / privata per il server / l'applicazione
  2. Copia la chiave pubblica (solo) nel percorso dell'applicazione tra l'utente e il database
  3. Ogni volta che arrivano dati sensibili, genera una chiave segreta casuale e utilizza questa chiave per crittografare i dati sensibili utilizzando un algoritmo simmetrico (come AES)
  4. Cripta la chiave segreta casuale con la chiave pubblica dell'applicazione

Ci sono un certo numero di cose che sono ideali per questo approccio:

  • Sistemi di backend e utenti con esigenze aziendali e i diritti appropriati possono utilizzare la chiave privata in un sistema separato per recuperare i dati sensibili
  • Poiché solo la chiave privata può essere utilizzata per decrittografare le chiavi segrete casuali non esiste una superficie di attacco utile a parte la forza bruta cruda per un utente malintenzionato che compromette l'applicazione
  • L'efficacia di un attacco di forza bruta è drasticamente ridotta poiché un attacco riuscito contro una qualsiasi delle chiavi segrete casuali fornisce accesso solo a quel singolo pezzo di dati; tutti gli altri tasti sono diversi. Ciò rende molto poco attraente un attacco di forza bruta contro le chiavi simmetriche.
  • Attualmente una forza bruta contro una coppia di chiavi pubblica / privata di 4096 bit è considerata intrattabile

Quindi, di nuovo, hai l'idea giusta, ma potresti voler semplificare il tuo approccio un po '!

    
risposta data 09.12.2014 - 06:10
fonte
0

Innanzitutto @taz ti fa bene a pensare fuori dagli schemi per mantenere i dati dei tuoi clienti più sicuri, tuttavia ho alcune preoccupazioni e possibili suggerimenti per aumentare la sicurezza dell'archiviazione dei dati ...

Alla tua domanda sulla sicurezza del sistema finalizzato, vedo il potenziale di un compromesso nascosto tra server che porta a comprenderne i dati al momento del login e vedo che il potenziale dell'account admin è un singolo punto di errore / compromesso . Mentre il sistema proposto sarebbe più sicuro di quello che ho visto implementato da altri amministratori di server, coprirò alcune altre opzioni che potresti voler prendere ispirazione per rendere la sicurezza ancora più stretta.

opzioni abilitate per Web / app

  1. Considera openpgpjs per la decrittografia del client nel browser

  2. Considera openpgp-php per la crittografia lato server

  3. Considera di estrarre il codice sorgente da ProtonMail o KeyBase per come questi team hanno implementato la crittografia / decrittografia tra server e client.

La soluzione alternativa possibile è la crittografia sshfs + GnuPG ... è un po 'di setup per client e server ma manterrà i client & ammette le chiavi private sul loro file system correlato e completamente fuori dal file system del server.

imposta sshfs sul server cloud per eseguire il chroot dei client

  1. Installa sshfs sul server

    apt-get install sshfs
    
  2. Crea un nuovo gruppo per i client da riconoscere

    group add sshfsmount
    
  3. Aggiungi utenti a nuovo gruppo e utenti al server

    Var_users_list="bob,alise"
    Var_chroot_group="sshfsmount"
    for _user in ${Var_users_list//,/ }; do
        ## Add user
        adduser ${_user}
        ## Lock user account from logins and append to chroot group
        passwd -l ${_user}
        usermod -s /bin/false  -a -G ${Var_chroot_group} ${_user}
        ## Make directory for user to be chrooted to with restricting permissions
        mkdir -p ${Var_chroot_group}/${_user}
        chown root:root ${Var_chroot_group}
        chown ${Var_chroot_group}:${_user} ${Var_chroot_group}/${_user}
        chmod 760 ${Var_chroot_group}/${_user}
    done
    
  4. Modifica la configurazione ssh del server

    nano /etc/ssh/sshd_config
    ## snip, change subsystem settings
    Subsystem      sftp     internal-sftp
    ## snip, append the following to chroot the group
    Match Group sshfsmount
        ChrootDirectory /sshfsmount/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no
        PermitTunnel no
        X11Forwarding no
    
  5. Verifica le impostazioni e ricarica la configurazione del server ssh

    sshd -T
    if [ "$?" = "0" ]; then
        /etc/init.d/ssh reload
    fi
    

Note Subsystem sftp internal-sftp may cause ssh logins to fail so attempt to login via a normal ssh account after restarting the server before logging out of current ssh terminal that made the above changes.

  1. Aggiungi le chiavi ssh pubbliche dei client ad autorizzate

    Var_users_list="bob,alise"
    Var_key_dir="/ssh_pub_keys"
    for _user in ${Var_users_list//,/ }; do
        find "${Var_key_dir}" -xtype f | while read _key; do
            if grep -qE "${_user}" <<<"${_key}"; then
                mkdir -p /home/${_user}/.ssh
                cat "${_key}" >> /home/${_user}/.ssh/authorized_keys
            fi
        done
    done
    

Impostazione per bob client sshfs

  1. Installa sshfs

    apt-get install sshfs
    
  2. Modifica le impostazioni del client ssh per utilizzare i tasti

    nano /etc/ssh/ssh_config
    ## append the following config block
    host cloud_server
        User bob
        HostName host.domain
        IdentityFile /some/dir/private_ssh_key
        IdentitiesOnly yes
    

Note host.domain should point to the cloud server's domain name or IP address

  1. Crea directory e monta il server cloud sul file system locale dei client

    mkdir -p /mnt/glow_cloud
    sshfs cloud_server:/ /mnt/glow_cloud
    

Note to unmount use the following

    fusermount -u /mnt/glow_cloud
  1. Utilizza la crittografia a chiave pubblica GnuPG per l'utente bob per crittografare un file con l'output salvato sul server cloud

    cat some_local_file.txt | gpg -a -e -r bob@glow_cloud.domain -r admin@glow_cloud.domain -o /mnt/glow_cloud/enc_file.gpg
    

Note for text files the user bob may use a vim plugin/script to edit the above encrypted file on the remote server.

Note for non-text files you may wish to checkout the latest build of Paranoid_Pipes for further inspiration and utilize similar steps as above to make encrypting/decrypting between server and clients automatic. However, this last suggestion is experimental and results in clients keeping decryption key's passphrase in their local memory... so with above security mainly rests upon your clients' shoulders because the admin can use similar mounting schemes for keeping their own private keys off the server too.

    
risposta data 16.12.2016 - 21:39
fonte
-2

Ci sono alcune noiose realtà riguardo la memorizzazione di qualsiasi cosa su un cloud pubblico. L'unico modo sicuro per decrittografare / crittografare qualsiasi cosa è sul client locale stesso e tutte le questioni relative alla gestione locale delle chiavi private: furto di telefono, furto di chiavi, ecc. Utilizzare il cloud pubblico significa che devi fidarti di questo, su un sistema multi-tenant , gli altri inquilini non riescono a racimolare in memoria, o il provider di hosting non preleva una copia. Se si dispone di una parte di dati veramente critica, nessuna risposta è fornita da public cloud.

    
risposta data 18.05.2016 - 01:28
fonte

Leggi altre domande sui tag