2.1 Blockchain

블록체인⁽⁴⁾은 트랜잭션 단위의 데이터들을 수집하여 만든 블록을 연쇄적으로 연결하여 체인 형태로 데이터를 관리하는 전자 장부이다. 각 블록은 이전 블록의 해시를 블록 내 헤더 영역에 포함한 형태를 보인다. 이는 외부자가 블록에 포함된 트랜잭션을 임의로 수정할 경우, 수정된 트랜잭션이 포함된 블록의 이전 블록들도 수정하도록 강요하여 위변조를 막는다.

데이터의 성격에 따라, 블록체인에 트랜잭션을 기록하고 읽는 것은 제한될 수 있다. 참여자의 기여가 자유로운 블록체인을 퍼블릭 블록체인이라 하며 허가를 요구하는 것을 프라이빗 블록체인이라 한다.

블록체인은 신뢰성과 무결성을 보장하는 저장소의 역할 뿐만 아니라 애플리케이션 플랫폼⁽⁵⁾으로도 사용된다. 블록체인 플랫폼 위에서 동작하는 애플리케이션은 기본적으로 플랫폼 내 다른 애플리케이션, 그리고 트랜잭션들과 상호작용될 수 있으며 오라클을 통해 외부 데이터를 불러올 수 있다.

2.2 IPFS(InterPlanetary File System)

IPFS⁽⁶⁾는 분산 파일 시스템으로 데이터를 특정 하드디스크 또는 서버에 저장하지 않고 나눠가지며, 제 3자가 데이터를 요청할 때 여러 노드로부터 조각들을 합치는 방식으로 동작한다. 특정 서버에서 모든 데이터를 요청하지 않으므로 IPFS를 통한 데이터 요청은 기존보다 낮은 대역폭을 사용하며, 자료를 요청한 노드는 동일한 자료를 요청받을 때 자료 제공에 참여하게 되므로 사용자 요청이 많은 자료일수록 자료 손실 발생이 적어진다. 데이터와 저장된 노드들은 분산 해시 테이블로 관리되며 데이터는 개별적으로 부여되는 컨텐츠 주소를 통해 접근된다. 데이터의 변경이 발생할 경우 형상 관리처럼 이전 데이터와 최신 데이터로 나뉘어 개별적으로 기록된다.

2.3 분산 신원

Decentralized Identity(DID)⁽⁷⁾는 중앙 정부, 또는 기관에서 발급되는 신원, 또는 자격들을 소유자가 Attribute처럼 관리하고 인증이 요구될 때 필요한 정보만 제공할 수 있도록 하는 분산 신원 기술이다. DID는 자격을 발행하는 issuer, 발행한 자격을 소유하고 관리하는 holder, 자격을 제출받고 이를 검증할 수 있는 verifier로 구분되며 데이터의 무결성과 공개성을 보장하는 verifiable data registry로 구성된다. 블록체인의 tamper-proof, interoperability한 성질을 이용하여 블록체인 환경을 verifiable data registry의 기반으로 하는 DID가 다수 연구되었으며, U-Port⁽⁸⁾, Sovrin⁽⁹⁾ 와 같이 웹 표준을 개발하는 국제 조직인 W3C(World Wide Web Consortium)의 DID format protocol⁽¹⁰⁾을 따르는 DID가 존재한다.

제안 시스템은 정보의 분산과 상호운용성, 그리고 사람을 고려한 데이터 가독성에 목적을 두었으며 이는 기존 시스템과 일부 유사성, 그리고 차별성을 갖는다.

U-Prove는 다양한 전자 증명서를 생성하고 이를 타인이 요청할 경우 자격증 형태로 제공한다. 이는 사용자가 검증자에게 정보 없이 간접적으로, 또는 ID토큰을 통해 필요 정보만을 제공할 수 있고 서명 과정으로 자신의 개인정보 사용을 관리할 수 있다. 개인 정보는 개인키와 함께 기기에서 관리되며 정보 제공을 위해 외부 서비스와 연결되기 위해 기술 제공자인 Microsoft를 거치게 된다.

