2016-02-12 16 views
10

Si noti che questa non è mia domanda, è un'applicazione che sto pentestando per un cliente. Solitamente faccio domande come questa su https://security.stackexchange.com/, tuttavia in quanto questo è più legato alla programmazione che ho chiesto qui.UuidCreate utilizza un CSPRNG?

Concesso, RFC 4122 per UUIDs non specifica che UUID di tipo 4 devono essere generati da un generatore di numeri Pseudo Casuali (CSPRNG) crittograficamente sicuro. Dice semplicemente

Imposta tutti gli altri bit in modo casuale (o pseudo-casuale) con valori scelti.

Sebbene alcune implementazioni dell'algoritmo, ad esempio this one in Java, utilizzino un CSPRNG.

Stavo cercando di capire se l'implementazione di Microsoft funziona o no. Principalmente su come .NET o MSSQL Server li genera.

Controllo della .NET source possiamo vedere questo codice:

Marshal.ThrowExceptionForHR(Win32Native.CoCreateGuid(out guid), new IntPtr(-1)); 
return guid; 

Controllo del CoCreateGuid Docco, afferma

La funzione CoCreateGuid chiama la funzione RPC UuidCreate

Tutto quello che posso scoprire su questa funzione è here. Mi sembra di aver raggiunto la fine della tana del coniglio.

Ora, qualcuno ha qualche informazione su come UuidCreate genera i suoi UUID?

Ho visto molti Related posts:

Il primo dei quali dice:

Un GUID non fornisce garanzie sulla casualità, garantisce le garanzie in relazione all'unicità. Se vuoi casualità, usa Random per generare una stringa .

sono d'accordo con questo, tranne nel mio caso per casuali, numeri imprevedibili che ci naturalmente utilizza un CSPRNG invece di Random (ad esempio RNGCryptoServiceProvider).

E quest'ultima afferma (effettivamente citato da Wikipedia):

Cryptanalysis del generatore WinAPI GUID mostra che, poiché la sequenza di V4 GUID è pseudo-casuale; dato piena conoscenza dello stato interno , è possibile prevedere precedenti e successive valori

Ora, dall'altra parte della barricata this post di Will Dean dice

L'ultima volta che ho guardato in questo (alcuni anni fa, probabilmente XP SP2), I è passato direttamente al codice del sistema operativo per vedere cosa stava effettivamente accadendo e stava generando un numero casuale con il generatore di numeri casuali sicuro .

Naturalmente, anche se al momento stava usando un CSPRNG questo sarebbe specifico di implementazione e soggetto a modifiche in qualsiasi momento (ad esempio qualsiasi aggiornamento a Windows). Improbabile, ma teoricamente possibile.

Il mio punto è che non c'è alcun riferimento canonico per questo, quanto sopra è stato per dimostrare che ho svolto la mia ricerca e nessuno dei post sopra menzionati fa riferimento a qualcosa di autorevole.

Il motivo è che sto cercando di decidere se un sistema che utilizza GUID per i token di autenticazione deve essere modificato. Dal punto di vista del design puro, la risposta è un numero definito , tuttavia da un punto di vista pratico, se la funzione Windows UuidCreate utilizza infatti un CSPRNG, non c'è alcun rischio immediato per il sistema. Qualcuno può far luce su questo?

Sto cercando tutte le risposte con una fonte attendibile per il backup.

+0

Domanda bizzarra. Supponiamo che qualcuno dica "sì".Stai andando alla base della sicurezza del tuo sistema su ciò che ti dice un estraneo su Internet? Chiama Microsoft. –

+1

No, sto chiedendo qualche prova in un modo o nell'altro. per esempio. [vedi il mio commento qui] (http://stackoverflow.com/questions/816882/how-to-predict-the-next-guid-from-a-given-guid/817150#comment58381222_817150). – SilverlightFox

+0

Ottieni Windbg ed entra nella chiamata e guarda cosa fa. Quindi per almeno un SO ad un certo punto nel tempo lo saprai. Guid non sarà ancora adatto a quello che stai usando, ma avrai almeno scalfito questo prurito. –

risposta

10

Anche se io sono ancora solo una persona su Internet, ho appena ripetuto l'esercizio di entrare in UuidCreate, in un'applicazione a 32 bit in esecuzione su una versione a 64 bit di Windows 10.

Ecco un po 'di pila da parte modo attraverso il processo:

> 0018f670 7419b886 bcryptPrimitives!SymCryptAesExpandKeyInternal+0x7f 
> 0018f884 7419b803 bcryptPrimitives!SymCryptRngAesGenerateSmall+0x68 
> 0018f89c 7419ac08 bcryptPrimitives!SymCryptRngAesGenerate+0x3b 
> 0018f8fc 7419aaae bcryptPrimitives!AesRNGState_generate+0x132 
> 0018f92c 748346f1 bcryptPrimitives!ProcessPrng+0x4e 
> 0018f93c 748346a1 RPCRT4!GenerateRandomNumber+0x11 
> 0018f950 00dd127a RPCRT4!UuidCreate+0x11 

E' abbastanza chiaro che si tratta di utilizzare un RNG AES-based per generare i numeri. I GUID generati chiamando le funzioni di generazione GUID di altre persone non sono ancora adatti per essere utilizzati come token di autenticazione non guidabili, perché non è questo lo scopo della funzione di generazione GUID: si sta semplicemente sfruttando un effetto collaterale.

Il tuo "improbabile, ma teoricamente possibile". cambiamenti nella realizzazione tra le versioni del sistema operativo è invece smentito da questa dichiarazione nella documentazione per "UuidCreate":

Se non avete bisogno di questo livello di sicurezza, l'applicazione può utilizzare la funzione di UuidCreateSequential, che si comporta esattamente come fa la funzione UuidCreate su tutte le altre versioni del sistema operativo.

cioè, era più prevedibile, ora è meno prevedibile.