L U N I V E R S E
DID와 함께 자주 언급되는 탈중앙화 주제의 하나로, SSI (Self Sovereign Identity)가 있습니다. SSI와 DID에 대해 자세하게 알고싶으신 분에게 이 아티클을 추천합니다.

1. SSI (Self Sovereign Identity) 개념?

DID 소개에 이어서 이번 주제는 SSI에 대한 내용입니다. DID와 함께 자주 언급되는 탈중앙화 주제의 하나로, SSI (Self Sovereign Identity)가 있습니다. SSI는 직역하자면 “자주 주권 신원” 정도로 해석해 볼 수 있지만 쉽게 이해되지는 않습니다. wiki에서 확인해보면 SSI는 다음과 같이 정의하고 있습니다.
“With self-sovereign identity (SSI) the individual identity holders fully create and control their credentials, without being forced to request permission of an intermediary or centralized authority and gives control over how their personal data is shared and used. … (중략)”
조금 더 구체화시켜 시스템적으로 풀어서 보면 SSI는 다음 정도로 설명할 수 있을 것 같습니다.
”개인의 정보는 개인 스스로 통제하고 제어할 수 있으며, 기존 ID Provider 역할을 자처하는 IT 대기업과 같은 제 삼자의 중재나 개입이 없어도 신뢰 네트워크 기반에서 충분히 높은 보안성을 유지하면서 독립적인 일회성 채널을 통해서 서비스에 필요한 신원 정보만 선택적으로 제출할 수 있고, 제출된 정보에 대한 신뢰성 역시 제 삼자 개입 없이도 증명할 수 있는 시스템”
이번 아티클에서는 20년 이상 Internet Identity 분야에서 각종 표준화 WorkingGroup 멤버로 활약 중인 Evernym사의 Chief Trust Officer이자 Sovrin Foundation Trustee인 Drummond Reed의 발표 자료와 Sovrin Foundation에서 공개한 자료들을 기반으로 설명하려 합니다.

2. 기존 인증 시스템과 SSI 비교

먼저, 기존의 전통적인 인증 시스템 2가지를 살펴보고 SSI 시스템의 추상 아키텍처를 알아보겠습니다. 특히, 개인 데이터 소유/취급 관점에서 각각의 차이가 어디에 있는지 살펴보겠습니다.
2–1. 서비스 업체가 개인 데이터 소유 및 직접 사용
기반 기술: SSL/TLS
첫 번째는 서비스 제공자가 모든 개인 데이터를 직접 소유 및 사용하는 방법으로, 사용자는 ID/Password 기반의 인증(Credential) 정보를 입력하여 회원가입/로그인 함으로써 해당 서비스 이용이 가능합니다. 이러한 전통적인 인증 시스템은 서비스 제공자가 모든 사용자의 민감한 정보를 일괄 보유 및 관리 한다는 측면에서 항상 보안적인 리스크가 존재합니다. 특히, 사용자의 개인정보를 다른 목적으로 유용하면 사용자는 자신도 모르게 개인정보가 타인에게 노출되는 상황에 직면하게 됩니다. 또한, 보안 위험 이외에도 각기 다른 사용자 계정을 만들고 관리해야 하기 때문에 사용자의 편의성은 크게 떨어집니다.
2–2. 서비스 업체는 데이터 소유한 IDP를 통해서 개인 데이터 사용
기반 기술: SAML, OAuth2, OpenID Connect
두 번째는, 서비스 제공자가 데이터를 직접 소유 하는 대신 IDP를 통해서 개인 데이터를 사용하는 가장 보편적인 시스템입니다. Google, Facebook과 같은 IDP라고 불리는 ID provider들이 개인 정보를 보유하고, 서비스 제공자는 IDP를 통해서 사용자가 허용한 개인정보에 한해서 액세스가 가능한 federate 방식의 인증 시스템입니다. 사용자 입장에서는 본인이 신뢰하는 IDP에 계정만 등록하면 되므로 관리 측면에서 유리한 편입니다. 하지만, 독점적 지위를 갖는 중앙 집중화된 IDP는 사용자에게 이러한 편리함을 제공하는 대신에 사용자가 어떤 서비스를 얼마나 자주 이용하는지 같은 기본적인 정보는 물론 좀 더 고도화된 분석을 통해서 사용자의 모든 활동을 추적합니다. 결국, 사용자가 IDP에 맡긴 정보는 기업 영리를 위해 활용되며, 이 과정에서 심각한 개인정보 침해가 발생하며, 시스템 보안 레벨이 낮거나 운영상의 실수로 해킹 사고가 발생하면 결국 많은 사용자가 피해를 받을 수 있습니다.
2–3. 신원 데이터는 각자 소유하고 필요 시 신원 데이터 제출/사용
기반 기술: DLT (Blockchain), DID, DKMS, DID Auth, Verifiable Credentials
블록체인과 같은 신뢰 기반의 네트워크 위에서 사용자와 서비스 제공자는 중재자나 중앙의 제어 기관의 도움이 없이, 각자가 본인의 데이터를 소유하고 관리하는 시스템입니다. 각 피어는 서비스 요청, 서비스 제공이 필요할 때만 일회성 P2P 통신으로 데이터를 교환하게 됩니다.

