MPPE: invio e ricezione derivazione chiave da MS-CHAPv2

Question

MPPE: invio e ricezione derivazione chiave da MS-CHAPv2

#1 da (1 voti)

14

Sto cercando di ottenere la chiave di invio MS-MPPE e la chiave MS-MPPE-Recv dal materiale di sfida MS-CHAPv2. Sono in grado di seguire gli RFC 2548 3078 e 3079 al passaggio di ottenere GetNewKeyFromSHA() è 16 byte.

Posso utilizzare la chiave per crittografare i dati come nell'esempio in 3079 . Il problema è che non sono sicuro di cosa dovrei fare per ottenere le chiavi di sessione utilizzate nell'RFC 2548 per ottenere Campi MS-MPPE-Send-key e MS-MPPE-Recv-key da lì.

Ho un esempio di freeradius e la chiave di sessione viene convertita da 16 byte lunghi a 32 byte molto prima della costruzione della stringa dichiarata in RFC 2548 .

Ho provato a cifrare con RC4 le chiavi di sessione dopo GetNewKeyFromSHA() ma non funziona per me. Se qualcuno potesse spiegare un po 'in dettaglio questo passaggio intermedio sarebbe bello!

Modifica 1

Ho anche provato a fare la crittografia in 2548 due volte, ma ancora nessun risultato, sto ora scavando il codice sorgente freeRADIUS ma non è facile da seguire dopo aver ottenuto la chiave master dal materiale MS-CHAPv2. Qualche idea?

Modifica 2

Guardando al freeradius sembra essere che per prima cosa ricava le chiavi dal materiale MS-CHAv2 ma poi invece di criptarle e inviarle, usa il master secret ei numeri casuali dall'handshake TLS per produrre i 32 byte Invia e ricevi le chiavi. Questo è come dice RFC 2716 , quindi li crittografa come RFC 2548 e infine li invia.

Quindi è possibile utilizzare la chiave master derivata dal materiale MS-CHAPv2 come nella RFC 3079 ? o l'unico modo per farlo è come fa il freeradius?

windows authentication encryption key-generation radius

posta Jaime 10.05.2013 - 09:17

fonte

1 risposta

Leggi altre domande sui tag windows authentication encryption key-generation radius

Whitelisting elementi DOM per sconfiggere XSS Perché ci autenticiamo chiedendo a un utente di inserire sia nome utente che password? La richiesta di password è sufficiente?

score 1 · Answer 1

Non sei sicuro della tua domanda, è come questi valori sono criptati? È descritto in RFC-2548 sezione 2.4.2 .

Il motivo per cui penso sia questo nella tua domanda:

I have an example of freeradius and the session key is converted from 16 bytes long to 32 bytes long before the construction of the string stated in RFC 2548.

quindi ti stai chiedendo come passare dalla tua chiave da 16 byte al valore a 32-byte utilizzato nell'attributo RADIUS?

Fondamentalmente la tua chiave da 32 byte è 2 hash MD5 catenati della tua chiave da 16 byte. Il valore deve essere un multiplo di 16 per questo motivo. Il motivo per cui si ha 32, anziché 16 è che si antepone un valore a byte singolo 16 (per lunghezza chiave) sul valore chiave che rende la lunghezza 17 e quindi la spinge in una seconda finestra da 16 byte. I restanti 15 byte dovrebbero essere riempiti di 0.

Ad ogni modo stai cifrando il tuo valore-chiave ora a 17-byte utilizzando il segreto condiviso RADIUS, l' Autenticatore richiesta a 16 byte dalla richiesta RADIUS originale e un sale casuale da 2 byte valore.

Il valore salt random può essere letteralmente qualsiasi cosa. Come hai notato, il freeradius deriva da una funzione TLS, ma è adatto solo per il tunneling su TLS. Puoi semplicemente tirare fuori qualcosa.

Quindi anteponi il valore salt di due byte al valore crittografato a 32 byte, per creare un valore a 34 byte e il gioco è fatto!

     Construct a plaintext version of the String field by concate-
     nating the Key-Length and Key sub-fields.  If necessary, pad
     the resulting string until its length (in octets) is an even
     multiple of 16.  It is recommended that zero octets (0x00) be
     used for padding.  Call this plaintext P.

     Call the shared secret S, the pseudo-random 128-bit Request
     Authenticator (from the corresponding Access-Request packet) R,
     and the contents of the Salt field A.  Break P into 16 octet
     chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
     ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
     Intermediate values b(1), b(2)...c(i) are required.  Encryption
     is performed in the following manner ('+' indicates
     concatenation):

  b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
  b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
              .                      .
              .                      .
              .                      .
  b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

  The   resulting   encrypted   String   field    will    contain
  c(1)+c(2)+...+c(i).