[Blockchain] 탈중앙화 신원 증명 방법 DID 이해하기

 

DID란?

 

탈중앙화 신원증명(Decentralized Identity)는 데이터의 주권을 개인이 가지고, 중앙화된 인증기관에 의존하지 않고 신원증명을 할 수 있는 기술입니다. 기존에 사용하던 공인인증서나 금융인증서, ID/PW에 대한 주체가 개인이 될 수 있습니다. 

 

 

DID는 SSI(자기 주권 모델)을 분산 원장 기술 혹은 블록체인을 활용해 구현한 모델입니다. 사용자들의 개인 정보는 개인 단말기에 저장한 후 DID와 1:1 매칭되는 DID Document는 블록체인에 저장합니다. 이 후 사용자의 요청에 따라 선별된 개인정보만 추출해 블록체인의 DID Document와 비교해 인증을 마칠 수 있습니다.

 

DID 등장 배경

 

2000년 초반 이후 PC가 보급되고 인터넷이 보급되기 시작하면서 Web은 눈부신 성장을 해왔습니다. 하지만 대부분의 해커들의 정보탈취 공격으로 인해 점점 데이터는 중앙집중화되기 시작하였고, 구글, 아마존, 페이스북 등 공룡 IT 기업들은 사용자들의 데이터를 가지고 천문학적인 수익을 올리기 시작합니다.

여기서 문제는 데이터의 주인은 사용자들이지만 실제 수익을 올리는 건 거대 플랫폼 기업들이라는 점입니다. 내 정보임에도 불구하고, 함부로 조회가 안되고 또한 이런 기업들이 해커의 공격을 받으면 개인 정보 유출 이라는 거대 사고로 이어지게 됩니다.

실제로  인터파크, 현대캐피탈, 페이스북 등 일부 기업들은 해커의 공격으로 개인정보유출 사고를 겪었으며, 이로 인한 피해는 고스란히 사용자에게 전가되는 상황입니다. 웹을 창시한 팀 버너스 리는 데이터의 중앙화를 방지하고자 W3C를 중심으로 데이터 탈중앙화 운동을 시작했고, 2019년 DID 워킹 그룹이 결성되어 DID 기술 표준을 마련하고 있습니다. 

 

 

DID 구성 요소

 

DID(Decentralized Identifier)

DID는 3 부분으로 구성됩니다. 

• Scheme : DID 스키마를 정의합니다. 항상 did를 사용합니다.
• DID Method : DID 메소드를 정의합니다. DID 메소드 종류는 다양합니다. 블록체인이나 분산원장에서 DID 문서들에 대한 CRUD나 비활성화 하는 메커니즘입니다. DID 메소드 더 알아보기
• DID Method-Specific Identifier : DID 메소드 내의 고유한 아이디를 의미합니다.

 

 

DID Document

DID Document는 DID 소유권과 제어권을 증명할 수 있는 공개키, 인증정보를 담고 있습니다. DID와 DID Document는 1:1로 매칭되며 DID발행자와 사용자는 DID Document를 블록체인에 기록합니다. 퍼블릭한 블록체인 네트워크에 기록되므로 개인 정보는 담고 있지 않습니다. 인증에 필요한 개인정보는 Issuer가 발행하는 VC에 기록됩니다. JSON 형태를 가지고 있습니다.

// Simple Example of DID Document

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

 

DID Document 명세를 정의하는 DID Method는 그 종류가 다양합니다. 이더리움 블록체인을 사용하는 DID의 경우 uPort를 사용한 ethr가 있습니다. DID Method를 사용해 발급되는 DID는 1:1로 매칭되는 DID Document를 블록체인에 기록하게 됩니다. 

 

Verifiable Data Registry

DID와 DID Document를 저장하기 위한 공간입니다. DID나 DID Document를 생성하고 업데이트 할 때 데이터가 이곳에 기록됩니다. Issuer, Holder, Verifier가 동의한다면 블록체인 뿐만 아니라 다른 분산원장을 사용할 수도 있습니다. 

 

DID Resolver

DID Method들이 다양하기 때문에 이에 맞는 DID Document를 가져오기 시작하면 해석하기가 어렵기 때문에 통일된 DID Document를 지원하는 컴포넌트입니다. 대표적으로 DIF에서 제시한 Universal Resolver를 사용하면 DID를 가지고 DID Document로 전환해줍니다. 

 