3. SSI 추상 아키텍처

SSI의 추상 아키텍처는 네 가지 구성 요소로 정의되어 있습니다. 각각의 구성 요소를 하나씩 살펴보겠습니다.
[그림 4. Abstract Architecture of Self Sovereign Identity]
3–1. DID
W3C 주도로 표준화가 진행되고 있는 DID는 DID 주소 값과 1:1 관계를 가지는 DID document가 있으며, 이는 DLT(Distributed Ledger Technology)에 저장됩니다. 보통은 DLT로 블록체인을 사용하며, Bitcoin, Ethereum과 같은 퍼블릭 네트워크 뿐만 아니라 Sovrin의 Indy-node와 같이 DID에 특화된 네트워크도 사용됩니다. W3C DID 표준 명세에서는 Verifiable Data Registries라고 정의하며 다음의 키워드가 포함되어 있습니다. – distributed ledgers – decentralized file systems – databases of any kind, – peer-to-peer networks – and other forms of trusted – data storage DID document는 DID 소유 인증에 사용되는 PublicKey 값을 포함하고 있습니다. 그리고, DLT 마다 DID document를 읽고 쓰는 방법이 다르기 때문에 각 DLT 마다 액세스 방법을 정의한 명세가 필요합니다. 이를 DID method라고 합니다.
3–2. DKMS(Decentralized Key Management System)
DKMS는 데이터 암호화 및 암호화 키 관리를 위한 KMIP을 만든 OASIS 주도로 표준화 노력이 진행되고 있습니다. SSI 2번째 구성요소인 DKMS는 SSI 플랫폼마다 다른 명칭을 사용하기도 하고, 추구하는 아키텍처 방향 또한 다른 경향이 있어서 나름 SSI 플랫폼마다 독자적인 색채가 부여되는 구성요소라고 볼 수 있습니다. Sovrin Foundation 기준으로 DKMS는 DID 소유 인증에 사용되는 Private Key 값을 안전하게 보관, 전달, 관리하는 시스템으로 구성되어 있으며, 현재 오픈 표준으로 제안되어 있습니다. DKMS의 두드러지는 특징 중 하나로 견고한 키 관리 및 복구에 대한 고 사용성 시스템을 꼽을 수 있습니다. Private Key 보관을 위해서 사용자의 단말 내 Edge Wallet과, 클라우드 서비스 내 Cloud Wallet을 구성하여 저장 가능하며, Agent 레이어를 통해서 단말 및 클라우드 상에 구성된 Wallet에 액세스 가능합니다. 키 복구의 경우, “paper wallet”을 이용한 offline recovery 방식으로 키 값을 쪼개서 “trustee”를 이용하여 social recovery를 지원합니다. 예를 들어, 키를 쪼개서 trustee들에게 나눠준 후 일정 수 이상이 복구를 시도하면 키 값이 복원되는 방식입니다.
3–3. DID Auth
– 이 구성 요소는 SSI 플랫폼마다 다른 명칭을 사용하기도 하고, 대상과 그 범위에 대한 정의도 약간씩 상이한 경향이 있습니다. 하지만, 대체로 DID 소유 인증에 필요한 데이터 규격, 메시지 프로토콜, 암호화 알고리즘 등을 포함하는 구성 요소라고 이해하시면 좋겠습니다. – One-time challenge request/response 방식의 인증 프로토콜을 기반으로 동작합니다. – DIF, IETF 주도로 표준화가 진행됩니다.
3–4. Verifiable Credentials
줄여서 VC라고도 표현하고 있습니다. 앞선 세 가지 기본 구성 요소들 보다는 표준화 측면에서 가장 잘 되어있는 편입니다. 상호 교환이 가능하고, 암호학적으로 검증 가능한 디지털 증명서를 의미합니다. 그리고, Verifiable Credential Ecosystem은 VC를 중심으로한 데이터 개인 정보 흐름을 정의하고 있는데, Issuer, Holder, Verifier라는 세 종류의 엔티티가 있습니다. 보통 VC 발급자를 Issuer, VC 발급 받아 보관하는 사용자를 Holder, 사용자가 제출하는 VC를 검증하는 주체는 Verifier라고 정의합니다. 사용자가 Issuer로부터 발급 받는 VC는 사용자의 단말(Edge Wallet)이나 클라우드 서비스(Cloud Wallet)에 보관 됩니다. VC에는 발급자, 만료일, 사용자 관련 assertion, 서명 값 등이 포함되어 있습니다. 이후에 사용자가 서비스 이용 하는 과정에서 Verifier(=서비스 제공자)는 사용자에게 VC 정보를 요청할 수 있습니다. 이 때, 사용자는 요청된 정보들 중에서 본인이 전달하고 싶은 정보에 해당하는 VC들만 선택한 후 Verifiable Presentation이라는 형식의 데이터를 Verifier에게 제출하여 인증을 수행하게 됩니다. Verifiable Presentation는 VC를 복수 개 이상 포함할 수 있으며 특히, Verifiable Presentation에 포함되는 VC들이 모두 본인 것 임을 증명하기 위한 사용자 추가 서명을 포함하고 있습니다. 결국, Verifier는 Verfiable Presentation에 포함된 사용자 서명 및, 각 VC에 포함된 Issuer의 서명들을 확인하고 최종적으로 데이터 검증까지 마치면 인증을 마무리하게 됩니다. 앞선 시나리오를 잘 이해하셨다면 VC를 중심으로한 DID 생태계 존립의 핵심은 “Issuer에 대한 Verifier의 신뢰 수준”이라고 볼 수 있습니다. 즉, 제 아무리 암호학적으로 모든 계산이 성공해서 VC 증명이 완료되어도, Verifier가 신뢰하지 않는 혹은 출처가 불분명한 Issuer가 발급한 VC는 받아들이기 어렵기 때문입니다.

