공개 키 암호화의 핵심 과제를 해결하기 위해 a16z가 선호하는 세 가지 솔루션

출처: 노에미 글레이저, a16z 크립토

공개키 암호화에서는 암호화 키(예: 공개키)를 특정 신원( 특정 개인이나 조직 등)과 올바르게 연결하는 것이 항상 어려웠습니다. 이 문제의 핵심은 신원과 공개키 간의 관계를 공개적이고 일관된 방식으로 표시하여 모든 사람이 공개키를 사용하여 정보를 암호화할 수 있도록 하는 것입니다.

이러한 명확한 관계가 없으면 누군가가 특정 공개키가 누구의 것인지 확인할 수 없어 암호화된 정보가 엉뚱한 사람에게 전송되어 정보 유출이나 기타 심각한 결과를 초래할 수 있습니다. Web3에서는 이 문제가 여전히 존재합니다.

위에서 설명한 문제에 대한 해결책에는 공개 키 디렉토리, 신원 기반 암호화(IBE), 등록 기반 암호화(RBE)의 세 가지가 있습니다. 이 세 가지 접근 방식은 익명성, 상호 작용성, 효율성 측면에서 각각 고유한 장점이 있습니다. 예를 들어, IBE는 강력한 신뢰 기반이 필요하지만 경우에 따라서는 익명성과 효율성 측면에서 IBE가 더 나은 성능을 발휘하기도 합니다. 이 백서의 목적은 블록체인에서 이 세 가지 접근 방식을 살펴보고 장단점을 비교하는 것입니다.

세 가지 접근 방식

일반적으로 암호화 키를 신원 정보와 연결하는 일반적인 접근 방식은 공개 키 카탈로그가 핵심 구성 요소인 공개 키 인프라(PKI)를 사용하는 것입니다. 이 접근 방식에서는 메시지를 보내는 사람이 암호화된 메시지를 전송하기 위해 신뢰할 수 있는 제3자(즉, 이 디렉터리를 관리하는 기관, 일반적으로 인증 기관)와 상호 작용해야 합니다.

그러나 웹2.0 환경에서는 이 공개 키 디렉터리를 유지 관리하는 데 비용이 많이 들고 번거롭습니다. 또한 사용자는 인증 기관의 잠재적인 악용 위험에 노출됩니다.

공개 키 인프라(PKI)의 문제를 해결하기 위해 암호학자들이 몇 가지 대안을 제안했습니다. 1984년 아디 샤미르는 당사자의 식별자(예: 전화번호, 이메일 또는 ENS 도메인 이름)를 공개 키로 직접 사용할 수 있는 신원 기반 암호화(IBE)를 제안했습니다. 이 방식은 공개 키 카탈로그를 유지할 필요가 없었지만, 개인 키를 생성할 때 신뢰할 수 있는 제3자(키 생성자)에 의존해야 한다는 새로운 문제가 발생했습니다.

최초의 실용적인 IBE 구성은 2001년에 Dan Boneh와 Matthew Franklin에 의해 제안되었지만 이 기술은 널리 채택되지 않았으며 주로 기업 또는 정부 배포 환경과 같은 폐쇄적인 에코시스템에서 사용되었습니다.IBE가 널리 사용되지 않은 이유는 다음과 같습니다. IBE가 널리 사용되지 않은 이유 중 하나는 강력한 신뢰 가정, 즉 타사에서 생성한 키에 대한 신뢰에 의존하기 때문일 수 있습니다.

그러나 이 백서의 뒷부분에서 설명하겠지만, 이 신뢰 문제는 신뢰할 수 있는 다수(즉, 참가자 그룹의 정족수)에 의존함으로써 해결할 수 있으며, 이는 블록체인 기술을 통해 쉽게 달성할 수 있습니다.

장단점

이러한 암호화 체계를 비교할 때 고려해야 할 여러 가지 요소가 있으며, 저는 이에 대해 두 가지 가정을 하고 있습니다.

사용자가 키를 업데이트하거나 해지하지 않음: 이 논의에서는 각 사용자의 키가 고정되어 있고 변경되지 않는다고 가정합니다.

스마트 컨트랙트는 오프체인 데이터 가용성 서비스(DAS) 또는 블롭 데이터를 사용하지 않습니다: 즉, 스마트 컨트랙트는 온체인 데이터에만 의존하며 오프체인 데이터 서비스나 추가 데이터 저장소가 관여하지 않는다고 가정합니다.