Stampery⁽¹¹⁾는 비트코인에서 제공하는 80Byte의 여유 공간을 이용하여 개인정보를 증명하는 일종의 스탬프를 기록한다. 스탬프는 구체적인 데이터를 갖지 않은 Proof의 성격을 지니며 비트코인이 갖는 영속성과 무결성이 스탬프에 포함될 파일, 또는 정보가 변하지 않음을 보장한다. 정보에 대한 타임스탬프 개념에 가깝기 때문에 원본 데이터가 필요하다.

CredenceLedger⁽¹²⁾는 퍼미션 블록체인 환경의 신원 증명 서비스로 동일 네트워크 안에 참여된 서비스라면 SSO처럼 자신을 증명하거나 활동을 퍼미션 블록체인에 서명하고 기록할 수 있다. CredenceLedger는 교육과 관련된 증명 분야에서 사용되며 권한형 블록체인의 특성상 증명서 생성이 권한자에 한정되고 네트워크 참여 역시 권한을 요구하기 때문에 중앙형 서비스에 가까운 형태를 갖는다.

자기주권형 콘텐츠 관리 시스템⁽¹³⁾은 콘텐츠 소유자가 외부 서비스에게 자신의 콘텐츠 사용을 허가하고 관리할 수 있도록 한 시스템으로 IPFS를 사용하여 콘텐츠를 저장하고 이를 컨트랙트로 관리한다. 해당 서비스는 공개 콘텐츠를 대상으로 하므로 민감한 개인정보를 다루기 어렵고 작성한 데이터는 모두 공개된 형태이기 때문에 도용에 취약하다.

3.1 시스템 구조

제안하는 시스템은 누구나 자유롭게 자격증(credential)을 발행하고 이를 신뢰 가능한 블록체인에 배포할 수 있으며, 자격자(credential holder)는 기관의 부재와 관계없이 자신의 자격증을 관리할 수 있도록 한다. 이를 위한 방법으로 DID에서의 데이터 주권과 탈중앙화된 참여 방식을 블록체인을 통해 적용하였으며 그림 1의 구조와 같다.

그림. 1. 시스템 구조와 시나리오 흐름

Fig. 1. Solution structure and flow

Issuer는 소유자에게 온전한 형태의 자격증을 발급하고 블록체인상에서의 자격증 발행인(Issuer contract)에 텍스트 형태로 기록한다. Holder는 임의의 문자열을 기반으로 생성한 credential key를 credential identifier와 함께 공용 Holder contract에 기록한다. 생성한 key를 통해 소유자는 verifier에게 제공하고자 하는 정보들을 선택할 수 있으며 제공하는 증서의 key와 발급된 기관의 contract address를 함께 전달하면 검증자가 확인할 수 있다.

3.2 증명 규격

그림. 2. W3C에서 제안하는 credential과 context

Fig. 2. W3C recommended credential and context

시스템에서 참여자들이 주고받는 데이터의 형식으로 W3 DID가 표준화를 진행중인 context format⁽¹⁰⁾을 이용한다. Con- text format은 그림 2와 같이 JSON 형태로 구성되어 있으며 다양한 형태의 데이터들을 표현하는 방법을 사전에 정의하고 이를 누구나 시각적으로 확인할 수 있도록 만들어놓은 규격이다.

그림. 3. Contexts 컨트랙트 형태

Fig. 3. Contexts Contract format

제안하는 시스템에서는 이더리움 블록체인에 각 발급 기관들이 관련된 내용들을 합의하여 context화 시킬 수 있으며 그림 3과 같이 단일 contract에서 관리한다. Context는 투표를 통해 관리되어 부적절한 context는 제거된다.

3.3 시스템 요소

3.3.1 발행인(Issuer)

Issuer는 holder가 필요한 자격 정보들을 발급해주고 발급된 전자 문서가 올바른 것임을 자신의 전자 서명이 포함한 형태로 이더리움 블록체인에 그림 4의 Issue와 같이 등록한다.

