Castello gonfiabile - documento firmato dal mittente e leggibile solo dal destinatario?

2

Sto creando un'applicazione che richiede il trasferimento sicuro dei dati. In particolare, il mittente ha un file di dati che deve essere inviato al destinatario. È richiesto che solo il ricevitore sia in grado di leggere i dati. È anche richiesto che il ricevitore possa sapere con certezza che i dati provengono dal mittente.

Il mittente e il destinatario hanno una relazione commerciale a lungo termine e avranno scambiato le chiavi pubbliche. I file di dati da trasmettere non sono piccoli.

Sto presumendo che Bouncy Castle sia una buona strada da percorrere, ma sono aperto ad altri suggerimenti.

Ho letto tutta la documentazione di BC che posso trovare (nessuna) e guardo l'API e alcuni esempi che ho trovato su internet. Sembra che voglia usare CMSEnvelopedDataGenerator , ma ho alcune domande specifiche:

  1. Esattamente come posso configurare la crittografia dei dati (presumibilmente usando AES)?
  2. Esattamente come posso configurare la doppia firma (utilizzando la chiave privata del mittente e la chiave pubblica del destinatario)?
  3. Posso configurarlo in modo tale che i dati vengano compressi / compressi prima di essere crittografati?
  4. L'implementazione BC di questo scenario è sicura e sicura da usare? Ci sono impostazioni / algoritmi / parametri specifici che sono necessari per renderlo sicuro?
  5. Esiste un'applicazione standalone disponibile di terze parti che posso utilizzare per leggere / convalidare che l'output BC è effettivamente corretto e sicuro?
  6. Che altro dovrei chiedere (sono un new-crypto)? O c'è un modo migliore per fare ciò che sto cercando?

Domanda di follow-up Facendo ulteriori ricerche, mi sono imbattuto in questo articolo . Le mie esigenze sono tali che non devo essere suscettibile all'inoltro surrettizio. L'articolo è vecchio Le varie tecnologie "sicure" continuano a soffrire dei difetti citati? Qualcuno dei prodotti / librerie standard fornisce una soluzione sicura in un modo standard?

    
posta Rob 05.06.2012 - 06:28
fonte

4 risposte

2

The BouncyCastle OpenPGP o S / MIME ti consentono di fare ciò che desideri. OpenPGP sarà più appropriato quando si usano i certificati OpenPGP (spesso indicati solo come "chiavi pubbliche PGP"), mentre S / MIME sarà più appropriato quando si usano i certificati X.509.

Non ci sono "doppie firme" coinvolte: firmi con la chiave privata del mittente e codifica con la chiave pubblica del destinatario.

GnuPG (o altre implementazioni di OpenPGP) dovrebbero consentire di testare i risultati se si utilizza l'implementazione di OpenPGP di BouncyCastle.

Si noti che è necessario firmare prima e crittografare in seguito, non viceversa, sulla base del fatto che il firmatario deve essere in grado di vedere ciò che firma e il destinatario deve essere in grado di decifrare e leggere, ma mantenere la firma allegato se necessario.

Non sembrano esserci molti esempi di BouncyCastle OpenPGP in giro, ma questo post di blog sembra piuttosto completo (anche se dovrei ancora firmare prima e criptare in seguito). Anche la compressione viene presa in considerazione.

    
risposta data 05.06.2012 - 19:02
fonte
1

Non ho esperienza con l'API di Bouncy Castle ma cercherò di sistemare le cose in modo criptato e potrebbe aiutarti a trovare la tua strada (dal momento che dici di essere un novellino di crittografia):

Q1: è un processo in due fasi:

  • Per prima cosa cripti il tuo messaggio usando un algoritmo a chiave simmetrica come AES.

  • Quindi crittografate la chiave del passaggio precedente utilizzando un algoritmo non simmetrico (ad esempio RSA) e la chiave pubblica del destinatario.

  • Invia i tuoi messaggi (simmetricamente criptati) lungo la tua chiave (non simmetricamente criptata) al tuo destinatario. Usa lo stesso algoritmo (non simmetrico) e la sua chiave privata per decifrare la chiave che gli darà accesso al messaggio (simmetricamente criptato).

