DID / SSI 를 위한 블록체인 플랫폼 - Hyperledger Indy

Hyperledger Indy에 대해서 정리해봤습니다. Indy는 변화,발전되고 있으며, 인사이드에 대한 정밀한 조사,검증을 하진 않았기 때문에 참고용으로만 읽어 주십시요. 4년전 처음 이글을 적을 때에는 Indy-SDK가 모든 것(블록체인과 인터페이스, DID,VC를 다루는 공통 함수들, 지갑역할, P2P역할, 익명성 역할) 을 다 담고 있었으나 2023년 3월 현재 Indy-SDK는 다양한 모듈별로 나누어진 버전들이 있습니다. (Aries, Indy-vdr,AnonCreds 등) 

개요

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

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

Indy의 Credential / ZKP기반은 Fabric의 Identity Mixer와 같으며  Camenisch-Lysyanskaya (CL) signature scheme or BBS+ 으로 어떤 속성에 대해서 올바른 서명을 알고있다는 것을 실제 서명 자체를 노출하지 않고도 증명 할 수 있는 방식) Indy의 암호학적 근거에 대해서 더 자세하게 이해 하려면 https://www.evernym.com/white-papers/ : Evernym 백서인  핵심적인 레퍼런스를 읽어야 합니다.

네트워크 구성

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 소유자를 위해 데이터를 단순하게 저장하고 공유할 수 있습니다. Indy에서 이 부분은 Hyperledger aries로 이전되었다.

App (Client)
신원 소유자(백서상 Identity owner 에서 Identity holder로 변경됨)들은 그들의 신원 정보를 Indy 클라이언트를 통해 통제하고 관리하는데, Client의 가장 중요한 기능은 Owner의 키 체인을 관리하고 보호하는 것으로 볼 수 있습니다. 
쉡게 풀어 무슨얘기냐하면 Indy sdk 클라이언트에 지갑기능이 있고, 그 지갑에 DID관련 키가 저장되어있다는 말

DIDs 와 Verifiable Credential

DID

사용자는 자신의 ID에 대해 기억할만한 이름을 만들어서 원장에 DID 형식으로 변환하여 저장합니다. (당연히 개인키는 자신의 지갑에 분리되어 저장됨) DID는 탈중앙형 식별자로, pure DID는 암호학적 속성을 가지고 있지 않으며 version 4 UUID를 사용하여 유니크하며 원장에 저장되고 원장에서 읽을 수 있습니다. 

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

DID Document

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

Verifiable Credential

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

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

DID 말고 CID는?

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로써는 조금 약한게 사실입니다. 중앙화는 탈피 했지만 완벽한 분산(탈중앙)은 아니라는 말이데, 작동 가능한 정도의 합리적인 탈중앙성을 보유하고 있다라고 말하고 싶습니다. 

Interoperability of Digital Certificates

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

DIDComm

에이전트간의 통신인 DIDComm 및 구현체인 Aries에 대해선 나중에 기회되면 서술합니다. 
https://identity.foundation/didcomm-messaging/spec/

스토리 라인

대략적인 스토리 라인을 살펴 보겠습니다. (이 스토리라인은 Indy와 Aries을 이용해서 구현 가능합니다.) 

Actor

공통) KeyPair 생성 -> Ledger 에 DID 및 DID Document 저장 , 지갑에 Secret key 저장. 

@Government :
기본 schema 를 설정하는 역할. (schema란 졸업증명서라든지 재직증명서등의 기본구성요소를 정의해 놓은 것이다.)
@Alice:
 Faber College에 성적표 요청 
 Acme Corp에 입사신청 (prover 및 credential holder 롤) 
@Faber College :
 Alice에게 성적표 발급(credential issuer 롤)
@Acme Corp :
 지원 서류 중 하나로 지원자에게 학교 성적표 요구 (credential verifer 롤) 
 Alice에게 재직 증명서 발급 (credential issuer 롤)

Step 1. Steward의 Trust Anchor 생성

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

Step 2. 각자의 DID를 Ledger에 생성

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

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

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

