Claves de acceso vinculadas a dispositivos vs. sincronizadas (SCA y claves de acceso I)

Descripción general: Autenticación reforzada de clientes con claves de acceso#

• Análisis de los requisitos de PSD2 y SCA
• Qué significan los requisitos de la SCA para las claves de acceso
• Implicaciones de la PSD3 / PSR para las claves de acceso

1. Introducción: Claves de acceso vinculadas a dispositivos vs. sincronizadas#

En nuestro blog anterior sobre las claves de acceso y la PSD2, hablamos sobre cómo empresas fintech como Revolut y Finom ya utilizan las claves de acceso y cómo mejoran la seguridad digital de la banca.

Las claves de acceso (passkeys) se presentan en dos formas principales: claves de acceso sincronizadas y claves de acceso vinculadas a dispositivos. Mientras que las claves de acceso sincronizadas permiten a los usuarios autenticarse en múltiples dispositivos sin problemas, las claves de acceso vinculadas a dispositivos están estrictamente vinculadas a un dispositivo de clave de acceso, como una llave de seguridad de hardware o un autenticador local.

Con esta serie de cuatro publicaciones en el blog, queremos analizar en profundidad cómo los diferentes tipos de claves de acceso (vinculadas a dispositivos vs. sincronizadas) cumplen con los requisitos de la SCA y la PSD2.

Esta primera parte de la serie trata de comprender la diferencia entre las claves de acceso vinculadas a dispositivos y las sincronizadas.

La segunda parte explica qué significan la PSD2 y la Autenticación Reforzada de Clientes (SCA) de forma comprensible, exponiendo también su desarrollo histórico.

La tercera parte de la serie muestra cómo los diferentes tipos de claves de acceso cumplen con la SCA y lo que esto significa para los bancos, las empresas fintech y las instituciones financieras que piensan en adoptar claves de acceso.

La cuarta y última parte de la serie concluye lo que la PSD3 / PSR significará para la SCA y las claves de acceso en el futuro.

2. Autenticación reforzada de clientes, PSD2 y claves de acceso#

Tras la publicación de nuestra última entrada en el blog, recibimos muchas preguntas de seguimiento con respecto a nuestra postura sobre las claves de acceso, específicamente en relación con la SCA bajo el marco de la PSD2. Existe un claro interés en comprender no solo la aplicación de las claves de acceso, sino también cómo se alinean con las Normas Técnicas de Regulación (RTS). Además, las partes interesadas sienten curiosidad por las posibles interpretaciones y la orientación de los reguladores, incluida la Autoridad Bancaria Europea (EBA), sobre el uso de claves de acceso.

Reconociendo esto, nuestro objetivo es profundizar en cómo las claves de acceso pueden integrarse dentro de la directiva PSD2, las RTS sobre la SCA y proporcionar claridad sobre nuestra posición en el uso de esta tecnología. También exploraremos las preguntas y respuestas existentes de la EBA para arrojar luz sobre cómo los reguladores y la EBA podrían percibir las claves de acceso. Este examen no solo abordará las distinciones entre las claves de acceso sincronizadas y las vinculadas a dispositivos, sino también sus aplicaciones prácticas en la mejora tanto de la seguridad como de la experiencia del usuario.

Al comprender los matices, las partes interesadas pueden tomar decisiones informadas que no solo cumplan con los estrictos requisitos de la PSD2, sino que también aprovechen la última tecnología de autenticación para asegurar las transacciones digitales. Nuestra discusión tiene como objetivo iluminar aún más el camino para la integración de claves de acceso en los procesos de autenticación, asegurando que las medidas de seguridad mantengan el ritmo del panorama digital en evolución.

Por supuesto, cada entidad regulada que se encuentre bajo la PSD2 debe tomar sus propias decisiones sobre cómo cumplir con los objetivos regulatorios, ya que cada implementación tiene sus propias complejidades. Este enfoque individual reconoce que, si bien el marco regulatorio proporciona un estándar uniforme, la aplicación práctica de estos estándares variará significativamente en diferentes organizaciones debido a sus entornos operativos, capacidades tecnológicas y bases de usuarios únicos.

Por lo tanto, si bien nuestras perspectivas pretenden orientar e informar, no son prescriptivas. Cada entidad debe considerar sus circunstancias y desafíos específicos al integrar claves de acceso en sus protocolos de seguridad y autenticación.

