Comprender la seguridad de un esquema de clave pública federada usando WebCrypto

Navega tus respuestas
2

Estoy proponiendo este esquema para la autenticación federada y WebCrypto. No estoy seguro de si existe algo como esto (o mejor), envíenme material relacionado.

Entidades

  1. Navegador de Alicia, NAVEGADOR
  2. servidor de Bob, BOB
  3. servidor de Alicia, ALICE

Fondo

Las identidades son nombres de dominio y cada servidor tiene una lista de control de acceso en cada recurso.

  • Bob escribe en el archivo de control de acceso "alice.com" que puede leer "/ foo"
  • Alice quiere leer foo

Protocolo

tl; versión de dr:

  • El Navegador de Alicia intenta acceder a un recurso en el servidor de Bob, Bob responde con un mensaje no autorizado y un nonce
  • Alice genera una clave en su navegador con webcrypto y la guarda en la memoria
  • Alice carga su clave en su sitio web
  • Alice firma el nonce, la dirección del servidor bob y la dirección de su clave
  • Bob recibe el mensaje y comprueba si la ubicación que alicia mencionó tiene la clave pública que verifica la firma

Diagrama 

1. Alice's Browser tries to access a resource on Bob's server

BROWSER   -------------- GET /foo ---------------------->  BOB
BROWSER   <------------- RESPONSE 401 {nonce} -----------  BOB

2. BROWSER uses WebCrypto to generate Pub/Priv key pair

3. Alice's post her new key on her server

BROWSER   -------------- POST /keys/nonce -------------->  ALICE
                         { Pub }
BROWSER   <------------- RESPONSE 200 -------------------  ALICE

4. Alice's Browser signs the location of the key, the nonce and
   the Bob's Server origin

BROWSER   -------------- POST /foo --------------------->  BOB
                         Sign(location, nonce, bob)

5. Bob's server gets the advertised location

          BOB -------------- GET /keys/nonce --------------->  ALICE
          BOB <------------- RESPONSE {Pub} -----------------  ALICE

6. Bob's server verifies the signature

BROWSER   <------------- RESPONSE 200 -------------------  BOB
                         {set cookie}

Preguntas

  • ¿Hay algún escollo que no esté viendo?
  • ¿Puede ocurrir algún ataque en el punto # 4 del diagrama?
  • ¿Existe este esquema o tiene un nombre?
pregunta nick 06.05.2016 - 20:09
fuente

1 respuesta

1

Lo que estás describiendo es muy similar a PoP / RFC7800 (semántica de clave de prueba de posibilidad para los tokens web de JSON ). (También es algo similar a lo que AC / DC (Código de Autorización Entre Dominios) está tratando de hacer).

Con PoP, los pasos propuestos 1 y amp; 2 son iguales: BOB (llamado Destinatario) emite un nonce con la respuesta 401, el Navegador (llamado Presentador) genera un par de claves públicas / privadas para enviar al servidor ALICE (llamado Emisor). El paso 3 también es muy similar: el navegador / presentador envía la solicitud con la clave pública a ALICE / Emisor.

El PoP y su protocolo propuesto divergen ligeramente después del Paso 3, mientras que está almacenando la clave pública + nonce firmado en el servidor de ALICE, en PoP, ALICE / Emisor simplemente firma la clave pública y devuelve En la respuesta (en un JWT). El Navegador / Presentador luego reenvía el JWT del Emisor, agregando el nonce (que se firma con su clave privada), al Destinatario.

El Receptor puede verificar varias cosas: a) que el Navegador / Presentador es el que recibió el nonce inicial (esto evita el secuestro de token del cliente), yb) que el Navegador / Presentador realmente posee el JWT firmado por el Emisor .

  

¿Hay algún error que no esté viendo?

Tanto tu propuesta como PoP cumplen lo siguiente:

  1. Protegen contra el secuestro de tokens del cliente al verificar que el navegador / presentador es el mismo que recibió el nonce en la respuesta 401 original no autorizada.
  2. Verifican que el navegador / presentador se autenticó correctamente con el Emisor: con su propuesta, porque el Emisor permitió que el POST fuera /keys/nonce , y con PoP, porque el Emisor devolvió un JWT, firmado por sí mismo, que incluía la clave pública del navegador.

Lo que su propuesta no aborda es el siguiente problema importante:

Dado que estás hablando de una aplicación en el navegador (el Navegador / Presentador), ¿cómo se autentica esa aplicación con ALICE / Emisor? Es decir, dado que el Emisor acepta un POST para /keys/nonce , probablemente ha verificado el cliente y ha autenticado al usuario. ¿Pero cómo? OAuth2 y OpenID Connect (con los cuales PoP está diseñado para funcionar) tienen mecanismos muy específicos para autenticar las aplicaciones cliente públicas (en el navegador) para el Emisor, con protección de redireccionamiento, etc., porque no es una tarea fácil y es propenso a muchas cosas. De agujeros de seguridad. Es probable que esté intentando usar algún tipo de mecanismo de cookies, pero si la aplicación / el presentador del lado del navegador se ejecuta desde un origen diferente al del Emisor, ¿cómo lo va a autenticar el emisor?

Esto es relevante para aplicaciones en el navegador, pero también es especialmente relevante para aplicaciones nativas, aplicaciones móviles o aplicaciones web tradicionales del lado del servidor. ¿Cómo intenta el esquema propuesto abordar la autenticación con esos?

  

¿Puede ocurrir algún ataque en el punto 4 del diagrama?

No puedo ver, aunque ni siquiera tiene que hacer un POST aquí, puede hacer un GET simple e incluir la parte Sign(location, nonce, bob) en el encabezado Authorization: , estilo de token de portador.

    
respondido por el Dmitri Zagidulin 16.06.2016 - 20:53
fuente

Lea otras preguntas en las etiquetas

¿Debo solicitar un CVE para errores en el software de cálculo de números? Valor del hash en la firma digital