In che modo l'aggiunta di un numero seriale casuale migliora la sicurezza di un certificato?

Question

In che modo l'aggiunta di un numero seriale casuale migliora la sicurezza di un certificato?

#1 da (15 voti)

12

"Finding collisions is a tricky process, since it requires you to muck with the bits of the public key embedded in the certificate (see this paper for more details). Also, Microsoft could have prevented this somewhat by adding a random serial number to the cert, which they didn't do."

La mia domanda è: come aggiungere un valore casuale a un certificato migliorare sicurezza? L'autore dell'attacco non può semplicemente generare un numero seriale per creare una collisione MD5?

Aggiornamento:

Ecco le informazioni su come Microsoft implementa la randomizzazione in una chiave CA . Non sono sicuro dei vantaggi e degli svantaggi di ciascuno.

Configure Serial Number Generation

In a Windows 2000 CA, two types of fixed-length serial numbers are generated. The registry can be modified to generate one or the other type. The default serial number is (from high to low): a DWORD from GetTickCount() + a USHORT CA cert index (0 to start) + a DWORD RequestId (10 bytes/20 hexadecimal digits). The alternate form is: one byte derived from the registry + a DWORD RequestId + 8 bytes of CryptGenRandom output + a USHORT CA cert index + a DWORD RequestId (19 bytes/38 hexadecimal digits).

To enable the alternate form and set the byte derived from the registry, use the following command:
    certutil –setreg ca\HighSerial 0x33 
The byte value specified will be modified to clear the sign bit and to set a bit in the high nibble to work around serial number encoding ambiguity bugs in certain non-Microsoft PKI applications.

In a Windows Server 2003 CA, three types of fixed-length serial numbers are generated. The default and alternate forms are the same as in Windows 2000. The Windows 2000 alternate form uses a new random 8 bytes generated by CryptGenRandom for each serial number. The new alternate form for Windows Server 2003 uses a fixed random 8 bytes from CryptGenRandom, generated during the first attempt to issue a certificate, and saved in the registry as 8 bytes of fixed CryptGenRandom output + a USHORT CA cert index + a DWORD RequestId (14 bytes/28 hexadecimal digits).

To enable the new alternate form in the registry, use the following command:
   certutil –setreg ca\HighSerial 0xffffffff 
Since the fixed random 8 bytes from CryptGenRandom are encoded as a string and saved in the registry, you could set them directly and cause them to be used for new serial numbers. In fact, any length hexadecimal string could be set in the registry (but there must be an even number of digits). The number of bytes used from the registry will be reduced if it would overflow a total of 19 bytes for the serial number. The high byte is manipulated as described previously to avoid problems with certain non-Microsoft applications. The IETF standards specify a maximum of 20 byte serial numbers.

encryption public-key-infrastructure certificates threat-mitigation

posta random65537 05.06.2012 - 23:15

fonte

1 risposta

Leggi altre domande sui tag encryption public-key-infrastructure certificates threat-mitigation

Memorizzazione password MS-SQL Verifica dell'integrità del software del server?

score 15 · Accepted Answer

Risposta breve. Il vantaggio deriva da un numero di serie imprevedibile , non da un numero seriale precedente.

In effetti, un numero seriale sequenziale non aggiunge sicurezza, poiché è facilmente prevedibile. Ma randomizzare il numero di serie (quindi è difficile da prevedere) rende più difficile sfruttare gli attacchi di collisione noti su MD5 per ottenere un certificato contraffatto. Lasciami spiegare.

Sfondo. quando una CA emette un certificato, include una firma su MD5 (P), per un carico utile del certificato P che include una chiave pubblica, un nome di dominio e un numero di serie. Gli attacchi noti di collisione su MD5 consentono all'utente malintenzionato di scegliere due valori P e Q con lo stesso hash MD5. Questo può essere usato per attaccare le CA che usano MD5, come segue. L'attaccante utilizza gli attacchi di collisione MD5 per trovare P, Q con la seguente proprietà: P è un payload del certificato benigno che la CA vorrebbe firmare volontariamente (ad esempio, un certificato per un nuovo dominio controllato dall'hacker), ma Q è un certificato malvagio carico utile che la CA non firmerebbe mai (ad esempio, un certificato per microsoft.com). L'attaccante invia una richiesta di certificato corrispondente a P alla CA; la CA lo firma e restituisce il certificato firmato; e quindi la firma su questo certificato sarà anche una firma valida su Q.

Si noti che questo attacco richiede che l'attaccante preveda il valore del numero seriale che verrà utilizzato quando la CA firma il certificato per P. Se i numeri seriali vengono assegnati in sequenza, questo compito di previsione è semplice. Ma se i numeri seriali sono (diciamo) un numero 128-bit crittograficamente casuale, allora l'attacco non si applica più. Pertanto, alcuni hanno suggerito di utilizzare numeri seriali casuali come attenuazione.

Ulteriori dettagli. consulta il seguente documento di ricerca per ulteriori dettagli:

Short Collected Prefix Collisions per MD5 e la creazione di un certificato CA canaglia , Marc Stevens e Alexander Sotirov e Jacob Appelbaum e Arjen Lenstra e David Molnar e Dag Arne Osvik e Benne de Weger, CRYPTO 2009. Sito web: link

Raccomandazione. La migliore difesa è: non usare MD5! Smetti di usarlo. Le CA dovrebbero usare un hash moderno come SHA1 o SHA256 o SHA2. Non dovrebbero mai usare MD5 quando emettono certificati.

Ma se per qualche ragione sei costretto ad usare MD5, randomizzare i tuoi numeri seriali è una ragionevole attenuazione. In realtà, l'uso di un numero seriale casuale potrebbe non essere una cattiva idea, indipendentemente dall'algoritmo di hash che usi, come una forma di difesa della profondità delle sospensioni a cinghia e bretelle.