3. De las claves de acceso vinculadas a dispositivos a las sincronizadas#

Para entender la diferenciación entre las claves de acceso vinculadas a dispositivos y las sincronizadas, exploraremos brevemente cómo se desarrolló el ecosistema.

3.1 ¿Qué son las claves de acceso vinculadas a dispositivos (claves de un solo dispositivo)?#

Comenzamos repasando la historia y la evolución de las claves de acceso vinculadas a dispositivos antes de analizar en detalle sus aspectos técnicos.

3.1.1 Historia de las claves de acceso vinculadas a dispositivos#

Históricamente, los mecanismos de autenticación dentro de WebAuthn (el estándar subyacente de las claves de acceso) estaban fuertemente acoplados a dispositivos físicos: llaves de seguridad (por ejemplo, YubiKeys). Antes de la adopción generalizada de las claves de acceso, las credenciales FIDO2 vinculadas a un único autenticador representaban el estándar de oro en seguridad. Estas credenciales están vinculadas al dispositivo en el que residen. La implicación de esta vinculación era significativa: la credencial no podía transferirse ni utilizarse más allá de su hardware original.

Este enfoque, si bien mejoraba la seguridad al localizar el proceso de autenticación en un solo dispositivo, inevitablemente encontraba limitaciones prácticas que afectaban su adopción generalizada, especialmente entre los consumidores generales sin conocimientos técnicos. Los usuarios se veían obligados a tener su dispositivo de autenticación disponible para cada intento de inicio de sesión, lo que no solo limitaba la movilidad del usuario, sino que también suscitaba preocupaciones en escenarios en los que el dispositivo se perdía, se dañaba o no estaba accesible de inmediato.

Además, también había reticencia por parte de los consumidores a invertir en hardware adicional. Históricamente, la propiedad y el uso de llaves de seguridad dedicadas ha sido muy bajo entre los consumidores en general. La perspectiva de comprar hardware especializado para fines de autenticación, a pesar de sus beneficios de seguridad mejorados, no resonó bien en la mayoría de los usuarios B2C, que al mismo tiempo suelen ser el objetivo de amplias campañas de phishing o ataques de relleno de credenciales (credential stuffing).

3.1.2 Detalles técnicos de las claves de acceso vinculadas a dispositivos#

Las claves de acceso vinculadas a dispositivos se caracterizan por su categorización específica en credenciales detectables y no detectables, una distinción que define principalmente su capacidad de descubrimiento. Pero el factor clave que distingue a las claves vinculadas a dispositivos se encapsula en las propiedades de las credenciales WebAuthn, en particular a través de los indicadores (flags) isBackupEligible y isBackupSynchronized. Para las claves de acceso vinculadas a dispositivos, ambos campos se establecen en cero, lo que indica que las credenciales no son elegibles para copias de seguridad o sincronización entre dispositivos. Estas características subrayan su vínculo intrínseco con el dispositivo físico en el que se crearon, asegurando que la credencial permanezca atada a esa pieza específica de hardware y se utilice únicamente en ella.

Un ejemplo notable de credenciales vinculadas a dispositivos en la práctica se observa dentro del ecosistema de Windows. Las credenciales de Windows Hello en Windows 10 y Windows 11 siguen vinculadas al dispositivo: el propio Windows Hello aún no sincroniza las claves de acceso entre dispositivos. Sin embargo, Microsoft ha dado un primer paso significativo al introducir el guardado y sincronización de claves de acceso en Microsoft Edge (a partir de Edge 142). Esta sincronización a nivel del navegador a través de Microsoft Password Manager permite que las claves de acceso se sincronicen en dispositivos Windows cuando se usa Edge, de manera similar a cómo Google Password Manager habilita la sincronización de claves de acceso en el navegador Chrome en Windows. Esto representa un avance importante en las capacidades de claves de acceso de Windows, aunque es específico del navegador Edge en lugar del autenticador de plataforma Windows Hello. Las claves de acceso de Windows Hello siguen vinculadas al dispositivo, pero esta integración de Edge proporciona un camino práctico hacia las claves de acceso sincronizadas en Windows, mientras que el propio autenticador de la plataforma puede evolucionar para admitir la sincronización en el futuro.