공개 키 디렉토리

누구나 스마트 컨트랙트를 호출하여 다른 사람이 차지하지 않은 ID, 일명 '(id, pk)&39;항목을 온체인 디렉토리에 추가할 수 있습니다.

탈중앙화된 PKI는 다른 사람이 점유하지 않은 ID를 통해 PKI를 사용하는 것을 말합니다. 스마트 컨트랙트를 통해 ID(신원) 및 해당 공개 키의 카탈로그를 유지하는 것을 말합니다. 이 디렉토리는 공개적이며 중앙화된 제3자에 의존하지 않습니다. 예를 들어, 도메인 이름(즉, ID)과 도메인 이름이 확인되는 주소(그리고 해당 주소의 거래에서 공개 키를 파생할 수 있는 주소)를 포함한 관련 메타데이터에 대한 매핑을 유지하는 ENS를 예로 들 수 있습니다. ENS는 공개 키뿐만 아니라 다른 메타데이터도 저장하는 좀 더 복잡한 시스템입니다. 탈중앙화 PKI의 기능은 비교적 간단합니다. 스마트 콘트랙트는 단순히 각 신원에 해당하는 공개 키 목록을 유지 관리합니다.

사용자가 ID를 등록하려면 먼저 키 쌍(공개 및 개인)을 생성하거나 이미 생성된 키 쌍을 사용하고, 스마트 컨트랙트에 ID ID와 공개 키를 전송(유료일 수 있음)하면, 스마트 컨트랙트는 다른 사람이 이미 등록한 ID가 있는지 확인해야 합니다. 만약 이미 등록되지 않았다면 스마트 컨트랙트는 이 ID와 공개 키를 디렉터리에 추가합니다. 등록이 완료되면 누구나 스마트 컨트랙트에 특정 ID에 해당하는 공개 키를 요청하여 해당 사용자에게 보낼 메시지를 암호화할 수 있습니다. 발신자가 이전에 이미 해당 사용자에게 메시지를 암호화하여 해당 사용자의 공개 키를 이미 가지고 있다면 스마트 컨트랙트에 공개 키를 다시 요청할 필요가 없습니다. 발신자는 공개 키를 사용하여 평소처럼 메시지를 암호화한 다음, 암호화된 메시지를 수신자에게 보내면 수신자는 해당 개인 키를 사용하여 메시지를 해독하고 원본을 복구할 수 있습니다.

이 방법의 장단점을 살펴봅시다.

장점비대화형 복호화 : 복호화 프로세스에는 다른 당사자와의 상호작용이 필요하지 않으며, 복호화자가 독립적으로 복호화를 완료할 수 있습니다. 간결하지 않음: 시스템이 어떤 면에서 간결하지 않을 수 있으며, 이는 더 복잡하거나 더 많은 데이터 또는 더 많은 리소스를 의미할 수 있습니다. 투명성: 시스템이 어떤 면에서 투명하지 않을 수 있으며, 이는 운영이 공개되어 있고 검토가 가능하다는 것을 의미합니다. 대화형 암호화: 암호화 프로세스에는 다른 당사자와의 상호 작용이 필요할 수 있어 복잡성이 추가될 수 있습니다. 임의 ID: 사용자는 특정 형식이나 규칙의 제약을 받지 않고 임의의 ID를 자유롭게 선택하거나 사용할 수 있습니다. 발신자의 비익명성: 발신자의 신원이 시스템에서 완전히 익명으로 유지되지 않을 수 있습니다.

신원 기반 암호화(IBE)

사용자의 신원은 공개 키로 표시되며, 이는 공개 키가 암호화에 사용될 뿐만 아니라 사용자의 고유 식별자 역할도 함을 의미합니다. 그러나 이 접근 방식은 키를 생성하고 배포할 책임이 있는 하나 이상의 신뢰할 수 있는 제3자에게 의존해야 합니다. 또한 이러한 제3자는 시스템 수명 기간 동안 마스터 키를 보유해야 하며, 경우에 따라 암호 해독 또는 기타 중요한 작업에 사용될 수 있습니다.

