Todas las entradas

8 min de lectura

Identidades de equipo compartidas: una identidad, muchas personas

Un equipo puede compartir una identidad de CardanoWall compartiendo su semilla de identidad, pero eso entrega a cada poseedor plena capacidad de firma y descifrado, sin posibilidad de revocación parcial ni por persona.

Un equipo puede compartir una identidad de CardanoWall, pero compartir una identidad significa compartir la semilla de identidad. No hay una versión más ligera de eso.

Entregar la semilla es una delegación total. Cualquiera que la posea puede firmar registros como esa identidad y descifrar los registros sellados dirigidos a ella. CardanoWall puede hacer que el flujo de trabajo resulte cómodo entre cuentas separadas, pero no puede convertir una semilla en una autoridad parcial, revocable y por persona. La criptografía no funciona así.

Así que usa una identidad compartida solo cuando la autoridad compartida sea exactamente lo que buscas.

¿Qué es una identidad de equipo compartida?

Es una identidad Label 309 usada por más de una persona o cuenta.

Una identidad Label 309 se arraiga en una única semilla de identidad de 32 bytes. Cualquiera que importe esa semilla reconstruye la misma clave de firma y las mismas claves de recepción, en cualquier cuenta y en cualquier herramienta compatible. La identidad no está atada a una sola cuenta de CardanoWall, porque la semilla por sí sola la define.

Una redacción podría operar así una identidad de «Equipo de prensa». El editor jefe crea la identidad, guarda la semilla y la comparte con los colegas seleccionados a través de un canal de confianza. Cada colega importa la semilla en su propia cuenta y la desbloquea con sus propios passkeys. A partir de ese momento, todos poseen la misma identidad criptográfica.

¿Qué puede hacer cada poseedor de la semilla?

Todo lo que la identidad puede hacer. La semilla es la raíz, no un permiso acotado.

Cada poseedor puede:

  • firmar nuevos registros Label 309 como la identidad;
  • descifrar registros sellados dirigidos a la identidad;
  • leer los registros sellados entrantes una vez que los desbloquea;
  • volver a exportar la semilla y compartirla con otros;
  • importar la identidad en otra herramienta compatible, como el CLI de código abierto;
  • publicar las direcciones de recepción de la identidad en cualquier sitio.

Esto no es como invitar a alguien a un espacio de trabajo con permisos limitados y un botón de revocar. No hay un nivel de «solo lectura» ni de «publicar pero no descifrar». Si tienes la semilla, tienes la identidad entera.

¿Cuándo tiene sentido una identidad compartida?

Cuando el mundo exterior debe ver una sola identidad que representa un rol, no a una persona.

Algunos casos razonables son:

  • una dirección de recepción de una redacción;
  • la identidad probatoria de un departamento jurídico;
  • un contacto para la divulgación de fallos de seguridad;
  • la identidad de un comité de auditoría;
  • la identidad de un equipo de cumplimiento;
  • la identidad de los registros de una empresa;
  • la identidad compartida de un proyecto pequeño.

En cada uno de estos casos, la identidad de cara al público representa una función o un equipo, y el hecho de que varias personas estén detrás de ella es justamente el sentido.

¿Cuáles son los riesgos de una identidad compartida?

La atribución pasa a ser compartida, y la exposición también.

Si varias personas pueden firmar como la misma identidad, un verificador externo solo ve una clave pública Ed25519. La cadena no registra qué persona usó la semilla. Eso puede ser exactamente lo que el equipo quiere, o un problema real de rendición de cuentas, según la situación.

Los demás riesgos se derivan de la misma raíz:

  • cualquier miembro puede filtrar la semilla, de forma deliberada o por accidente;
  • un solo dispositivo comprometido puede comprometer toda la identidad;
  • un exmiembro puede conservar una copia después de marcharse;
  • todos los poseedores de la semilla pueden leer cada registro sellado enviado a la identidad;
  • no hay rotación de claves establecida: cambiar de claves significa pasar a una identidad nueva.

La autoridad compartida funciona, pero exige disciplina operativa a su alrededor.

¿Cómo gestiona CardanoWall esto entre cuentas?

Cada cuenta conserva su propia copia cifrada de la identidad compartida.

Si dos personas —llamémoslas Alice y Bob— importan la misma semilla, cada cuenta obtiene su propio vínculo cuenta-identidad y su propia bóveda cifrada. Los passkeys de Alice desbloquean la bóveda de Alice; los de Bob desbloquean la suya. La misma identidad criptográfica simplemente aparece en ambas cuentas, sin ningún estado compartido del lado del servidor entre ellas.