Por otro lado, Google ha articulado una postura clara con respecto a las claves de acceso no detectables, indicando que las claves de acceso no detectables existentes podrán permanecer sin sincronizarse en futuras implementaciones. Esta decisión se alinea con el principio más amplio de que las credenciales no detectables desempeñan un papel crucial en ciertos contextos de seguridad al permanecer estrictamente vinculadas al dispositivo y no son detectables, por lo que no se pueden utilizar como claves de acceso.

En contraste, el enfoque adoptado por Apple con macOS e iOS difiere significativamente. A diferencia de la estrategia fija vinculada a dispositivos que se observa con Windows y las claves no detectables de Google, el ecosistema de Apple se inclina mucho más por permitir solo claves de acceso sincronizadas, especialmente en iOS, por lo que resulta imposible crear claves de acceso vinculadas a dispositivos a través de WebAuthn.

Esta segmentación de estrategias en las principales plataformas ilustra los diversos enfoques para gestionar las credenciales WebAuthn, en particular al considerar el equilibrio entre la seguridad, la conveniencia y la accesibilidad del usuario. Si bien las claves de acceso vinculadas a dispositivos ofrecen un alto nivel de seguridad al garantizar que las credenciales no se puedan mover o usar de forma indebida fuera de su dispositivo previsto, la industria continúa evolucionando, buscando soluciones que mantengan los estándares de seguridad sin comprometer la experiencia y la movilidad del usuario.

3.2 ¿Qué son las claves de acceso sincronizadas (claves de acceso de múltiples dispositivos)?#

También aquí, echamos un vistazo al desarrollo histórico de las claves de acceso sincronizadas antes de analizar los detalles técnicos. En ocasiones, las claves de acceso sincronizadas también se denominan claves de acceso sincronizables.

3.2.1 Historia de las claves de acceso sincronizadas#

Tras la publicación de las especificaciones WebAuthn Nivel 2 y CTAP 2.1 entre mediados y finales de 2021, el grupo de trabajo de WebAuthn lanzó una importante iniciativa en la industria destinada a superar los principales obstáculos que impedían la capacidad del estándar WebAuthn para reemplazar las contraseñas y aumentar su adopción. Esta iniciativa se centró en dos áreas críticas: eliminar el requisito de dispositivos de seguridad de hardware adicionales y mitigar el riesgo asociado con la pérdida del autenticador, manteniendo la total compatibilidad con los estándares existentes.

3.2.1.1 Utilización de autenticadores de plataforma como módulos de hardware seguro#

El primer desafío (erradicar la necesidad de hardware nuevo) se abordó mediante la utilización de autenticadores de plataforma incorporados en los dispositivos de consumo modernos (por ejemplo, Touch ID, Face ID, Windows Hello).

Los dispositivos modernos están cada vez más equipados con módulos de seguridad especializados, como el Entorno de Ejecución Confiable (TEE) en Android, el Secure Enclave en iOS y macOS, y el Módulo de Plataforma Confiable (TPM) en los dispositivos Windows. Estos almacenes de claves de seguridad integrales sirven como una base sólida para las claves de acceso, funcionando efectivamente como "llaves de seguridad" integradas. Este enfoque permite la adopción generalizada de la criptografía de clave pública, un nivel de seguridad que antes solo se podía alcanzar a través de llaves de seguridad de hardware externas (por ejemplo, YubiKeys), y que estaba limitado en gran medida a personas u organizaciones expertas en tecnología dentro de industrias altamente reguladas.

Al aprovechar las capacidades de TEE, Secure Enclave o TPM, los protocolos WebAuthn están habilitados para proporcionar mecanismos criptográficos sólidos de autenticación de usuarios. Ahora, los métodos de autenticación sofisticados son fáciles de usar y accesibles para el público en general, sin la necesidad de hardware adicional y especializado.

Esta evolución es una mejora muy importante en el enfoque de la seguridad digital, que enfatiza el papel crítico que desempeñan las soluciones de seguridad centradas en el usuario a la hora de impulsar la adopción generalizada. Las organizaciones que combinan claves de acceso sincronizadas con flujos optimizados de creación y de inicio de sesión con claves de acceso ven las tasas de adopción más altas. Al utilizar las características de seguridad de los dispositivos contemporáneos, el esfuerzo de la industria abordó con éxito el obstáculo inicial de eliminar la necesidad de hardware externo.

Este desarrollo fue un paso crucial en una nueva era del ecosistema de autenticación digital, donde la amplia aplicación de la criptografía de clave pública se vuelve directamente aplicable a una gran variedad de casos de uso y, al mismo tiempo, simplifica la autenticación para los usuarios.