그림. 4. IssuerHub과 목록으로 등록된 Issuer 컨트랙드들

Fig. 4. IssuerHub and included Issuer contracts

Issuer는 IssuerHub에 등록되어야 신뢰할 수 있는 발행인 자격을 얻을 수 있으며 등록하기 위해서는 발행인의 이더리움 주소와 컨트랙트 주소, 그리고 홈페이지 URL이 필요하다.

신뢰할 수 있는 발행인은 계층적 구조로 되어 있으며 도메인 규칙을 따른다. 발행인이 계층 구조에 포함되기 위해서는 다수의 검증된 발행인들의 동의를 구해야 한다. 검증되고자 하는 발행인은 포함되고자 하는 계층의 발행인들에게 추천을 받거나 일정량 이상의 해당 계층 발행인들에게 찬성을 받을 경우 스스로 포함될 수 있다. 새로운 발행인에 대한 검증은 발행인의 이더리움 주소와 발행인이 등록한 URL에서 응답받은 이더리움 주소와의 일치 여부로 판단한다.

그림. 5. 신뢰할 수 있는 Issuer들의 계층 구조

Fig. 5. Hierarchical structure of trustworthy issuers

그림 5는 계층적으로 구성된 Issuer를 표현한 예이다. 발행인의 성격에 따라 최초로 구분되며 한 발행인 그룹 안에서 다양한 기관들이 자격 정보를 발행할 수 있다면 대표 발행 기관 내에 존재하는 Issuer들이 속하는 새로운 계층(level)을 갖는다.

IssuerHub의 발행인 검증이 수행되기 위해 지정되는 최초의 신뢰할 수 있는 발행인은 IssuerHub contract의 배포자로 지정된다. 신뢰할 수 있는 issuer들은 도메인 형태의 계층 구조로 구성되어 동일한 계층의 다른 발행인의 평판을 감소시킬 수 있고 자신의 하위 그룹을 생성하고 수정할 수 있다. 감소된 평판은 일정량 누적될 경우 검증된 발행인의 자격이 취소된다. 최초로 등록된 신뢰할 수 있는 발행인 역할은 맡은 최상위 발행인은 검증인이 충분하다고 판단될 경우 스스로 자격을 말소한다. 충분한 검증인은 단순한 숫자보다 올바르게 역할을 수행할 수 있을 정도의 신뢰성, 또는 공신력을 요구하며 최선의 경우 시와 정부 부처, 단체 및 대기업이 최상단 참여자로 30개의 검증인이 참여한다면 충분하다고 판단할 수 있다. 상위 수준의 신뢰가능한 검증자가 없다면 분야별로 장기간 동안 적극적인 거버넌스 참여를 수행할 때 검증인이 최상위 검증인으로 재편성될 것이며 재편성은 거버넌스의 활성도와 문제 발생 빈도에 따라 가변적으로 이뤄진다.

3.3.2 소유자(Holder)

Holder는 전달받은 증서를 credential key – identifier 형태로 이더리움 블록체인에 기록하여 verifier가 원활하게 전달받고자 하는 identifier를 사용할 수 있도록 한다.

Credential key는 사용자가 생성한 임의의 문자열의 연속된 해시이며 credential key는 contract 외부에서 생성되어야 한다. Identifier와 매핑된 key는 verifier가 검증한 후에 전달받은 자격 정보를 다시 사용하는 것을 막기 위해 holder가 임의로 key를 바꿀 수 있다.

Holder는 그림 6의 Record에 선택적으로 credential에 대한 메모를 할 수 있다. 메모는 사용자가 해당 credential을 인지할 수 있을 수준으로 작성한다. Record는 구체적인 데이터가 등록된 issuer contract의 주소를 숨김으로써 추적할 수 없도록 한다.

그림. 6. HolderHub contract

Fig. 6. HolderHub contract

3.4 시스템 흐름

3.4.1 사용자 인증

