관리 메뉴

HAMA 블로그

[하이퍼레저 인디] DID / SSI 를 위한 블록체인 플랫폼 본문

블록체인

[하이퍼레저 인디] DID / SSI 를 위한 블록체인 플랫폼

[하마] 이승현 (wowlsh93@gmail.com) 2019.10.23 12:09


Hyperledger Indy에 대해서 정리해봤습니다. Indy는 변화,발전되고 있으며, 인사이드에 대한 정밀한 조사,검증을 하진 않았기 때문에 참고용으로만 읽어 주십시요.

개요

Hyperledger Fabric과 Ethereum의 경우 Smart Contract/ChainCode 를 통해서 DID/SSI를 실현 할 수 있는 범용 플랫폼인 반면에 Indy는 오직 DID를 구축하고자 하는 상황에 맞춤으로 만들어진 public permissioned 블록체인 플랫폼이며 다음과 같은 특징이 있습니다.

@ Sovrin Foundation (개발조직: Evernym) 에서 제공된 코드 기반의 프로젝트 
@ 사용자는 Public 이고 (아무나 사용가능)
@ 노드 관리는 Permissioned ( 선출된 대표노드: Steward)가 Validation / Write 역할을 함)
@ ZKP에 기반한 비 노출적 신원 증명 암호학 처리
@ ZKP에 기반한 비 연결적 Identity 
@ 자체적인 합의 시스템이 있다-> RBFT  
@ 자신의 지갑에 개인정보 보관 및 관리
@ 자체 장부를 가지고 있으며, 신뢰성있게 선출된 분산 장부에 Public 정보들 저장 / 읽기 한다.  
@ 연관 End-Point 간에 암호화 된 연결 후 필요 정보 요청/검증 프로세스 
@ 스마트 컨트랙트 기능은 없다. 

Indy의 DID와 영지식 증명 툴들을 가져다가 Fabric에서 사용 할 수 도 있으며, (Indy의 Credential / ZKP기반은 Fabric의 Identity Mixer와 거의 흡사) 더 자세하게 이해 하려면 https://www.evernym.com/white-papers/ : Evernym 백서로 Indy의 근간이 되는 가장 핵심적인 레퍼런스를 읽어야 합니다.

네트워크 구성

Validate Node 
validator 노드는 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 소유자를 위해 데이터를 단순하게 저장하고 공유할 수 있습니다.

App (Client)
신원 소유자(백서상 Identity owner 에서 Identity holder로 변경됨)들은 그들의 신원 정보를 Indy 클라이언트를 통해 통제하고 관리하는데, Client의 가장 중요한 기능은 Owner의 키 체인을 관리하고 보호하는 것으로 볼 수 있습니다.

DIDs 와 Verifiable Claims (=Verifiable Credential)

DIDs

사용자는 자신의 ID에 대해 기억할만한 이름을 만들어서 원장에 DID 형식으로 변환하여 할당합니다. (당연히 개인키는 자신의 지갑에 분리되어 저장됨) DID는 탈중앙형 식별자로, pure DID는 암호학적 속성을 가지고 있지 않는다. version 4 UUID를 사용하여 유니크하며 원장에 저장되고 원장에서 읽을 수 있다. DID는 단순한 JSON 객체인 Descriptor Objects DDO를 가리키며, 이 키-값 쌍을 DID레코드라고 합니다. DDO는 DID 소유자와 상호 작용하기 위한 공개 키 및 서비스 끝점을 노출하며,디지털 신원속성과 관계를 교환하기 위한 상호운용이 가능한 형식입니다. 


https://www.w3.org/2018/vocabws/presentations/Sabadello.pdf

각 DID는 주어진 네트워크에 특정한 method 사양과 연관되어 있으며, DID method 는 해당 네트워크에서 DID가 등록, 확인, 업데이트 및 해지되는 방법에 대한 규칙을 지정합니다.


https://www.w3.org/2018/vocabws/presentations/Sabadello.pdf

Verifiable Claims ( = Verifiable Credential)