3.2.1.2 Sincronización de claves de acceso a la nube#

Con el fin de abordar el riesgo asociado a la pérdida del teléfono móvil y, por extensión, de las claves de acceso almacenadas en él, la iniciativa de la industria se centró en permitir la sincronización de las credenciales detectables con la nube. Este enfoque transformó eficazmente las credenciales de estar estrictamente vinculadas al dispositivo a ser multidispositivo y, más concretamente, a estar vinculadas a la cuenta del usuario en su proveedor de la nube, como iCloud para dispositivos Apple o Google para dispositivos Android.

Esta solución práctica significaba que incluso si el teléfono de un usuario se perdía o era reemplazado, las credenciales previamente establecidas no se perderían de forma permanente. En cambio, estas credenciales podrían recuperarse desde la cuenta en la nube del usuario y sincronizarse con un dispositivo nuevo. Este cambio redujo significativamente los inconvenientes y los riesgos de seguridad previamente asociados con la pérdida de un autenticador físico.

Al aprovechar la sincronización en la nube, las claves de acceso ahora podían realizar una transición perfecta entre los dispositivos de un usuario, manteniendo su integridad y seguridad independientemente del dispositivo específico en uso. Por ejemplo, cuando un usuario inicia sesión en un sitio web desde un nuevo dispositivo, las credenciales disponibles en su cuenta en la nube podrían sugerirse automáticamente para la autenticación. De ser necesario, estas credenciales se podrían transmitir al nuevo dispositivo, manteniendo una experiencia de autenticación consistente y segura en diferentes plataformas y dispositivos.

Esta transición hacia credenciales sincronizadas con la nube y vinculadas a la cuenta representa un enfoque pragmático para la seguridad digital. Reconoce la realidad del uso de dispositivos modernos y la frecuencia con la que se producen intercambios de dispositivos, ya sea por pérdida, daño o actualización. Al vincular las credenciales a la cuenta en la nube del usuario (ya sea con iCloud de Apple o los servicios en la nube de Google), la solución no solo mitiga el riesgo asociado con la pérdida de un dispositivo, sino que también mejora la capacidad del usuario para administrar y recuperar su identidad digital en múltiples dispositivos.

Este desarrollo amplía de manera efectiva la aplicabilidad de los sólidos mecanismos criptográficos de autenticación de WebAuthn, haciéndolos más adaptables a los escenarios de los usuarios en el mundo real. También garantiza que la autenticación fuerte sea accesible y manejable, no solo para aquellos con antecedentes técnicos o aquellos en industrias altamente reguladas, sino para el usuario promedio que navega por el mundo digital con múltiples dispositivos.

3.2.2 Detalles técnicos de las claves de acceso sincronizadas#

Las claves de acceso sincronizadas también se conocen como credenciales detectables o claves residentes. Estas se distinguen de las claves vinculadas a dispositivos por dos propiedades críticas: isBackupEligible e isBackedUp tienen valores diferentes. Para las claves de acceso sincronizadas, el indicador isBackupEligible se establece en 1, lo que indica que estas credenciales son elegibles para una copia de seguridad. Tras la sincronización exitosa en la nube, el indicador isBackedUp también se establece en 1, lo que confirma que la credencial se ha sincronizado correctamente. Es importante tener en cuenta que el estado de sincronización puede cambiar con el tiempo, reflejando la naturaleza dinámica del uso y la gestión de los dispositivos.

Cuando las plataformas solicitan claves residentes, al establecer el parámetro "requireResidentKey" en required o preferred, las plataformas que admiten servicios en la nube crean automáticamente claves de acceso sincronizadas. Este proceso asegura que los usuarios puedan confiar en que sus credenciales serán accesibles a través de sus diversos dispositivos. En Windows, las claves de acceso sincronizadas están ahora disponibles a través de Microsoft Edge/Microsoft Password Manager (sincronización a nivel del navegador), mientras que las credenciales del autenticador de plataforma de Windows Hello siguen estando vinculadas al dispositivo. Los administradores de contraseñas de terceros (por ejemplo, Dashlane, KeePassXC, 1Password) con capacidades de gestión de claves de acceso también brindan sincronización en todas las plataformas. En los escenarios en los que se utilizan claves de acceso sincronizadas, los indicadores isBackupEligible e isBackedUp se establecen en 1, indicando la elegibilidad para la copia de seguridad y la sincronización exitosa.

