Decentralized ID Matching with Zero-Knowledge Proofs

This slide describes what is DID, how we build DID systems, and how we approach DID matching with Zero-Knowledge Proofs.

Transcript

1. Decentralized User Identity Using Zero-Knowledge Proofs. Hyojun Kim Lead Developer & PM
2. About Speaker • Hyojun Kim • Airbloc Lead Developer @ ab180 • Former Airbridge Android Developer • Former Airbridge Backend Developer Hyojun Kim
3. Table of Contents 1. About Airbloc 2. Decentralized Identity (DIDs) I. Verifiable Credentials (Claims) II. Using DID on Ethereum 3. Zero-Knowledge Credentials in Airbloc I. ZKCredential Level 1: More Privacy II. ZKCredential Level 2: Derivability 4. Future of Airbloc, with Data Privacy
4. What is Airbloc?
5. 사용자의 동의와 통제 하에 데이터를 수집하고 거래하는 사용자 중심 데이터 거래 프로토콜
6. Consent SDK Data collection authorization and easy monetization through the User Consent SDK
7. Airbridge bought your GPS Data from MapMo. Yesterday Your Installed App List data was collected from MapMo. 3 days ago Withdrawal of 10,240 ABL is completed.
9. Components of Airbloc Protocol User Identity Data Warehouse Data Controller Data Transport
10. Some Key Technologies Sparse Merkle Tree P2P Networking Data Consent Challenge Decentralized Identity Zero-Knowledge Proofs ID Resolution OpenGDPR Metatransaction
11. Some Key Technologies Sparse Merkle Tree P2P Networking Data Consent Challenge Decentralized Identity Zero-Knowledge Proofs ID Resolution OpenGDPR Metatransaction
12. Decentralized Identity (DID) • 어떤 중앙화된 기관이나 단체에 의존하지 않고, 개인이 직접 통제할 수 있는
 사용자 아이덴티티를 의미함. • Self–Soverignity (자기주권화)가 핵심이다. • 중앙 주체에 의존하지 않는 대신, PKI (공개 키 인프라)를 사용한다. • 분산 원장이 사용된다. • W3C CCG에서 현재 DID 표준화 작업이 진행중임.
13. Decentralized Identity (DID) Agent App Private Key Blockchain DID 정보는 사용자 기기에 직접 저장되며, 사용자 키로 서명 후 블록체인에 등록됨
14. Usage Scenario: Diploma using DID
15. Example of DID • DID는 사용자 고유 ID와 (did:),
 DID 문서로 구성됨 • 기본적으로 사용자의 공개 키와
 DID 문서 서명을 포함 • 그 외에도 • DID 소유자 인증 수단 • 해당 DID 사용 서비스 목록 • …
16. Q.
 ৵ DIDۄݶࢲ ࢎਊ੗ী ؀ೠ ѐੋ੿ࠁо হաਃ? 프라이버시 때문에 DID 안에 정보가 직접 제공되진 않음. 대신 Verifiable Credential로 제공된다.
17. Verifiable Credentials (Claims) • 어떤 대상에 대해서 주장하는, 위조불가능한 디지털 증명 • Subject: 설명하거나 주장할 대상. 일반적으로 나. • Issuer: 발급 주체나 기관 (e.g. 정부, 은행, 대학교, 회사, …) • Claim: 주장할 내용 (e.g. "이 사람은 20세 이상", 연 소득 3000만원 이상!) • 서명을 통해 해당 Issuer로부터 발급되었다는걸 보장할 수 있음.
18. 정부가 did:홍길동 보고 20세 이상이래!
19. 정부가 did:홍길동 보고 20세 이상이래! Issuer Subject Claim
20. Example • Proof-of-Age Credential • 정부 (DMV)가 2010년 1월에 • did:example:ebfeb1f… 이 • 21세 이상인 증명을 발급함. • 정부의 키로 문서가 서명됨. • 나이를 직접 드러내는 대신
 간접적인 성인 인증만 발급한다.
21. Verifiable Claims on Ethereum • ERC-780: Ethereum Claims Registry • Issuerо Claimਸ ੷੢ೡ ࣻ ੓ח ৡ୓ੋ Claim ࠁҙࣗ • ENS (Ethereum Name Service)੄ DID ߡ੹੉׮. • Use Cases: uPort, Civic
22. Example: Insurance Dapp using ERC780
23. Limitation of Verifiable Claims Privacy, Authority.
24. Limitation: Privacy • 분산원장 특성상 모든 정보가 공개될 수밖에 없기 때문에 • Claim의 주제가 제한적이고 간접적이다. • 공개된 Claim의 내용 자체도 개인의 프라이버시를 침해함. • 예시: 보험 발급을 위한 소득 정보, 우대를 위한 국가유공자 / 장애인 정보 등
25. Limitation: Authority • 새 Claim을 발급받으려면 무조건 Issuer / Authority를 거쳐야 한다. • Authority 의존성으로 중앙화 우려 • Dapp의 UX 문제: Claim이 아직 없으면 Issuer가 등록해줄때까지 기다려야. Issuer … Request Claim User Dapp Blockchain ??
26. Adopting Zero-Knowledge Proofs To Decentralized Identity
27. Before we begin… Zero-Knowledge Proofs?
28. What is Zero-Knowledge Proof? Have you heard about…
29. Trivial Prover System Prover Computes some task 
 and conviences a verifier Verifier Verifies that the prover done his job correctly Proof Knowledge
