DPKI: 블록체인을 사용하여 중앙 집중식 PKI의 단점 제거

개방형 네트워크에서 데이터 보호가 불가능한 일반적으로 사용되는 보조 도구 중 하나가 디지털 인증서 기술이라는 것은 비밀이 아닙니다. 그러나 기술의 가장 큰 단점은 디지털 인증서를 발급하는 센터에 대한 무조건적인 신뢰라는 것은 비밀이 아닙니다. ENCRY의 기술 및 혁신 이사인 Andrey Chmora는 조직화에 대한 새로운 접근 방식을 제안했습니다. 공개 키 인프라 (공개 키 인프라, PKI)는 현재의 단점을 제거하는 데 도움이 되며 분산 원장(블록체인) 기술을 사용합니다. 하지만 가장 먼저 해야 할 일이 있습니다.

현재 공개 키 인프라의 작동 방식을 잘 알고 있고 주요 단점을 알고 있다면 아래에서 제안하는 변경 내용으로 건너뛸 수 있습니다.

디지털 서명과 인증서란 무엇입니까?인터넷에서의 상호작용에는 항상 데이터 전송이 수반됩니다. 우리 모두는 데이터가 안전하게 전송되는지 확인하는 데 관심이 있습니다. 그러나 보안이란 무엇입니까? 가장 많이 찾는 보안 서비스는 기밀성, 무결성 및 신뢰성입니다. 이를 위해 현재 비대칭 암호화 방법, 즉 공개 키를 사용한 암호화 방법이 사용됩니다.

이러한 방법을 사용하려면 상호 작용 대상에 공개 키와 비밀 키라는 두 개의 개별 쌍 키가 있어야 한다는 사실부터 시작해 보겠습니다. 이들의 도움으로 위에서 언급한 보안 서비스가 제공됩니다.

정보 전송의 기밀성은 어떻게 달성됩니까? 데이터를 보내기 전에 송신 가입자는 수신자의 공개 키를 사용하여 공개 데이터를 암호화(암호 변환)하고, 수신자는 쌍을 이루는 비밀 키를 사용하여 수신된 암호문을 복호화합니다.

전송된 정보의 무결성과 신뢰성은 어떻게 달성됩니까? 이 문제를 해결하기 위해 또 다른 메커니즘이 만들어졌습니다. 공개 데이터는 암호화되지 않지만 암호화 해시 함수를 적용한 결과(입력 데이터 시퀀스의 "압축" 이미지)는 암호화된 형식으로 전송됩니다. 이러한 해싱의 결과를 "다이제스트"라고 하며 전송 구독자("감시자")의 비밀 키를 사용하여 암호화됩니다. 다이제스트를 암호화하면 디지털 서명이 획득됩니다. 이는 일반 텍스트와 함께 수신자 가입자(“검증자”)에게 전송됩니다. 그는 증인의 공개 키에 있는 디지털 서명을 복호화하고 이를 암호화 해시 함수를 적용한 결과와 비교합니다. 검증자는 수신된 공개 데이터를 기반으로 독립적으로 계산합니다. 일치하는 경우 이는 데이터가 송신 구독자에 의해 인증되고 완전한 형식으로 전송되었으며 공격자가 수정하지 않았음을 나타냅니다.

개인 데이터 및 결제 정보를 다루는 대부분의 리소스(은행, 보험 회사, 항공사, 결제 시스템 및 세무 서비스와 같은 정부 포털)에서는 비대칭 암호화 방법을 적극적으로 사용합니다.

디지털 인증서는 그것과 어떤 관련이 있습니까? 간단 해. 첫 번째와 두 번째 프로세스 모두 공개 키를 포함하며 핵심적인 역할을 하기 때문에 키가 실제로 보낸 사람(서명 확인의 경우 증인) 또는 수신자에게 속하고 공개 키가 아닌지 확인하는 것이 매우 중요합니다. 공격자의 키로 교체되었습니다. 이것이 공개 키의 신뢰성과 무결성을 보장하기 위해 디지털 인증서가 존재하는 이유입니다.