Para vincular una identidad ya existente, quien la importa tiene que demostrar que realmente posee la semilla, y no solo que conoce las claves públicas, que cualquiera puede leer de un perfil o de la cadena. La cuenta firma un desafío de servidor de un solo uso con la clave derivada de la semilla antes de crear el vínculo. Esto impide que alguien vincule una identidad de la que solo conoce las claves públicas, sin dejar de permitir que un poseedor legítimo de la semilla la vincule.

Las etiquetas de visualización siguen siendo privadas para cada cuenta. Alice podría etiquetar la identidad como «Equipo de prensa»; Bob, como «Recepción». Esas etiquetas viven dentro de la bóveda cifrada de cada cuenta, nunca en la identidad pública, de modo que ninguna cuenta puede ver la etiqueta de la otra y una brecha en la base de datos no revela ninguna de ellas.

La facturación también es por cuenta. Si Alice publica desde su cuenta, paga la cuenta de Alice. No hay un saldo compartido, porque ningún saldo podría imponerse criptográficamente cuando, de todos modos, cualquiera con la semilla puede publicar.

¿Se puede revocar una identidad compartida a una sola persona?

No criptográficamente, no una vez que esa persona ya conoce la semilla.

CardanoWall puede quitar la identidad de la bóveda de una cuenta, eliminar un passkey o desactivar la identidad en una cuenta concreta. Esos son controles reales en la capa de servicio, y son importantes para las cuentas que tú controlas.

Pero ninguno de ellos alcanza una copia de la semilla que ya vive en el gestor de contraseñas de alguien, en una impresión en papel, en su memoria, en una copia de seguridad, en una herramienta de escritorio o en una segunda cuenta. El conocimiento de 32 bytes no se puede retirar.

Así que, si alguien que poseía la semilla ya no debería tener autoridad, lo honesto es crear una identidad nueva y retirar la antigua, no fingir que la semilla vieja puede volver a ser secreta.

¿Cuál es un buen procedimiento para una identidad compartida?

Trata la semilla como el secreto compartido de alto valor que es.

Antes de que alguien la comparta, el equipo debería acordar:

  • quién está autorizado a poseer la semilla;
  • cómo se transfiere la semilla (en persona o cifrada de extremo a extremo);
  • dónde reside la copia de seguridad de referencia;
  • quién puede añadir la identidad a una cuenta;
  • qué passkeys desbloquean la bóveda de cada cuenta;
  • quién está autorizado a publicar bajo la identidad;
  • qué ocurre cuando alguien se marcha;
  • cuándo hay que reemplazar la identidad;
  • dónde se anuncian las nuevas claves públicas.

Déjalo por escrito antes de que un incidente o un cambio de personal te obligue a decidir bajo presión.

¿Debería un equipo usar una sola identidad compartida para todo?

Por lo general, no.

Las identidades separadas mantienen los flujos de trabajo limpios y contienen el daño. Una empresa podría operar una identidad para la divulgación de fallos de seguridad, otra para las pruebas jurídicas, otra para los lanzamientos públicos y otra para las auditorías internas.

Esa separación limita el radio de impacto. Si una identidad se ve comprometida, las demás no heredan automáticamente el problema. También hace más fácil razonar sobre la agenda de contactos y el modo lista de permitidos, ya que cada identidad tiene un propósito claro y acotado.

¿Qué haces cuando el equipo rota?

Crear una identidad nueva. El conocimiento de la semilla antigua no se puede revocar, así que un corte limpio es la única solución real.

Cuando una identidad compartida se ve comprometida, o cuando un antiguo poseedor debe perder el acceso, el camino es:

  1. crea una identidad nueva y guarda su nueva semilla;
  2. comparte la nueva semilla solo con los miembros que aún deban tenerla;
  3. actualiza los perfiles públicos, las direcciones de recepción y los contactos con las nuevas claves;
  4. desactiva la identidad antigua en las cuentas que controlas;
  5. deja de usar las antiguas direcciones de recepción;
  6. opcionalmente, publica un registro bajo la nueva identidad que sustituya a la antigua.

Los registros sellados ya dirigidos a la clave antigua siguen siendo legibles por todos los que alguna vez poseyeron la semilla antigua, incluida la persona de la que te estás desvinculando. Eso es una propiedad de cifrar hacia una clave pública de largo plazo, no un fallo que puedas parchear. Planifica teniéndolo en cuenta; no finjas que la semilla antigua puede dejar de estar compartida.

La versión corta

Las identidades de equipo compartidas son potentes y contundentes.

Permiten que un equipo opere una sola identidad Label 309 pública entre varias cuentas y dispositivos. Pero todos los que tienen la semilla disponen de plena capacidad de firma y descifrado, y esa capacidad no se puede conceder parcialmente ni revocar en silencio.

Usa una identidad compartida para roles que de verdad necesiten autoridad compartida. Usa identidades separadas siempre que la rendición de cuentas, la separación o la rotación importen más.

Para seguir leyendo

cardanowall-guidesidentityteams