Q2: solo il mittente firma il suo messaggio utilizzando la propria chiave privata. In poche parole il processo è: (1) Crea un hash del messaggio (2) crittografalo usando la chiave privata del mittente (3) invia il messaggio + l'hash crittografato (4) il ricevitore esegue un hash del messaggio ricevuto (5 ) decifra anche l'hash crittografato ricevuto usando la chiave pubblica del mittente (6) se i due corrispondono, allora il messaggio proviene davvero dal mittente e non è stato moderato lungo la strada.

Q3: questo non ha nulla a che fare con l'API crypto; trova una libreria che comprimerà i tuoi messaggi e usarli prima di applicare la crittografia.

Q5: Mi aspetto che se BC implementasse correttamente gli standard crittografici sarebbe interoperabile con OpenSSL o GPG ecc.

Q6: hai preso in considerazione l'utilizzo di una soluzione pronta come GPG o OpenSSL (ad esempio all'interno degli script?) Puoi anche utilizzare la funzionalità di firma / crittografia dei tuoi client di posta elettronica (usando S / MIME) e certificati autofirmati (ad es. MS Outlook ha funzionalità di firma digitale / crittografia incorporata, anche la maggior parte degli altri client di posta elettronica.)

    
risposta data 05.06.2012 - 11:22
fonte
1

Per rispondere alle tue domande 1-3:

Sto usando l'API BouncyCastle 1.47 (ovvero, con le interfacce operatore leggere) con openPGP per l'implementazione della chiave pubblica / privata. È davvero piuttosto complicato capire cosa sta succedendo; ma ho avuto una pugnalata di recente. Caveat emptor, come tutto quello che posso dire è che "funziona per me (TM)".

Guarda il metodo di crittografia per vedere qualche codice per realizzare questo.

Uso anche l'intestazione "destinatario anonimo", che impedisce a qualcuno che può vedere i dati di identificare l'ID della chiave pubblica del destinatario (anche se non possono decrittografarlo.) Questo può o non può essere rilevante per te, ma con questo meccanismo, dovresti utilizzare anche il metodo di decrittografia appropriato che prova tutte le chiavi disponibili.

Non posso parlare per le domande 4 e amp; 5, ma alcuni pensieri specifici di openPGP per la domanda 6:

1) Il debugging dei tuoi contenuti generati con GnuPGP è un buon modo per identificare i problemi.

Anche

gpg --list-packets è molto utile.

2) Crea un portachiavi con chiavi di firma e crittografia separate (in questo modo utilizzerai due coppie di coppie di chiavi pubbliche / private). Alcuni teorie sul perché è necessario .

2) Utilizzare chiavi di lunghezza esplicite e appropriate laddove possibile, poiché il provider predefinito basato su Java crea chiavi abbastanza brevi. (Vedi il codice generazione della chiave per alcune opzioni .)

3) Potresti considerare di "pre-costruire" un messaggio di revoca firmato al momento della generazione della chiave, nel caso in cui una delle tue parti dimentichi la loro password o perda la loro chiave privata. Questo può essere rilasciato per invalidare le chiavi pubbliche scambiate in precedenza.

    
risposta data 08.06.2012 - 23:39
fonte
0

Ti consiglio di utilizzare GPG (GnuPG) o PGP o OpenPGP per crittografare e firmare i tuoi messaggi. Il loro formato dei messaggi e il codice crittografico sono ben controllati. L'utilizzo di un formato e di un codice crittografico esistenti è più affidabile di te stesso con BouncyCastle, poiché ti farà risparmiare dai dettagli che altrimenti potresti rovinare. Questo dovrebbe facilitare la risoluzione del tuo problema.

    
risposta data 06.06.2012 - 06:01
fonte

Leggi altre domande sui tag