El Secure Enclave de macOS protege tus claves SSH, pero su interfaz es un desastre

Hace años decidí que quiero proteger mis claves con un dispositivo de hardware que sea independiente del proveedor de la máquina que estoy usando actualmente. También quiero tener claves de respaldo y poder moverlas libremente entre varios lugares físicos. O que me envíen una copia de respaldo al otro lado del mundo si es necesario.

Los YubiKeys eran la única solución que cumplía estos requisitos, así que me decidí por ellos. Los he estado usando durante los últimos diez años aproximadamente y he estado muy contento con esta solución. Ver https://github.com/drduh/YubiKey-Guide para una descripción de cómo hacer que tus claves RSA almacenadas en YubiKeys funcionen con GPG y SSH al mismo tiempo.

Un problema fundamental con el desarrollo agéntico es que acceder a la clave del enclave seguro requiere presencia humana. Si estás ejecutando sin interfaz y no has iniciado sesión, Secretive (no estoy seguro de otros) no podrá acceder al enclave, incluso cuando solo elegiste "notificar" y no "touchid".

Por esto soy escéptico de que el enfoque pueda escalar de manera confiable, aunque hoy dependo de él. (Sí, los PAT lo solucionarían, pero el modelo de enclave es lo que intento conservar por ahora). Lo que he hecho en su lugar es escribir un pequeño demonio que establece el socket de autenticación SSH y hace reenvío de agente. Esto funciona cuando viajo con el portátil... pero aún no desde mi teléfono móvil.

Ejemplo:

Laptop Remote Mac

┌─────────────────────┐ ┌──────────────────────────┐

│ Secretive │ │ ssh / git commit -S │

│ (Secure Enclave) │ │ │ │

│ ▲ │ ForwardAgent │ ▼ │

│ └── ssh ─────┼─────────────────►│ ~/.ssh/agent.sock │

│ │ │ (stable proxy) │

└─────────────────────┘ │ │ │ │

│ ▼ ▼ │

│ forwarded local │

│ laptop Secretive │ […]

El artículo parte de una premisa incorrecta.

El autor dice que no le gusta la idea de tener claves en su sistema de archivos listas para ser arrebatadas por actores maliciosos.

Por eso deberían estar protegidas con contraseña.

Usas ssh agent para almacenar las claves en memoria y, por comodidad, puedes guardar las contraseñas en el llavero. OpenSSH de macOS tiene la directiva de configuración UseKeychain para eso.

Yo mismo uso Yubikey/FIDO2, pero no porque las claves privadas no puedan protegerse en un sistema de archivos.

He sido un usuario feliz de Secretive durante años, incluso para la firma de commits de Git, para lo cual lo configuré como una clave separada con interacción pero no para pull/push. Encuentro que el equilibrio es ideal para GitHub.com y tengo otras claves con configuración diferente para servidores.

Las claves SSH en texto plano fueron una de las primeras cosas en las que se centró bagel [0], nuestra detección de secretos en endpoints de desarrollador. Luego integramos bagel como biblioteca en nuestra protección de endpoints de desarrollador [1].

[0] https://boostsecurityio.github.io/bagel/

[1] https://boostsecurityio.github.io/dazio/docs/install/

Uso `op` de 1Password para esto, pero con una excepción: las claves de mi entorno de desarrollo.

Descubrí que estaba sufriendo fatiga de huellas dactilares. ¿Necesito una solicitud de huella cada vez que mi servidor de desarrollo quiere conectarse a Supabase de desarrollo? No. Eso es esperado y riesgo cero. No hay datos allí.

Me preocupaba que una solicitud maliciosa fuera aprobada automáticamente por mí. Cuando ves 20 solicitudes al día, tu memoria muscular simplemente alcanza el sensor.

Así que tengo una bóveda separada de 1Password que una cuenta de servicio [0] puede leer. Ese token está en mi entorno como OP_SERVICE_ACCOUNT_TOKEN, que la herramienta `op` entiende.

También tiene acceso a una bóveda con claves 'seguras para IA' a las que quiero que Claude pueda acceder sin preguntarme.

Ahora, estas solicitudes funcionan de forma invisible. Y cuando veo una ventana emergente de huella dactilar, es inusual y no la apruebo automáticamente por costumbre.

También mantengo un elemento llamado '_One-day keys' en una bóveda separada. (El guion bajo solo lo empuja a la parte superior de la lista para facilitar el acceso).

Tiene claves de producción, en su mayoría restringidas a solo lectura. Si es necesario, muevo eso a la bóveda abierta. Claude conoce este elemento y tiene instrucciones para recordarme que lo mueva de vuelta cuando termine lo que estaba haciendo.

[0]: https://www.1password.dev/service-accounts/get-started

Deberías echarle un vistazo al TKey (https://www.tillitis.se/products/tkey/)

Es efectivamente una versión de código abierto de un YubiKey, el hardware en sí es totalmente de código abierto y maneja muy bien las claves SSH ed255519.

inb4 no son lo mismo, lo sé, realmente me gusta lo que está haciendo el equipo de TKey.

Secure Enclave, TPM y otras características de seguridad similares están, desafortunadamente, tan mal documentadas y requieren tantos obstáculos para hacerlas funcionar, que cualquier error puede dejarte bloqueado por completo o no darte la protección que deseabas. Realmente debería haber una mejor manera de hacer que estas tecnologías sean utilizables...