30. What If Verifier Steals a Knowledge? Prover I've finished my job! Here is proof data. Verifier Leaks Knowledge (e.g. Input Data) Proof Knowledge
31. Zero-Knowledge Proof System Prover I've finished my job! Here is proof data. Verifier Only able to know
 that the proof is true Proof Knowledge
32. zk-SNARKs We use
33. Zero-Knowledge Succinct Non-interactive ARgument of Knowledge zk-SNARKs
34. Y = C(x, w) Public Output How zk-SNARK works? Public Function Public Input Secret Input
35. C is for Circuit • We need to code public function C using only Arithmetic Circuit • This circuit representation is called
 R1CS (Rank-1 Constraint System) • We cannot just apply zkSNARK to
 every general computations. Y = C(x, w)
36. Setup: (C, ) → (pk, vk) Prove: (pk, x, w) → Proof Verify: (vk, Proof, x, y) → Bool How zk-SNARK works?
37. Prove: (x, w) → Proof Verify: (Proof, x, y) → Bool There is no secret (w) on verify! = Zero-Knowledge How zk-SNARK works?
38. Why zk-SNARK? • Ethereum-Friendly (alt_bn256 ECC Arithmetic Support in Byzantium) • Smallest Verification cost for now
39. Adopting Zero-Knowledge Proofs To Decentralized Identity
40. • 1단계: 프라이버시 문제 해결 • 익명성을 이용해 간접적인 정보조차 드러내지 않을 수 있음 • 2단계: Authority 의존성 문제 해결 (Derivable Proof) • 하나의 최초 Credential에서 필요할 때마다 Proof을 생성할 수 있음. • Commitment Scheme을 활용해 Authority 거치지 않고 신원 증명 가능. Zero-Knowledge Verifiable Credential
41. • 아까다이어그램으로봤던Dapp UX문제를해결하기위해 Airbloc ZKCredential PoC Issuer … Request Claim User Dapp Blockchain ??
42. • ݾ಴: Issuer에게한데이터에대해한번만받으면,이후Issuer없이도재사용가능 Airbloc ZKCredential PoC Issuer User Dapp Age Proof Age > 20 Age < 50
43. • github.com/airbloc/zero-knowledge-poc • Level 1: For "More Privacy" • Level 2: For "Derivability" • Still Developing Yet 🥺 Airbloc ZKCredential PoC
44. Example: Verifiable Credential • 가상의 민원24에서 발급한 Credential • 사용자 ID (Subject)와 나이 조건 노출됨
45. Example: ZKCredential • Credential 및 Proof 종류가
 SnarkCredential / SnarkProof • 나이 조건은 Proof에 노출되지 않음 • 대상도 Proof에 노출되지 않음 • 온체인에서 사용 가능한 Proof
46. ZKCredential Level 1: More Privacy • Proof-of-Age Example using ZoKrates • Age as Private Field!
47. ZKCredential Level 2 Derivability • Level 1의 문제:
 같은 데이터라도 조건이 달라질 때
 Proof의 재사용이 불가능함 • Commitment Scheme을 활용하자! • 미리 온체인에 해시만 등록해두고 • 등록된 해시와 같은지 검증함 • Preimage는 Private하게 계산됨
48. Derivability: Detailed Private Values 🔐 Hash Public Values ✅ Root Credential Nonce My Age Claim
 Age > 20 SNARK Derived Credential + = Witness
49. 시연
50. Still has a long way to go 😂 • 데이터 필드의 완전한 재사용 불가 • 같은 Circuit에 대해서만 재사용이 가능함 • CL (Camenisch-Lysyanskaya) Signature Scheme 차용 및 검토 • 아직 조금 비싼 온체인 검증 비용 • PGHR13 -> Groth17 전환으로 검증비용 약 47% 최적화 성공 • 그러나 SHA3 (Keccak) 계산에 Constraint를 너무 많이 사용 • MiMC 및 Perdersen Commitment 도입시 최적화 가능
51. Future of Airbloc, with Privacy
52. Thank you!