Shamir's Secret Sharing과 Drop의 하이브리드 모델
지갑이 키를 어떻게 보호하는지는 기술적인 선택처럼 보입니다. 하지만 그것은 사람에 관한 선택이기도 합니다. 누가 내 돈을 옮길 수 있는지, 누가 그것을 잃을 수 있는지, 그리고 누구를 믿어야 하는지의 문제입니다. 기술적 결정은 곧 도덕적 결정입니다.
보안 모델 페이지는 Drop이 키를 어떻게 보호하는지 설명합니다. 이 페이지는 그 배경에 있는 한 가지 결정을 다룹니다. 키를 나누는 가장 일반적인 방법인 Shamir's Secret Sharing을 왜 사용하지 않는지, 그리고 그 선택에 어떤 대가가 따르는지입니다.
Shamir's Secret Sharing 요약
Shamir's Secret Sharing(SSS)은 개인 키를 셰어라고 부르는 조각으로 나누고, 복원에 몇 개가 필요한지 정할 수 있게 합니다. 예를 들어 3개 중 임의의 2개입니다. 그보다 적게 가진 사람은 키에 대해 아무것도 알 수 없고, 셰어 하나를 잃어도 키는 잃지 않습니다. 이 방식은 1979년에 나왔으며 업계 전반에서 쓰입니다.
일반적인 SSS 지갑은 셰어 하나를 사용자 기기에, 하나를 제공업체에 두고, 복구 셰어 하나는 사용자가 직접 보관합니다.
Drop은 대신 키를 두 개의 셰어로 나누며, 항상 둘 다 필요합니다. SSS처럼 개인 키를 복원할 수 있는 추가 셰어는 없습니다.
세 가지 결정
여분의 셰어는 누가 보관하는가?
SSS에서는 사용자입니다. 셰어 하나를 잃어도 된다는 점이 SSS의 가장 큰 매력이지만, 이는 어딘가에 보관된 여분에 달려 있습니다. 파일, 클라우드 드라이브, 인쇄한 코드 같은 것입니다. 잃어버리거나 유출될 수 있는 것이 하나 더 생깁니다.
Drop에서는 여분의 셰어가 없고, 사용자가 따로 보관할 것도 없습니다.
대가: 셰어를 잃는 것은 선택지가 아니므로, 백업을 유지하는 일은 당사와 사용자의 두 번째 기기 몫이 됩니다.
무언가 도난당했을 때 누구에게 확인을 구하는가?
SSS에서는 아무에게도 구하지 않을 수 있습니다. 복구 셰어가 기기 셰어 옆에, 즉 같은 휴대폰, 같은 클라우드 계정, 같은 노트북 백업에 놓이면, 그 한 곳에 들어온 사람이 키 전체를 갖게 됩니다. 셰어 두 개면 충분하기 때문에 승인 단계도, 한도도, 알림도 없습니다.
Drop에서는 복사된 파일이나 도난당한 백업만으로는 결코 충분하지 않습니다. 지원되는 패스키를 쓰면 사용자 측 셰어는 그 패스키 없이는 쓸모가 없고, 당사 서비스는 사용자의 패스키가 승인한 요청에 대해서만 다른 셰어를 공개합니다.
연산에서 얼마나 많은 것이 잘못될 수 있는가?
SSS에서는 생각보다 많습니다. SSS는 일반적인 테스트로는 잡히지 않는 실수가 생길 여지가 있는 연산에 의존합니다. 꼼꼼하게 만들어지고 널리 쓰이는 Privy의 오픈소스 라이브러리에 대한 독립 감사에서, 일부 경우 의도한 것보다 적은 셰어로 비밀의 일부를 복구할 수 있다는 점이 발견되었습니다. Privy는 이를 수정하고 그 내용을 공개적으로 설명했습니다. 또한 SSS는 셰어가 잘못되었는지 알 수 없습니다. 잘못된 셰어를 결합하면 경고 없이 다른 키가 만들어집니다.
Drop에서는 두 셰어를 가능한 가장 단순한 방법으로 결합합니다. 이렇게 하면 셰어 하나만으로는 아무것도 드러나지 않는다는, SSS가 높이 평가받는 속성을 유지하면서 잘못될 여지는 훨씬 줄어듭니다. Drop은 또한 복원된 키가 사용자 지갑의 주소와 일치하는지 사용 전에 확인합니다.
대가: 유연성입니다. "3개 중 임의의 2개"는 바로 그 추가 연산으로 얻는 것입니다.
대가를 어떻게 메우는가
- 당사 측의 백업 사본 3개. 현재 암호화된 서버 측 셰어의 백업 사본을 3개 보관하며, 앞으로 복제본을 더 늘릴 수 있습니다. 하나는 백업 데이터베이스에, 하나는 분리되고 격리된 별도 AWS 계정의 데이터베이스에, 하나는 오프라인 하드웨어에 있습니다
- 사용자 측의 두 번째 기기. 패스키 백업으로 기기를 하나 페어링해 두면, 기기 하나를 잃어도 접근이 막히지 않습니다
- 나가는 길. 언제든지 개인 키를 내보낼 수 있습니다. 그 이후 그 사본을 지키는 것은 온전히 사용자의 몫입니다