Gestione delle chiavi ibrida che funziona male?

3

Attualmente sto lavorando a un progetto che ha bisogno di essere il più sicuro possibile per la gestione delle chiavi. La mia esperienza con la crittografia, la decrittazione e la gestione delle chiavi non è affatto così ho fatto qualche ricerca sull'argomento in questione, ma non sono ancora sicuro di cosa ho pensato di essere sicuro quindi le mie domande:

Progetto

Il progetto in breve: Un'applicazione client che invia (tramite WIFI) i dati sensibili della carta di credito verso un server locale che invia i dati a un elaboratore di carte di credito. La comunicazione tra il client e il server locale deve essere protetta in ogni momento e non voglio fare affidamento sulle impostazioni del server o del router, quindi avvio la mia comunicazione sicura.

applicazione client < - > [server locale - > Applicazione di pagamento per la conformità PA-DSS] < - > Processore

(So che per i pagamenti con carta di credito esistono requisiti espressamente indicati dal PCI-SSC in particolare PA-DSS e ho già letto attentamente questi dati ma non sono un esperto.)

Domande

  1. (Guardando al "Client-Server Setup" sotto) È questa una corretta implementazione di un approccio di gestione delle chiavi ibrido?
  2. Per garantire che i contenuti dei messaggi siano validi devo aggiungere un checksum o un hash nei dati crittografati?
  3. La prima chiave AES256 che sia il client che il server sono incorporati nel codice, poiché questa è necessaria solo per il primo contatto, perderebbe questa chiave per l'insicurezza dell'intero sistema? (penso di no ma non ne sono sicuro)
  4. Dovrei garantire più autenticazione se sì, allora come potrei ottenere questo?

Come gestione delle chiavi, scelgo un sistema di gestione delle chiavi ibrido utilizzando sia AES-256 che RSA-1024/2048.

Impostazione server client

  • [BOTH] client e server hanno la stessa chiave AES-256
  • [CLIENT] genera una coppia di chiavi 1024 o 2048 privata / pubblica
  • [CLIENT] invia la chiave pubblica (formato PEM x509) crittografata (CBC-PKCS7 con riempimento) sotto la chiave AES256 condivisa verso il server
  • [SERVER] decrittografa i dati ricevuti e recupera la chiave pubblica
  • [SERVER] genera una nuova chiave AES-256 casuale e crittografa con la chiave pubblica (O-AEP imbottita)
  • [SERVER] restituisce la chiave AES-256 crittografata con la chiave pubblica
  • [CLIENT] decrittografa i dati ricevuti e recupera la nuova chiave AES-256
  • [BOTH] l'ulteriore comunicazione è crittografata con la nuova chiave AES-256

Grazie in anticipo

    
posta JustinV 03.04.2012 - 12:43
fonte

1 risposta

5

Sembra di reinventare la ruota. Grande tempo. SSL dovrebbe essere in grado di soddisfare i requisiti (PCI e molte altre esigenze di comunicazioni sicure), mantenere sia la riservatezza che l'integrità + supportare una buona autenticazione solida in modo semplice ed efficace senza dover inventare il proprio protocollo.

    
risposta data 03.04.2012 - 15:43
fonte

Leggi altre domande sui tag