Además, aunque en la actualidad todavía es posible identificar el autenticador específico donde se ha almacenado la clave de acceso, la ausencia de atestación para la mayoría de estas credenciales significa que su origen no se puede verificar criptográficamente. Este aspecto destaca una limitación potencial a la hora de garantizar el pedigrí de seguridad de las claves de acceso sincronizadas únicamente a través de los mecanismos estándar de WebAuthn.

Este desarrollo en las claves de acceso sincronizadas esencialmente amplía el alcance de las credenciales detectables al integrarlas en un marco de sincronización basado en la nube. Al hacer que estas claves sean aptas para copias de seguridad y asegurar su sincronización en los dispositivos de un usuario, WebAuthn aborda dos de los principales desafíos en la autenticación digital: el riesgo de perder el acceso debido a la pérdida de dispositivos y la inconveniencia de gestionar múltiples credenciales vinculadas a dispositivos.

3.3 Vinculación a un solo dispositivo de las credenciales de WebAuthn sacrificada por un bien mayor#

La transición de claves de acceso vinculadas a dispositivos a claves sincronizadas inició un diálogo crítico dentro del grupo de trabajo de WebAuthn, centrándose en la necesidad de medidas de seguridad avanzadas, las cuestiones legales involucradas y un compromiso que fuera a la vez fácil para el consumidor y seguro.

La adopción de claves de acceso sincronizadas se celebró por su promesa de mejorar la conveniencia y seguridad del usuario a través de funciones como la sincronización en la nube y la perfecta funcionalidad multidispositivo. Sin embargo, introdujo cierta incomodidad entre algunas partes usuarias (Relying Parties o RPs), especialmente con respecto a las implicaciones para la seguridad y el cumplimiento normativo en entornos con requisitos elevados. La esencia del debate era el requisito de un mecanismo que garantizara que incluso las claves de acceso sincronizadas mantuvieran una conexión con dispositivos específicos, un concepto crucial para las partes usuarias que se ocupan de transacciones confidenciales u operan bajo estrictas normas regulatorias.

Para los RP que no podían o no querían adoptar claves de acceso, la ausencia de un método fiable para vincular estas credenciales a dispositivos específicos en aplicaciones críticas representaba un desafío importante. Algunas de las partes usuarias consideraron que un mecanismo de este tipo era de suma importancia. La falta de esta capacidad de vinculación de dispositivos, una expectativa que tal vez no se declaró de forma explícita pero que sin duda se esperaba, representó una seria sorpresa y un abuso de confianza desde su perspectiva.

La discusión concluyó que debería haber una armonización de intereses, pero que en un principio debería primar el bien mayor de propagar las claves de acceso. En la discusión, la extensión devicePubKey se consideró como una forma de abordar esas preocupaciones, pero luego fue reemplazada por supplementalPubKeys, que adopta un enfoque mucho más amplio en el borrador actual de WebAuthn Nivel 3. Desafortunadamente, este enfoque también se suspendió en agosto de 2024.

3.4 Lo mejor de dos mundos: claves de acceso y la extensión supplementalPubKeys [obsoleta a partir de agosto de 2024]#

Analicemos cómo se formó el compromiso con la extensión supplementalPubKeys y qué significa esto desde el punto de vista técnico.

3.4.1 De devicePubKey a la extensión supplementalPubKeys#

La discusión en torno a la transición de la extensión devicePubKey a la extensión supplementalPubKeys resalta la naturaleza dinámica de la especificación WebAuthn. En un principio, devicePubKey sirvió para mejorar la seguridad a través de claves públicas vinculadas a dispositivos, pero posteriormente fue reemplazada por la sugerencia de supplementalPubKeys en el Borrador de Trabajo del Editor de WebAuthn Nivel 3. Esta extensión más reciente ofrece una solución más integral al permitir el uso de múltiples claves para mejorar los procesos de autenticación.

El núcleo del debate se centró en equilibrar las medidas de seguridad mejoradas con la adopción más amplia y la utilidad práctica de las claves de acceso en diferentes dispositivos y plataformas. La extensión supplementalPubKeys representa una combinación de estas prioridades, lo que permite una autenticación más estricta. Por ejemplo, se adapta a las normativas que requieren ciertos estándares de autenticación al permitir "subclaves" adicionales con declaraciones de atestación. Estas claves pueden señalar el cumplimiento de los requisitos de autenticación, lo que podría reducir la necesidad de desafíos de inicio de sesión adicionales bajo ciertas condiciones (incluso con claves de acceso).

