Il mio invio di informazioni crittografate è sicuro?

2

Per favore, sopportami perché non sono un esperto in sicurezza. Ho un server e un client. Sul server sto crittografando un messaggio molto segreto (utilizzando AES256-GCM per nascondere le informazioni e proteggerne l'integrità) che invierò al client. Il client però non decodificherà mai questo messaggio, lo riceverà solo dal server e lo rimanderà al server con le sue richieste. Il mio server decodificherà e riceverà il messaggio segreto di cui ha bisogno per elaborare altre informazioni. Devo assicurarmi che il cliente non sappia mai dei contenuti all'interno del messaggio. Sto usando javascript (NodeJS) per il mio codice server e sembra questo (spero sia facile da leggere e facile da capire):

var crypto = require('crypto'); //get crypto library
var algorithm = 'aes-256-gcm'; // select which algorithm I want to use
var password = '3zTvzr3p67VC61jmV54rIYu1545x4TlY'; //Random generated 256bit key

function encrypt(text) {
  var iv = crypto.randomBytes(128) // generate a random 128bit iv for every encryption
  var cipher = crypto.createCipheriv(algorithm, password, iv)
  var encrypted = cipher.update(text, 'utf8', 'hex')
  encrypted += cipher.final('hex');
  var tag = cipher.getAuthTag();
  var enc = {
    content: encrypted,
    tag: tag.toString('hex')
  };

sendToClientOverInternet(enc,iv); //send the encrypted content + the iv to client over the internet

}

function decrypt(encrypted) {
  var decipher = crypto.createDecipheriv(algorithm, password, iv)
  decipher.setAuthTag(new Buffer(encrypted.tag, 'hex'));
  var dec = decipher.update(encrypted.content, 'hex', 'utf8')
  dec += decipher.final('utf8');
  return dec;
}

Sono preoccupato più del processo e dei metodi di crittografia che si oppongono alla sicurezza dell'infrastruttura. Con questo, si assume che il mio server sia completamente sicuro e che la password codificata nel mio codice non sia mai accessibile e che il trasporto di dati su Internet sia limitato a ssl.

Il mio codice con le mie domande:

1) Per prima cosa ho generato una chiave di 32 byte globale sicura in modo casuale.

D: Questa è la taglia corretta? Un modo per migliorare la chiave?

2) Ho un metodo di crittografia che prende del testo e lo crittografa utilizzando AES256-GCM. Quindi prende questo oggetto crittografato e insieme al iv (128 bit di sicurezza generato casualmente per ogni messaggio) lo invia al client. Il cliente se volesse allora potrebbe ora vedere questo oggetto criptato e il iv.

D: È necessaria la protezione dell'integrità dei dati utilizzando GCM? Se io uso CTR invece non sarebbe impossibile per l'hacker decifrare e cambiare il messaggio comunque senza la chiave? Quindi GCM 'overkill'? L'invio di iv e il suo accesso all'utente sono sicuri? Un 128 bit iv abbastanza lungo? Qualche grande miglioramento che posso apportare qui?.

3) Ho un metodo di decrittografia che accetta la mia stringa crittografata e la decrittografa.

D: (Non penso che qui debba essere migliorato qualcosa).

Qualsiasi miglioramento o suggerimento sarebbe molto apprezzato.

    
posta user2924127 18.01.2016 - 23:53
fonte

2 risposte

4

Presumo che il client e il server comunichino tramite un canale sicuro, ad es. TLS? Altrimenti, chiunque sia seduto sul filo può montare un attacco di replay , ovvero intercettare il testo cifrato inviato al client e inviare nuovamente il testo cifrato il server per impersonare il destinatario previsto.

Dai commenti sembra che tu stia usando il ciphertext passato al client come un modo per non mantenere lo stato sul server. Più specificamente, si invia un messaggio al client del proprio stato criptato e poi si fa spedire indietro e decodificare / elaborare quello stato all'arrivo. Se stai già archiviando le chiavi di crittografia è davvero molto più difficile rifattorizzare la memorizzazione dei token di sessione?

Riguardo alla tua domanda usando GCM

  • Il iv (o nonce come viene generalmente chiamato in modalità GCM) viene inviato insieme al testo cifrato, la sicurezza di GCM non si basa sul fatto che l'iv sia segreto, solo che non viene mai riutilizzato, quindi 128 bit di random vanno bene (anche se come dice la risposta di Xander, ci sono attacchi teorici contro ivs che non sono 96 bit). Finché la tua chiave ha abbastanza entropia dovresti stare bene.
  • GCM aggira alcuni dei problemi che hanno le altre modalità. CTR (che hai menzionato) e CBC, ad esempio, hanno attacchi di bit-flipping contro di loro in cui il testo cifrato può essere modificato senza la conoscenza della chiave per produrre cambiamenti significativi nel testo in chiaro. Le modalità CBC e CTR richiederebbero un MAC del testo cifrato inviato insieme a loro per verificarne l'integrità. Quindi, mentre è possibile utilizzare queste modalità in modo sicuro, è necessario un paio di passaggi in più rispetto a GCM.

In conclusione questa costruzione è piuttosto non ortodossa e un meccanismo come i token di sessione migliorerebbe le prestazioni (e darebbe il vantaggio di essere un metodo provato e testato). Se devi seguire questa strada, GCM dovrebbe andare bene per proteggere i dati dal client.

    
risposta data 19.01.2016 - 09:23
fonte
3

Tutto ciò in generale sembra ragionevole, ma ci sono un paio di elementi da esaminare:

  • Innanzi tutto, la nota in la risposta di Puzzlepalace sulla necessità di TLS è sicuramente la più valida. E preferibilmente HSTS, se puoi.

  • In secondo luogo, ci sono attacchi teorici (letti, non pratici) su GCM con nonces (IV) con lunghezze diverse da 96 bit. Quindi, anche se questo potrebbe non essere critico, sarebbe sicuramente una pratica consigliata per abbreviare il tuo nonce da 128-bit a 96.

  • Terzo e infine, gestione delle chiavi. Le chiavi dovrebbero essere archiviate in un luogo sicuro e sicuramente non nel codice sorgente. Non dovrebbero essere affidati al controllo del codice sorgente, archiviati in testo chiaro, condivisi tra ambienti, noti agli utenti diversi dagli operatori dell'ambiente e ruotati regolarmente. Quindi, questo praticamente esclude di avere le chiavi nel codice sorgente dell'applicazione stesso.

Non sono un esperto di Nodo in alcun modo, ma a parte questi problemi, ma l'approccio è sicuramente valido.

    
risposta data 19.01.2016 - 17:09
fonte

Leggi altre domande sui tag