SSH 키를 파일로 관리해 본 사람이라면 누구나 한 번쯤 불안함을 느낀다. ~/.ssh/id_ed25519 같은 개인키 파일은 결국 디스크에 저장된 바이트 뭉치이고, 암호를 걸어두더라도 파일 자체가 유출되면 오프라인 공격의 표적이 된다. 그런데 최근 맥에는 이 문제를 근본적으로 다른 방식으로 푸는 수단이 기본 탑재돼 있다. 바로 시큐어 엔클레이브(Secure Enclave)에 개인키를 만들고 터치 ID로 보호하는 방법이다. 핵심은 개인키가 애초에 엔클레이브 밖으로 나올 수 없게 생성된다는 점이다. 파일로 존재하지 않으니 복사할 수도, 실수로 깃 저장소에 커밋할 수도 없다.
세 줄로 끝나는 설정
전체 흐름은 세 단계다. 먼저 sc_auth create-ctk-identity 명령으로 엔클레이브 안에 서명용 신원(identity)을 생성한다. 이때 터치 ID를 한 번 대면 키가 만들어진다. 다음으로 ssh-add에 애플이 제공하는 변환 계층 /usr/lib/ssh-keychain.dylib를 보안 키 제공자로 등록해, SSH 에이전트가 이 엔클레이브 신원을 인식하도록 알려준다. 마지막으로 ssh-add -L의 출력 중 sk-ecdsa-sha2-nistp256...으로 시작하는 줄을 깃허브의 SSH 키로 등록하면 된다. 이후로는 git을 통한 SSH 인증, 즉 깃허브에 push하거나 pull할 때마다 터치 ID 프롬프트가 뜨고 손가락만 대면 인증이 끝난다.
한 가지 기억할 점은 SSH 에이전트의 기억력이 좋지 않다는 것이다. 재부팅하고 나면 엔클레이브 신원을 다시 등록해 줘야 한다. 등록 과정에서 PIN을 묻는 프롬프트가 나타나는데, 빈 값으로 넘겨도 정상 동작한다. 이는 ssh-add가 유비키 같은 USB 인증기를 쓴다고 가정해 습관적으로 PIN을 묻는 것일 뿐, 실제 보안은 PIN이 아니라 지문에서 나오기 때문이다.
내부에서 벌어지는 일
조금 더 들여다보면 애플 특유의 난해한 용어들이 등장한다. 신원은 sc_auth(여기서 sc는 스마트카드를 뜻한다)로 관리되며 애플은 이를 'CryptoTokenKit(CTK) 신원'이라 부른다. 왜 스마트카드이고 왜 CTK인지는 문서만으로는 명쾌하지 않지만, 실체는 결국 시큐어 엔클레이브에 저장된 개인키다. 키 생성 시 지정하는 타입 중 SSH에 쓸 수 있는 선택지는 사실상 p-256-ne 하나뿐이다. -ne는 'Non-Extractable', 즉 엔클레이브가 직접 생성하고 밖으로 꺼낼 수 없다는 뜻이며, p-384 계열은 OpenSSH가 지원하지 않기 때문에 자연히 범위가 좁혀진다. 보호 수준은 bio와 none 중 고를 수 있는데, none으로 두면 키 추출은 여전히 불가능하지만 프로그램이 터치 ID 없이 조용히 서명할 수 있게 된다. 매번 뜨는 지문 프롬프트가 거슬린다면 none도 선택지이나, 보안을 생각하면 bio가 권장된다.
SSH 에이전트가 엔클레이브 키를 직접 다루지 못하는 간극은 ssh-keychain.dylib가 메운다. 이 라이브러리는 ssh-add의 FIDO 인증기 지원 기능(-K)을 빌려 쓴다. 원래 이 기능은 유비키 같은 USB 장치의 공개키를 찾도록 돼 있지만, -S로 제공자 라이브러리를 지정하면 그 동작을 바꿀 수 있다. 라이브러리는 _sk_load_resident_keys로 엔클레이브에 상주하는 키들의 공개키 목록을 돌려주고, _sk_sign으로 특정 신원을 써서 서명을 만든다. 실제 접속 시에는 에이전트가 공개키를 서버에 제시하고, 서버가 그중 하나를 받아 챌린지를 던지면, 서명 요청이 엔클레이브로 전달돼 터치 ID 승인 후 서명이 반환되는 흐름이다.
실무자가 따져봐야 할 한계
매력적인 만큼 분명한 대가도 있다. 키를 훔칠 수 없다는 말은 곧 당신조차 그 키를 백업하거나 다른 기기로 옮길 수 없다는 뜻이다. 맥이 고장 나거나 분실되면 신원도 함께 사라지며, 새 키를 만들어 깃허브를 비롯한 모든 곳에 다시 등록해야 한다. 여러 대의 기기를 쓰거나 팀 환경에서 키를 공유하는 워크플로에는 그만큼 복리 비용이 생긴다. 또한 이 설정의 상당 부분은 애플이 공식 문서로 보증하지 않은 영역이다. 원저자 자신도 매뉴얼 페이지와 타인의 조사, 직접 실험을 통해 동작을 역추적했다고 밝히고 있어, 향후 macOS 업데이트로 인터페이스가 바뀔 가능성을 배제하기 어렵다.
그럼에도 이 방식이 주는 방향성은 실무에 시사하는 바가 크다. 과거 전용 하드웨어 보안 모듈이나 별도 USB 토큰이 있어야 가능했던 수준의 키 보호가, 이제 널리 쓰이는 소비자용 노트북에 기본으로 들어 있다는 점이다. 개인 개발 환경이나 단일 기기 중심의 작업에서는 파일 기반 키를 엔클레이브 기반으로 전환하는 것만으로 유출 위험의 상당 부분이 사라진다. 다만 재부팅 시 재등록, 기기 분실 시 복구 불가, 다중 FIDO 인증기와의 상호작용 같은 운영상의 세부는 조직 차원에서 도입하기 전에 반드시 점검해야 할 지점이다. 더 많은 사용자가 이런 하드웨어 보안 기능을 쓰고 개방성을 요구할수록 제조사의 지원과 문서화도 개선될 여지가 크다.