Derivación de claves de envío y recepción de MPPE de MS-CHAPv2

Question

Derivación de claves de envío y recepción de MPPE de MS-CHAPv2

#1 de robert (1 votos)

14

Estoy intentando obtener la clave de envío MS-MPPE y la clave de recuperación MS-MPPE del material de desafío MS-CHAPv2. Puedo seguir las RFC 2548 3078 y 3079 al paso de obtener el GetNewKeyFromSHA() que es 16 bytes de largo.

Puedo usar la clave para cifrar datos como el ejemplo en 3079 . El problema es que no estoy seguro de qué debo hacer para obtener las claves de sesión utilizadas en el RFC 2548 para obtener MS-MPPE-Send-key y MS-MPPE-Recv-key desde allí.

Tengo un ejemplo de freeradius y la clave de sesión se convierte de 16 bytes a 32 bytes mucho antes de la construcción de la cadena indicada en RFC 2548 .

He intentado cifrar con RC4 las claves de sesión después de GetNewKeyFromSHA() pero no me funciona. Si alguien pudiera explicar un poco en detalle este paso intermedio, ¡estaría bien!

Editar 1

También he intentado realizar el cifrado en 2548 pero aún no he obtenido resultados, ahora estoy investigando El código fuente de freeRADIUS, pero no es fácil de seguir después de obtener la clave maestra del material de MS-CHAPv2. ¿Alguna idea?

Editar 2

Mirando en freeradius parece ser que, en primer lugar, deriva las claves del material de MS-CHAv2, pero luego, en lugar de encriptarlas, las usa, utiliza el secreto maestro y los números aleatorios del protocolo de enlace TLS para producir el envío de 32 bytes. y recibir claves. Esto es como RFC 2716 , luego las cifra como RFC 2548 y finalmente los envía.

Por lo tanto, es posible usar la clave maestra derivada del material de MS-CHAPv2 como en el RFC 3079 ? o la única forma de hacerlo es como lo hace freeradius?

authentication encryption windows key-generation radius

pregunta Jaime 10.05.2013 - 09:17

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication encryption windows key-generation radius

Lista blanca de elementos DOM para derrotar a XSS ¿Por qué nos autenticamos solicitando a un usuario que ingrese el nombre de usuario y la contraseña? ¿Es suficiente pedir la contraseña?

score 1 · Answer 1

No estoy seguro de tu pregunta, ¿es cómo se cifran estos valores? Se describe en RFC-2548 sección 2.4.2 .

La razón por la que creo que esta es tu pregunta:

Tengo un ejemplo de freeradius y la clave de sesión se convierte de 16 bytes de largo a 32 bytes de largo antes de la construcción de la cadena indicado en RFC 2548.

¿Entonces se pregunta cómo pasa de su clave de 16 bytes al valor de 32 bytes utilizado en el atributo RADIUS?

Básicamente, su clave de 32 bytes es 2 hashes MD5 de su clave de 16 bytes. El valor debe ser un múltiplo de 16 por este motivo. La razón por la que tiene 32, en lugar de 16 es que antepone un valor de un solo byte 16 (para clave-longitud) sobre el valor clave que hace la longitud 17 y por lo tanto lo empuja en una segunda ventana de 16 bytes. Los 15 bytes restantes deben estar 0-rellenados.

De todos modos, de todos modos, está cifrando su valor clave de 17 bytes utilizando el secreto compartido de RADIUS, el Request Authenticator de 16 bytes de la solicitud RADIUS original y una sal aleatoria de 2 bytes. valor.

El valor de sal aleatorio puede ser literalmente cualquier cosa. Como ha notado, freeradius deriva esto de una función TLS, pero eso solo es adecuado cuando se está haciendo un túnel sobre TLS realmente. Solo puedes sacar algo del aire.

Luego, añade un valor de sal de dos bytes a su valor encriptado de 32 bytes, para obtener un valor de 34 bytes, ¡y listo!

     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).