WebAuthn pubKeyCredParams y credentialPublicKey: CBOR y COSE

En la seguridad digital, las passkeys son el nuevo estándar sin contraseñas. En el núcleo de las passkeys se encuentra la criptografía de clave pública, utilizada dentro del protocolo WebAuthn en el que se basan. Entender cómo se utiliza la criptografía de clave pública en WebAuthn, especialmente en la creación, extracción, gestión y almacenamiento de passkeys, es crucial al diseñar o usar la [autenticación con passkeys]. La clave pública se almacena en el servidor del [relying party] (RP), que es el backend del sitio web que quiere autenticar a un usuario mediante passkeys, y la clave privada se almacena de forma segura en un Módulo de Seguridad de Hardware dependiendo del sistema operativo: [Secure Enclave] ([iOS]), TEE ([Android]) o un [TPM] (Windows).

En esta publicación de blog, repasaremos rápidamente los conceptos básicos de la criptografía de clave pública utilizada en las passkeys. Al final de esta publicación, habremos respondido a las siguientes preguntas:

• Qué algoritmos de cifrado son compatibles con WebAuthn
• Cómo funciona pubKeyCredParams al crear un par de claves
• Cómo funciona credentialPublicKey al extraer las claves públicas creadas

Para entender cómo funciona la criptografía de clave pública dentro de WebAuthn, echaremos un vistazo rápido a cómo funciona en general y cuáles son los tipos de algoritmos más comunes.

La criptografía de clave pública, también conocida como criptografía asimétrica, se diferencia de la criptografía simétrica, donde se utiliza la misma clave tanto para el cifrado como para el descifrado. La criptografía asimétrica emplea dos claves distintas: una clave pública, que se puede compartir abiertamente, y una clave privada, que el propietario mantiene en secreto.

Tomado de: https://en.wikipedia.org/wiki/Public-key_cryptography

Este método no solo permite el cifrado de datos para asegurar su confidencialidad, sino que también permite firmar mensajes. La firma verifica la identidad del remitente y asegura que el mensaje no ha sido alterado, confirmando así su autenticidad e integridad.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Aquí presentamos un resumen de algunos tipos comunes de algoritmos utilizados en la [criptografía de clave pública]:

La base matemática de la criptografía de curva elíptica (ECC), que incluye ECDSA y EdDSA, involucra las propiedades de las curvas elípticas, que no cubriremos en este artículo. Pero es evidente por la tabla anterior que existen ventajas que impulsan su adopción. Repasaremos las más importantes en la siguiente sección.

Become part of our Passkeys Community for updates & support.

Join

La criptografía de curva elíptica ha sido ampliamente adoptada en dispositivos móviles, ya que se benefician de los tamaños de clave más pequeños, lo que aporta las siguientes ventajas:

• Requisitos de almacenamiento reducidos: Las claves más pequeñas de ECC requieren menos espacio de almacenamiento en comparación con los métodos criptográficos tradicionales como RSA. Esto es especialmente beneficioso para dispositivos con recursos de memoria limitados, permitiendo un uso más eficiente del espacio. La siguiente tabla muestra una aproximación de los niveles de seguridad comparables y los tamaños reales de las claves utilizadas. El nivel de seguridad se mide en bits y generalmente corresponde a un cifrado de clave simétrica de ese tamaño:

El término nivel de seguridad en este contexto se refiere a la fortaleza del sistema criptográfico, específicamente al nivel de dificultad para que un atacante supere las medidas de seguridad. Generalmente se mide en bits y representa la cantidad de trabajo (el número de operaciones) que se requeriría para romper el cifrado o falsificar una firma. Con el aumento del nivel de seguridad, las ventajas de tamaño se vuelven evidentes, llegando a relaciones de tamaño de clave de hasta 1:30.

• Rendimiento mejorado: Las claves más pequeñas permiten operaciones criptográficas más rápidas, lo cual es crucial para dispositivos con menor potencia de procesamiento. Esto se traduce en actividades de cifrado y descifrado más rápidas, mejorando el rendimiento general y la capacidad de respuesta de las aplicaciones móviles. Dependiendo del tipo de benchmarks, las mejoras de velocidad varían entre 10 y 40 veces en la ejecución. Aquí hay un ejemplo de datos de benchmark que [AWS] realizó al implementar ECDSA para Cloudfront en 2018:

• Eficiencia de batería mejorada: Con un procesamiento más eficiente gracias a las claves más pequeñas, las operaciones ECC pueden consumir menos energía. Esta conservación de [energía] es vital para los dispositivos móviles, donde preservar la vida de la batería es un desafío constante.