Un ejemplo directamente del borrador de WebAuthn:

“Supongamos que aparece una solicitud de inicio de sesión en un sitio web junto con una señal de geolocalización que no se ha visto antes en esta cuenta de usuario y está fuera de las horas de uso habituales observadas para la cuenta. El riesgo puede considerarse lo suficientemente alto como para no permitir la solicitud, incluso con la afirmación por parte de una credencial de múltiples dispositivos por sí sola. Pero si también se puede presentar una firma proveniente de una clave suplementaria que está vinculada al dispositivo y que está bien establecida para este usuario, entonces eso podría inclinar la balanza”.

Durante la discusión se destacó que estas estaban destinadas únicamente a los RP con requisitos de seguridad extremadamente altos (por ejemplo, en el contexto gubernamental).

Al incorporar los comentarios y abordar casos de uso específicos (incluidas también las transacciones financieras reguladas y la necesidad de señales vinculadas al dispositivo en un entorno de credenciales de múltiples dispositivos), la comunidad de WebAuthn buscó abordar tanto las preocupaciones de seguridad como de interoperabilidad. La extensión supplementalPubKeys es por tanto un enfoque que pretende brindar características de seguridad robustas y a la vez respaldar la experiencia de usuario fluida y la amplia compatibilidad esenciales para la adopción generalizada de las claves de acceso. Se trata de una extensión completamente opcional que no interfiere con la implementación de las claves de acceso que ya se ha observado durante los últimos 2 años.

Esta evolución hacia un marco más inclusivo y flexible subraya el compromiso de la comunidad de WebAuthn de mejorar los métodos de autenticación web incluso para casos de uso más estrictos.

3.4.2 Detalles técnicos de supplementalPubKeys#

La extensión supplementalPubKeys introducida en WebAuthn permite el uso de pares de claves adicionales junto con la credencial principal.

Tomado del problema original en GitHub

La imagen muestra el concepto de supplementalPubKey tomado del problema original en GitHub (pk = passkey, pspk = clave suplementaria del proveedor, dspk = clave suplementaria del dispositivo).

A continuación, se desglosa cómo funciona y su uso previsto:

Propósito y funcionalidad de supplementalPubKey

• Se mantiene una credencial de clave de acceso central: Es importante tener en cuenta que solo queda una clave de acceso central como método principal de autenticación del usuario, y las claves adicionales proporcionan capas de seguridad y garantías adicionales. Esta estructura mantiene la simplicidad y la eficiencia del uso de una única clave de acceso principal para la autenticación en múltiples dispositivos, garantizando una experiencia de usuario perfecta. Las claves suplementarias, por su parte, sirven para mejorar el contexto de autenticación, ofreciendo a la Parte Usuaria (RP) señales adicionales sobre el entorno de seguridad o el cumplimiento de normas de autenticación específicas. Estas claves suplementarias no son métodos de autenticación independientes, sino que aumentan la clave de acceso principal y refuerzan su confiabilidad con evidencia de la integridad del dispositivo.
• Claves vinculadas a dispositivos: Están vinculadas específicamente a un solo dispositivo. Pueden ofrecer garantías de que una solicitud de autenticación proviene de un dispositivo confiable que ya ha sido autenticado. No se sincronizarán bajo ninguna circunstancia.
• Claves vinculadas a proveedores: Estas claves tienen un alcance de "proveedor", lo que significa que pueden ofrecer garantías adicionales en función de las políticas del proveedor de autenticación o la certificación específica del proveedor. Por ejemplo, un proveedor podría emitir este tipo de clave únicamente después de que el usuario haya completado un nivel superior de autenticación (como 2FA).
• Múltiples claves públicas: A diferencia de su predecesor, la extensión devicePubKey, que permitía solo una clave pública vinculada a dispositivo, supplementalPubKeys permite la inclusión de uno o dos tipos de claves complementarias. Estas claves pueden servir para diferentes propósitos y alcances, a saber, alcances vinculados al dispositivo y vinculados al proveedor.

Casos de uso y ejemplos de supplementalPubKey

