1 pontos por GN⁺ 2025-11-24 | 1 comentários | Compartilhar no WhatsApp
  • Na versão Tahoe do macOS, o recurso de geração e uso de chaves SSH com Secure Enclave passou a ser suportado nativamente
  • A biblioteca /usr/lib/ssh-keychain.dylib, além do PKCS11Provider para smart cards já existente, implementa a interface SecurityKeyProvider, permitindo comunicação direta com o Secure Enclave em vez de usar um dispositivo FIDO2
  • Com o comando sc_auth, é possível gerar chaves com autenticação biométrica via Touch ID e, por meio de ssh-keygen ou ssh-add, carregar e usar chaves diretamente da área segura
  • Ao definir a variável de ambiente SSH_SK_PROVIDER no .zprofile, SSH, ssh-agent e ssh-keygen passam a reconhecer isso automaticamente
  • Sem ferramentas externas, é possível implementar uma estrutura de autenticação SSH que combina segurança e praticidade usando apenas os recursos nativos do macOS

Visão geral do suporte a chaves SSH com Secure Enclave

  • O macOS Tahoe oferece suporte à geração e ao uso de chaves SSH baseadas no Secure Enclave
    • Antes, eram necessários projetos externos como secretive, mas agora isso pode ser substituído pelos recursos nativos do macOS
  • /usr/lib/ssh-keychain.dylib implementa SecurityKeyProvider, permitindo acesso ao Secure Enclave de forma semelhante a dispositivos FIDO2
  • Com isso, é possível realizar autenticação SSH com o chip de segurança embutido do macOS, sem hardware externo como YubiKey

Geração e gerenciamento de chaves

  • Comando sc_auth create-ctk-identity -l ssh -k p-256-ne -t bio para gerar uma chave do Secure Enclave que exige autenticação via Touch ID
    • O comando list-ctk-identities permite verificar a lista de chaves criadas e seus hashes
    • O comando delete-ctk-identity permite excluir chaves
  • A opção list-ctk-identities -t ssh permite verificar a fingerprint da chave SSH

Uso no SSH

  • O comando ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N "" permite carregar o par de chaves a partir do Secure Enclave
    • Não é necessário inserir PIN; a autenticação é feita com Touch ID
    • A “private key” gerada não é a chave secreta real, mas sim um valor de referência de credencial FIDO
  • Após copiar a chave pública para o servidor com ssh-copy-id,
    é possível conectar com ssh -o SecurityKeyProvider=/usr/lib/ssh-keychain.dylib localhost

Integração com ssh-agent

  • Com ssh-add -K -S /usr/lib/ssh-keychain.dylib, é possível registrar diretamente a chave do Secure Enclave no ssh-agent
    • As chaves registradas podem ser verificadas com ssh-add -L
    • Depois disso, a autenticação pode ser feita com ssh -o SecurityKeyProvider=/usr/lib/ssh-keychain.dylib

Configuração padrão do SecurityKeyProvider

  • É possível definir isso diretamente em .ssh/config ou adicionar ao .zprofile
    export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib para reconhecimento automático
  • Depois disso, basta usar ssh-add -K ou ssh my-server para conexão SSH baseada em chave de segurança

Chaves exportáveis (Exportable Keys)

  • Com sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio, é possível gerar uma chave exportável criptografada pelo Secure Enclave
    • Ela pode ser exportada em arquivo PEM com export-ctk-identity e
      registrada novamente em outro dispositivo com import-ctk-identities
  • Esse método é um pouco menos seguro, mas mais favorável para backup

Discussão entre desenvolvedores e expansão do código

  • Nos comentários, discutiu-se a possibilidade de usar a flag .biometryCurrentSet
    • Atualmente, há suporte apenas para “usar biometria ou não (on/off)”, sem controle mais detalhado
  • O autor está avaliando a possibilidade de adicionar suporte a biometryCurrentSet à função sk_enroll() por meio de engenharia reversa (reverse-engineering) de ssh-keychain.dylib
  • O exemplo de código proposto exige assinatura de código (codesign) com uma conta do Apple Developer Program para acessar o Secure Enclave
  • O código inclui a lógica de geração, assinatura e registro de chaves (sk_enroll, sk_sign etc.),
    implementando o processo de gerar e assinar chaves ECDSA P-256 dentro do Secure Enclave

Resumo

  • O macOS agora oferece suporte nativo à autenticação SSH usando diretamente o Secure Enclave
  • A autenticação biométrica via Touch ID e a estrutura compatível com FIDO2 melhoram segurança e praticidade
  • É possível gerenciar chaves SSH apenas com recursos integrados do sistema, sem hardware externo nem software adicional
  • Desenvolvedores estão expandindo ssh-keychain.dylib para testar controle biométrico mais granular

