일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 플레이프레임워크
- hyperledger fabric
- Akka
- 이더리움
- play2 강좌
- 파이썬 동시성
- Play2
- akka 강좌
- 하이브리드앱
- CORDA
- 파이썬 강좌
- 그라파나
- 스칼라 강좌
- 파이썬
- 스위프트
- 안드로이드 웹뷰
- 블록체인
- 파이썬 머신러닝
- play 강좌
- Adapter 패턴
- 파이썬 데이터분석
- 주키퍼
- 엔터프라이즈 블록체인
- Actor
- 하이퍼레저 패브릭
- Play2 로 웹 개발
- Golang
- 스칼라 동시성
- Hyperledger fabric gossip protocol
- 스칼라
- Today
- Total
HAMA 블로그
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 서명을 리턴함.