DID Architecture

DID Controller는 DID Document를 control 할 수 있는 주체입니다.

DID는 DID Subject가 가진 ID입니다.

DID Resolver에서 DID를 가지고 DID Document로 전환할 수 있습니다. 

DID와 1:1로 매칭되는 DID Document는 Verifiable Data Registry에 기록됩니다.

 

 

Issuer, Holder, Verifier 모두 DID 계층을 통해 DID 발급자와 소유자를 영구 식별자로 등록한 뒤 Issuer와 Holder의 디지털 서명을 복호화 하기 위한 공개키를 얻을 수 있습니다.

 

DID Authentication

Company는 DID 소유권자를 인증하기 위해 DID를 받아 DID Resolver에서 DID Document로 전환합니다.

DID Document내의 인증정보를 가지고 DID Subject의 소유권을 검증합니다. 

 

Verifiable Credentials

DID Holder가 요청한 개인정보들을 담고 있는 JSON 형태의 데이터입니다. DID Holder는 Issuer에게 Claims을 요청하게 되고, Issuer는 요청된 Claims를 검증합니다. 졸업하지도 않은 학교에서 졸업증명서를 내줘서는 안됩니다. 만약 요청에 문제가 없는 경우 Claims를 VC에 담아 Holder에게 반환합니다.

 

Credential Metadata는 Issuer의 정보, Credentials만료 기간등의 정보가 담깁니다.

Claims 에는 Holder가 요청한 Claims가 담깁니다.

Proofs에는 VC를 발행한 Issuer의 디지털 서명이 기록됩니다. 

 

 

Issuer가 발급한 VC에는 다양한 정보가 기록됩니다. 

@context는 VC를 교환할 때 호환성을 위해 spec을 정의한 파일의 주소를 기록합니다. @context는 VC내에 반드시 시 포함되어야 하는데, 형태는 배열로 입력됩니다. 첫번째 주소값은 무조건 https://www.w3.org/2018/credentials/v1"이 들어가야 합니다.

id는 Credential의 주체입니다. 필수값은 아니지만, DID 와 다르게 URI 형태로 담깁니다.

types 는 이 데이터가 어떤 데이터인지 규정합니다. 반드시 포함되어야 하며, VC의 경우 VerifiableCredentials가 , VP의 경우 Verifiable Presentation이 들어갑니다.

issuer는 VC를 발급한 주체입니다. URI로 입력되거나 Issuer의 DID가 입력됩니다. 

issuanceDate는 발급시간을 담고 있으며 RFC3339를 준수합니다. 현재 Deprecated 될 예정에 있으며, issued로 대체될 예정으로 알려져 있습니다. 호환성을 고려하면 둘다 적는게 맞습니다.

credentialSubject는 Holder가 요청한 claims의 정보를 담고 있습니다. VC의 개인 자격 정보는 이곳에 기록됩니다.

proof는 VC를 검증하기 위한 디지털 서명 정보입니다. 서명 알고리즘에 따라 기록되는 정보는 상이합니다. 

예시 1: 검증 가능한 크리덴셜의 간단한 예
{
  
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  
  "id": "http://example.edu/credentials/1872",
  
  "type": ["VerifiableCredential", "AlumniCredential"],
  
  "issuer": "https://example.edu/issuers/565049",
  
  "issuanceDate": "2010-01-01T19:73:24Z",
  
  "credentialSubject": {
    
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  
  
  "proof": {
    
    "type": "RsaSignature2018",
    
    "created": "2017-06-18T21:19:10Z",
    
    "proofPurpose": "assertionMethod",
    
    "verificationMethod": "https://example.edu/issuers/keys/1",
    
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

 

Verifiable Presentation

인증을 위해 Issuer로 부터 받은 정보를 모두 Verifier에게 공개할 필요는 없습니다. VC에는 민감한 개인정보를 다수 포함하고 있으므로, 필요한 정보를 선별해 VP를 생성한 다음 자격인증을 하게 됩니다. VP는 VC와 유사한 구조를 가지고 있습니다.

 

Presentation Metadata는 type, termsOfuse 등 정보를 담고 있습니다.

Verifiable Credentials는 Issuer에게 발급받은 VC가 기록됩니다.

Proof는 검증을 위해 디지털 서명 정보가 기록됩니다. 이 때 public Key는 Holder의 소유입니다. 즉, VP에는 VC와 다르게 디지털 서명이 2번 기록됩니다. 당연히 복호화도 2번 진행되어야 합니다. 아래 초록색 Credential Proof Graph는 Issuer의 디지털 서명 부분이며, 파란색 Presentation Proof Graph는 Holder의 디지털 서명 부분이 됩니다.

 

VP에도 @context, type이 그대로 기록됩니다. type은 VerifiablePresentaion이 기록됩니다.

VC에는 claims가 기록되었지만, VP에는 verifiableCredential이 배열 형태로 기록됩니다. 

proof에는 replay attack을 방어하기 위해 1회성으로만 사용가능하도록 인증 정보가 기록됩니다. 

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.edu/credentials/1872",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "issuer": "https://example.edu/issuers/565049",
    "issuanceDate": "2010-01-01T19:73:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": [{
          "value": "Example University",
          "lang": "en"
        }, {
          "value": "Exemple d'Université",
          "lang": "fr"
        }]
      }
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://example.edu/issuers/keys/1",
      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
        PAYuNzVBAh4vGHSrQyHUdBBPM"
    }
  }],
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}

 

 

 

 