1. Seguridad mejorada: En situaciones en las que un sitio web (parte usuaria) debe cumplir con ciertas normas de seguridad mejoradas para la autenticación, se pueden usar claves complementarias para cumplir con estos requisitos. Si el sitio ha visto y verificado previamente esta clave suplementaria, podría permitir que el usuario evite los desafíos de inicio de sesión adicionales, ya que la continuidad del dispositivo se puede confirmar mediante señales previas.
2. Gestión de riesgos: En el caso de solicitudes de inicio de sesión que parezcan riesgosas (p. ej., provenientes de una nueva geolocalización o a horas inusuales), la presencia de una clave suplementaria vinculada al dispositivo que tenga un historial de uso con la cuenta del usuario podría reducir el riesgo percibido y permitir que la solicitud continúe donde, de lo contrario, se habría bloqueado.

Aspectos técnicos de supplementalPubKey

• Sin ID de credencial propia: Las claves suplementarias no son credenciales de usuario y no tienen sus propios ID de credenciales.
• Declaraciones de atestación: Las claves suplementarias pueden tener, de manera opcional, una atestación. Éstas son cruciales para comprender el alcance y el nivel de seguridad de las claves suplementarias. Una atestación puede indicar el nivel de protección de la que disfruta una clave vinculada a hardware, o las políticas para otros tipos de claves suplementarias.
• Implementación para las partes usuarias (Relying Parties): Las partes usuarias pueden solicitar estas claves suplementarias como parte del proceso de autenticación. Sin embargo, la complejidad de lidiar con múltiples claves y declaraciones de atestación significa que esta extensión se adapta mejor a entidades con necesidades de seguridad específicas, como los bancos o los servicios que operan bajo requisitos regulatorios estrictos.

Es crucial señalar que, a fecha de abril de 2024, la extensión supplementalPubKeys no ha sido adoptada por ningún navegador importante y la especificación WebAuthn Nivel 3 aún está en desarrollo y sujeta a cambios. Aún no se sabe con certeza si esta característica se incluirá en la versión final de la especificación ni si se implementará y adoptará en el futuro, ya que en la actualidad solo figura en el Borrador del Editor.

3.4.3 Obsoleto de supplementalPubKeys en agosto de 2024#

A partir de agosto de 2024, la extensión supplementalPubKeys ha sido descontinuada oficialmente. El grupo de trabajo de WebAuthn decidió eliminar esta función debido a la falta de soporte suficiente. La desaprobación de esta extensión también resalta una nueva dirección. En la actualidad, la FIDO Alliance está trabajando en el desarrollo de un enfoque diferente para dar soporte a las Partes Usuarias (Relying Parties) con altos requerimientos de seguridad. Se espera que esta próxima solución aborde las brechas que dejó la descontinuación de supplementalPubKeys y ofrezca nuevos métodos para fortalecer los procesos de autenticación en escenarios en los que las normas de seguridad estrictas son críticas.

Para obtener más detalles sobre el estado de obsoleto, consulte el pull request oficial en GitHub sobre WebAuthn.

4. Cómo maneja Corbado las diferencias entre claves vinculadas a dispositivos y sincronizadas en la práctica#

Comprender las diferencias entre las claves de acceso vinculadas a dispositivos y las sincronizadas es esencial, pero los bancos también necesitan herramientas para poner en práctica estas diferencias a escala. La plataforma de Corbado ofrece inteligencia de confianza del dispositivo que clasifica automáticamente los tipos de claves de acceso y aplica el tratamiento de SCA correcto a cada una.

Visibilidad de la confianza del dispositivo a través de los tipos de claves de acceso#

El panel de Confianza del Dispositivo de Corbado muestra cómo las claves de acceso vinculadas al dispositivo y las sincronizadas se desempeñan de manera diferente en producción. Las claves de acceso vinculadas al dispositivo logran mayores tasas de éxito (99,1 %) sin requisitos de paso adicional (step-up), mientras que las claves de acceso sincronizadas con señales de confianza del dispositivo alcanzan el 98,4 % con una pequeña tasa de paso adicional para los nuevos dispositivos.

El panel también realiza un seguimiento de la clasificación de dispositivos, identificando cuáles dispositivos son exclusivos de un solo usuario (92 % en implementaciones típicas de la banca), cuáles se comparten entre dos usuarios (7 %) y cuáles son dispositivos compartidos / de tipo quiosco (0,8 %). Esta clasificación influye directamente en las decisiones de cumplimiento de la SCA.

