7일차 study (hyperledger indy)

hyperledger indy 는 hyperledger 프로젝트 중 DID 를 구축하고자 특화된

public-permissioned 블록체인 플랫폼이다.

 

- 누구나 사용 가능한 public 블록체인
- 노드 관리는 Permissioned (선출된 대표노드: 일명 Steward가 Validation / Write 역할을 함)

-  ZKP에 기반한 비 노출적 신원 증명 암호학 처리 (ZKP 는 영지식증명 알고리즘 으로 내정보를 노출하지 않고 나임을 증명 할 수 있다.)
- ZKP에 기반한 비 연결적 Identity 
- 자체적인 합의 시스템이 있다-> RBFT  (PBFT에서 View Change 부분을 개선한 버전) 

(PBFT 는 실용적 비잔틴 장애허용  으로 장애노드가 f 개 일때 3f+1의 노드 갯수만 있으면 정상적 이라는 입증된 수학적 알고리즘이다.

즉 3분의 2가 정상 노드이면 정상적으로 합의가 가능하다는 합의 알고리즘)
- 자신의 지갑에 개인정보 보관 및 관리 (지갑의 개념이 이더리움,비트코인의 그것보다 넓다. 즉 키 이외의 것도 저장) 
- 자체 장부를 가지고 있으며, 신뢰성있게 선출된 분산 장부에 Public 정보들을 저장 / 읽기 한다.  
- 보통 Agent라고 부르는 연관 End-Point 간에 암호화 된 연결 후 필요 정보 요청/검증 프로세스 
- 스마트 컨트랙트 기능은 없다. 

네트워크 구성
Vaildate node ( 노드 검증)
vaildato(검증자) 노드는 RBFT 구현인 Plenum 프로토콜에 의해 작동하며 주로 장부에 기록이 이루어짐

observer node (관찰자 노드)
원장읽기 전용 사본이며 아래 3가지 역할을 한다.
read requests : validate node의 성능에 영향을 주지 않고 id 레코드에 대한 수요가 확장될수있도록 함.
hot standbys(항시대기) : 기존 validate node 에서 기술적 문제가 발생할 경우 active validate node 로 서비스 전환 될 수 있음.
push subscriptions (구독): 이벤트 알림을 배포하는 수단을 제공함 .

 

agent (대리인)
에이전트는 p2p 메시징 엔드 포인트을 제공하여 일반적으로 자체 메시지이 엔드포인트를 제공하지 않는 인디 클라이언트의 통신을 용이
하게 합니다. sovrin 에이전트는 다양한 장치에서 작동하는 여러 sovrin 클라이언트 간에 메세지와 상태를 조정하며 agent 는 indy 키체인들의 암호화된 백업을 유지할 수 있고, ID 소유자를 위해 데이터를 단순하게 저저아하고 공유할 수 있습니다. indy 애소 아부분은
hyperledger aries 로 이전 됨.

- p2p란? (peer to peer network)

컴퓨터 끼리 연결되어 데이터를 주고 받음 

망구성에 참여하는 기계들의 계산과 대역폭 성능에 의존 하여 구성되는 통신망

 

did
사용자는 자신의 id 에 대해 기억할만한 이름을 만들어서 원장에 did 형식으로 변환하여 저장합니다.
did 는 탈중앙형 식별자로 pure DID는 암호학적 속성을 가지고 있지 않으며 version4 UUID를 사용하여 유니크하며 원장에 저장되고
원장에서 읽을 수 있습니다.
각 DID는 주어진 네트워크에서 특정한 method 사양과 연관되어 있으며, DID method 는 해당 네트워크에서 DID가 등록 , 확인,업데이트 및 해지 되는 방법에 대한 규칙을 지정 합니다.