참고: 공개 키의 신뢰성 및 무결성은 공개 데이터의 신뢰성 및 무결성과 동일한 방식, 즉 전자 디지털 서명(EDS)을 사용하여 확인됩니다.
디지털 인증서는 어디에서 제공되나요?신뢰할 수 있는 인증 기관 또는 CA(인증 기관)는 디지털 인증서를 발급하고 유지 관리하는 일을 담당합니다. 신청자는 CA에 인증서 발급을 요청하고, 등록센터(CR)에서 본인 확인을 거쳐 CA로부터 인증서를 받습니다. CA는 인증서의 공개 키가 해당 인증서가 발급된 엔터티에 정확히 속함을 보장합니다.

공개 키의 신뢰성을 확인하지 않으면 이 키를 전송/저장하는 동안 공격자가 이를 자신의 키로 대체할 수 있습니다. 대체가 발생하면 공격자는 발신 가입자가 수신 가입자에게 전송하는 모든 내용을 해독하거나 자신의 재량에 따라 공개 데이터를 변경할 수 있습니다.

비대칭 암호화가 가능한 모든 곳에서는 디지털 인증서가 사용됩니다. 가장 일반적인 디지털 인증서 중 하나는 HTTPS 프로토콜을 통한 보안 통신을 위한 SSL 인증서입니다. 다양한 관할권에 등록된 수백 개의 회사가 SSL 인증서 발급에 참여하고 있습니다. 주요 점유율은 IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave 등 XNUMX~XNUMX개의 대규모 신뢰할 수 있는 센터에 속합니다.

CA 및 CR은 다음을 포함하는 PKI의 구성 요소입니다.

• 디렉토리 열기 – 디지털 인증서의 안전한 저장을 제공하는 공용 데이터베이스입니다.
• 해지된 인증서 목록 – 취소된 공개 키의 디지털 인증서를 안전하게 저장하는 공개 데이터베이스(예: 쌍을 이루는 개인 키의 손상으로 인해) 인프라 주체는 이 데이터베이스에 독립적으로 액세스하거나 검증 프로세스를 단순화하는 특수 온라인 인증 상태 프로토콜(OCSP)을 사용할 수 있습니다.
• 인증서 사용자 – CA와 사용자 계약을 체결하고 디지털 서명을 확인하거나 인증서의 공개 키를 기반으로 데이터를 암호화한 서비스 대상 PKI 주체입니다.
• 팔로워 – 인증서의 공개 키와 쌍을 이루는 비밀 키를 소유하고 CA와 가입자 계약을 체결한 PKI 주체에게 서비스를 제공했습니다. 가입자는 동시에 인증서의 사용자가 될 수 있습니다.

따라서 CA, CR 및 공개 디렉터리를 포함하는 공개 키 인프라의 신뢰할 수 있는 엔터티는 다음을 담당합니다.

1. 지원자의 신원이 맞는지 확인합니다.
2. 공개 키 인증서를 프로파일링합니다.
3. 신원이 확실하게 확인된 신청자에 대하여 공개키증명서를 발급한다.
4. 공개키 인증서 상태를 변경합니다.
5. 공개키인증서 현황에 대한 정보 제공

PKI의 단점은 무엇입니까?PKI의 근본적인 결함은 신뢰할 수 있는 엔터티가 존재한다는 것입니다.
사용자는 CA와 CR을 무조건 신뢰해야 합니다.. 그러나 실습에서 알 수 있듯이 무조건적인 신뢰는 심각한 결과를 초래합니다.

지난 XNUMX년 동안 이 분야에서는 인프라 취약성과 관련된 몇 가지 주요 스캔들이 발생했습니다.

— 2010년에 Stuxnet 악성 코드는 RealTek 및 JMicron에서 훔친 디지털 인증서를 사용하여 서명되어 온라인으로 확산되기 시작했습니다.