Estos factores hacen que ECC sea particularmente adecuado para entornos móviles, donde la optimización del almacenamiento, la velocidad de procesamiento y el consumo de energía es esencial. Como resultado, ECC es cada vez más preferido en la computación móvil por su capacidad para proporcionar una seguridad robusta sin comprometer el rendimiento del dispositivo. Sin embargo, hasta hoy existen muchas versiones antiguas de protocolos extendidos como TLS (utilizado para HTTPS, FTPS o SMTPS), SSH o IPsec que todavía soportan RSA pero han comenzado a ofrecer variantes basadas en ECC a los clientes que las soportan.

El estándar WebAuthn no es un estándar de cifrado, sino un protocolo de seguridad que proporciona una autenticación fuerte basada en clave pública para aplicaciones web, permitiendo a los usuarios iniciar sesión usando datos biométricos, dispositivos móviles o [llaves de seguridad de hardware] (por ejemplo, [YubiKeys]) en lugar de contraseñas. Por lo tanto, WebAuthn es intencionadamente agnóstico sobre qué criptografía subyacente basada en clave pública se utiliza realmente. Veamos cómo se logra esto.

El protocolo de seguridad WebAuthn facilita la autenticación criptográficamente segura entre el Usuario y el [Relying Party]. En términos técnicos, esto significa que el [Relying Party] (un sitio web que quiere usar passkeys con sus usuarios) necesita intercambiar claves a través del navegador con el usuario y su [autenticador], que luego almacena la clave privada en el módulo de seguridad de hardware (HSM) específico.

Para el registro de passkeys, hay tres pasos importantes:

• (1) El [Relying Party] señala los algoritmos de cifrado compatibles: El [relying party] señala los algoritmos de cifrado compatibles a través de PublicKeyCredentialCreationOptions.pubKeyCredParams junto con las otras PublicKeyCredentialCreationOptions.
• (2) El [autenticador] del usuario crea el par de claves: El [autenticador] comprueba la lista pubKeyCredParams en busca de algoritmos de cifrado que soporte y crea un par de claves junto con un [Credential ID] único. Almacena la clave privada dentro del HSM y luego devuelve la clave pública y el algoritmo de cifrado utilizado al navegador. Luego, el navegador envía una solicitud POST al backend del Relying Party con el attestationObject en la sección “authData”. En caso de que no haya coincidencia de los algoritmos de cifrado compatibles, la ceremonia de creación fallará.
• (3) El Relying Party extrae la clave pública y la almacena: El relying party recibe el attestationObject del navegador. Analiza la sección authData.credentialPublicKey y extrae la clave pública. Junto con la clave pública, también se envía información sobre el algoritmo de cifrado utilizado y el [Credential ID] al relying party.

Para inicios de sesión / autenticaciones posteriores con passkeys, son necesarios los siguientes pasos (detalles simplificados):

• (1) El Relying Party presenta un desafío: El relying party genera un desafío aleatorio y lo proporciona al [autenticador] para su firma.
• (2) El [autenticador] del usuario firma el desafío: El autenticador firma el desafío con la clave que coincide con la solicitud de autenticación y lo devuelve con el [Credential ID] al Relying Party.
• (3) El Relying Party valida la firma: El Relying Party recibe la información y busca la clave pública asociada con el Credential ID utilizado. Luego, valida criptográficamente la firma utilizando el algoritmo de cifrado/firma acordado durante el registro de las passkeys.

Al observar ambos casos, podemos ver que solo para el registro de passkeys se transporta información sobre la clave pública y el algoritmo de cifrado entre los actores.

Para eventos posteriores de inicio de sesión / autenticación con passkeys, solo el desafío y la firma forman parte de los datos transmitidos.

El estándar WebAuthn utiliza los IANA COSE Algorithm IDs para identificar los algoritmos de cifrado utilizados. Los COSE Algorithm IDs se utilizan tanto para señalar los algoritmos compatibles en pubKeyCredParams como para transmitir el tipo de par de claves realmente creado en credentialPublicKey. Nos centraremos en su implementación en las próximas dos secciones.

La lista de algoritmos COSE de IANA incluye más de 75 algoritmos que teóricamente podrían usarse con el estándar WebAuthn. La mayoría de los algoritmos con ID negativo son de clave pública asimétrica y la mayoría de los positivos son simétricos, pero esto es más una convención, ya que hay excepciones.

