SSH 키를 macOS Secure Enclave에 넣어봤더니, 보안은 완벽한데 UI가 못생겨서 포기했다
Protecting SSH Keys with macOS Secure Enclave
SSH 개인 키를 파일 시스템에 두는 불안감을 해결하려고 macOS Secure Enclave에 키를 저장하는 네이티브 방식을 직접 시도했다. 키는 하드웨어 밖으로 절대 나오지 않고, 모든 SSH 작업에 Touch ID 승인이 필요해 보안은 확실했다. 하지만 Touch ID 프롬프트가 "ctccardtoken needs to authenticate to continue"라는 불친절한 문구로 뜨는 등 UI가 너무 조악해 결국 Secretive 같은 대안을 찾기로 했다. 키가 Mac에 종속돼 백업이 불가능하다는 점도 유의해야 한다.
내 미적 감각은 이 못생김과 도저히 타협할 수 없어서, SSH 키를 Secure Enclave에 저장하는 다른 방법, 예를 들어 Secretive 같은 걸 알아볼 생각이다.
HN 토론
131- database64128
이런 보안 기능은 작동하지만, 어느 순간 작동하지 않게 된다.
macOS에 WireGuard를 설치했을 때, 시스템 키체인에 개인 키를 저장한다는 사실을 알고 기뻤다. 개인 키에 접근하려면 Touch ID가 필요했다.
그런데 어느 날 시스템 업그레이드 후 WireGuard 앱이 시작 시 다음과 같은 오류와 함께 충돌했다:
[APP] Unable to open config from keychain: -25300
그런 다음 앱이 모든 프로필을 삭제했다. 모두 "고아"가 되었다며, 분명히 "키체인 일관성"을 위해서라고 했다[0].
그때부터 나는 그냥 텍스트 편집기로 WireGuard 구성 파일을 편집하고 앱으로 가져온다. 버그는 오늘날까지도 존재한다[1].
[0] https://github.com/WireGuard/wireguard-apple/commit/dfb685f2...
[1] https://www.reddit.com/r/WireGuard/comments/wyt828/osx_wireg...
- jwr
몇 년 전에 나는 현재 사용 중인 머신의 공급업체와 독립적인 하드웨어 장치로 키를 보호하겠다고 결심했다. 또한 백업 키를 갖고 싶고, 여러 물리적 위치로 자유롭게 옮길 수 있기를 원한다. 필요하다면 전 세계 어디로든 백업을 배송받을 수도 있다.
YubiKey가 이러한 요구 사항에 맞는 유일한 솔루션이었기 때문에 그것을 선택했다. 지난 10년 정도 사용해 왔고 이 솔루션에 매우 만족하고 있다. YubiKey에 저장된 RSA 키를 GPG와 SSH에서 동시에 작동시키는 방법에 대한 설명은 https://github.com/drduh/YubiKey-Guide를 참조하라.
- mavam
에이전틱 개발의 근본적인 문제 중 하나는 보안 엔클레이브 키에 접근하려면 사람이 있어야 한다는 점이다. 헤드리스로 실행 중이고 로그인하지 않은 경우, Secretive(다른 것은 확실하지 않음)는 "알림"만 선택하고 "touchid"를 선택하지 않았더라도 엔클레이브에 접근할 수 없다.
이것이 내가 이 접근 방식이 안정적으로 확장될 수 있을지 회의적인 이유다. 비록 오늘날 나는 그것에 의존하고 있지만. (예, PAT가 이 문제를 해결하겠지만, 지금은 엔클레이브 모델을 유지하려고 한다.) 대신 내가 한 일은 SSH 인증 소켓을 설정하고 에이전트 포워딩을 수행하는 작은 데몬을 작성한 것이다. 이는 노트북을 가지고 여행할 때는 작동하지만... 아직 휴대폰에서는 안 된다.
예시:
Laptop Remote Mac
┌─────────────────────┐ ┌──────────────────────────┐
│ Secretive │ │ ssh / git commit -S │
│ (Secure Enclave) │ │ │ │
│ ▲ │ ForwardAgent │ ▼ │
│ └── ssh ─────┼─────────────────►│ ~/.ssh/agent.sock │
│ │ │ (stable proxy) │
└─────────────────────┘ │ │ │ │
│ ▼ ▼ │
│ forwarded local │
│ laptop Secretive │ […]
- LeBit
이 글은 잘못된 전제에서 시작한다.
저자는 키가 파일 시스템에 있어 악의적인 행위자에게 쉽게 탈취될 수 있다는 생각을 싫어한다고 말한다.
그렇기 때문에 키는 암호로 보호되어야 한다.
ssh agent를 사용하여 키를 메모리에 저장하고, 편의를 위해 암호를 키체인에 저장할 수 있다. macOS OpenSSH에는 이를 위한 UseKeychain 구성 지시문이 있다.
나는 Yubikey/FIDO2를 직접 사용하지만, 개인 키를 파일 시스템에서 보호할 수 없기 때문은 아니다.
- flexorium
나는 몇 년 동안 Secretive를 만족스럽게 사용해 왔다. Git 커밋 서명에도 사용하는데, 상호작용이 필요한 별도의 키로 만들어 pull/push에는 사용하지 않는다. GitHub.com에는 이 절충안이 이상적이라고 생각하며, 서버에는 다른 설정의 키를 사용한다.
평문 SSH 키는 우리 개발자 엔드포인트 비밀 탐지가 가장 먼저 초점을 맞춘 것 중 하나였다[0]. 그런 다음 bagel을 개발자 엔드포인트 보호 제품에 라이브러리로 내장했다[1].
- jen729w
나는 이를 위해 1Password의 `op`를 사용하지만, 한 가지 허용을 두고 있다: 내 개발 환경 키들이다.
지문 인증 피로를 느끼고 있었다. 개발 서버가 개발 Supabase에 연결할 때마다 지문 요청이 필요할까? 아니다. 그건 예상된 일이고 위험이 전혀 없다. 거기에는 데이터가 없다.
악의적인 요청이 나도 모르게 자동 승인될까 봐 걱정했다. 하루에 20번의 요청을 보면 근육 기억이 그냥 센서로 향한다.
그래서 서비스 계정[0]이 읽을 수 있는 별도의 1Password 볼트를 두었다. 그 토큰은 OP_SERVICE_ACCOUNT_TOKEN으로 내 환경에 있으며, `op` 도구가 이를 이해한다.
또한 Claude가 나에게 묻지 않고 접근할 수 있기를 원하는 'AI-safe' 키가 있는 볼트에도 접근할 수 있다.
이제 이러한 요청은 보이지 않게 작동한다. 그리고 지문 팝업이 보이면 이례적인 일이므로 습관적으로 자동 승인하지 않는다.
또한 별도의 볼트에 '_One-day keys'라는 항목을 보관한다. (밑줄은 쉽게 접근할 수 있도록 목록 맨 위로 올리기 위한 것일 뿐이다.)
여기에는 주로 읽기 전용으로 제한된 프로덕션 키가 있다. 필요하면 그것을 열린 볼트로 옮긴다. Claude는 이 항목을 알고 있으며, 작업이 끝나면 다시 옮기라고 나에게 알려주는 지침이 있다.
- dylanger
TKey(https://www.tillitis.se/products/tkey/)를 확인해 보라.
사실상 YubiKey의 오픈 소스 버전이며, 하드웨어 자체가 모두 오픈 소스이고 ed255519 SSH 키를 정말 잘 처리한다.
inb4 그들은 같지 않다고, 나도 안다. 나는 TKey 팀이 하는 일을 정말 좋아한다.
- gsliepen
Secure Enclave, TPM 및 기타 이러한 보안 기능은 불행히도 문서화가 너무 형편없고 작동시키려면 너무 많은 장애물을 넘어야 하며, 실수 하나로 완전히 잠기거나 원하는 보호를 받지 못할 수 있다. 이러한 기술을 사용 가능하게 만드는 더 나은 방법이 정말 있어야 한다...