DID 졸업 프로젝트 관련 공부

5 minute read

2021년 졸업 프로젝트 (DID) 관련 공부 내용 정리

DLT (Distributed ledger technology) based identity management (idM)

특징

  • Decentralized
  • tamper resistant
  • inclusive
  • cost effective
  • user control

사용 방식

  • SSI (Self-sovereign identity)

어떤 외부 관리 권한에도 의존할 필요가 없고 사용자에 의해서만 소유되며 컨트롤되는 것

Sovrin, uport 가 속함

  • Decentralized trusted identity

여권 등 기존의 방식으로 신원 증명을 한 후, 나중에 제 3자에 의한 검증을 위해 신원 증명을 DLT에 기록

자기주권 신원증명 (Self-Sovereign Identity, SSI)

  • 탈중앙화 구조를 바탕으로 사용자가 직접 자신의 ID를 관리할 수 있게 만드는 기술
  • 필요한 정보만 제한적으로 제공하거나, 영지식 증명을 통해 정보 공개 없이 신원 인증이 가능하게 만드는 기술
  • 영지식 증명 (zero-knowledge proof) : 참, 거짓을 제외한 어떤 정보도 노출되지 않는 증명 방식

구성 요소

  1. DID, DID document : 식별자와 인증 수단으로 사용
  2. VC (Verifiable Credential, 검증 가능한 자격 증명) : 보관용 ID로 사용 (실제 신분증 용도)
  3. VP(Verifiable Presentation, 검증 가능한 제공 ID 데이터 집합) : 제출용 ID로 사용, VC를 직접 사용하는 것이 아닌 필요한 속성만을 추출하여 VP로 가공하여 사용 (실제 신분증 용도)

DID (Decentralized IDentifier)

  • 분산화된 환경에서 동일한 식별자가 생성되지 않는 구조로 만들어야 한다.
  • DID를 사용하는 객체에 대한 식별자로 사용됨과 동시에, 인증 수단인 DID document 를 참조할 수 있는 URI 역할도 동시에 수행할 수 있다.
  • DID scheme(URI scheme), DID method(DID 저장된 저장소 이름), Method-specific identifier(저장 소 내 DID Document가 저장된 주소)로 구성 (ex: did:btcr:aaaa-xxxx-yyyy)
  • DID resolver/registrar 프로그램을 사용해 다양한 저장소에 접근 가능하다.

DID Document

  • DID 소유권 증명을 위한 인증 수단이 포함 (공개키 등 열람 가능한 정보들이 들어간다.)
  • W3C DID 표준 문서 참고 W3C Decentralized Identifier
  • DID Auth : DID 소유권을 인증하는 방식 총칭

id 필드에는 타겟 DID가 들어가며, publicKey의 controller 필드에는 인증을 진행한 DID가 들어가기 떄문에 두 개를 잘 조합하면 여러 서비스를 구현할 수 있게 된다.

service 필드의 serviceEndpoint 필드를 이용해 다양한 서비스 개발이 가능
DID Auth를 다른 곳에서 수행하는 경우 등에 대해, 해당 지점을 찾을 수 있는 주소가 들어간다.

@context :
JSON-LD 문법으로 정의되어 있으며, 데이터의 의미, 타입 등에 대한 정확한 통신을 위한 정의들이 기록된다.

DID dereference

  • DID document의 특정 항목만 선택해서 호출할 수 있는 방법
  • did:xxx:yyyy;service=Example 등과 같이, 세미콜론으로 구분하여 원하는 항목 호출 가능
  • 웹 URL과 동일하게 동작한다. (path: /, query: ?, fragment: #)

DID Auth

  • 상대방에게 DID에 대한 소유권을 증명하는 과정
  • 비대칭키 뿐만 아니라, 생체 데이터, 문자 인증, 전화 인증 데이터 등 다양하게 사용할 수 있다.
  • Challenge-Response 인증 방식 사용

DID deactivation

  • 블록체인에서는 정보를 완전히 삭제할 수 없기 때문에, DID Auth를 막는 방식으로 사용한다.
  • ex) hyperledger indy의 경우, DID Document의 공개키 값을 모두 0으로 바꿈으로써 인증 불가능하게 만든다.

DID Resolver

  • DID 정보를 가져오기 위해 사용되는 프로그램으로, 사용자 디바이스용과 외부 디바이스용으로 구분된다.
  • DID document의 항목을 개별적으로 저장하는 저장소 등의 경우에서 데이터를 취합, 가공하는 절차 등이 필요한데, 이 과정을 해 준다고 생각하면 될듯
  • 이 과정을 DID Resolution 이라고 한다.
  • DIF(Decentralized Identity Foundation)에서 개발한 universial resolver 라는 오픈소스에서 다양한 종류의 드라이버를 제공 중

DID Registrar

  • 각 플랫폼별로 DID document 등록 방식이 다른데, DID document를 플랫폼에 맞게 변환시켜 등록시켜주는 프로그램이라고 생각하면 될듯
  • DIF(Decentralized Identity Foundation)에서 개발한 universial resolver 라는 오픈소스에서 다양한 종류의 드라이버를 제공 중

VC (Verifiable Credential)

  • 자신을 표현할 수 있는 모든 정보들 (신분증, 증명서, …)
  • Credential metadata, Claims, Proofs로 구성

Credential metatata : VC를 누가 발행했는지, 명시하고 있는 객체(Credential subject), 만료 기간, 폐기 방법 등이 정의

Claim : Credential subject의 ID 속성에 대한 정보가 Subject-Property-Value 방식으로 저장 (현재 non-normative)된다. 여러 개의 subject가 명시될 수 있다.