- 2017년 구글은 시만텍이 위조된 인증서를 대량으로 발급했다고 비난했습니다. 당시 Symantec은 생산량 측면에서 가장 큰 CA 중 하나였습니다. Google Chrome 70 브라우저에서는 이 회사와 제휴 센터인 GeoTrust 및 Thawte에서 발행한 인증서에 대한 지원이 1년 2017월 XNUMX일 이전에 중단되었습니다.

CA가 손상되었고 그 결과 CA 자체는 물론 사용자와 가입자까지 모두가 피해를 입었습니다. 인프라에 대한 신뢰가 훼손되었습니다. 또한, 정치적 갈등 상황에서 디지털 인증서가 차단될 수 있으며, 이는 많은 리소스의 운영에도 영향을 미칠 수 있습니다. 이는 바로 몇 년 전 러시아 대통령 행정부에서 두려워했던 것입니다. 2016년에는 RuNet 사이트에 SSL 인증서를 발급하는 국가 인증 센터를 만들 가능성에 대해 논의했습니다. 현재 상황은 러시아의 국가 포털조차도 마찬가지입니다. 사용하다 미국 회사인 Comodo 또는 Thawte(Symantec의 자회사)에서 발행한 디지털 인증서입니다.

또 다른 문제가 있습니다 - 질문 사용자의 기본 인증(인증). 직접적인 개인 접촉 없이 CA에 디지털 인증서 발급을 요청한 사용자를 식별하는 방법은 무엇입니까? 이제 이는 인프라의 기능에 따라 상황에 따라 해결됩니다. 공개 등록부에서 정보를 가져옵니다(예: 인증서를 요청하는 법인에 대한 정보). 신청자가 개인인 경우 은행이나 우체국을 사용할 수 있으며 여권과 같은 신분증을 사용하여 신원을 확인합니다.

사칭을 목적으로 자격 증명을 위조하는 문제는 근본적인 문제입니다. 정보 이론상의 이유로 이 문제에 대한 완전한 해결책은 없다는 점에 유의하십시오. 선험적으로 신뢰할 수 있는 정보가 없으면 특정 주제의 신뢰성을 확인하거나 거부하는 것이 불가능합니다. 원칙적으로 확인을 위해서는 신청자의 신원을 증명하는 서류를 제시해야 합니다. 다양한 확인 방법이 있지만 그 중 어느 것도 문서의 진위를 완벽하게 보장하지 않습니다. 따라서 신청자의 신원에 대한 진위 여부도 보장할 수 없습니다.

이러한 단점을 어떻게 제거할 수 있습니까?현재 상태의 PKI 문제를 중앙 집중화로 설명할 수 있다면, 분산화가 확인된 단점을 부분적으로 제거하는 데 도움이 될 것이라고 가정하는 것이 논리적입니다.

분산화는 신뢰할 수 있는 엔터티의 존재를 의미하지 않습니다. 분산형 공개 키 인프라 (분산형 공개키 인프라, DPKI), CA나 CR이 필요하지 않습니다. 디지털 인증서라는 개념을 버리고 분산 레지스트리를 사용하여 공개 키에 대한 정보를 저장해 보겠습니다. 우리의 경우 블록체인 기술을 사용하여 연결된 개별 기록(블록)으로 구성된 선형 데이터베이스를 레지스터라고 부릅니다. 디지털 인증서 대신 '알림'이라는 개념을 도입하겠습니다.

제안된 DPKI에서 알림 수신, 확인 및 취소 프로세스는 다음과 같습니다.

1. 각 신청자는 등록 중에 양식을 작성하여 독립적으로 통지 신청서를 제출한 후 전문 풀에 저장되는 거래를 생성합니다.

2. 공개 키에 대한 정보는 소유자 세부 정보 및 기타 메타데이터와 함께 디지털 인증서가 아닌 분산 레지스트리에 저장되며 CA가 중앙 집중식 PKI에서 발급을 담당합니다.