Control basado en políticas para diferentes escenarios de claves de acceso#

En lugar de tratar todas las claves de acceso por igual, las políticas de confianza de Corbado permiten que los bancos apliquen reglas diferentes según el tipo de clave de acceso, el estado del dispositivo y el nivel de confianza. Las claves de acceso vinculadas al dispositivo en dispositivos conocidos obtienen una autenticación sin fricciones, mientras que las claves de acceso sincronizadas en dispositivos nuevos desencadenan una verificación adicional (step-up), exactamente el tipo de enfoque matizado que exige el marco de SCA de la PSD2.

Esto significa que los bancos pueden implementar de manera confiada claves de acceso sincronizadas para obtener una mejor experiencia de usuario al tiempo que mantienen el estricto control de los dispositivos que brindan las claves de acceso vinculadas a dispositivos para escenarios de alta seguridad, todo administrado a través de la configuración de políticas en lugar de flujos de autenticación separados.

Acerca de Corbado

Corbado es la Passkey Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →

Preguntas frecuentes#

¿Cómo mejoran la seguridad las claves de acceso vinculadas a dispositivos?#

Las claves de acceso vinculadas a dispositivos son credenciales WebAuthn vinculadas de manera estricta al dispositivo en el que se crearon. A diferencia de las claves de acceso sincronizadas, permanecen en un solo dispositivo, lo que las hace inherentemente más seguras para ciertos casos de uso:

• Sin robo de credenciales: La clave privada nunca abandona el dispositivo, por lo que los atacantes no pueden interceptar las credenciales.
• Prevención del acceso no autorizado: La autenticación sólo se produce desde el dispositivo específico en el que se creó la clave de acceso.
• Sin dependencia de la nube: Elimina los riesgos asociados con las filtraciones de datos de la nube o las adquisiciones de cuentas.
• Cumplimiento de alta seguridad: Cumple con los estrictos requisitos de autenticación vinculados a dispositivos para industrias reguladas como los servicios financieros (AAL3).

La desventaja principal es la portabilidad limitada. Si el dispositivo se pierde, la clave de acceso no se puede recuperar a menos que el usuario registre una nueva en otro dispositivo.

¿Por qué se introdujeron las claves de acceso sincronizadas y cuáles son sus beneficios?#

Las claves de acceso sincronizadas (claves de acceso para múltiples dispositivos) se introdujeron para resolver los problemas de usabilidad de las claves de acceso vinculadas a dispositivos, en particular la falta de portabilidad y el posible bloqueo de la cuenta en caso de pérdida de un dispositivo. Los principales beneficios incluyen:

• Autenticación en múltiples dispositivos: Acceda a las cuentas desde varios dispositivos sin tener que registrar manualmente una nueva clave de acceso para cada uno de ellos.
• Sin riesgo de perder el acceso: Las credenciales se respaldan en la nube (p. ej., iCloud Keychain, Google Password Manager), garantizando la recuperación en caso de pérdida de un dispositivo.
• Mejora en la experiencia del usuario (UX): Elimina la fricción al quitar la necesidad de transferir o recrear credenciales de forma manual.
• No requiere hardware adicional: A diferencia de las llaves de seguridad de hardware, las claves de acceso sincronizadas utilizan módulos de seguridad integrados en el dispositivo.
• Seguridad robusta con la comodidad de la nube: El cifrado de extremo a extremo (E2EE) asegura que la clave privada nunca abandone el dispositivo en formato sin cifrar.

5. Conclusión#

En la primera parte de nuestra serie de 4 entregas, hemos analizado cuáles son las diferencias históricas y técnicas de las claves de acceso vinculadas a dispositivos y las sincronizadas. Comprender estas diferencias nos ayudará a aplicar los requisitos de PSD2 y SCA en consecuencia. También hemos echado un vistazo a lo que nos depara el futuro al analizar los últimos cambios en el estándar Webauthn Nivel 3, que aún está en evolución.

A continuación, se incluyen los enlaces a las otras partes de nuestra serie:

• Parte 2 "Análisis de los requisitos de PSD2 y SCA (SCA y claves de acceso II)"
• Parte 3 "Qué significan los requisitos de la SCA para las claves de acceso (SCA y claves de acceso III)"
• Parte 4 "Implicaciones de PSD3 / PSR para las claves de acceso (SCA y claves de acceso IV)"