Como hemos señalado antes, el algoritmo de cifrado debe ser compatible con el autenticador y el backend del Relying Party para poder ser utilizado en la ceremonia de WebAuthn. Como la mayoría de los relying parties utilizan bibliotecas de WebAuthn existentes que tienen acceso a una amplia gama de algoritmos de cifrado, es más importante observar qué algoritmos son compatibles con qué [autenticadores]:

(*) = Una pequeña parte de las llaves de seguridad (p. ej., [Yubikeys] 5+, Solokey o Nitrokey) Extracto de la tabla de IANA: Ver lista completa aquí

Como se puede ver en esta tabla, para dar soporte a todos los [autenticadores] importantes, RS256 y ES256 son suficientes. Hay partes de la comunidad que recomiendan integrar también EdDSA para mejorar aún más la seguridad. Por otro lado, los Credential IDs que también deben almacenarse parecen ser significativamente más largos para las claves EdDSA. A día de hoy, el borrador del editor del W3C sobre el próximo estándar WebAuthn de nivel 3 sugiere los tres algoritmos.

La configuración de los algoritmos de cifrado compatibles para la [creación de passkeys] se realiza a través de las PublicKeyCredentialCreationOptions:

const publicKeyCredentialCreationOptions = {
    challenge: "*",
    rp: {
        name: "Corbado",
        id: "corbado.com",
    },
    user: {
        id: "user-X",
        name: "user@corbado.com",
        displayName: "Corbado Name",
    },
    pubKeyCredParams: [
        {
            alg: -8,
            type: "public-key",
        },
        {
            alg: -7,
            type: "public-key",
        },
        {
            alg: -257,
            type: "public-key",
        },
    ],
    authenticatorSelection: {
        authenticatorAttachment: "platform",
        requireResidentKey: true,
    },
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions,
});

El ejemplo muestra cómo se especifican los algoritmos dentro de pubKeyCredParams mediante alg para el ID y añadiendo public-key como tipo de algoritmo. En la línea 29/30, las [PublicKeyCredentialCreationOptions] se pasan al autenticador a través de la API de WebAuthn del navegador. Eliminar el soporte para ES256 o RS256 producirá errores y no se recomienda en absoluto.

Como ejemplo funcional, ejecutaremos las siguientes PublicKeyCredentialCreationOptions en un Mac en el Passkeys Debugger.

{
    "rp": {
        "id": "www.passkeys-debugger.io",
        "name": "Relying Party Name"
    },
    "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -8
        },
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "excludeCredentials": [],
    "timeout": 120000,
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required",
        "authenticatorAttachment": "platform"
    },
    "hints": [],
    "attestation": "direct",
    "user": {
        "name": "User-2024-08-19",
        "displayName": "User-2024-08-19",
        "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk"
    }
}

La respuesta producida por el autenticador se envía al relying party (como [atestación]) y tiene el siguiente aspecto:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
        "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

En la siguiente sección, veremos cómo se pueden extraer las claves públicas y el algoritmo de cifrado utilizado de la respuesta.

Primero, necesitamos examinar cómo se construye realmente el attestationObject, porque como vemos arriba, no se transporta en JSON al Relying Party.

El attestationObject juega un papel importante en el proceso de registro de WebAuthn, sirviendo como un contenedor para la [declaración de atestación] proporcionada por el autenticador. Este objeto proporciona mucha información necesaria para que el Relying Party (RP) verifique el origen y la integridad de la credencial de clave pública recién creada.

En su núcleo, el attestationObject es una estructura compleja. Está mayormente codificado en formato [CBOR] (Concise Binary Object Representation), que luego se codifica con Base64URL. Encapsula los datos del autenticador junto con una declaración de [atestación] que verifica la autenticidad de la información. Como las passkeys se crean con [atestación] “none” y, por lo tanto, no llevan una declaración de [atestación], no cubriremos esto en este artículo. Como nota al margen: escribimos mayormente [CBOR] porque también hay prefijos no estándar de [CBOR] involucrados debido a las longitudes variables que se necesitan para las extensiones opcionales. No profundizaremos en eso, se puede encontrar una discusión sobre las complejidades aquí.

Tomado de la especificación de WebAuthn

Dentro de los datos del autenticador (authData), la clave pública recién generada, junto con el ID de credencial del usuario, se almacenan de forma segura y pueden ser recuperados por el relying party. Como los desarrolladores deben abordar la tarea de extraer la clave pública del attestationObject en cualquier sistema basado en WebAuthn, es importante entender su arquitectura.

