a16z: 공개 키 암호학의 핵심 난제를 해결하는 세 가지 최선의 방법
글: Noemi Glaeser, a16z crypto
글: Chris, Techub News
공개키 암호학에서는 오랫동안 하나의 난제가 존재해 왔다. 바로 암호화 키(예: 공개키)를 특정한 신원(예: 개인 또는 조직)과 정확하게 연결하는 방법이다. 이 문제의 핵심은 신원과 공개키 간의 관계를 공개적이고 일관된 방식으로 표시하여, 누구나 안심하고 해당 공개키를 사용해 정보를 암호화할 수 있도록 하는 것이다.
이러한 명확한 관계가 없다면, 누군가 어떤 공개키가 누구에게 속하는지 알 수 없게 되고, 결과적으로 암호화된 정보를 잘못된 사람에게 전송하여 정보 유출이나 그 밖의 심각한 사태를 초래할 수 있다. Web3 환경에서도 여전히 이 문제는 유효하다.
위와 같은 문제에 대해 현재 세 가지 해결책이 제시되고 있다: 공개키 디렉터리(Public Key Directory), 신원 기반 암호화(IBE), 그리고 등록 기반 암호화(RBE). 이 세 가지 방법은 익명성, 상호작용성, 효율성 측면에서 각기 다른 장점을 지닌다. 예를 들어 IBE는 강력한 신뢰 기반을 요구하지만, 특정 상황에서는 익명성과 효율성 면에서 더 나은 성능을 보인다. 본문은 블록체인 위에서 이 세 가지 방법의 적용 가능성을 탐색하고, 각각의 장단점을 비교하고자 한다.
세 가지 방법
일반적으로 암호화 키를 신원 정보와 연결하는 가장 흔한 방법은 공개키 인프라(PKI)를 사용하는 것으로, 여기서 중심이 되는 것은 공개키 디렉터리이다. 이 방식에서 메시지를 보내는 사람은 암호화된 정보를 전달하기 위해 신뢰할 수 있는 제3자(즉, 이 디렉터리를 관리하는 기관, 일반적으로 인증 기관 CA)와 상호작용해야 한다.
그러나 Web2 환경에서는 이러한 공개키 디렉터리 유지에 높은 비용과 번거로운 운영이 수반된다. 또한 사용자는 인증 기관이 권한을 남용할 가능성이라는 리스크도 감수해야 한다.
암호학자들은 PKI의 문제점을 해결하기 위한 대안들을 제안했다. 1984년 Adi Shamir는 신원 기반 암호화(IBE)를 제안했는데, 여기서 한 당사자의 식별자(예: 전화번호, 이메일 주소 또는 ENS 도메인)가 직접 공개키로 사용될 수 있다. 이 방법은 공개키 디렉터리 유지의 필요성을 없애지만, 새로운 문제를 야기한다. 즉, 비밀키 생성을 위해 신뢰할 수 있는 제3자(키 생성기)에 의존해야 한다는 점이다.
2001년 Dan Boneh와 Matthew Franklin은 최초의 실용적인 IBE 구조를 제안했으나, 이 기술은 널리 채택되지 못했으며 주로 기업이나 정부 배포 환경과 같은 폐쇄형 생태계에서 일부 사용되었다. IBE가 널리 보급되지 않은 이유 중 하나는 강력한 신뢰 가정, 즉 제3자가 올바르게 키를 생성한다는 점을 전제로 해야 하기 때문일 수 있다.
다만, 본문 후반에서 논의하겠지만, 이러한 신뢰 문제는 복수의 신뢰 가능한 참여자들(즉, 일정 수 이상의 참가자들로 구성된 법정수(quorum))에 기반함으로써 해결될 수 있으며, 블록체인 기술은 이를 쉽게 구현할 수 있다.
장점과 단점
여러 암호화 방식을 비교할 때 다양한 요소들을 고려해야 하며, 이에 대해 필자는 두 가지 가정을 설정한다:
사용자는 자신의 키를 갱신하거나 폐기하지 않는다: 이는 각 사용자의 키가 고정되어 있으며 변하지 않는다고 가정하는 것이다.
스마트 계약은 체인 외 데이터 가용성 서비스(DAS)나 blob 데이터를 사용하지 않는다: 즉, 스마트 계약이 오직 체인 상의 데이터에만 의존하며, 체인 외부의 데이터 서비스나 추가 저장 공간을 포함하지 않는다고 가정하는 것이다.
공개키 디렉터리 (Public Key Directory)
누구나 스마트 계약을 호출하여 아직 사용되지 않은 ID, 즉 (id, pk) 항목을 체인상의 디렉터리에 추가할 수 있다.
탈중앙화된 PKI란 스마트 계약을 통해 신원(ID)과 해당 공개키의 매핑 관계를 유지하는 시스템이다. 이 디렉터리는 공개적이며 중앙화된 제3자에 의존하지 않는다. 예를 들어 ENS는 도메인 이름(즉, 신원)과 관련 메타데이터 사이의 매핑을 유지하는데, 여기에는 도메인이 가리키는 주소(해당 주소의 거래로부터 공개키를 추론 가능)도 포함된다. ENS는 공개키 외에도 다양한 메타데이터를 저장하는 보다 복잡한 시스템이지만, 탈중앙화된 PKI는 상대적으로 기능이 단순하다: 스마트 계약은 각 신원에 대응하는 공개키 목록만 관리하면 된다.
사용자가 신원을 등록하고자 할 경우, 먼저 새롭게 키 쌍(공개키 및 개인키)을 생성하거나 이미 존재하는 키 쌍을 사용하여 자신의 신원 ID와 공개키를 스마트 계약에 전송한다(수수료를 지불할 수도 있음). 스마트 계약은 해당 ID가 이미 등록되었는지 확인하며, 미등록 상태라면 ID와 공개키를 디렉터리에 추가한다. 등록이 완료되면, 누구든지 스마트 계약에 질의하여 특정 ID에 해당하는 공개키를 조회할 수 있고, 이를 통해 해당 사용자에게 메시지를 암호화하여 전송할 수 있다. 만약 발신자가 이전에 동일한 수신자에게 암호화된 메시지를 보낸 적이 있어 이미 공개키를 보유하고 있다면, 다시 스마트 계약에 요청할 필요는 없다. 공개키를 확보한 후 발신자는 일반적인 방식으로 이를 사용해 메시지를 암호화하고, 암호문을 수신자에게 전송한다. 수신자는 대응하는 개인키를 사용해 암호문을 해독하고 원문을 복원한다.
이 방법의 장단점을 살펴보자:
신원 기반 암호화 (IBE)
사용자의 신원은 그들의 공개키로 표현되며, 즉 공개키는 암호화뿐 아니라 사용자의 고유 식별자 역할도 수행한다. 그러나 이 방법은 하나 이상의 신뢰할 수 있는 제3자가 키를 생성하고 배포해야 하므로, 이들 제3자에 대한 의존성이 필요하다. 또한 이 제3자들은 시스템의 전체 수명 주기 동안 마스터 키를 보관해야 하며, 이 마스터 키는 특정 상황에서 복호화나 기타 중요한 작업에 사용될 수 있다.
IBE 시스템에서 사용자는 기존 암호화 시스템처럼 스스로 키 쌍을 생성하지 않는다. 대신 사용자는 신뢰할 수 있는 키 생성기에 등록해야 한다. 키 생성기는 마스터 키 쌍(msk: 마스터 개인키, mpk: 마스터 공개키)을 소유한다. 사용자가 자신의 ID를 제공하면, 키 생성기는 msk와 사용자의 ID를 이용해 해당 사용자 전용의 개인키를 계산한다. 생성된 개인키는 안전한 경로를 통해 사용자에게 전달되어야 하며, 일반적으로 키 교환 프로토콜을 사용해 안전한 통신 채널을 구축한다.
발신자 입장에서 IBE는 암호화 과정을 단순화한다. 발신자는 키 생성기의 mpk를 단 한 번 다운로드하면, 이후부터는 수신자의 ID만으로 메시지를 암호화할 수 있다. 수신자 입장에서도 복호화는 간단하다. 등록된 사용자는 키 생성기가 제공한 개인키를 사용해 수신한 암호문을 해독할 수 있다.
키 생성기의 마스터 개인키(msk)는 시스템 운영 기간 내내 지속적으로 새로운 사용자 개인키를 생성해야 하므로 영구적으로 보관되어야 한다. 이는 일부 SNARK 시스템과 다르다. SNARK는 신뢰 설정 과정에서 생성되지만 설정 완료 후에는 삭제될 수 있다. 반면 IBE 시스템에서는 초기화 후 msk를 삭제할 수 없다.
msk가 철저히 보호되더라도, 각 등록 사용자는 여전히 키 생성기가 자신의 메시지를 열람하지 않음을 믿어야 한다. 왜냐하면 키 생성기는 언제든지 사용자 개인키의 사본을 보관하거나 msk를 이용해 개인키를 재계산할 수 있기 때문이다.
또한 키 생성기는 문제가 있거나 제한된 개인키를 제공할 가능성도 있다. 이러한 키는 대부분의 메시지는 해독할 수 있지만, 키 생성기가 사전에 설정한 특정 메시지만은 해독할 수 없는 형태일 수 있다. 이는 곧 키 생성기가 사용자의 복호화 능력을 조작함으로써, 사용자 간의 통신을 어느 정도 통제하거나 제한할 수 있다는 의미다.
등록 기반 암호화 (RBE)
IBE와 마찬가지로, 이 시스템에서도 사용자의 신원(예: 이메일 주소 또는 전화번호)이 직접 공개키 역할을 한다. 하지만 IBE와 달리, 이 시스템은 더 이상 신뢰할 수 있는 제3자나 quorum 집단에 의존하지 않는다. 대신 그러한 제3자를 'key curator(키 큐레이터)'라고 부르는 존재로 대체한다.
본 섹션에서는 RBE의 효율적인 구성 방식 하나를 논의할 것이다. 내가 아는 한, 이 방식은 다른 실용적인 RBE 구성보다 뚜렷한 장점을 가지며, pairing-based이기 때문에 블록체인에 배포할 수 있다는 점에서 lattice-based 방식과 차별화된다.
RBE 시스템에서 각 사용자는 스스로 키 쌍(공개키 및 개인키)을 생성한다. 또한 사용자는 자신의 개인키와 공개 참조 문자열(CRS)을 기반으로 일부 갱신 값(그림에서 'a'로 표시됨)을 계산해야 한다. 이 갱신 값은 시스템 내 추가 작업에 사용된다. CRS의 존재는 시스템 설정이 완전히 신뢰 불필요(trustless)하지 않다는 것을 의미한다. 그러나 CRS는 'tau의 거듭제곱'이라는 방법으로 생성되며, 이 과정은 체인 상에서 여러 참여자가 협력하여 계산할 수 있다. 단 하나라도 정직한 참여자가 존재한다면, 이 CRS는 안전하다고 간주된다.
스마트 계약은 예상 사용자 수 N에 맞춰 설정되며, 사용자들은 서로 다른 buckets(버킷) 그룹으로 분류된다. 사용자가 시스템에 등록할 때는 자신의 신원 ID, 공개키, 갱신 값을 스마트 계약에 전송해야 한다. 스마트 계약은一组 공공 파라미터 pp를 유지하는데, 이 pp는 앞서 언급한 CRS와는 다르다. pp는 시스템에 등록된 모든 사용자의 공개키를 간결하게 요약한 것으로 이해할 수 있다. 스마트 계약은 사용자의 등록 요청을 받으면 갱신 값의 정확성을 검증한 후, 해당 사용자의 공개키를 pp 내 적절한 버킷에 곱하여 포함시킨다. 이 과정은 새로운 사용자의 공개키를 시스템의 공공 파라미터 집합에 통합하는 것으로, 이후 작업에 활용된다.
등록 기반 암호화(RBE) 시스템에서 사용자는 메시지를 복호화하는 데 필요한 보조 정보를 로컬에 저장해야 한다. 동일한 그룹에 속한 새로운 사용자가 등록될 때마다 이 정보는 갱신되어야 한다. 사용자는 블록체인을 직접 모니터링하여 수동으로 정보를 업데이트하거나, 스마트 계약이 제공하는 최근 등록 정보를 받아 정기적으로 자신의 복호화 정보를 최신 상태로 유지할 수 있다.
이 시스템에서 발신자가 해야 할 일은 두 가지뿐이다:
공개 참조 문자열(CRS) 다운로드: 단 한 번만 다운로드하면 이후로는 갱신할 필요가 없다.
공공 파라미터 다운로드: 발신자는 주기적으로 최신 공공 파라미터를 다운로드해야 한다. 발신자에게 중요한 것은 이 파라미터에 수신자의 공개키가 포함되어 있는지 여부이며, 반드시 최신 버전을 다운로드할 필요는 없다. 수신자의 공개키를 찾을 수 있으면 된다.
이후 발신자는 다운로드한 CRS, 공공 파라미터, 그리고 수신자의 신원 ID를 사용해 메시지를 암호화하고 수신자에게 전송할 수 있다. 즉, 발신자는 공공 파라미터에 수신자의 공개키가 포함되어 있는 한, 데이터를 자주 갱신할 필요가 없다.
사용자가 암호화된 메시지를 수신했을 때, 먼저 로컬에 저장된 보조 정보를 확인하여 특정 조건(예: 특정 검증 절차를 통과한 값)을 만족하는 값이 있는지 검사한다. 만약 로컬에 그런 값이 없다면, 스마트 계약에서 최신 갱신 정보를 가져와야 함을 의미한다. 적절한 보조 정보 값을 찾은 후에는, 이를 자신의 개인키와 함께 사용해 암호문을 복호화하고 원래 메시지를 복원할 수 있다.
분명히 이 방식은 다른 두 가지 방식보다 더 복잡하다. 그러나 체인상 저장 공간은 공개키 디렉터리보다 적게 필요하며, IBE의 강력한 신뢰 가정도 피할 수 있다.
간결한 파라미터:
체인상에 저장되는 파라미터의 크기는 사용자 수에 대해 아드리니어(sub-linear) 관계를 갖는다. 이는 공개키 디렉터리의 선형 증가보다 훨씬 작지만, 여전히 상수는 아니므로 IBE 시스템만큼 효율적이진 않다.
일정 수준의 상호작용성(암호화):
메시지를 보낼 때, 발신자는 수신자가 포함된 공공 파라미터 사본이 필요하다. 즉, 발신자는 수신자가 등록된 이후 어느 시점에서든 파라미터를 갱신해야 한다. 그러나 각 수신자마다 개별적으로 갱신할 필요는 없으며, 한 번의 갱신으로 여러 수신자의 키를 포함할 수 있다. 전반적으로 메시지 전송 시의 상호작용성은 IBE보다 많지만, 공개키 디렉터리를 사용하는 것보다는 적다.
일정 수준의 상호작용성(복호화):
암호화와 마찬가지로, 수신자는 암호화 시 사용된 공공 파라미터 버전과 일치하는 보조 정보를 보유해야 한다. 특정 그룹에 새로운 사용자가 등록되면 공공 파라미터와 보조 정보가 갱신되며, 암호문을 해독할 수 있는 값은 암호화 당시 사용된 파라미터 버전에 대응한다. 사용자는 실패할 때까지 매번 즉시 갱신하지 않고 정기적으로 보조 정보를 갱신할 수 있다. 공공 파라미터 갱신과 달리, 보조 정보를 더 자주 갱신하더라도 개인정보가 노출되지 않는다.
발신자 익명성:
공개키 디렉터리와 유사하게, 발신자는 독립적으로 메시지를 암호화할 수 있다(최신 파라미터만 있으면 됨). 발신자가 체인상에서 정보를 읽을 때, 그 정보는 수신자와 무관하다(특정 파라미터 분할 그룹만 요청하는 경우를 제외하면, 이 경우 일부 정보가 유출될 수 있음).
투명성:
시스템은 신뢰 설정(분산 또는 외부 관리 가능)을 통해 시작되어 수정된 CRS(공개 참조 문자열)를 출력하지만, 일단 설정이 완료되면 더 이상 신뢰할 수 있는 제3자나 중재 그룹에 의존하지 않는다. 비록 조정 역할을 하는 제3자(스마트 계약)에 의존하지만, 이 시스템은 완전히 투명하며 누구나 조정자 역할을 하거나 상태 전이를 검증함으로써 정직하게 운영되고 있는지 확인할 수 있다(그래서 스마트 계약으로 구현 가능). 또한 사용자는 자신이나 타인이 시스템에 등록되었는지 확인하기 위해 간결한(비)멤버십 증명을 요청할 수 있다. 이는 IBE와 대조된다. IBE에서는 신뢰할 수 있는 제3자가 복호화 키를 비밀리에 유출하지 않았음을 입증하기 어렵다(예: 비밀 사본을 보관하거나 타인에게 유출). 반면 공개키 디렉터리는 완전히 투명하다.
제한된 ID 집합:
여기 설명된 RBE 구조는 기본 버전이다. ID가 속한 버킷을 투명하게 결정하기 위해 ID는 공개적이고 결정적인 순서를 가져야 한다. 전화번호는 쉽게 정렬 가능하지만, 임의의 문자열을 정렬하는 것은 매우 복잡하거나 불가능할 수 있다. 특히 버킷 수가 매우 많거나 무한할 수 있기 때문이다. 이 복잡성은 ID 매핑을 계산하는 별도의 계약을 제공하거나, 후속 연구에서 제안된 cuckoo-hashing 기법을 채택함으로써 완화할 수 있다.
수신자 익명성:
이 방법을 통해 암호문이 수신자의 신원을 노출하지 않도록 할 수 있다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
a16z