DID Document
DID Document 에는 주로 해당 did 를 어떻게 검증 할수 있는지 에 대해서 나와있다. did 가 진짜 그사람의 소유인지를 확인하려면 DID의
쌍인 Private ket 를 가지고 있는지 확인하면 된다. Document 에 있는 did 소유자의 끝점을 통해 테스팅 할 수 있다. 또한 did 의 소유를 확인하기 위해서는 단일 소유주 뿐만 아니라 다양한 방식으로 테스트 할 수있는데 예를 들어 소유자가 회사의 구성원이라면 회사가 대신해서 검증 해 줄수 도 있을 것이다.

Verifiable credential (검증 가능한 자격증명)
정체성과 관련된 단일 속성을 Claim 이라고 하는데 claim 은 한명의 신분 소유자(사람 또는 조직)가 자신이나 다른 신분 소유자에 대해제공 하는 속성 정보를 말한다. 예를 들어 claim은 주민등록증 상의 나이를 나타낸다고 생각하면 된다.
2018년 Evernym 백서상에서 claim 들의 묶음인 claims라는 용어를 credential 로 바꿧다고 한다.
주민등록상 (혹은 주민등록증)의 모든 정보를 berifiable credential 이라고 하고, 해당 정보중 에 편의점에서 필요한 최소한의 노출정보를
verifiable presentation 이라고 한다.

claim(단일속성) -> credential(단일속성들의 전체합) -> presentation (노출시키고자 하는 속성만의 합)

interoperability of digital certificates (디지털 인증서의 상호 운용성)
디지털 인증서는 상호운용성을 보장하는 필수적인 형식인데. X.509는 식별자와 필요한 메타 데이터로 암호키를 바인딩하여 공개키 인증서를 정의하는 표준입니다. 이 X.509 인증서는 일반적으로 계충적 PKI 모델에서 작동하는 CA에 의해 배포되는 반면 DID 와 DDO는 디지털 아이덴티티가 피어로서 상호 운용될 수 있도록 합니다.검증 가능한 credential 을 상호작용, 연결 및 공유 할 때 peers는 필요에 따라 복수의 겹치는 "신뢰의 거미줄"을 형성하는데 X.509인증서를 생성하는 데 DID 및 DDO 핵심자료와 메타데이터를 사용할 수 있으며 ,X.509 인증서는 DID/DDO 모델과 함께 검증 가능한 Credential 으로 사용할 수있습니다. 이런식으로 두 모델 모두 서로와 상호작용을 될 수 있습니다.

 

 

스토리 라인

Actor

- government : 기본 schema 를 설정하는 역할 (schema 는 증명서를 뚯함)

- alice : faber college 에 성적표 요청 후 acme corp 에 입사 신청

- faber college : alice에게 증명서(성적표) 발급

- faber college : alice에게 성적표 발급

- acme corp : 지원자 alice 에게 성적표 요구 후 alice 에게 재직 증명서 발급

 

1 . steeward 의 trust Anchor 생성

steward 는 분산되어 did 관련 데이터를 블록체인에 저장/읽기 한다. steward 는 참여하는 모든 actor 들을 생성 할 수 있고 각 actor 에게 적당한 역할을 부여한다. (먼저 역할 분담 누가 학교,회사 ,지원자인지 정해놓는것)

2. 각자의 did 를 ledger(원장)에 생성

지원자가 자신의 ID를 만들고 DID를 ledger에 등록하는 부분

 

indy SDK 에서 이렇게 됨. (SDK 란 프로그래머를 위한 개발 도구 라고 생각하면 된다.)

 alice= { 이름, 지갑id, 지갑 비번, Indy풀) // 지갑 기본 정보를 만들고 
 create_wallet(alice)  // 지갑만들고 
 (alice['did'], alice['key']) = await did.create_and_store_my_did(alice['wallet'], "{}")  // did과 부속물을 만들어서 지갑에 저장하고 did키와 verifying key를 리턴해 준다. 

 

3. credential definition(작업증명 정의) 생성