[CBOR] (Concise Binary Object Representation) es un formato de datos diseñado para codificar datos de una manera compacta, eficiente y extensible. Es binario, lo que lo hace más pequeño y rápido de analizar que su modelo de referencia basado en texto, JSON. El siguiente ejemplo ilustra cómo JSON y [CBOR] son diferentes (Texto vs. Binario):

Negrita es Name. Cursiva es Corbado. (se puede encontrar más información en https://cbor.io/)

En el contexto de WebAuthn, CBOR se utiliza por varias razones:

• Vínculo con [FIDO2] / CTAP: Como CBOR se utiliza en los estándares subyacentes, se logra una optimización del análisis y procesamiento de datos, ya que tanto WebAuthn como CTAP utilizan el mismo esquema de codificación compacto.
• Compacidad: La codificación eficiente de CBOR lo convierte en una excelente opción para el tráfico web donde minimizar el tamaño de los datos puede impactar significativamente en el rendimiento, especialmente en redes móviles o en entornos donde el ancho de banda es una limitación.
• Flexibilidad: CBOR admite una variedad de tipos de datos y estructuras, incluyendo arrays, mapas, cadenas de texto, cadenas de bytes y etiquetas para extensibilidad. Esto lo hace lo suficientemente versátil como para manejar los diferentes tipos de datos y estructuras complejas necesarias para las operaciones de WebAuthn.
• Extensibilidad: El formato está diseñado para ser extensible, lo que significa que se pueden agregar nuevas características a WebAuthn sin romper la compatibilidad con las implementaciones existentes.

El uso de CBOR es especialmente adecuado para codificar las claves públicas y el attestationObject porque necesita manejar los diferentes formatos y longitudes que discutimos anteriormente. Por ejemplo, una clave RSA tendría diferentes atributos y tamaños en comparación con una clave ECDSA. Dentro del attestationObject, las claves públicas se almacenan en formato COSE Key, que se basa en CBOR.

Una estructura de clave COSE se basa en un objeto de mapa CBOR. Define una forma estructurada para la representación de claves, abarcando varios tipos de claves y sus parámetros correspondientes, como el módulo y el exponente de RSA, o las coordenadas de la clave pública de curva elíptica. Este formato estandarizado permite que las claves se serialicen y deserialicen de manera consistente, independientemente de su algoritmo criptográfico subyacente, además del ID del algoritmo de cifrado que hemos discutido anteriormente.

Al aprovechar CBOR y el formato de clave COSE, WebAuthn puede facilitar una amplia gama de operaciones criptográficas mientras se asegura de que la carga útil permanezca lo más pequeña posible, y se mantenga adaptable para futuras actualizaciones en la tecnología criptográfica. Esta elección se alinea con los objetivos de WebAuthn de proporcionar un protocolo seguro, eficiente y compatible con el futuro para la autenticación web.

Cuando se trata de decodificar el attestationObject dentro de WebAuthn, los desarrolladores se enfrentan a una decisión importante: desarrollar una solución personalizada o aprovechar una biblioteca establecida. La complejidad y la naturaleza crítica de este proceso no pueden subestimarse. La implementación manual de la decodificación de Base64URL y CBOR, aunque técnicamente factible, introduce el riesgo de errores sutiles que pueden comprometer la integridad del proceso de autenticación.

Para garantizar la verificación criptográfica de la firma, así como la precisión de todos los demás pasos de validación, se recomienda encarecidamente utilizar una biblioteca de WebAuthn bien probada y ampliamente adoptada. Dichas bibliotecas están construidas con experiencia en cifrado para manejar los detalles de la decodificación y validación del attestationObject, incluyendo:

• Analizar el formato CBOR correctamente para extraer la declaración de [atestación] y los datos del autenticador.
• Interpretar el formato de clave COSE para recuperar la clave pública.
• Realizar comprobaciones criptográficas para validar la firma de acuerdo con el estándar WebAuthn.

Al confiar en una biblioteca de buena reputación, los desarrolladores no solo ahorran tiempo y recursos, sino que también ganan tranquilidad. La clave pública, una vez extraída y verificada a través de estas herramientas fiables, puede ser [almacenada de forma segura en la base de datos], lista para ser utilizada en sesiones de autenticación seguras. Este enfoque garantiza la adhesión a las especificaciones del protocolo y mantiene la postura de seguridad esperada en las implementaciones de WebAuthn. Para simplificar, usaremos el SimpleWebauthn Debugger que devuelve una versión completamente decodificada con los campos CBOR convertidos en JSON expandido:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": {
            "fmt": "packed",
            "attStmt": {
                "alg": "ES256 (-7)",
                "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs"
            },
            "authData": {
                "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": false,
                    "backupStatus": false,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503",
                "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
                "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
                    "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
            "origin": "https://opotonniee.github.io",
            "crossOrigin": false
        },
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

La biblioteca SimpleWebAuthn se utiliza para decodificar el attestationObject completo. Como podemos ver, toda la información es ahora legible. Toda la información criptográfica forma parte de credentialPublicKey, que es parte de authData, que la biblioteca ha expandido en la declaración parsedCredentialPublicKey. En la especificación, hay varios ejemplos de cómo se ve el formato de clave COSE.

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

Esta salida muestra todos los elementos criptográficos del credentialPublicKey perfectamente analizados en forma legible para humanos. Esta instancia en particular revela una clave EC2 para el algoritmo ES256, como lo indica el parámetro del algoritmo y la presencia de las coordenadas x e y.

En contraste, la salida de un sistema Windows 10 se ve así:

{
    "parsedCredentialPublicKey": {
        "keyType": "RSA (3)",
        "algorithm": "RS256 (-257)",
        "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ",
        "exponent": 65537
    }
}

Aquí, el ID del algoritmo es -257, correspondiente a RS256, y podemos discernir que los atributos que caracterizan esta clave pública difieren significativamente de los de una clave ECDSA. El formato de clave COSE permite especificar atributos únicos por tipo:

Además, el módulo RSA es sustancialmente más largo que las coordenadas de la curva elíptica utilizadas en la clave ES256, lo que subraya nuestra discusión anterior sobre las diferencias en los tamaños de las claves y los requisitos inherentes de los diferentes algoritmos criptográficos.

Después de repasar los conceptos básicos de la criptografía de clave pública y entender cómo se incorpora en el estándar WebAuthn / [FIDO2], tenemos dos recomendaciones principales para los relying parties:

• Seleccionar los algoritmos de cifrado correctos: En la implementación de WebAuthn, es importante usar los algoritmos correctos para una máxima compatibilidad. Basado en las recomendaciones actuales, es aconsejable una combinación de RS256, ES256 y EdDSA. RS256 y ES256 destacan por su amplio soporte, y la inclusión de EdDSA puede mejorar la seguridad cuando sea posible.
• Usar bibliotecas de WebAuthn bien probadas para extraer la clave pública: Una vez que hayas decidido los algoritmos, el siguiente paso es integrar una biblioteca de WebAuthn bien probada. Dicha biblioteca puede manejar competentemente las complejidades de analizar el * attestationObject*. Después de que la biblioteca haya extraído las claves públicas y sus datos asociados, se pueden almacenar de forma segura en la base de datos. El formato utilizado por la biblioteca generalmente asegura que la clave se almacene de una manera que pueda ser leída y utilizada con precisión para futuros propósitos de autenticación.

Es crucial no reinventar la rueda: aprovecha el conocimiento colectivo integrado en las bibliotecas establecidas. La implementación personalizada corre el riesgo de introducir errores y fallos de seguridad que podrían socavar la eficacia de la autenticación y la seguridad general del sistema.

En esta publicación de blog, hemos investigado los conceptos básicos de la criptografía de clave pública para responder a las tres preguntas centrales iniciales:

1. Algoritmos de cifrado compatibles en WebAuthn: WebAuthn está diseñado para ser flexible y admite una amplia gama de algoritmos de cifrado, incluyendo prominentemente RSA (RS256), ECDSA (ES256) y EdDSA. Esta adaptabilidad le permite integrarse sin problemas con varios [autenticadores] y plataformas, asegurando una amplia compatibilidad.
2. Funcionalidad de pubKeyCredParams en la creación de pares de claves: Los pubKeyCredParams juegan un papel importante en la fase de registro del proceso de WebAuthn al especificar qué algoritmos criptográficos admite el relying party. Esto asegura que los pares de claves creados sean compatibles tanto con el autenticador del usuario como con los requisitos del relying party.
3. Funcionalidad de credentialPublicKey y extracción de claves públicas: El credentialPublicKey se utiliza para extraer claves públicas del attestationObject proporcionado por los autenticadores.

Además, hemos destacado la independencia del protocolo WebAuthn de algoritmos de cifrado específicos, lo que mejora significativamente su flexibilidad y preparación para el futuro frente a los métodos criptográficos emergentes. Esperamos que este artículo también ayude a otros desarrolladores a depurar y comprender conceptos / problemas relacionados con la criptografía de clave pública en WebAuthn.