정체성과 관련된 단일 속성을 Claim이라고 하는데 Claim은 한 명의 신분 소유자(사람 또는 조직)가 자신이나 다른 신분 소유자에 대해 제공하는 속성 정보를 말합니다. 예를들어 Claim은 주민등록증 상의 나이를 나타낸다고 생각하면 됩니다.  혹시 Credential하고 헤깔릴수도 있을텐데, 2018년에 Evernym 백서상에서 claim들의 묶음인 claims라는 용어를 credential로 바꿨다고 합니다. 참고로 주민등록상(혹은 운전면허증) 상의 모든 정보를 Verifiable Credential 이라고 하고, 해당 정보 중에 편의점에서 필요로 하는 최소한의 노출 정보(나이겠죠?)를 Verifiable Presentation 이라고 합니다.

Claim(단일속성) -> Credential(단일속성들의 전체합) -> Presentation (노출시키고자 하는 속성만의 합) 

DIDs 말고 CIDs는?

CIDs는 Cryptographic IDentifiers의 약자로써, pure DID가 단순UUID인것 비해서 공개키,공개키의 해시와 같은 암호학적 특징을 가지고 있으며 제안된 cid-1 스키마는 아래와 같습니다.
• The starting value is a 256 bit Ed25519 public key.
• This value is then base58Check encoding to produce a 44 character string

Example: cid-1:MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCABMC

먼가 복잡해 보인다면 하나만 기억하세요. DID나 CID나 사용자가 스스로 만든다는 것이며 중앙기관에서 누군가가 만들어 주는 게 아닙니다. 여담이지만 Hyperledger Indy는 SSI는 잘 지켜지지만, DID로써는 조금 약한게 사실입니다. 중앙화는 탈피 했지만 완벽한 분산(탈중앙)은 아니라는 말이데, 작동 가능한 정도의 합리적인 탈중앙성을 보유하고 있다라고 말하고 싶습니다. 

Sovrin Keys & Key Management

decentrailized public key infrastructure 에 대한 내용으로 소유자의 키는 Sovrin Ledger에 ID 로 매칭되고 있다.

Key discovery ?

Ledger에서 특정 Identity Owner의 public key를 찾는 방법에 관한 내용으로 자세한 설명은 추후에 기술

Credential Types

Indy는 Claims 데이터를 JSON 객체로 저장하는 5가지 클레임 유형을 지원합니다.

  1. Cleartext claims are directly readable, with no hashing or encryption, with no expectation of privacy; for information that is a matter of public record.
  2. Encrypted claims contain an encrypted version of a cleartext claim, that may be decrypted with a private key.
  3. Hash signature claims contain a specially encrypted tree of cleartext claims, so the identity owner can selectively reveal specific claims to relying parties.
  4. Proof of existence claims (aka POE claims or hash claims) are hashes of a digital object, enabling an identity owner to prove that object existed at a point in time. POE claims are useful for proving consent as required under EU General Data Protection Regulation (GDPR). The hash doesn’t reveal information about the consent, or the relationship between parties, but can be used by either to prove consent was granted.
  5. Anonymous credentials transmit claims are Zero Knowledge Proofs about a claim. The classic example of an anonymous credential is a proof of age (i.e., “over 21”) that does not reveal the actual birthdate. (이 방식은 Fabric 의 IDMixer 방식에서도 비슷하게 사용됩니다. 그리고 소위 "over 21"방식으로 ZKP가 작동하지는 않는 것으로 알고 있습니다. 그냥 21만 disclose) 


https://docs.google.com/document/d/1YzXz0aM8w7kSp3_ao3ue9tOFwK9paofXbtBptR1Jucg/edit

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 를 설정하는 역할

앨리스:
KeyPair 생성 -> Ledger 에 DID 저장 
Faber College에 성적표 요청 
Acme Corp에 입사신청 (prover 및 credential holder 롤) 
Faber College :
Alice에게 성적표 발급(credential issuer 롤)
Acme Corp :
지원 서류 중 하나로 지원자에게 학교 성적표 요구 (credential verifer 롤) 
Alice에게 재직 증명서 발급 (credential issuer 롤)
Thrift Bank :
Alice에게 자동차 대출을 위하여 필요한 정보들 요구 (credential verifier 롤)

Step 1. [Steward] actor 생성