1 comentários

 
GN⁺ 2025-11-24
Comentários do Hacker News
  • Se entendi direito, isso significa que não dá para fazer backup da chave privada
    Como ela fica armazenada no Secure Enclave, se você perder o notebook, a chave vai junto
    Parece que só a chave pública pode ser exportada. Claro, pode haver outras formas de acesso ou reset administrativo, mas ainda assim isso me deixa um pouco desconfortável
    Depois o OP respondeu e disse que vai atualizar a página

    • Basta consultar man sc_auth. Em vez de gerar diretamente no Secure Enclave, dá para criar uma chave criptografada exportável
      Nos exemplos, é possível executar sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio e depois usar export-ctk-identity para gerar um arquivo .pem
      Em outro dispositivo, dá para importar de novo com import-ctk-identities. Ele pretende adicionar isso ao guia
    • A ideia é justamente não “exportar” a chave original. Sempre que você move uma chave, surge risco de exposição
      O ponto central de uma PKI é mover apenas a chave pública, enquanto a chave privada deve existir em um único lugar
    • Sim. É melhor criar várias chaves como backup
      Assim, em nenhum caso a chave é exposta
    • Não poder exportar a chave privada é o mesmo conceito do YubiKey
      A chave privada gerada em um YubiKey também não pode ser copiada como backup
    • Em princípio, o certo é usar várias chaves
      O ideal é ter uma por dispositivo, para que perder ou ter um aparelho roubado não seja um problema
      Eu mantenho um YubiKey protegido por PIN no cofre. Assim estou coberto mesmo se perder o notebook, o celular e o YubiKey do dia a dia
  • Indo um pouco além, também dá para fazer assinaturas GPG baseadas em ECDSA
    Só que, por causa de um bug, é preciso usar um GPG com patch e um SSH agent
    Existe uma versão empacotada com UI para macOS (KeetaNetwork/agent),
    e o mesmo backend também funciona no Linux com TPM via PKCS#11
    A diferença entre GPG e SSH está apenas na forma de encapsular chaves e assinaturas; no fundo, tudo é ECDSA

  • O Secretive é mais simples de configurar, mas vou mudar para esse método para reduzir um app da minha lista
    Escrevi no meu blog como configurar chaves SSH baseadas em TPM no Windows 11

    • Fiquei curioso se no Linux também dá para armazenar uma ssh-key no TPM
  • É uma funcionalidade bem legal
    Eu uso o Secretive há muito tempo, e ele foi bem mais conveniente do que chaves físicas ou cartões
    Sempre que uma chave SSH vai ser usada, é preciso apertar um botão ou autenticar com biometria, então fica claro quando ela está sendo usada
    Dá para manter um túnel do ssh-agent e fazer assinatura de git com segurança em servidores remotos
    Só que a versão Tahoe tem muitos bugs e trava com frequência. Não tenho tempo para depurar, então deixei para lá
    Já sofri bastante com a UX de SSH baseada em Smart Card no passado, mas, se estiver estável, vale tentar

    • Eu também gosto do Secretive, mas o recurso de confirmação do ssh-agent já existe no OpenSSH há muito tempo
      Com ssh-askpass, é possível confirmar cada uso da chave privada. Só não distingue entre uso local e remoto
  • É preciso ter cuidado porque esse método usa uma curva que alguns suspeitam ter backdoor da NSA

  • Se a chave fica no Secure Enclave, por que é necessário um arquivo de chave privada?

    • A implementação sk do OpenSSH é igual. Mesmo com a opção de “resident key”, ainda é preciso um arquivo de chave privada
      Ele é apenas uma referência para a credencial FIDO e não contém o material secreto da chave em si
      No caso de chaves sk não residentes, o arquivo é necessário porque o autenticador de hardware não armazena estado
      Não está claro se a implementação do macOS armazena estado ou não. Pode até quebrar após reinstalar o sistema operacional
  • Existe um projeto chamado facebookincubator/sks
    É uma biblioteca em golang que abstrai vários tipos de chaves SSH baseadas em hardware e oferece suporte a Linux, Windows e macOS

    • Mas só a biblioteca em golang não faz o ssh-agent funcionar
      Por isso, no passado, comecei eu mesmo a criar o ssh-tpm-agent
  • Eu gostaria de usar a mesma chave privada no iPhone para assinar e-mails ou arquivos
    Fico pensando se o iCloud poderia cuidar disso

    • Essas chaves não são sincronizadas pelo iCloud
      Em vez disso, quem sincroniza é o Passkey. Seria preciso criar um novo SecurityKeyProvider que se comunique com a API de Passkey
      Passkeys ficam vinculadas a um ID de bundle de app específico ou a um domínio
      Por exemplo, se o Secretive suportasse Passkey, esse par de chaves não poderia ser usado em outros apps, mas
      seria sincronizado entre vários dispositivos do mesmo app
  • Está na hora de adicionar mais um recurso ao KeyMux
    Essa ferramenta oferece suporte a chaves de enclave para SSH, SSL e PGP e,
    por exemplo, pode acessar um servidor Vault com um certificado SSL baseado em Secure Enclave e fazer autenticação SSH com uma chave privada do Vault não exportável
    Dá para ver em keymux.com e no link da App Store