4. DID (Decentralized Identifier)

DID와 SSI의 관계를 살펴보면 DID는 SSI를 실현하는데 필요한 기술 스택 중 하나라고 이해하면 좋겠습니다. SSI를 실현하기 위한 요소로써 각 개체를 구분하기 위한 식별자가 필요합니다. 그리고, 가장 이상적인 식별자는 다음과 같이 정의하고 있습니다.
“Pairwise pseudonymous DID”
직역하자면 “짝을 이루는 익명의 DID” 쯤 될텐데요, A라는 사용자(혹은 Thing)는 B와의 관계를 위해서 did@A:B를 생성합니다. A는 did@A:B를 B와의 인터랙션에서만 사용합니다. 그리고 C와의 관계를 위해서는 did@A:C를 생성해서 C와의 인터랙션에만 사용합니다. 즉, A는 각 관계마다 독립적인 DID 식별자를 사용할 수 있으며, 이는 보안적으로 많은 장점을 가질 수 있습니다.
DID 노테이션 DID의 노테이션은 다음과 같습니다.
[그림 5. DID 노테이션]
기본적으로 URN의 노테이션과 유사합니다. Scheme 위치에 “did”라는 심볼로 시작하며, 중간에 Method라는 항목에는 다양한 DID 플랫폼마다 부여된 고유의 심볼 값(i.e., sov, uport, ethr, btcr 등)이 위치합니다. 마지막으로 Method-Specific Identifier 항목에는 해당 DID 플랫폼에서 부여한 고유의 식별 값이 위치합니다. 위 예제에서는 Sovrin 네트워크에 등록된 3k9dg356wdcj5gf2k9bw8kfg7a를 나타냅니다. 보통 DID는 누구나 어디서든 필요한 만큼 만들어서 쓸 수 있는 단순한 식별 값이라고 보시면 됩니다. 아래 그림을 보시면, 하나의 DID를 생성할 때 Private-Key, Public-Key 쌍을 생성하고, Private-Key는 단말과 같은 안전한 장소에 보관하고 Public-Key는 블록체인에 기록하는 모습을 확인할 수 있습니다. 사실 아래 그림에는 자세히 표현되지는 않지만 Pubilc-Key가 블록체인에 기록될 때는 DID document라는 데이터 구조의 “publicKey” 속성에 추가되어 저장됩니다.
[그림 6. DID와 키 페어의 관계 및 보관 위치]
DID document 다음은 DID document에 대해서 살펴보겠습니다.
DID document는 언제, 그리고 왜 조회하는 것일까요? 이는 상대방과의 인터랙션 과정에서 서명 확인이나 challenge 암호화와 같은 동작을 위해서 대상 DID와 연관된 Public-Key 값을 조회하기 위한 목적과 DID와 연관된 Service-Endpoint 정보를 디스커버리하기 위한 목적으로 사용됩니다. 각 DID 플랫폼마다 약간의 차이는 있을 수 있지만 일반적으로 DLT에 기록되는 DID document의 내용으로는 “publicKey”, “authentication”, “service” 정보들을 포함하고 있습니다. 따라서, DID 생성할 때 만든 Public-Key 값은 DID document 데이터 구조체 안에 “publicKey” 속성에 추가되고 해당 내용이 기록되는 것입니다. 참고로, DID document는 여러 개의 Public-Key를 보유할 수 있습니다. (인증 방식이나 용도 마다 서로 다른 Public-Key를 여러 개 등록해서 사용하기도 하며, 특정 Public-Key를 컨트롤하는 소유자의 정보도 “controller”라는 속성과 함께 기록이 되기도 합니다. 물론 key rotation을 목적으로 Public-Key 값을 업데이트하는 것도 가능합니다.) DID 인프라스트럭처 관점에서 블록체인과 같은 DLT는 DID를 위한 global key-value 저장소로 생각하면 됩니다. Key 값으로 “did:sov:3k9dg356wdcj5gf2k9bw8kfg7a” 형태의 DID 값이 저장되고, Value 값으로는 DID document가 저장됩니다. 즉, 특정 DID 값으로 블록체인을 조회하면 입력으로 주어진 DID에 해당하는 DID document를 확인할 수 있습니다. DID document는 JSON-LD 형식의 데이터이며 대표적으로 다음과 같은 속성으로 구성됩니다. W3C 표준에는 더 많은 속성들에 대한 명세가 있지만 여기서는 핵심적인 3가지 속성만 살펴보겠습니다. – “id”: 해당 DID document의 대상 즉, DID subject에 대한 DID 식별 값 – “publicKey”: 상대방과 인터랙션 과정에서 암호학적으로 증명이 필요한 경우에 해당 속성(들)을 사용하게 됩니다. 주로 서명 확인, challenge 암호화에 사용됩니다. – “authentication: 인증 방식에 대한 정보들을 포함합니다. – “service”: DID subject와의 인터랙션을 위한 Service-Endpoint 정보를 확인하는데 사용됩니다. 보통 URL 형태입니다. 위와 같이 블록체인에 기록되는 DID document는 외부에 공개되어도 무리가 없는 항목들로만 구성되어 있으며, PII (Personally Identifiable Information)에 해당하는 내용은 가급적 포함하지 않도록 합니다.
[그림 7. DID document 샘플]
DID 컴포넌트 구조 DID 노테이션과, DID document, 그리고 DID document를 구성하는 주요 속성들을 몇 가지 살펴봤습니다. 소개되지 않은 몇 가지 항목을 더 살펴보도록 하겠습니다.
[그림 8. The basic components of DID architecture]
위 그림에서 DID 컨트롤러는 DID document를 업데이트 할 수 있는 권한을 가진 엔티티의 DID 값 입니다. 보통은 DID 컨트롤러는 DID document의 Subject 자신이 되는게 일반적이지만, 다른 엔티티가 업데이트 권한을 위임 받아서 DID document를 업데이트 할 수 있습니다. 즉, DID 컨트롤러는 DID document의 Public-Key를 추가/제거하거나 Service-Endpoint를 추가/제거하는 것은 DID 컨트롤러가 수행할 수 있습니다. 이 외에 DID 컨트롤러와 비슷하지만 약간 다른 개념으로 Key 컨트롤러라는 것도 있습니다. 이 둘의 차이점은, DID 컨트롤러는 DID document의 최상위 엘리먼트로써 “controller” 이름의 속성으로 지정하며 해당 속성이 지정되지 않더라도 암묵적으로 추론 가능합니다 (i.e., 가령, 해당 DID document의 디폴트 DID 컨트롤러는 DID Subject라는 사실 추론). 반면에 Key 컨트롤러는 각 “publicKey” 속성 하위에 “controller” 이름의 속성으로 지정하며 반드시 명시적으로 지정을 해야 합니다. 이는 DID document의 DID 컨트롤러가 엔티티를 Key 컨트롤러에 지정 가능하기 때문입니다. 마지막으로 DID resolver는 DID 값을 입력으로 받아서 해당하는 DID document를 결과로써 반환하는 소프트웨어나 하드웨어를 의미합니다. 이러한 처리를 DID resolution이라고 하며, 입력된 DID에 대한 DID document를 가져올 때, DID 값에 지정된 DID method에 따라서 resolution 절차를 달리하게 됩니다. 이는 DID 플랫폼마다 DID document를 생성, 조회, 갱신, 삭제하는 방법이 전혀 다르기 때문입니다. 이렇듯 DID Method Registry에 등록된 여러 DID 플랫폼이 정의해 놓은 다양한 규격에 맞춰서 DID document를 조회하는 것은 쉽지 않습니다. 그래서, 여러 DID 플랫폼들에서 만들어진 DID 값을 입력하면 resolution을 쉽게 처리해주는 것으로 DIF에서 오픈소스로 공개된 Universal Resolver라는 것도 있습니다. 다음은 Universal Resolver의 아키텍처를 보여주고 있습니다.
[그림 9. DIF Universal Resolver`s Extensible Driver Architecture]
DID 플랫폼이 Universal Resolver의 플러그인 구조에 맞는 드라이버를 작성해서 등록하면 해당 DID 플랫폼에서 생성한 Universal Resolver를 통해서 DID resolution을 수행할 수 있습니다. 이와 반대로 여러 DID 플랫폼들에 대한 DID를 등록을 할 수 있는 Universal Registrar라는 것도 있습니다. 이 역시 DIF에서 오픈소스로 공개되어 있습니다.

루니버스 주요 아티클 소식을 가장 먼저 접하고 싶다면?

Get Started!

Enterprise Solutions for Blockchain Development, Operation, and Service Enterprise Solution
Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Related Posts

blockchain_raw_data
Tech

루니버스 비공개 데이터 최초 공개

루니버스 출시 후 1년이 지난 지금, 어떤 의미 있는 데이터가 축적되었을까요? 기업 고객 수, 활성화된 토큰 수 등 생태계 지표와 기술 지표를 전부 공개합니다. 축적된 데이터에는 어떤 의미가 담겨있는지 아티클을 통해 확인해보세요.

Read More »

4F, 14 Teheran-ro 4-gil, Gangnam-gu, Seoul, Korea, 06232
Ceo. Park Jaehyun
Business Registration No. 694-86-01434
Online Marketing Report No. 2019-Seoul Gangnam-02255

ⓒ Lambda256 Inc, All Rights Reserved.