제목
로그인 도구로만 알았던 Passkey를 해킹해 암호화 키 관리의 지옥을 탈출한 경험 (기술적 충격 보고서)
본문
솔직히 고백하자면, 대기업으로 이직한 후 저는 조금 게으른 개발자가 되어가고 있었습니다. 스타트업 시절에는 당장 서비스가 죽느냐 사느냐의 기로에서 온갖 오픈소스를 뜯어고치고 레거시 코드를 난도질하며 '생존형 코딩'을 했지만, 지금은 잘 갖춰진 사내 표준과 보안 가이드를 따르는 것이 미덕인 환경에 놓여 있기 때문입니다. "표준을 준수하라"는 말은 안전하지만, 때로는 우리의 상상력을 가두는 감옥이 되기도 합니다.
최근 WebAuthn과 Passkey 관련 기술 문서를 다시 들여다보다가, 한 아티클을 읽고 머리를 한 대 세게 맞은 듯한 충격을 받았습니다. 바로 'PassSeeds'에 관한 내용이었습니다. 저는 지금까지 Passkey를 그저 비밀번호 없는 로그인(Passwordless Login)을 위한, 아주 안전하고 편리한 '인증 수단'으로만 여겼습니다. 하지만 누군가는 이 기술을 뜯어보고 비틀어서, 블록체인이나 복잡한 암호화 애플리케이션의 최대 난제인 '키 관리(Key Management)' 문제를 해결하는 도구로 탈바꿈시켰더군요. 오늘은 제가 느낀 이 기술적 전율과 부끄러움을 여러분과 나누고 싶습니다.
과거 스타트업에서 핀테크 서비스를 개발할 때 가장 큰 골칫거리는 사용자 경험(UX)과 보안의 딜레마였습니다. 암호화폐 지갑이나 종단 간 암호화 메신저를 만들 때, 우리는 사용자에게 "보안을 위해 12~24개의 니모닉 단어를 종이에 적어서 금고에 보관하세요"라고 강요했습니다. 결과는 뻔했습니다. 이탈률은 치솟았고, CS 채널은 "비밀키를 잃어버렸는데 복구해달라"는 요청으로 마비되었습니다. 개발자로서 우리는 사용자의 부주의를 탓했지만, 사실은 기술의 한계를 사용자에게 떠넘긴 비겁한 변명이었습니다.
PassSeeds의 접근 방식은 이 지점에서 매우 영리하고 도발적입니다. 기본적으로 Passkey는 P-256 비대칭 키 쌍(Key Pair)을 생성하고, 개인키(Private Key)는 기기의 보안 영역(Secure Enclave 등)에 숨깁니다. 그리고 이 키는 iCloud나 Google Password Manager를 통해 기기 간에 동기화되죠. 보통의 개발자라면 여기서 "아, 로그인이 편하겠네" 하고 끝납니다.
하지만 PassSeeds는 여기서 'Hijacking(탈취)'이라는 표현을 쓸 정도로 과감한 발상을 합니다. Passkey의 개인키는 절대 밖으로 나오지 않지만, ECDSA 서명의 수학적 특성을 이용하면 서명된 데이터로부터 공개키(Public Key)를 역산(Recovery)할 수 있다는 점에 착안한 것입니다.
작동 원리는 이렇습니다. 먼저 navigator.credentials.create를 통해 Passkey를 생성합니다. 그리고 사용자가 특정 메시지에 대해 서명을 하게 만듭니다. 이때, 동일한 메시지에 대해 두 번 서명을 요청하여 얻은 값들을 이용해 ECDSA 공개키 복구 알고리즘을 돌립니다. 이렇게 추출된 공개키는 기기 간에 동기화되는 고유한 값이므로, 이를 일종의 'Seed(시드)'로 삼는 것입니다. 즉, 사용자가 별도의 니모닉을 관리할 필요 없이, Passkey가 동기화된 아이폰이나 맥북만 있다면 언제 어디서든 비트코인 지갑 키나 ZKP(영지식 증명)용 키를 결정론적으로 파생해낼 수 있게 됩니다.
이 아이디어를 접하고 나서 저는 8년 차 개발자로서의 관성을 뼈저리게 반성했습니다. 저는 그동안 WebAuthn 스펙 문서가 정해준 길로만 걸으려 했습니다. "이건 로그인용 API니까 로그인에만 써야 해"라는 고정관념에 갇혀 있었던 것이죠. 하지만 진짜 문제를 해결하는 엔지니어는 주어진 도구의 본질(여기서는 동기화되는 암호화 키 쌍)을 꿰뚫어 보고, 필요하다면 그 용도를 과감히 '납치'해서라도 비즈니스 가치를 만들어냅니다.
물론, 이러한 방식이 '표준'적인 사용법은 아닙니다. 브라우저 정책이 바뀌거나 스펙이 변경되면 리스크가 생길 수도 있습니다. 대기업의 보안 감사팀이 본다면 기겁할지도 모릅니다. 하지만 사용자가 암호화 키를 관리하는 고통에서 해방될 수 있다면, 기술적 부채를 감수하고서라도 시도해 볼 만한 가치가 충분합니다. AI가 코드를 짜주는 시대에 우리 인간 개발자가 가져야 할 경쟁력은 바로 이런 '통찰'과 '응용력'이 아닐까요?
후배 개발자분들께 꼭 드리고 싶은 말씀이 있습니다. 공식 문서(Official Docs)는 정답지가 아니라 설명서일 뿐입니다. API 뒤에 숨겨진 원리, 그 기술이 작동하는 로우 레벨(Low-level)의 메커니즘을 호기심 어린 눈으로 파헤쳐 보세요. 때로는 엉뚱한 호기심이 '단순 로그인 도구'를 '가장 강력한 키 관리 솔루션'으로 바꾸는 혁신의 열쇠가 되기도 합니다. 저도 오늘부터는 다시 야생의 감각을 깨워, 돌 하나하나를 뒤집어보는 심정으로 기술을 대하려 합니다.