Issuer와 holder는 Issuance Step에서 사전에 알고 있음을 전제로 진행되므로 그림 7과 같이 handshake step을 통해 issuer가 holder의 이더리움 주소를 인지해야 한다. 그러므로 사전에 안전한 방법으로 holder의 이더리움 주소를 알고 있다면 본 step은 생략 가능하다.

Holder가 issuer의 대회 참여 또는 입사를 위해 제출한 이더리움 주소는 메타 마스크를 통한 전자 서명을 통해 Holder가 해당 이더리움 주소를 소유하고 있음을 증명한다.

최초 연결에서 issuer는 holder의 이더리움 주소를 요청한다. Issuer는 holder의 이더리움 주소와 임의의 nonce를 사상한 후 이를 자신의 메모리에서 일정 시간 동안 관리하며 holder에게 nonce를 전달한다. Holder는 nonce를 자신의 개인 키로 전자서명한 후 Issuer에게 이더리움 주소와 함께 전달한다. 전자서명은 ECRecover를 통해 누가 서명하였는지 확인할 수 있으며, Web3는 ECrecover 과정을 통해서 서명자의 이더리움 주소를 생성할 수 있다. 전자서명과 같이 전달된 이더리움 주소가 자신이 메모리상에서 사상한 것과 동일하면 올바르게 인증된 것으로 판단한다.

그림. 7. Handshake step의 진행 순서

Fig. 7. Process of handshake step

3.4.2 증명서 발행

Issuer는 그림 8과 같이 웹사이트, 또는 QR코드 등을 통해 holder에게 credential을 전달하고 이더리움 블록체인에 credential을 기록하여 검증 과정에서 고정된 데이터 제공자가 필요하지 않도록 한다. Holder는 issuer에게 전달받은 credential에서 identifier와 자신이 임의로 생성한 key를 한 쌍으로 하여 블록체인에 기록한다. Key는 검증자에게 전달하고자 하는 요소들을 표현하는 데 쓰인다.

그림. 8. Issuance step의 진행 순서

Fig. 8. process of issuance step

Issuer는 임의의 허가되지 않은 사용자가 credential의 holder를 확인하는 것을 막기 위해 그림 9와 같이 credential과 holder 값을 이용하여 생성한 xholder 값을 사용한다. credential을 Context에 맞게 JSON 형태로 생성한 후 Handshake step에서 확보한 Holder의 이더리움 주소를 JSON 끝에 Holder의 이더리움 주소를 추가한 후 해싱한다.

해시 값은 Holder의 이더리움 주소와 XOR 연산하며 이를 통해 생성된 값을 xholder attribute로 취급하여 credential에 포함한다. 포함된 xholder 값은 Holder가 발급 기관을 기억하지 못할 경우 자신의 credential들을 탐색할 때 사용될 수 있으며 Holder와 Issuer를 제외한 외부인은 해싱되기 전의 JSON값 뒤에 포함된 값이 무엇인지 알 수 없으므로 증서의 소유자를 유추하거나 임의의 대상과 연관 관계를 생성할 수 없다.

Holder는 발행인에게 credential을 발급받으며 xholder 값을 credential identifier로 삼는다. Holder는 Issuer contract address와 credential identifier를 이용하여 그림 9의 과정을 역으로 수행하는 방법으로 이더리움 블록체인에서 자신의 Credential을 찾아낼 수 있다.

Holder는 자신이 발급받은 credential identifier를 임의로 생성한 문자열을 반복하여 해싱한 값과 identifier를 사상한다.

그림. 9. 익명성과 검증 가능성을 보장하는 ID 생성

Fig. 9. verifiable ID generation method to ensure privacy

3.4.3 증명서 검증

Verifier는 holder로부터 다양한 credential identifier와 Issuer contract가 연결된 key set을 받는다. 검증자는 그림 10과 같이 각각 사상된 contract에서 identifier를 사용하고 해싱을 통해 나온 결과 값으로 올바른 holder가 제시한 값인지 확인한다.

그림. 10. Verification step의 진행 순서

Fig. 10. Process of verification step