alice 에게 credential 을 발급해주기 위해서 필요한 양식 (schema 와 credential definition) 들을 만들어 ledger 에 저장

 

goverment 는 기본 스키마를 ledger에  저장해두며 Faver college 는 alice 에게 성적표 발급에 필요한 Transcript Credetial Definition(성적 증명서 자격 정의) 을 만들어서 ledger 에 저장하고, Scme Corp 은 재직증명서를 발급하는데 필요한 job-

Certificate Credential Definition (직업인증서 자격 증명 정의) 을 만들어서 ledger에 저장한다.

4. credential 발급

alice 는  credential 을 faber college로 부터 발급받기 위하여 faber college 와 secure channel 을 생성한다.

생성된 안전한 xhannel 을 통하여 faber college는 Credetial Definition(자격정의)-항목 에 해당하는 alice 의 정보를 입력하여  alice 에게 전송

이름,학위,졸업여부,연도와학점,ssn 에대한 정보를 발급하여 alice 에게 전달.

발급받은 alice 에 지갑에 저장됨

 

5. credential 요청 및 검증

acme corp 은 alice 에게 학교 성적 관련 정보를 요청하기 위해 alice 와 secure channel 생성 후

회사 지원을 위해서 학위, 현재상태,ssn에 대한 정보가 필요하다고 alice에게 요청.

alice 는 faber college 로 받은 정보들을 기반으로 acme corp 가 요구하는 정보들을 전달 후

전달한 정보가 faber college 가 발급해준 정보가 맞다는 사실에 대한 증명을 추가로 생성하여 

acme corp 에게 전달

acme corp 은 alice 가 전송해준 증명을 통해 전송 받은 정보가 faber college 로부터 발급된 정보라는 것을 확인.

 

Alice's Identity 는?

이 네트워크에서 alice 는 어떻게 식별될까? alice 는 가각의 조직과 의사소통을 할때마다 다르 did를 이용한다.

스토리 라인 에서 앨리스 와 조직 사이에 먼저 보안 연결이 성립 해야 한다고 했는데, 이 보안 연결에 필요한 것이 

pairwise-unique DID 이며, pairwise-unique DID 는 오직 해당 조직관의 연결에만 사용된다.

 

 

현재 alice의 지갑을 열어서  DID를 몇개 가지고 있는지 확인하면 3개의 DID 를 가지고 있을것이다.

서로 다른 DID 이며 세개의 DID는 모두 대응되는 verkey 와 함께 원장에 기록 됨.

원장에는 alice에 관한 다른 어떤것도 찾을 수 없다.

필요로 하는 속성을 얻기 위해서는 alice 와 직접 보안 통신하여 요청, 확인 해야 한다.

 

블록체인에 저장되는 것은 무엇인가?

-Public DIDs and associated DID documents with verification keys and endpoints.
-Schemas and credential definitions
-Revocation registries
-Agent authorisation policies

 

공개해야 하며 공개해도 괜찮은 것이다.

verifier는 issuer의 DID,Public Key를 장부에서 찾아야한다. (은행은 자신의 Public DID를 은행의 홈페이지에 QR코드등을 통해서 게시해 둘 수 있다.) 서로의 DID를 검증하는 것등의 안전한 P2P통신을 하기 위한 정보들이 있다. 그리고 신원서가 유효한지도 확인 할 수 있는 기록들이 저장된다. 예를들어 재직증명서를 발급받았더라도 회사를 떠나게 되면 무효화 되야하니깐

블록체인에 저장 안되는 것은 무엇인가?

-Signing key 

-Private credentials (Verifiable Proofs )

-Consent receipts or data exchange records

이런 정보는 Ledger에 존재하여 아무나 찾아 볼 수 있게 하면 안되며, 

 Alice-to-Faber, Alice-to-Acme, and Alice-to-Thrift 등과 같은 보안연결 하에 Peer to Peer로 제공되야 한다.