IBE 시스템에서 사용자는 다음을 수행하지 않습니다. 기존 암호화 시스템에서처럼 자신만의 공개 키와 개인 키를 생성하지 않습니다. 대신, 사용자는 신뢰할 수 있는 키 생성기에 등록해야 합니다. 키 생성기에는 한 쌍의 마스터 키(마스터 개인 키 msk와 마스터 공개 키 mpk 포함)가 있습니다. 사용자가 자신의 ID를 제공하면 키 생성기는 마스터 개인 키 msk와 사용자의 ID를 사용하여 해당 사용자에게 특정한 개인 키를 계산합니다. 생성된 개인 키는 일반적으로 키 교환 프로토콜을 사용하여 설정되는 보안 채널을 통해 사용자에게 전달되어야 합니다.

발신자의 경우, IBE 시스템은 암호화 프로세스를 간소화합니다. 발신자는 키 생성기의 마스터 공개 키(mpk)를 한 번만 다운로드하면 되고, 그 이후에는 이 ID를 사용하여 메시지를 암호화할 수 있습니다. 수신자의 경우 암호 해독도 간단합니다. 등록된 사용자는 키 생성기가 전송한 개인키를 사용하여 수신한 암호문을 해독할 수 있습니다.

키 생성기의 마스터 개인키(msk)는 시스템 운영 중에 지속적으로 새로운 사용자 개인키를 생성해야 하므로 장기간 보관해야 합니다. 이는 신뢰할 수 있는 설정 중에 생성되지만 설정이 완료된 후 파기할 수 있는 일부 SNARK 시스템과는 다릅니다. 반면에 IBE 시스템에서는 SNARK에서처럼 초기화 후 마스터 개인 키를 삭제할 수 없습니다.

마스터 개인 키(msk)가 제대로 저장되어 있더라도 등록된 각 사용자는 키 생성자가 자신의 메시지를 읽지 않을 것이라고 신뢰해야 합니다. 이는 키 생성자가 항상 사용자의 개인키 사본을 보관하거나 마스터 개인키를 사용하여 사용자의 개인키를 다시 계산할 수 있기 때문입니다.

키 생성자가 사용자에게 대부분의 메시지를 해독할 수 있지만 키 생성자가 설정한 일부 특정 메시지는 해독하지 못하는 결함이 있거나 제한된 개인키를 제공할 수도 있습니다. 이는 키 생성자가 사용자의 암호 해독 기능을 조작할 수 있으므로 사용자의 통신을 어느 정도 통제하거나 제한할 수 있음을 의미합니다.

장점 일정/최소 온체인 스토리지: 블록체인에서 시스템에 필요한 스토리지의 양이 적거나 일정하며 시간이 지나도 증가하지 않습니다. 강력한 신뢰 가정: 시스템은 하나 이상의 신뢰할 수 있는 제3자에 의존하므로 이러한 제3자에 대한 강력한 신뢰가 필요합니다. 이러한 제3자가 손상되거나 신뢰할 수 없는 경우 시스템의 보안이 손상됩니다. 비대화형 암호화: 암호화 프로세스에는 다른 당사자와의 상호 작용이 필요하지 않으며 발신자가 독립적으로 암호화를 완료할 수 있습니다. 발신자 익명성: 시스템은 개인정보를 보호하기 위해 발신자의 신원을 익명으로 유지할 수 있습니다. 임의 ID: 사용자는 특정 형식이나 규칙의 제한을 받지 않고 임의의 ID를 자유롭게 선택하거나 사용할 수 있습니다.

등록 기반 암호화(RBE)

IBE와 마찬가지로 이 시스템에서는 사용자의 신원(예: 이메일 주소 또는 전화번호)이 직접 공개 키로 작동합니다. 하지만 IBE와 달리 이 시스템은 더 이상 키를 관리하기 위해 신뢰할 수 있는 제3자나 쿼럼에 의존하지 않습니다. 대신, 이 신뢰할 수 있는 제3자가 키 큐레이터로 대체됩니다.

이 섹션에서는 RBE를 효율적으로 구성하는 방법에 대해 설명하겠습니다. 제가 아는 한, 이는 격자 기반이 아닌 페어링 기반이므로 블록체인에 배포할 수 있다는 점에서 다른 실용적인 RBE 구성보다 상당한 이점이 있기 때문입니다.

