블록체인 기반 인증 서비스, DID

DID(Decentralized Identifiers)는 블록체인을 다루고 있다면 한번쯤은 들어 봤을 것이다. 블록체인을 다루지 않았더라도, 대한민국 사람들은 코로나19 시기에 DID를 어렵지 않게 만나 봤을 것이다. 백신 접종 시스템인 Coov를 사용하여 식당, 마트 등에서 QR코드로 백신 접종자라는 것을 인증하고 출입을 해본 경험이 있을텐데, Coov가 바로 DID를 적용한 신원인증 시스템이다. 이렇듯 DID는 '인증'이라는 개념으로 다른 블록체인 기반 서비스보다 일반 사용자들에게 친숙하게 다가갈 수 있는 서비스인데, 이번 글에서는 이 DID에 대한 개념과 기본적인 동작 방식에 대해 정리해보려 한다.

Why DID?

왜 DID를 사용하는 것인가에 대한 물음에 먼저 답을 하기 위해서는, SSI(Self-Soverign Identity)에 대해 먼저 언급을 해야 할것이다.
일반적인 서버-클라이언트 시스템에서는 '나'에 관련한 데이터에 대하여, 서버를 운영하는 서비스 프로바이더가 원하는 데이터를 모두 전달해야 서비스를 받을 수 있다. 그리하여, 서비스 제공자가 '나'의 개인정보를 관리하고, 그 개인정보가 제3자에게 제공되는 것은 모두 서비스 프로바이더가 결정한다.

개인정보에 대한 주권은 개인정보를 보유한 자신에게 있다는 개념에서 출발하는 것이 SSI이다. 개인정보를 내가 관리하게 된다면, 공유할 개인정보 데이터를 각자가 설정할 수 있고, 공유하는 대상도 설정할 수 있다.
더군다나, EU가 GDPR을 제정하며 개인의 데이터에 대한 주권 보호가 의무화되며 많은 나라들이 따라가고 있는 가운데, DID는 법을 준수하며 보편적 SSI를 이루기 위한 하나의 아이템이 될 수 있을것이다.

SSI 인증에 대한 예시를 편의점으로 들어보자.
A는 성인이고, 술을 사러 편의점에 들렀다. 자신이 성인임을 증명하기 위해 주민등록증을 제시한다면, A는 성인임을 증명할 수 있는 생년월일 뿐만 아니라, 성인임을 증명할 때에는 불필요한 이름, 주민등록번호, 주소 등을 함께 제시해야만 한다. SSI를 준수하는 DID를 사용한다면 내가 성인임을 증명하는 정보만 추려서 제출하여, 불필요한 개인정보 노출을 최소화할 수 있을 것이다.

Architecture

Role

DID 시스템은 각각의 역할을 맡은 구성원들이 존재한다.

w3.org

• Holder
  그림에서의 holder가 개인정보 데이터를 보유한 '나'이다. Holder만이 자신의 데이터를 소유할 수 있고, 관련 기관에 자신과 관련된 데이터의 export를 요청할 수 있다.
• Issuer
  Issuer는 holder와 관련된 데이터들을 발급해주는 기관이다. 예를 들어, holder의 졸업증명서를 발급해주는 대학교가 될 수 있고, 주민등록등본을 발급해주는 행정기관이 될 수도 있다.
• Verifier
  Verifier는 holder의 개인정보 데이터가 필요한 기관이며, holder가 제출한 정보를 검증하는 기관이다. 예를 들어, holder가 취업하기를 원하는 회사가 될 수 있다.
• Data registry
  DID를 보유한 블록체인이다. DID 시스템의 참여자들(issuer, holder, verifier)은 모두 DID를 보유해야 하며, 이 DID에 대한 정보들을 블록체인에서 저장/관리하게 된다.

모든 참여자들은 holder, issuer, verifier에 국한되는 것이 아니라 모두가 holder, issuer, verifier가 될 수 있다.

Data

그렇다면 어떤식으로 데이터 포맷이 정의되는지 보도록 한다.

w3.org

위 그림은 Verifiable Credential로써 holder가 요청한 데이터 항목들에 대해, issuer가 데이터를 정제하여 holder에게 전달하는 데이터 포맷이다.
각각의 데이터는 Claim으로 존재하는데, 단일 claim 또는 다수의 claim들을 VC에서 보유할 수 있다. Holder가 졸업증명서를 요청하였다면 issuer는 졸업증명서에 대한 정보를 claim으로 만들어 VC에 포함시킨다.
VC에는 proof가 존재하며, 이는 issuer가 발급한것이 맞다는 것을 보장하기 위한 issuer의 DID private key로 생성된 signature이다.

w3.org

위 그림은 Verifiable Presentation이다. Holder는 자신이 보유한 VC를 verifier에게 제출할 때에는 VP로 만들어서 제출해야 한다.
SSI의 특성에 맞게, 자신이 보유한 모든 데이터를 전송하는 것이 아니라, verifier가 필요한 데이터들을 선택하여 단일 혹은 다수의 VC를 모아 VP로 만든다.
VP에는 VC와 비슷하게 proof가 존재하는데, 이는 VP를 생성한 것이 holder가 맞다는 것을 보장하기 위한 holder의 DID private key로 생성된 signature이다.

W3C DID

DID의 표준은 W3C에서 발표가 되어 있다. 다양한 플랫폼, 서비스에서 호환을 위해서는 이 표준을 따라야 할것이며, 대부분의 DID 사용 서비스가 표준을 준수하고 있다.

w3.org

{
  "@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의 구조와 DID document의 예시이다. 블록체인에는 VC, VP가 저장되지 않고 이 DID document가 저장된다.

DID를 간략하게 설명하자면, 사용자를 나타낼 수 있는 key의 집합이라고 할 수 있을것 같다. 해당 DID document를 확인해보자.

하나의 DID(did:example:123456789abcdefghi)는 여러개의 key를 보유할 수 있다. authentication의 id를 확인해보면 did:example:123456789abcdefghi#keys-1로 되어 있는데, #을 기준으로 뒤의 keys-1가 각각의 priv/pub key를 나타내며, 다른 DID key를 발급할 시 keys-2같은 이름으로 DID document에 추가된다. 이렇게 DID와 key 이름이 합쳐진 것을 verificationMethod라고 부른다.
이 key는 예시에 나와있는 Ed25519 뿐만 아니라 Secp256k1 등의 다양한 타입의 key를 보유할 수 있다.
DID document에서는 DID private key는 (당연히) 기록되지 않고, public key만 base58형식으로 기록되어 있다. 추후 DID signature를 검증할 때 이 publc key를 조회하여 사용하게 된다.

DID 표준에 대한 내용은 너무 많으니, 더 깊은 내용을 확인하려면 W3C의 표준 내용을 참고하면 좋을것이다.(링크)

Flow

DID를 구성하는 기본적인 내용은 모두 다뤘다. 이번 단락에서는 verifier에 최종적으로 제출된 VP를 검증하는 방법을 설명하고자 한다. 아래의 VC, VP는 필자가 임의로 구성한 것이며 내부의 credential_subject 등의 데이터 형식이 플랫폼 별로 다를 수 있고, DID 서비스 별로 인증 방식이 다를 수 있음을 미리 명시한다.

Verifier는 VP를 두번 검증해야 한다.

• VP를 제출한 holder가 올바른지
• Holder에게 VC를 발급한 issuer가 올바른지

그림 상에서 차례로 확인해본다.

my

1. Holder로 부터 VP를 수신한다.
2. Verifier는 제출된 VP를 파싱한다. Holder의 Signature 검증을 위해 확인해야 할 사항은 VP 내의 VC, VC(VP)의 소유자의 proof, VP proof를 만들기 위해 사용된 사용자의 DID method key이다.

my

3. VC내에서 발급 대상인 holder를 지칭하는 subject DID를 추출한다. (VC가 아닌 VP 내부에서 추출해도 된다.)
4. 추출한 DID를 base64로 변환한다. (플랫폼 별로 base64변환 없이 사용해도 된다.)

my

5. 3.에서 추출한 DID와 2.에서 파싱한 method key를 이용하여 verification method(그림 상의 DID-method key)를 생성한다.

myj

6. 4.에서 확인한 DID를 이용하여 블록체인에 기록되어 있는 DID document를 조회한다.
7. DID document 상에서 5.에서 생성한 verification method가 어떤 public key를 가지고 있는지 확인하여 추출한다.

myj

8. 2.에서 파싱한 VP proof를 7.에서 획득한 public key를 이용하여 복호화 한다.
9. 검증한다. 복호화 시 해당 VP가 결과로 확인되면, VP를 전송한 사람이 holder라는 것을 DID pubkey를 통하여 검증 가능하다.

myj

10. Holder를 검증했으니, VC를 발급한 사람이 올바른 issuer 임을 확인해야 한다. VC 내에서 발급한 issuer의 DID를 확인한다.
11. Issuer의 DID를 사용하여 블록체인에서 DID document를 확인한다.
12. Issuer의 DID public key를 추출한다. VC 내에는 issuer의 verification method를 확인할 수 있으며, 이 과정은 위의 4.~7.의 과정과 유사하다.
13. 8.~9.와 유사하게 복호화 후 검증한다. 복호화 시 해당 VC가 결과로 확인되면, VC를 발급한 사람이 issuer라는 것을 DID pubkey를 통해 검증 가능하다.

Conclusion

DID 시스템의 구조와 DID를 사용한 인증 방법에 대해 간략히 확인해보았다.
자주 오해가 발생하는 사항이 있는데, DID가 블록체인에 저장되기 때문에 관련된 개인정보도 블록체인에 기록되는 것으로 생각할 수 있다. 그러나 블록체인에는 DID, public key와 관련된 정보만 기록되어 있다. 그래서 이전에 DID를 사용자를 나타낼 수 있는 key의 집합이라고 표현한 것이다. 사용자의 개인정보(=VC)는 holder의 단말에 보관되어 있어서 블록체인에 기록되지 않는다.

개인정보 데이터 주권을 보장할 수 있으며, '인증'이 사용처가 굉장히 방대한 아이템이기 때문에 DID는 블록체인의 킬러앱으로 항상 고려되어 왔다. 하지만 아직 서버 기반의 ID/PW 인증에 비해 사용하는 곳이 많이 없는 점은 사실이다. 블록체인을 다루는 사람으로써 이런 좋은 아이템이 사장되지 않도록 다방면에서 연구해볼 것이다.

참고
http://wiki.hash.kr/index.php/%EC%9E%90%EA%B8%B0%EC%A3%BC%EA%B6%8C%EC%8B%A0%EC%9B%90
https://www.w3.org/TR/did-core/
https://www.w3.org/TR/vc-data-model/