Modo corretto di firmare e verificare un messaggio

Question

Modo corretto di firmare e verificare un messaggio

#1 da (2 voti)

2

Ho un oggetto che ho bisogno di trasmettere ai client e ho bisogno che i client sappiano che ho effettivamente creato l'oggetto. Ovviamente, questo processo coinvolge in me la firma dell'oggetto con la mia chiave privata, quindi i client possono quindi verificarlo utilizzando la mia chiave pubblica. L'unico problema che ho è che c'è qualche elaborazione in un'altra applicazione che cambia alcune proprietà all'interno di questo oggetto. Ciò significa che non posso firmare l'intero oggetto poiché la verifica fallirà. Tuttavia, quello che ho davvero bisogno di verificare è il Payload, che non cambia. Il processo che ho seguito è il seguente. Per favore fatemi sapere se questo è il modo corretto di farlo e segnalare eventuali difetti di sicurezza che potrebbero esserci.

Ho aggiunto 2 proprietà nell'oggetto (SignedPayload e PublicKey)
Crea una coppia di chiavi pubblica / privata
Firmato il payload utilizzando la chiave privata e imposta SignedPayload
Aggiunta la chiave pubblica alla proprietà PublicKey

L'applicazione centrale verrà colpita e alcune proprietà cambieranno, ma il Payload non lo farà. In definitiva, i passaggi successivi verranno eseguiti una volta ricevuto il messaggio sul client:

Deserializza il messaggio
Verifica il messaggio utilizzando le proprietà PublicKey, Payload e SignedPayload. Se il Payload è cambiato, o la chiave pubblica non ha origine dalla mia organizzazione, il messaggio viene ignorato. Ciò significa che devo firmare la chiave pubblica.

Le mie domande principali sono:

Questo approccio è sicuro?
Come posso firmare la chiave pubblica in modo che il cliente possa verificare che io sia il proprietario della chiave?
Da quello che ho letto, è una pratica comune per trasmettere la chiave pubblica al momento della firma e della verifica dei dati. È questo corretta?
C'è qualcosa di sbagliato nell'approccio alla creazione di una coppia di chiavi per ogni messaggio, poiché trasmetto sempre la chiave pubblica? La ragione di ciò è evitare di dover memorizzare la chiave privata sul server, che può essere dirottata.

Molte grazie in anticipo.

digital-signature public-key-infrastructure

posta seedg 14.10.2015 - 10:37

fonte

1 risposta

Leggi altre domande sui tag digital-signature public-key-infrastructure

Non è ssh-copy-id che espone a un attacco di forza bruta? E 'possibile disabilitare' ypcat passwd '

score 2 · Answer 1

A meno che tu abbia omesso un elemento importante, l'approccio del tour sembra avere un grosso difetto: stai verificando la validità del carico utile utilizzando la chiave pubblica inclusa nello stesso messaggio.

Chiunque potrebbe quindi creare un pacchetto valido semplicemente generando una nuova coppia di chiavi, firmando il payload e allegando la chiave pubblica al pacchetto. Ecco perché il tuo primo passo dovrebbe sempre valutare la validità della chiave pubblica.

Di solito ciò avviene inserendo la chiave pubblica in un certificato firmato che descrive il reclamo di identità del mittente e che ha il certificato firmato da un'autorità fidata dal destinatario.

Come per le altre tue domande:

Without going through a CA, how can I generate a PKI which I myself, can verify that I, and nobody else, has created that PKI?

Supponendo che stai semplicemente usando male l'acronimo "PKI" per significare "coppia di chiavi pubblica / privata", allora non puoi: hai assolutamente bisogno di avere un modo per convalidare la chiave pubblica in ordine per convalidare il mittente del messaggio. Altrimenti, come ho descritto, chiunque potrebbe creare un pacchetto.

Questa convalida è ciò che serve alla CA: consente all'utente di dire che una determinata chiave pubblica è di proprietà di uno specifico responsabile della sicurezza .

Un altro modo di convalidare una chiave di questo tipo è usare un server delle chiavi: un sistema che contiene le informazioni che collegano una chiave pubblica con un'entità di sicurezza. Questo potrebbe essere usato se si desidera creare un sistema di trasporto semi-anonimo: se non si desidera che il destinatario sia in grado di sapere chi ha inviato un payload specifico ma desidera che sia in grado di assicurarsi che disponga dell'autorizzazione appropriata e, a allo stesso tempo, assicurarsi che il server centrale non possa vedere il contenuto di ciascun payload. Però non sembra che tu stia implementando quel tipo di sistema.

From what I have read, it is common practice to transmit the public key when signing and verifying data. Is this correct?

Devi fornire la chiave pubblica all'utente finale, sì. Ma la pratica comune dipende da cosa stai facendo esattamente. Nella maggior parte dei casi, non avrai solo la chiave pubblica, ma anche una qualche forma di certificato digitale che permetta all'utente finale di validare la chiave stessa (se non hai un altro meccanismo in atto per convalidare quella chiave pubblica). Nel caso di TLS, la pratica comune è quella di trasmettere TUTTI i certificati nella catena di fiducia (fino alla radice) al client in modo che possano controllare l'intera catena anche se manca un certificato intermedio.

Is there something wrong with the approach of creating a PKI for every message, since I am always transmitting the public key?

Non come tale, ma la creazione di una coppia di chiavi è un'operazione delicata e ricca di risorse. A meno che non sia assolutamente necessario, in genere non è implementato in questo modo.