proofs : VC에 대한 진위 여부 검증에 필요한 값이 포함된다. ( ECDSA, 생체인증 등 다양한 암호 기법이 사용될 수있다.) 검증인은 이 부분을 검증함으로써 VC가 명시된 발행인으로부터 발행된 것 인지 검증할 수 있다.

issuer : VC를 발행한 사람 or 기관
termsOfUse : 이용약관을 추가
evidence : 검증인이 참고할 수 있는 추가적인 정보 입력 (VC 발행 시 확인했던 자료 정보 등), VC에 대한 신뢰 향상을 위함

VP (Verifiable Presentation)

  • VC를 VP 형태로 가공하여 제출
  • Presentation metadata, Verifiable Credentials, Proofs로 구성

Presentation metadata : VP 검증에 참고할 수 있는 데이터가 포함될 수 있다. (type, termsOfUse, evidence, …)

Verifiable Credentiails : VC가 포함되어 잇다. (검증인이 요구하는 ID 속성을 가진 Claim만 선택하여 포함할 수 있기 때문에, 프라이버시 보호 가능)
VC 내에 포함된 proof 항목을 통해 VC 진위 여부를 검증할 수 있다.

Proofs : 사용자의 서명이 들어간다. 검증인은 해당 서명을 검증함으로써 제출한 사용자를 검증할 수 있다. (다양한 암호 기법 사용 가능)

SSI 관련

하이퍼레저 SSI 프로젝트

하이퍼레저 인디 (Hyperledger Indy)

  • indy-node : SSI 플랫폼에 특화된 플록체인 노드 개발, Public Permissioned 형태로 운영되어야 한다.
  • indy-plenum : indy-node의 합의 알고리즘 개발
  • indy-sdk : indy-node와 연동하는 클라이언트 애플리케이션 개발용 SDK 개발

하이퍼레저 에어리즈

  • aries-rfcs: DID, VC, VP 등 SSI 구성요소 관련 기술 사양 및 프로토콜 정의
  • aries-framework-go :ACCEPTED 상태가 된 aries-rfcs의 RFC 내용을 바탕으로 Go 언어로 구현된 SSI 프레임워크 개발

RFC(Request For Comment) 상태

  • PROPOSED : 개발 커뮤니티의 승인을 받지 못한 RFC
  • ACCEPTED : 승인 받은 경우
  • ADOPTED : 실제 서비스에 적용된 경우
  • RETIRED : 더 이상 개발이 진행되지 않거나, 치명적인 결함이 발견된 경우

W3C Decentralized Identifier

  • Verifiable Data Registry (distributed ledger 등) 정해진 후에 어떤 식으로 제공할지(CRUD 등)에 대한 명세인듯?

  • https://www.w3.org/TR/did-core/

    screenshot

    This specification does not presuppose any particular technology or cryptography to underpin the generation, persistence, resolution or interpretation of DIDs. Rather, it defines: a) the generic syntax for all DIDs, and b) the generic requirements for performing the four basic CRUD operations (create, read, update, deactivate) on the information associated with a DID (called the DID document

    This specification is for:
    Developers who want to enable users of their system to generate and assert their own identifiers (producers of DIDs);
    Developers who want to enable their systems to accept user-controlled identifiers (consumers of DIDs);
    Developers who wish to enable the use of DIDs with particular computing infrastructure (DID method developers).

    A DID is a simple text string consisting of three parts, the:
    URI scheme identifier (did)
    Identifier for the DID method
    DID method-specific identifier.
    Example) did:example:12345678asdfghj

  • 깃허브 : https://github.com/w3c/did-core

  • did syntax : https://www.w3.org/TR/did-core/#did-syntax

DIF (Decentralized Identity Foundation)

  • DID 표준화 기구 중 하나

Sovrin

  • https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf
  • Sovrin 블록체인의 DID는 공개키 생성 시, 공개키의 일부분이 Method-specific identifier가 된다.
  • hyperledger indy 사용

Sovrin 플랫폼에서의 DID resolution

  1. DID resolver에 DID document 요청
  2. DID resolver에서 Sovrin driver를 통해 해당 플랫폼에 맞는 DID document 요청 메시지를 생성하여 Sovrin 노드에 전송
  3. Sovrin 노드는 사용자 DID의 Method-specific identifier를 사용해 각 트랜잭션에 나뉘어 저장된 DID 항목값을 검색
  4. 검색한 값을 취합해 DID resolver에 반환
  5. DID resolver에서 수신받은 값을 JSON 양식의 DID document로 변환 후 사용자에 반환

uPort

  • https://github.com/uport-project/specs
  • open source decentralized identity framework (Ethereum DLT 활용)
  • 이더리움 컨트랙트를 통해 디자인되었다.
  • controller, proxy로 구성

    controller : stores a reference to the public key
    proxy : contains a reference to the controller contract

  • 스마트 컨트랙트에 데이터 자체를 저장하는 건 비용이 많이 들기 때문에, 해시값만 저장해둔 후 실제 데이터는 IPFS에 저장한다.

Veres One

  • https://veres.one/developers/guides/create-did/
  • https://www.npmjs.com/package/did-cli

ERC725, 735, 1056

ERC725

ERC1056

  • Lightweight Identity
  • identity 생성 비용을 없애고, 오프라인 환경에서 사용 가능하게 만드는 방식인듯
  • This ERC specifies a contract called EthereumDIDRegistry that is deployed once and can then be commonly used by everyone.

참고
윤대근, 자기주권 신원증명 구조 분석서, 제이펍, 2020-07-03
W3C Decentralized Identifier
https://ettrends.etri.re.kr/ettrends/177/0905177012/34-3_114-124.pdf

Categories:

Updated: