제로널리지의 가장 아름다운 성질과 가장 무서운 성질은 같은 것에서 나옵니다. 서버가 키를 갖지 않으므로 아무도 몰래 데이터를 볼 수 없지만 동시에 사용자가 열쇠를 잃으면 서버도 그것을 되살려 줄 수 없습니다. 일반 서비스라면 "비밀번호 찾기" 이메일 한 통으로 끝나는 일이 제로널리지에서는 수학적으로 불가능합니다. Ciphek은 이 딜레마를 BIP39 복구 니모닉으로 완화했습니다.
왜 서버 복구가 불가능한가
일반적인 서비스는 비밀번호를 잊어도 이메일로 재설정할 수 있습니다. 서버가 사용자 계정의 통제권을 쥐고 있기 때문입니다. 하지만 제로널리지에서는 암호화 키가 마스터 패스워드에서 파생되어 브라우저 밖으로 나가지 않고 서버는 마스터키를 한 번도 가진 적이 없습니다. 재설정할 대상 자체가 서버에 없습니다. 만약 서버가 키를 복구할 수 있다면, 그것은 서버가 애초에 키에 접근할 수 있다는 뜻이 되어 제로널리지가 깨집니다.
그래서 복구는 서버가 아니라 사용자 손에 있어야 합니다. 사용자가 마스터 패스워드와는 별개의, 그러나 같은 마스터키로 이어지는 두 번째 열쇠를 안전하게 보관하게 만드는 것입니다. 이 두 번째 열쇠가 사람이 종이에 적어 금고에 넣을 수 있을 만큼 다루기 쉬워야 실제로 쓰이므로, 여기서 BIP39 니모닉이 등장합니다.
BIP39 24단어와 복구 blob
BIP39는 무작위 엔트로피를 사람이 옮겨 적을 수 있는 단어 목록으로 표현하는 표준입니다. Ciphek은 256비트 엔트로피를 24개 영어 단어로 만들어 사용자에게 보여 주고 안전한 곳에 적어 두게 합니다. 이 단어들은 체크섬을 포함하고 있어 한 단어를 잘못 옮겨 적으면 검증 단계에서 걸러집니다. 24개 단어의 순서와 철자가 곧 256비트 비밀입니다.
핵심은 이 니모닉을 마스터키에 어떻게 잇느냐입니다. 니모닉 자체가 마스터키인 것은 아닙니다. 대신 니모닉에서 파생한 복구키로 실제 마스터키를 암호화해 감싼 "복구 blob"을 만들어 서버에 저장합니다. 서버에 저장되는 것은 어디까지나 암호문이라 서버는 이걸로 아무것도 못 합니다. 복구가 필요할 때 사용자가 24단어를 입력하면 브라우저가 복구키를 되만들고 그 키로 복구 blob을 풀어 마스터키를 꺼낸 뒤 다시 로그인 상태로 돌아갑니다. 복구키가 틀리면 인증 태그가 어긋나 복호화가 거부되므로, 아무 단어나 넣어서 뚫을 수는 없습니다.
니모닉을 마스터키에 묶는 이유
여기서 왜 니모닉을 곧장 키로 쓰지 않고 굳이 마스터키를 감싸는 방식을 택했는지가 중요합니다. 만약 니모닉이 그 자체로 암호화 키였다면, 사용자가 패스워드를 바꿀 때마다 니모닉도 바뀌어야 하거나 반대로 니모닉이 고정되어 유연성이 사라집니다. 마스터키를 가운데 두고 패스워드 경로와 니모닉 경로가 각각 그 마스터키로 이어지게 하면, 두 경로는 독립적으로 같은 목적지에 도달합니다. 패스워드를 바꿔도 복구 blob만 새로 감싸면 되고 니모닉은 그대로 유효합니다.
이 구조는 결국 "하나의 마스터키, 여러 개의 입구"라는 그림입니다. 평소에는 패스워드라는 입구로 들어오고 그 입구를 잃으면 니모닉이라는 비상구로 들어옵니다. 두 입구 모두 서버를 거치지 않고 사용자 손안에서 마스터키로 이어지므로 제로널리지가 유지됩니다. 서버는 두 입구가 가리키는 암호문만 보관할 뿐입니다.
정직하게 알리는 것까지가 설계다
기술만으로는 이 문제가 완결되지 않습니다. 니모닉과 패스워드를 둘 다 잃으면 데이터는 정말로 복구되지 않기 때문입니다. 이 사실을 약관 깊은 곳에 묻어 두고 넘어가면, 데이터를 잃은 사용자는 배신감을 느끼고 그 감정은 신뢰가 전부인 보안 제품에 치명적입니다. 그래서 Ciphek은 이것을 숨기지 않는 쪽을 택했습니다.
가입 시 복구 니모닉을 보여 주는 단계에서 안전하게 보관했다는 확인을 명시적으로 받고 약관에는 "우리가 안 해 주는 것"이 아니라 "수학적으로 할 수 없는 것"이라는 표현으로 이 한계를 적었습니다. 정책이라면 예외를 만들 수 있다는 기대를 남기지만 암호 구조의 성질이라고 정확히 말하면 사용자는 자기 열쇠를 지키는 것이 유일한 길임을 이해합니다. 복구가 불가능하다는 사실을 명확히 전달하는 것까지가 복구 설계의 일부입니다.
이 니모닉이 감싸는 마스터키가 어떻게 만들어지는지는 브라우저 Argon2id 키 파생에서, 제로널리지 주장을 과장 없이 전달하는 방법은 제로널리지 주장 정직하게 하기에서 다룹니다. 전체 구조는 제로널리지 암호화 미디어 클라우드 사례에 있습니다.
자주 묻는 질문
왜 서버가 비밀번호를 재설정해 줄 수 없나요?
암호화 키가 마스터 패스워드에서 파생되어 브라우저 밖으로 나가지 않고 서버는 마스터키를 가진 적이 없기 때문입니다. 재설정할 대상 자체가 서버에 없습니다. 만약 서버가 키를 복구할 수 있다면 서버가 애초에 데이터에 접근할 수 있다는 뜻이 되어 제로널리지라는 전제 자체가 깨집니다.
24단어 니모닉을 잃으면 어떻게 되나요?
니모닉은 패스워드를 잊었을 때를 위한 비상 입구입니다. 패스워드를 알고 있다면 니모닉 없이도 정상 로그인할 수 있습니다. 다만 마스터 패스워드와 니모닉을 둘 다 잃으면 데이터는 복구되지 않습니다. 이것은 정책이 아니라 암호 구조의 성질이며 그래서 니모닉을 안전한 곳에 별도로 보관하는 것이 중요합니다.
니모닉이 서버로 전송되나요?
아니요. 서버에 저장되는 것은 니모닉이 아니라 니모닉에서 파생한 키로 마스터키를 감싼 복구 blob, 즉 암호문뿐입니다. 니모닉 자체와 복구키는 브라우저에서만 다뤄지고 서버로 전송되지 않으므로, 서버는 복구 blob을 가지고 있어도 그것을 풀 방법이 없습니다.