3. 신청자의 신원에 대한 진위 여부 확인은 CR이 아닌 DPKI 사용자 커뮤니티의 공동 노력에 의해 사후에 수행됩니다.

4. 그러한 알림의 소유자만이 공개 키의 상태를 변경할 수 있습니다.

5. 분산원장에 누구나 접근하여 공개키 현황을 확인할 수 있다.

참고: 신청자의 신원에 대한 커뮤니티 확인은 얼핏 보면 신뢰할 수 없어 보일 수 있습니다. 그러나 오늘날 모든 디지털 서비스 사용자는 필연적으로 디지털 발자국을 남기고 있으며 이 프로세스는 계속해서 추진력을 얻을 것이라는 점을 기억해야 합니다. 법인의 공개 전자 등록부, 지도, 지형 이미지의 디지털화, 소셜 네트워크 등은 모두 공개적으로 사용 가능한 도구입니다. 언론인과 법 집행 기관의 조사 중에 이미 성공적으로 사용되었습니다. 예를 들어 벨링캣이나 말레이시아 보잉 추락 사고 경위를 연구하고 있는 합동수사팀 JIT의 조사를 떠올리는 것만으로도 충분하다.

그렇다면 분산형 공개 키 인프라가 실제로 어떻게 작동할까요? 기술 자체에 대한 설명을 살펴보겠습니다. 2018년에 특허를 받았습니다 그리고 우리는 그것을 우리의 노하우라고 당연히 생각합니다.

많은 공개 키를 소유한 소유자가 있다고 상상해 보십시오. 여기서 각 키는 레지스트리에 저장되는 특정 트랜잭션입니다. CA가 없으면 모든 키가 이 특정 소유자에게 속한다는 것을 어떻게 알 수 있습니까? 이 문제를 해결하기 위해 소유자와 지갑에 대한 정보가 포함된 제로 트랜잭션이 생성됩니다(등록소에 트랜잭션을 배치하기 위한 수수료가 차감됩니다). null 트랜잭션은 공개 키에 대한 데이터가 포함된 다음 트랜잭션이 연결되는 일종의 "앵커"입니다. 이러한 각 트랜잭션에는 특수한 데이터 구조, 즉 알림이 포함되어 있습니다.

알림은 기능 필드로 구성되고 소유자의 공개 키에 대한 정보를 포함하는 구조화된 데이터 세트입니다. 이 정보의 지속성은 분산 레지스트리의 관련 레코드 중 하나에 배치하여 보장됩니다.

다음 논리적 질문은 제로 트랜잭션이 어떻게 형성되는가입니다. 후속 트랜잭션과 마찬가지로 null 트랜잭션은 XNUMX개 데이터 필드의 집합입니다. 제로 트랜잭션이 형성되는 동안 지갑의 키 쌍(공개 키와 쌍을 이루는 비밀 키)이 관련됩니다. 이 키 쌍은 사용자가 지갑을 등록하는 순간 나타나며, 여기서 레지스트리에 제로 트랜잭션을 배치하고 이후 알림 작업에 대한 수수료가 인출됩니다.

그림과 같이 SHA256과 RIPEMD160 해시 함수를 순차적으로 적용하여 지갑 공개 키 다이제스트를 생성합니다. 여기서 RIPEMD160은 너비가 160비트를 초과하지 않는 데이터의 압축된 표현을 담당합니다. 레지스트리는 저렴한 데이터베이스가 아니기 때문에 이는 중요합니다. 공개 키 자체는 다섯 번째 필드에 입력됩니다. 첫 번째 필드에는 이전 트랜잭션에 대한 연결을 설정하는 데이터가 포함되어 있습니다. 제로 트랜잭션의 경우 이 필드에는 아무 것도 포함되지 않으므로 후속 트랜잭션과 구별됩니다. 두 번째 필드는 트랜잭션의 연결성을 확인하기 위한 데이터이다. 간결함을 위해 첫 번째 및 두 번째 필드의 데이터를 각각 "링크" 및 "체크"라고 부르겠습니다. 이러한 필드의 내용은 아래 그림에서 두 번째와 세 번째 트랜잭션을 연결하여 보여주는 것처럼 반복 해싱을 통해 생성됩니다.