RBE 시스템에서는 각 사용자는 자신만의 키 쌍(공개 및 비공개)을 생성합니다. 또한 사용자는 자신의 개인 키와 공통 참조 문자열(CRS)을 기반으로 일부 업데이트 값(그림에서 a로 표시됨)을 계산해야 합니다. 이러한 업데이트된 값은 시스템에서 추가 작업에 사용됩니다. 공개 참조 문자열(CRS)이 존재한다는 것은 시스템이 완전히 신뢰할 수 없도록 설정되어 있지 않다는 것을 의미합니다. 그러나 CRS 생성 프로세스에서는 '타우의 거듭제곱'이라는 구성 방법을 사용합니다. 이 구성 방법은 체인의 여러 참여자가 공동으로 계산할 수 있습니다. 적어도 한 명의 참여자만 정직하다면 CRS는 안전합니다.

스마트 컨트랙트는 버킷으로 그룹화되고 시스템에 등록할 때 자신의 신원 ID, 공개 키, 업데이트 값을 스마트 컨트랙트에 보내야 하는 예상 사용자 수 N을 위해 설정됩니다. 스마트 컨트랙트는 앞서 언급한 공개 참조 문자열(CRS)과는 다른 일련의 공개 매개변수 pp를 유지합니다. pp는 시스템에 등록된 모든 사용자의 공개 키를 간결하게 요약한 것으로 이해할 수 있습니다. 스마트 콘트랙트는 사용자로부터 등록 요청을 받으면 업데이트된 값을 확인하여 올바른지 확인합니다. 확인이 완료되면 스마트 컨트랙트는 사용자의 공개 키를 적절한 버킷에 pp 단위로 곱합니다. 이 단계는 후속 작업을 위해 시스템의 공개 매개변수 집합에 새 사용자의 공개 키를 포함하는 것과 같습니다.

등록 기반 암호화(RBE) 시스템에서 사용자는 메시지를 해독하는 데 사용되는 일부 정보를 로컬에 보관해야 합니다. 이 정보는 새로운 사용자가 같은 그룹에 등록할 때 업데이트해야 합니다. 사용자는 블록체인을 직접 모니터링하여 이 정보를 수동으로 업데이트하거나, 스마트 컨트랙트가 최근에 등록된 사용자에 대한 정보를 제공할 수 있으며, 사용자는 주기적으로 이러한 업데이트를 가져와 해독된 메시지를 최신 상태로 유지할 수 있습니다.

이 시스템에서 발신자는 다음 두 가지 작업만 수행하면 됩니다.

공통 참조 문자열(CRS) 다운로드: 한 번만 다운로드하면 되고 이후에는 다시 업데이트할 필요가 없습니다.

공개 매개변수 다운로드: 발신자는 가끔씩 최신 공개 매개변수를 다운로드해야 합니다. 발신자는 수신자의 공개 키를 찾을 수 있는 한 매번 최신 버전을 다운로드할 필요 없이 이러한 공개 매개변수에 수신자의 공개 키가 포함되어 있는 것이 중요합니다.

그런 다음 발신자는 다운로드한 CRS, 공개 매개변수, 수신자의 ID를 사용하여 메시지를 암호화하여 수신자에게 전송합니다. 즉, 발신자는 데이터를 자주 업데이트할 필요 없이 수신자의 공개 키가 공개 매개변수에 있는지 확인하기만 하면 됩니다.

사용자는 암호화된 메시지를 받으면 먼저 로컬에 저장된 보조 정보를 확인하여 조건(예: 특정 유효성 검사를 통과한 값)과 일치하는 값이 있는지 확인하고, 조건에 맞는 값을 로컬에서 찾을 수 없는 경우 스마트 컨트랙트의 최신 업데이트를 가져와야 한다는 것을 의미합니다. 사용자가 보조 메시지에 적합한 값을 찾으면 이 값과 개인 키를 사용해 수신한 암호문을 해독하여 원래 메시지를 복구할 수 있습니다.

이 솔루션은 다른 두 솔루션보다 더 복잡합니다. 하지만 공개 키 카탈로그보다 온체인 저장소가 덜 필요하고 IBE의 강력한 신뢰 가정을 피할 수 있습니다.

매개변수의 단순성:

• 온체인에 저장되는 매개변수의 크기는 사용자 수에 따라 비선형이며, 이는 공개 키 디렉터리에 필요한 저장 공간(선형)보다 훨씬 작습니다. 디렉토리는 훨씬 적은 저장 공간을 필요로 하지만(선형적 증가), 여전히 일정하지 않으므로 이 점에서 IBE(신원 기반 암호화) 시스템보다 열등합니다.

일부 상호작용이 있는 암호화:

• 메시지를 보낼 때, 발신자에게는 대상 수신자가 포함된 공개 매개변수의 사본이 필요합니다. 즉, 발신자는 수신자가 등록된 후 어느 시점에 이러한 매개변수를 업데이트해야 하지만 한 번의 업데이트에 여러 수신자에 대한 키가 포함될 수 있으므로 각 수신자에 대해 개별적으로 업데이트할 필요는 없습니다. 전반적으로 메시지 전송은 IBE보다 대화형이지만 공개 키 카탈로그를 사용하는 것보다는 덜 대화형입니다.

일부 상호작용이 있는 복호화:

• 암호와 마찬가지로 수신자는 암호화에서 사용된 것과 유사한 공개 파라미터 버전의 복사본이 필요합니다. 암호화에 사용된 공개 매개변수 버전과 유사한 버전을 복사하여 보조 정보와 일치시켜야 합니다. 새 사용자가 그룹에 등록하면 암호화에 사용된 공개 매개변수 버전에 해당하는 값으로 암호문을 해독할 수 있도록 공개 매개변수 및 보조 정보가 업데이트됩니다. 사용자는 복호화에 실패하지 않는 한 보조 정보를 매번 즉시 업데이트하지 않고 주기적으로 업데이트하도록 선택할 수 있습니다. 공개 매개변수 업데이트와 달리 보조 정보 업데이트를 더 자주 받는다고 해서 개인 정보가 손상되지는 않습니다.

발신자 익명성:

• 공개 키 카탈로그의 경우와 마찬가지로 발신자는 독립적으로 메시지를 수신자와 관련된 특정 정보를 조회할 필요 없이 메시지를 독립적으로 암호화할 수 있습니다(최신 매개변수가 있는 경우). 발신자가 체인에서 정보를 읽어야 하는 경우, 해당 정보는 의도한 수신자와 무관합니다(발신자가 일부 정보를 유출할 수 있는 특정 매개변수 그룹만 요청하는 경우가 아니라면).

투명성:

• 시스템은 신뢰 설정(분산 또는 외부에서 관리할 수 있는 외부에서 관리)를 통해 설정하고 수정된 CRS(공통 참조 문자열)를 출력해야 하지만, 설정이 완료되면 더 이상 신뢰할 수 있는 제3자나 중재 그룹에 의존하지 않습니다. 조정하는 제3자(스마트 컨트랙트)에 의존하지만, 이 시스템은 완전히 투명하며 누구나 조정자 역할을 하거나 상태 전환을 확인하여 정직하게 운영되는지 확인할 수 있습니다(스마트 컨트랙트로 구현할 수 있는 이유). 또한 사용자는 자신 또는 다른 사람이 시스템에 등록되어 있는지 확인하기 위해 간결한 (비)회원 증명을 요청할 수 있습니다. 이는 신뢰할 수 있는 제3자가 복호화 키를 몰래 유출하지 않았음을 증명(예: 비밀 사본을 저장하거나 다른 사람에게 유출)하는 것이 어려운 IBE 시스템과 대조적입니다. 이와 대조적으로 공개 키 카탈로그는 완전히 투명합니다.

제한된 ID 집합:

• 다음은 RBE 구조의 기본 버전이 묘사된 것입니다. . ID가 속한 그룹을 투명하게 결정하기 위해서는 ID가 공통적이고 결정적인 순서를 가져야 합니다. 전화번호는 간단하게 순서를 정할 수 있지만 임의의 문자열은 그룹 수가 매우 많거나 무한대일 수 있기 때문에 순서를 정하는 것이 매우 복잡하거나 불가능할 수도 있습니다. 이러한 매핑을 계산하기 위해 별도의 계약을 제공하거나 후속 작업에서 제안한 뻐꾸기 해싱 접근 방식을 사용하면 이러한 문제를 완화할 수 있습니다.

수신자 익명성:

• 이 접근 방식을 사용하면 수신자의 신원을 밝히지 않는 암호 텍스트를 신원을 알 수 있습니다.