Issuer contract에서 검색된 credential과 Holder의 이더리움 주소를 통해 소유 여부를 확인할 수 있다. 검증은 그림 X의 과정을 역으로 수행하여 검증할 수 있다. Issuer의 issuer 계층 그룹과 신뢰 가능 여부를 확인하여 credential이 적합하게 소유했더라도 credential이 내포한 내용을 신뢰할 수 있는지 가늠할 수 있다.

Verifier는 filePath 값을 통해 IPFS 또는 Issuer가 제공하는 시스템에서 시각적으로 문서화 된 credential을 확인할 수 있다.

5.1 시스템 분석

모든 Holder의 증명 데이터는 이더리움 블록체인을 분석하는 것으로 사용자 정보를 추측할 수 없도록 구성되었다.

Holder의 정보를 알기 위해서는 개별적으로 발급된 credential들의 Issuer contract를 알고 있어야 하며 이 정보는 블록체인에 기록되어 있지 않다. 그러나 holder의 address를 XOR하는 방식으로 생성한 xholder가 각 credential에 포함되어 있으므로 holder는 특별한 요소 없이 자신의 모든 credential을 찾아낼 수 있다.

Issuer가 속한 계층을 통해서 해당 issuer의 신뢰도를 확인할 수 있다. Trustworthy issuer는 계층적인 형태의 issuer group에 포함되어 있으므로 사용자는 issuer의 group 정보를 통해 별도의 확인 절차 없이 신뢰할 수 있다.

Issuer group은 verifier와 연동된 홈페이지가 제공하는 이더리움 주소를 통해 신뢰하고자 하는 대상을 검증한다. 검증된 대상은 반대로 인해 신뢰도를 상실할 수 있으며 누적될 경우 group에서 제외될 수 있다. 신뢰할 수 있는 verifier라 하더라도 계층 권한 이상의 작업은 처리할 수 없다.

credential은 context에 정의된 유형에 따라 credential 값이 블록체인에 기록되며 credential에 관련된 문서 이미지가 포함될 수 있다.

5.2 시스템 비교

제안하는 시스템과 유사한 목적, 또는 서비스를 제공하고자 하는 시스템들을 비교한다.

U-Prove는 credential을 생성하고 소유자에게 제공하는 Issuance Protocol과 제공받은 credential을 요구하는 검증자에게 전달하는 Presentation Protocol로 나뉜다. Microsoft로부터 적합하다고 인정되는 attribute는 Microsoft의 이름으로 서명되어 소유자에게 제공된다. 소유자는 이를 Device 내에 존재하는 개별 개인 키로 서명한다.

Stampery⁽¹¹⁾는 비트코인 블록체인에서 증명의 무결성과 지속성, 그리고 Self-Sovereign을 제공하는 서비스이다. 비트코인에서 사용 가능한 80 Byte의 공간을 사용하여 제공되며 크기의 문제로 인해 증명에 관련된 인간 친화적인 데이터가 아닌 holder와 증명을 해싱한 값만 기록된다. 실질적인 증명에 관련된 부분은 이메일 등의 서비스를 통해 제공되며 issuer가 holder의 bitcoin address를 획득하는 과정도 이메일 내 포함된 invitation을 통해 얻는다. Stampery는 버전에 따라 이더리움 블록체인에 proof를 기록하는 방법도 제공하며 proof는 W3ID의 chainpoint 형식을 따른다.

CredenceLedger⁽¹¹⁾는 허가형 이더리움 블록체인을 기반으로 구축되었으며 학업에 관련된 자격증, 수료증의 증명 제공을 목표로 한다. 사용자는 CredenceLedger Client에서 Verifier에게 블록체인에 기록된 Credential에 접근할 수 있도록 할 수 있으며 Credential의 주소를 받은 검증자는 이를 확인할 수 있도록 구성된다. 사용 가능한 구성원이 한 기관 내의 한정된 인원이기 때문에 광범위한 영역에서 사용되기 위해서는 새로운 CredenceLedger를 형성해야 한다.