Steward 는 분산되어 DID 관련 데이터를 블록체인에 저장/읽기 한다. Steward는 참여하는 모든 actor (Trust Anchor) 들을 생성할 수 있고 각 actor마다 적당한 역할을 부여한다. (일종의 CA 역할)

Step 2. [DID] DID를 Ledger에 생성

아래 글은 백서(The Technical Foundations of Sovrin) 중 First-Time Provisioning에 나오는데 새로운 Sovrin ID의 최초 설정 (Provisioning)을 위한 기본 단계는 다음과 같다. (즉 엘리스가 자신의 ID를 만들고 DID를 Ledger에 등록하는 상황)

ID Owner는 먼저 Sovrin 클라이언트(브라우저나 스마트폰과 연계된) 를 사용 하여 Trust anchor의 웹서비스나 웹싸이트에 연결 한다. (이때 DID 말고 해당 웹싸이트에서 요구하는 개별적 인증을 사용함) 

1. Sovrin 클라이언트-> Trust anchor 로 연결
2. Trust anchor -> Sovrin 클라이언트로 챌린지 토큰을 리턴함.
3. Sovrin 클라이언트는 KeyPair 생성 
  3-1. Sovrin 클라이언트는 Owner의 Sovrin Keychain에 추가 
  3-2. KeyPair 중 Public(verification) key는 Sovrin identifier를 생성하기 위해 사용됨. 
  3-3.KeyPair 중 Private (signing) key는 챌린지 토큰을 서명하는데 사용됨.
  3-4.KeyPair 중 Private (signing) key는 챌린지 토큰을 서명하는데 사용됨.

4. Sovrin 클라이언트 -> Trust Anchor로 서명된 챌린지 토큰 보냄. 
5. Trust Anchor 는 챌린지 토큰의 서명을 확인하여 새 키쌍을 인증한 다음 새로운 Sovrin Identifier를 Sovrin Ledger에 등록하는 프로세스 진행 
6. Trust Anchor -> Sovrin 클라이언트로 등록에 대한 receipt 메세지와 자신의 private key를 리턴함. 
7. Sovrin 클라이언트는 Sovrin 원장을 확인하여 Trust Anchor의 서명을 최종 확인. 

이건 내 생각인데.. DID가 엘리스 혹은 지영이, 한성이 인지는 어떻게 알 수 있을까??
당연히 알 수 없다. DID는 그저 UUID일 뿐이고, DID가 링크하는 DID Document는 뻔한 public key를 가지고 있을 뿐..
실제 지영이,엘리스,한성이를 인증하는건 그 DID와 매칭되는 Credential 인데, 국가기관의 초기 Credential이 그것의 역할을 해야 한다고 본다. 즉 국기기관의 Credential에는 그 DID와 연결되는 나이,이름,주소,민증번호등이 있을 거고, 그것을 국가기관에서는 서명해 줄 것이다. 물론 서명 할 때 직접 그 사람이 동사무소라든지 찾아와야겠지..

Step 3. [Credential Issuer] Credential Definition 생성

Alice에게 credential을 발급해주기 위해서 필요한 양식 (credential definition)들을 지정하고, ledger에 저장한다.

즉, Faber college는 Alice에게 성적표 발급에 필요한 Transcript Credential Definition을 만들어서 ledger에 저장하고, Acme Corp는 재직 증명서를 발급하는데 필요한 Job-Certificate Credential Definition을 만들어서 ledger에 저장한다.

Credential Definition은 schema에 기반하여 만들어지며, 필요한 정보들을 추가적으로 넣을 수 있다.

Step 4. [Credential Issuer] Credential 발급

앨리스는 credential을 faber college로부터 발급받기 위하여 faber college와 secure channel을 생성한다. 생성된 안전한 channel을 통하여 faber college는 Credential Definition에 해당하는 앨리스의 정보를 입력하여 앨리스에게 전송한다.

이 예제에서는 Faber college는 Alice에 대한

@이름
@학위
@졸업 여부
@연도와 학점
@SSN

에 대한 정보를 발급하여 Alice에게 (서명과 함께) 전달한다.

Step 5. [Credential Verifier] Credential 요청 및 검증

Acme Corp는 앨리스에게 학교 성적과 관련된 정보들을 요청하기 위하여 앨리스와 secure channel을 생성하고, 회사 지원을 위해서 학위, 현재 상태, SSN에 대한 정보가 필요하다고 Alice에게 요청을 한다. 앨리스는 Faber college로부터 받은 정보들을 기반으로 Acme Corp가 요구하는 정보들을 전달하고, 전달한 정보가 Faber college가 발급해준 정보가 맞다는 사실에 대한 증명을 추가로 생성하여 Acme Corp에게 전달한다.Acme Corp는 Alice가 전송해준 증명을 통하여 전송받은 정보가 Faber College로부터 발급된 정보라는 것을 확인한다.

 

Step 6. [Credential Verifier] 2군데의 Credential 요청 및 검증

Thrift Bank는 대출을 하기 위해 앨리스에게 KYC와 근무이력에 관한 증명을 요구하고 있다.   
1. 양측은 암호화된 커넥션을 맺는다. (다양한 방식이 있겠는데  앨리스가 가진 스마트폰 App에서 Thrift Bank의 홈페이지에 있는 QR Code를 읽으면서 시작 할 수도 있겠다. https://try.connect.me/ 참고) 
2. Thrift Bank는 2개의 Proof Requests를 만든다. 즉 여러개의 Credential중 관심있는 선택해서 요청 할 수가 있다.
   예를들어 KYC정보로 부터는 나이와 주민등록번호 그리고 Acme Corp로 부터는 얼마나 일했는지에 관한 정보. 
3. 앨리스는 2개의 Proof Requests를 받아서 적절한 Proofs를 만든다. 
4. Thrift Bank는 Proofs 를 앨리스로 부터 받아서 Proofs안에 있는 내용을 확인하고, 그 내용에 대한 검증을 한다. 

 



Alice's Identity 는 ? 

그럼 이 네트워크에서 앨리스는 어떻게 식별되었을까? 앨리스는 각각의 조직과 의사소통을 할 때 마다 다른 DID를 이용한다. 스토리 라인에서 앨리스와 조직 사이에 먼저 보안 연결이 성립 해야 한다고 했는데, 이 보안 연결에 필요한 것이  pairwise-unique DID 이며, pairwise-unique DID는 오직 해당 조직과의 연결에만 사용 된다.

만약 현재 앨리스의 지갑을 열어서 그녀가 얼마나 많은 DID를 가지고 있는지를 확인 하면, 그녀가 이전에 소통했던 각 조직 (Faber College, Acme Corp, Thrift Bank)마다 한 개씩, 즉 3개의 DID가 있다는 것을 확인 할 수 있으며, 위에 말한바와 같이 서로 다른 DID이며, 이 세 개의 DID는 모두 대응되는 verkey와 함께 원장에 기록된다. 그 밖에 원장에는 앨리스에 관한 다른 어떤 것도 찾을 수 없다. (예를들어 나이,학교,회사정보 등등)
다른 어떤 것~! 즉 필요로 하는 속성을 얻기 위해서는 엘리스와 직접 보안 통신하여 요청하고, 확인 해야 한다. 

결국 블록체인(Ledger)에 저장되는 건 무엇인가? 

-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코드등을 통해서 게시해 둘 수 있다.)

결국 블록체인에 저장 안되는 건 무엇인가? 

-Private DIDs , Private DID Document
-Private credentials (Verifiable Proofs )
-Consent receipts or data exchange records


이런 정보는 Ledger에 존재하여 아무나 찾아 볼 수 있게 하면 안되며,  Alice-to-Faber, Alice-to-Acme, and Alice-to-Thrift 등과 같은 보안연결 하에 Peer to Peer로 제공되야 한다. 


레퍼런스) 
https://www.evernym.com/white-papers/ : Evernym 백서
https://eprint.iacr.org/2016/663.pdf : BBS+ Signature 논문 
https://try.connect.me/
https://medium.com/@kctheservant/exploring-hyperledger-indy-through-indy-dev-example-10075d2547ae
https://www.ernesto.net/hyperledger-indy-architecture/
https://wso2.com/blog/research/the-rise-of-self-sovereign-identity-hyperledger-indy

0 Comments
댓글쓰기 폼