Firma RSA su TLS

2

In un handshake TLS che usa ECDHE-RSA , il frame ServerKeyExchange deve includere ECDHE ServerPublicKey, firmato con la sua chiave privata RSA, come specificato nel RFC 4492 . Capito.

Cercando di implementare uno tipo ECDHE-RSA scambiandolo con crypto++ , mi trovo di fronte a un piccolo interrogatorio: qual è lo schema utilizzato per firmare il fotogramma ?

È

  • Signature Schemes with Appendix (SSA)

o

  • Signature Schemes with Recovery (PSSR)?

L'unico vantaggio dell'utilizzo del PSSR, come detto qui , è che non si invia il messaggio, è incorporato nella firma.

Inoltre, non viene menzionato da nessuna parte nella RFC 5246 , né negli RFC 4492 .

È una discrezione del programmatore?

    
posta EisenHeim 09.09.2015 - 13:36
fonte

1 risposta

4

Lo schema di firma esatta dipende dalla versione del protocollo; tuttavia, in tutti i casi, si riferisce a ciò che Crypto ++ chiama "schemi di firma con appendice".

PKCS # 1 descrive due schemi di firma (e due schemi di crittografia asimmetrici, che non sono rilevanti qui): il " vecchio "(chiamato" v1.5 ") e il" nuovo "(chiamato" PSS "). SSL / TLS si basa su quello vecchio (v1.5).

Nella generazione di firme v1.5 PKCS # 1, si verifica quanto segue:

  • I dati da firmare vengono sottoposti a hash, con qualche funzione di hash. Chiamiamo x la sequenza risultante di byte. Ad esempio, se la funzione di hash è SHA-256, la lunghezza di x è 256 bit, cioè 32 byte.

  • Un'intestazione t è aggiunta a x . L'intestazione è una sequenza fissa di byte che identifica la funzione hash (tecnicamente, x è usato come parametro in una struttura ASN.1 codificata DER che identifica anche la funzione hash con un OID; è più semplice pensarlo come un'intestazione fissa).

  • Alcuni byte vengono aggiunti prima della concatenazione di t e x , in modo da ottenere la seguente struttura:

    00 01 FF FF ... FF 00 t x

    Ovvero, un byte di valore 0, quindi un byte di valore 1, quindi alcuni byte di valore FF, quindi un byte di valore 0, quindi t , quindi x , sono concatenati in questo ordine. Il numero di byte "FF" viene regolato in modo che la lunghezza totale sia esattamente la lunghezza, in byte, del modulo RSA (cioè 256 byte per una chiave RSA a 2048 bit). Questo passaggio è chiamato "PKCS # 1 tipo 1 padding".

  • La stringa imbottita viene quindi interpretata come un grande numero intero (utilizzando la convenzione big-endian), che quindi entra nell'esponenziazione modulare che è al centro dello schema di firma RSA.

Con TLS-1.2 , lo schema della firma deve essere esattamente quello sopra, con una funzione di hash che dipende da ciò che il client e il server supportano. Con l'estensione Signature Algorithms , il client specifica nel suo messaggio ClientHello quali tipi di funzioni di hash che può utilizzare con l'algoritmo RSA; se tale estensione manca, il server deve presupporre che il client supporti SHA-1. Il valore dell'intestazione t viene fornito esplicitamente, per la funzione di hash più comune, nella sezione 9.2 di PKCS # 1.

Nelle precedenti versioni TLS (SSL-3.0, TLS-1.0 e TLS-1.1) , lo schema è sottilmente differente: l'intestazione t è vuota, e x è la concatenazione dell'MD5 e degli hash SHA-1 di ciò che deve essere firmato. Pertanto, la lunghezza di t è 0 e la lunghezza di x è di 36 byte (16 byte per MD5, 20 byte per SHA-1). Non c'è discussione tra client e server su quali funzioni hash usare; è sempre MD5 + SHA-1.

Un rapido sguardo al manuale sembra indicare che almeno le firme "normali" (per TLS-1.2) possono essere calcolate con Crypto ++ usando RSASS<PKCS1v15, H> dove H sarà SHA1 , SHA256 ... Non so se Crypto ++ include il codice per lo schema precedente dove l'hash è la concatenazione di MD5 e SHA-1, e non c'è l'intestazione.

    
risposta data 09.09.2015 - 14:33
fonte

Leggi altre domande sui tag