처음 XNUMX개 필드의 데이터는 지갑의 비밀 키를 사용하여 생성된 전자 서명으로 인증됩니다.

그게 바로 null 트랜잭션이 풀로 전송되고 성공적인 확인 후 레지스트리에 입력됩니다. 이제 다음 거래를 여기에 "연결"할 수 있습니다. XNUMX이 아닌 트랜잭션이 어떻게 형성되는지 생각해 봅시다.

아마도 가장 먼저 눈에 띄는 것은 풍부한 키 쌍일 것입니다. 이미 익숙한 지갑 키 쌍 외에도 일반 키 쌍과 서비스 키 쌍이 사용됩니다.

일반 공개 키는 모든 것이 시작된 이유입니다. 이 키는 외부 세계(은행 및 기타 거래, 문서 흐름 등)에서 펼쳐지는 다양한 절차와 프로세스에 관여합니다. 예를 들어, 일반 쌍의 비밀 키를 사용하여 다양한 문서(지불 주문 등)에 대한 디지털 서명을 생성할 수 있으며 공개 키를 사용하여 이러한 지침을 후속적으로 실행할 때 이 디지털 서명을 확인할 수 있습니다. 유효합니다.

서비스 쌍은 등록된 DPKI 주제에 발급됩니다. 이 쌍의 이름은 그 목적에 해당합니다. 제로 트랜잭션 생성/확인 시에는 서비스 키가 사용되지 않습니다.

키의 목적을 다시 명확히 해보자:

1. 지갑 키는 null 거래와 null이 아닌 다른 거래를 모두 생성/검증하는 데 사용됩니다. 지갑의 개인키는 많은 일반 공개키의 소유자이기도 한 지갑 소유자만이 알고 있습니다.
2. 일반 공개 키는 중앙 집중식 PKI에서 인증서가 발급되는 공개 키와 목적이 유사합니다.
3. 서비스 키 쌍은 DPKI에 속합니다. 비밀키는 등록된 개체에게 발급되며 거래에 대한 디지털 서명을 생성할 때 사용됩니다(XNUMX거래 제외). 공개는 거래가 레지스트리에 게시되기 전에 거래의 전자 디지털 서명을 확인하는 데 사용됩니다.

따라서 두 개의 키 그룹이 있습니다. 첫 번째에는 서비스 키와 지갑 키가 포함됩니다. 이는 DPKI의 맥락에서만 의미가 있습니다. 두 번째 그룹에는 일반 키가 포함됩니다. 해당 키의 범위는 다양할 수 있으며 사용되는 응용 프로그램 작업에 따라 결정됩니다. 동시에 DPKI는 일반 공개 키의 무결성과 신뢰성을 보장합니다.

참고: 서비스 키 쌍은 다른 DPKI 엔터티에 알려질 수 있습니다. 예를 들어, 모든 사람에게 동일할 수 있습니다. 이러한 이유로 XNUMX이 아닌 각 거래의 서명을 생성할 때 두 개의 비밀 키가 사용되며 그 중 하나는 지갑 키입니다. 이는 많은 일반 키의 소유자이기도 한 지갑 소유자에게만 알려집니다. 공개 키. 모든 키에는 고유한 의미가 있습니다. 예를 들어, 서명이 비밀 서비스 키에서도 생성되었으므로 등록된 DPKI 주체가 해당 거래를 레지스트리에 입력했음을 항상 증명할 수 있습니다. 그리고 거래마다 소유자가 비용을 지불하기 때문에 DOS 공격과 같은 남용이 있을 수 없습니다.