DID Echo System

DID 생태계에는 크게 Issuer, Holder, Verifier가 있습니다. Issuer는 자격증명을 발행하는 공인된 기관입니다. Issuer가 발행한 자격증명은 Holder의 디지털 기기에 저장됩니다. Verifier의 인증 요구가 있을 때 Holder는 발급받은 자격증명을 가지고 인증기관 중계없이 블록체인에 기록된 DID Document를 통해 자격을 증명할 수 있습니다.

 

DID 인증과정

 

 

ⓐ 발급

사용자가 claim을 요청하면 Issuer는 요청에 맞는 VC를 발급합니다.

1. Holder는 Issuer에게 claims를 요청합니다.
2. 공인인증받은 Issuer는 Holder의 Claims를 담은 VC를 생성하고 Issuer의 개인키로 디지털 서명을 합니다. 
3. Issuer는 발급정보, 스키마, 공개키를 블록체인에 존재하는 Holder의 DID Document에 기록합니다.
4. Holder는 신원증명 가능한 VC를 최종적으로 발급받습니다.

 

 

ⓑ 제출

Holder는 Issuer로 부터 발급받은 VC를 가지고 VP를 생성해 인증에 사용합니다.

1. Holder는 발급받은 VC에 자신의 개인키로 디지털 서명을 합니다. 즉, VC에는 Issuer의 서명 1번, Holder 서명 1번 총 2번의 디지털 서명이 들어갑니다.
2. Holder는 자신의 DID에 매칭되는 DID Document에 공개키를 등록합니다. 
3. Issuer에게 전달받은 VC를 디지털 기기(스마트폰 등등)에 저장합니다.
4. VC와 자신의 디지털 서명을 담은 VP를 Verifier에게 제출합니다.

ⓒ 검증

Holder가 제출한 VP를 전달받은 Verifier는 블록체인에 기록되어 있는 Holder의 DID Document를 가져와 검증을 시작합니다.

1. Verifier는 Holder의 VP를 전달받아 두번의 디지털 서명을 복호화 합니다.
2. Holder의 DID로 DID Document를 찾은 후 기록된 공개키를 찾습니다.
3. 먼저 Holder의 공개키로 첫번째 복호화를 진행합니다. 여기서 복호화에 성공하면 Holder가 작성한 VP라는 것을 검증할 수 있습니다.
4. 다음으로 Issuer의 공개키로 두번째 복호화를 진행합니다. 복호화에 성공하면 Issuer가 발행한 VC라는 것을 검증할 수 있습니다.

 

Reference

• Verifiable Credentials Data Model v1.0
• 탈중앙화 신원증명 DID
• DID Specification Registers
• 탈중앙화 신원증명 DID Verifiable Credential
• DID : 탈중앙화된 ID
• Decentralized Identifiers(DIDs) v1.0

 

 

[Blockchain] W3C 데이터 탈중앙화 표준 DID란?

 

[Blockchain] W3C DIDs 탈중앙화 식별자 표준

 

[Blockchain] DID 자기 주권 신원(SSI)이란?

 

[Blockchain] VC VP DID 개념 및 작동 방식