먼가 복잡한데 Indy SDK에선 단순히 이렇게 한다. (지갑이 중앙화 되었다) 

 alice= { 이름, 지갑id, 지갑 비번, Indy풀) // 지갑 기본 정보 기입하고  (1) 
 create_wallet(alice)  // 기본 정보를 통해 지갑을 만들고 (2) 
 (alice['did'], alice['key']) = await did.create_and_store_my_did(alice['wallet'], "{}")  // did과 부속물을 만들어서 지갑에 저장하고 did키와 verifying key를 리턴해 준다. 이 verifying key를 서버 혹은 개인이 선택 보관 할 수 있다. 

매우 간단하다. 

 DID가 실제 엘리스 혹은 지영이인지는 어떻게 알 수 있을까??
당연히 알 수 없다. DID는 그저 UUID일 뿐이고, DID가 링크하는 DID Document는 public key와 엔드포인트등 문자열을 가지고 있을 뿐.. 설사 거기에 이름을 적었더라도 그게 진짜인지 알 수 없다. 

실제 지영이,엘리스를 인증하는건 그 DID와 매칭되는 Credential을 통해 한다.  이 Credential을 누가 해줬냐에 따라서 신뢰의 강도가 달라지며, 국가기관이 동사무소에서 직접 얼굴보고 확인 해줘서 Credential을 하면 가장 확실하며(국기기관의 Credential에는 그 DID와 연결되는 나이,이름,주소,민증번호등이 있을 거고)  그것이 개인의 가장 Root Credential이 되면 좋을 것이다. 그 이하 신뢰의 강도를 가진 Credential이라면 그냥 특정기관,은행단위일 것이고....

Step 3. [Credential Issuer] Credential Definition 생성

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

즉, Goverment는 기본 스키마를 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로부터 발급된 정보라는 것을 확인한다.

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코드등을 통해서 게시해 둘 수 있다.) 서로의 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로 제공되야 한다. 

---

부록)

이 글을 처음 쓸 때만 하더라도 Indy만으로 모든게 다 되었지만 현재 P2P관련된 부분에서 Aries로 분리되었다.
Hyperledger Aries를 살펴본다. 

1. Hyperledger Aries 기능 

● Tool kit designed for creating, transmitting and storing verifiable digital credentials
●  Anchor to blockchain
●  Blockchain agnostic
●  Key management
●  DIDs
●  Messaging

2. 2023년 1월 31일 현재, 지원되는 Agents는 아래와 같다

• Aries Cloud Agent - Python (ACA-Py) is suitable for all non-mobile agent applications and has production deployments. ACA-Py and a controller run together, communicating across an HTTP interface. Your controller can be written in any language and ACA-Py embeds the Indy-SDK.
• Aries Framework - .NET can be used for building mobile (via Xamarin) and server-side agents and has production deployments. The controller for an aries-framework-dotnet app can be written in any language supporting embedding the framework as a library in the controller. The framework embeds the Indy-SDK.
• Aries Static Agent - Python is a configurable agent that does not use persistent storage.

There are several other frameworks that are currently under active development, including:

• Aries Framework - Go is a pure golang framework that provides a similar architecture to ACA-Py, exposing an HTTP interface for its companion controller. The framework does not currently embed the Indy SDK and work on supporting a golang-based verifiable credentials implementation is in progress
• aries-sdk-ruby
• aries-framework-javascript

아직도 Kotlin/Swift 구현이 없군요.

3. 주요 특성 
- It acts as a fiduciary on behalf of a single identity owner (수탁자 역할을 한다) 
- It holds cryptographic keys that uniquely embody its delegated authorization. (개인키를 관리한다) 
- Aries agent will act your behalf to issue create connections, issue credentials, send messages (커넥션,발급,검증기능) 
- a mobile agent and a cloud agent. These agents are grouped based on their "location", e.g. a mobile wallet or server. Some other categories are a static, thin, thick and rich Aries agents. Aries JavaScript ecosystem allows you to create a mobile agent and a cloud agent. (Aries 자바스크립트 에이전트로는 중앙화된 클라우드형과 독립적인 P2P형 모두 만들 수 있다)

4. Build Your Identity Solution Using Hyperledger Aries

---

레퍼런스) 
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