256을 따르는 모든 거래는 비슷한 방식으로 형성됩니다. 공개 키(160 거래의 경우 지갑이 아니라 일반 키 쌍에서 나온)는 두 개의 해시 함수 SHAXNUMX 및 RIPEMDXNUMX을 통해 실행됩니다. 이것이 세 번째 필드의 데이터가 형성되는 방식입니다. 네 번째 필드에는 관련 정보(예: 현재 상태, 만료 날짜, 타임스탬프, 사용된 암호화 알고리즘 식별자 등에 대한 정보)가 포함됩니다. 다섯 번째 필드에는 서비스 키 쌍의 공개 키가 포함되어 있습니다. 도움을 받으면 디지털 서명이 확인되어 복제됩니다. 그러한 접근 방식의 필요성을 정당화해 보겠습니다.

트랜잭션은 풀에 입력되어 처리될 때까지 그곳에 저장된다는 점을 기억하세요. 풀에 저장하는 것은 특정 위험과 관련이 있습니다. 즉, 거래 데이터가 위조될 수 있습니다. 소유자는 전자 디지털 서명으로 거래 데이터를 인증합니다. 이 디지털 서명을 확인하기 위한 공개 키는 거래 필드 중 하나에 명시적으로 표시되며 이후 레지스트리에 입력됩니다. 거래 처리의 특징은 공격자가 자신의 재량에 따라 데이터를 변경한 다음 자신의 비밀 키를 사용하여 이를 확인할 수 있고 거래에서 디지털 서명을 확인하기 위해 쌍을 이루는 공개 키를 나타낼 수 있다는 것입니다. 디지털 서명을 통해서만 진위성과 무결성이 보장된다면 그러한 위조는 눈에 띄지 않을 것입니다. 그러나 디지털 서명 외에도 저장된 정보의 보관 및 지속성을 보장하는 추가 메커니즘이 있는 경우 위조를 감지할 수 있습니다. 이를 위해서는 소유자의 진짜 공개 키를 레지스트리에 입력하는 것으로 충분합니다. 이것이 어떻게 작동하는지 설명해 보겠습니다.

공격자가 거래 데이터를 위조하도록 하세요. 키와 디지털 서명의 관점에서 다음 옵션이 가능합니다.

1. 공격자는 소유자의 디지털 서명이 변경되지 않은 상태에서 자신의 공개 키를 거래에 배치합니다.
2. 공격자는 자신의 개인 키에 디지털 서명을 생성하지만 소유자의 공개 키는 변경되지 않은 상태로 둡니다.
3. 공격자는 자신의 개인 키에 디지털 서명을 생성하고 한 쌍의 공개 키를 거래에 배치합니다.

분명히 옵션 1과 2는 디지털 서명 확인 중에 항상 감지되므로 의미가 없습니다. 옵션 3만 의미가 있으며, 공격자가 자신의 비밀 키에 디지털 서명을 형성하면 소유자의 공개 키와는 다른 쌍의 공개 키를 트랜잭션에 저장해야 합니다. 이는 공격자가 위조된 데이터를 강요할 수 있는 유일한 방법입니다.

소유자가 개인 키와 공개 키라는 고정된 쌍을 가지고 있다고 가정해 보겠습니다. 이 쌍의 비밀 키를 사용하여 디지털 서명으로 데이터를 인증하면 공개 키가 트랜잭션에 표시됩니다. 또한 이 공개 키가 이전에 레지스트리에 입력되었고 그 신뢰성이 확실하게 확인되었다고 가정해 보겠습니다. 그런 다음 거래의 공개 키가 레지스트리의 공개 키와 일치하지 않는다는 사실로 위조가 표시됩니다.

요약하자. 소유자의 첫 번째 거래 데이터를 처리할 때 레지스트리에 입력된 공개 키의 진위 여부를 확인하는 것이 필요합니다. 이렇게 하려면 레지스트리에서 키를 읽고 보안 경계(상대적으로 취약한 영역) 내 소유자의 실제 공개 키와 비교하세요. 키의 진위가 확인되고 배치 시 지속성이 보장되면 후속 트랜잭션의 키 진위를 레지스트리의 키와 비교하여 쉽게 확인/반박할 수 있습니다. 즉, 레지스트리의 키가 참조 샘플로 사용됩니다. 다른 모든 소유자 거래는 유사하게 처리됩니다.

거래는 전자 디지털 서명으로 인증됩니다. 여기서는 비밀 키가 필요하며 하나가 아닌 서비스 키와 지갑 키가 동시에 두 개 필요합니다. 두 개의 비밀 키를 사용함으로써 필요한 수준의 보안이 보장됩니다. 결국 서비스 비밀 키는 다른 사용자에게 알려질 수 있는 반면 지갑의 비밀 키는 일반 키 쌍의 소유자에게만 알려집니다. 우리는 이러한 두 개의 키 서명을 "통합" 디지털 서명이라고 부릅니다.

Null이 아닌 트랜잭션의 확인은 지갑과 서비스 키라는 두 개의 공개 키를 사용하여 수행됩니다. 검증 프로세스는 두 가지 주요 단계로 나눌 수 있습니다. 첫 번째는 지갑의 공개 키 다이제스트를 확인하는 것이고, 두 번째는 두 개의 비밀 키를 사용하여 형성된 동일한 통합 트랜잭션의 전자 디지털 서명을 확인하는 것입니다. 지갑 및 서비스). 디지털 서명의 유효성이 확인되면 추가 확인 후 거래가 등록부에 입력됩니다.

논리적인 질문이 발생할 수 있습니다. 트랜잭션이 제로 트랜잭션 형태의 "루트"가 있는 특정 체인에 속하는지 여부를 어떻게 확인합니까? 이를 위해 확인 프로세스에는 연결 확인이라는 한 단계가 더 추가됩니다. 여기에서 지금까지 무시했던 처음 두 필드의 데이터가 필요합니다.

실제로 3번 거래가 2번 거래 이후에 발생하는지 확인해야 한다고 가정해 보겠습니다. 이를 위해 결합된 해싱 방법을 사용하여 트랜잭션 번호 2의 세 번째, 네 번째 및 다섯 번째 필드의 데이터에 대해 해시 함수 값을 계산합니다. 그런 다음 트랜잭션 번호 3의 첫 번째 필드의 데이터와 트랜잭션 번호 2의 세 번째, 네 번째 및 다섯 번째 필드의 데이터에 대해 이전에 획득한 결합된 해시 함수 값의 연결이 수행됩니다. 이 모든 것은 두 개의 해시 함수 SHA256 및 RIPEMD160을 통해 실행됩니다. 수신된 값이 트랜잭션 번호 2의 두 번째 필드에 있는 데이터와 일치하면 검사가 통과되고 연결이 확인됩니다. 이는 아래 그림에서 더 명확하게 표시됩니다.

일반적으로 알림을 생성하고 등록부에 입력하는 기술은 다음과 같습니다. 알림 체인을 형성하는 프로세스를 시각적으로 보여 주는 그림은 다음과 같습니다.

이 글에서는 의심할 여지 없이 존재하는 세부 사항에 대해서는 다루지 않고 분산형 공개 키 인프라에 대한 아이디어 자체에 대한 논의로 돌아가겠습니다.

따라서 신청자 자신이 CA 데이터베이스가 아닌 레지스트리에 저장되는 알림 등록 신청서를 제출하므로 DPKI의 주요 아키텍처 구성 요소를 고려해야 합니다.

1. 유효한 통지(RDN) 등록.
2. 철회된 통지(RON)를 등록합니다.
3. 일시 중지된 알림(RPN) 등록.

공개 키에 대한 정보는 해시 함수 값의 형태로 RDN/RON/RPN에 저장됩니다. 일반 공개 키의 상태(폐기, 정지 등)에 대한 정보가 해당 코드 값 형태의 데이터 구조의 네 번째 필드입니다. DPKI의 아키텍처 구현에는 다양한 옵션이 있으며, 둘 중 하나를 선택하는 것은 공개 키 저장을 위한 장기 메모리 비용과 같은 최적화 기준과 같은 여러 요소에 따라 달라집니다.

따라서 DPKI는 더 단순하지는 않더라도 최소한 아키텍처 복잡성 측면에서 중앙 집중식 솔루션과 비교할 수 있는 것으로 판명될 수 있습니다.

주요 질문은 남아 있습니다 - 기술 구현에 적합한 레지스트리는 무엇입니까?

레지스트리의 주요 요구 사항은 모든 유형의 트랜잭션을 생성하는 기능입니다. 원장의 가장 유명한 예는 비트코인 ​​네트워크입니다. 그러나 위에서 설명한 기술을 구현할 때 기존 스크립팅 언어의 한계, 임의의 데이터 집합을 처리하는 데 필요한 메커니즘 부족, 임의 유형의 트랜잭션을 생성하는 방법 등의 어려움이 발생합니다.

ENCRY는 위에 공식화된 문제를 해결하기 위해 노력했으며 레지스트리를 개발했습니다. 우리 의견으로는 다음과 같은 여러 가지 장점이 있습니다.

• 여러 유형의 거래를 지원합니다. 자산 교환(즉, 금융 거래 수행)과 임의의 구조로 거래를 생성할 수 있습니다.
• 개발자는 다양한 기술 문제를 해결할 때 필요한 유연성을 제공하는 독점 PrismLang 프로그래밍 언어에 액세스할 수 있습니다.
• 임의의 데이터 세트를 처리하기 위한 메커니즘이 제공됩니다.

단순화된 접근 방식을 취하면 다음과 같은 일련의 작업이 수행됩니다.

1. 신청자는 DPKI에 등록하고 디지털 지갑을 받습니다. 지갑 주소는 지갑 공개 키의 해시 값입니다. 지갑의 개인키는 신청자 본인만이 알고 있습니다.
2. 등록된 주체에게는 서비스 비밀 키에 대한 액세스 권한이 부여됩니다.
3. 주체는 제로 트랜잭션을 생성하고 지갑의 비밀 키를 사용하여 디지털 서명으로 이를 확인합니다.
4. XNUMX이 아닌 거래가 형성되면 지갑과 서비스 키라는 두 개의 비밀 키를 사용하여 전자 디지털 서명으로 인증됩니다.
5. 주체는 트랜잭션을 풀에 제출합니다.
6. ENCRY 네트워크 노드는 풀에서 트랜잭션을 읽고 디지털 서명과 트랜잭션 연결을 확인합니다.
7. 디지털 서명이 유효하고 연결이 확인되면 등록부에 입력할 거래를 준비합니다.

여기서 레지스트리는 유효한 알림, 취소된 알림, 일시 중지된 알림에 대한 정보를 저장하는 분산 데이터베이스 역할을 합니다.

물론 탈중앙화가 만병통치약은 아닙니다. 기본 사용자 인증의 근본적인 문제는 어디에서나 사라지지 않습니다. 현재 신청자 확인이 CR에 의해 수행되는 경우 DPKI에서는 확인을 커뮤니티 구성원에게 위임하고 재정적 동기를 사용하여 활동을 활성화하는 것이 제안됩니다. 오픈소스 검증 기술은 잘 알려져 있다. 이러한 검증의 효과는 실제로 확인되었습니다. 온라인 간행물 Bellingcat의 여러 주요 조사를 다시 한번 상기해 보겠습니다.

그러나 일반적으로 다음과 같은 그림이 나타납니다. DPKI는 중앙 집중식 PKI의 많은 단점을 수정할 수 있는 기회입니다.

Habrablog를 구독하시면 앞으로도 당사의 연구 개발 활동을 적극적으로 다룰 예정입니다. 트위터, ENCRY 프로젝트에 대한 다른 소식을 놓치고 싶지 않다면.

출처 : habr.com