자기주권 신원증명 기반 스마트 계약 구현을 위한 자격증명 시스템 제안

2.1 디지털 인증서

디지털 인증서는 사용자의 신원을 전자 수단으로 인증하는 방식으로, 흔히 온라인에서는 대칭키, 비대칭키 암호화 기반의 디지털 인증서가 사용된다. 대칭키 암호화는 동일한 두 개의 키 쌍을 사용해서 암호화/복호화를 수행하고, 비 대칭키 암호화는 서로 다른 두 개의 키 쌍인 공개키와 비밀키를 사용해서 암호화/복호화를 수행한다[3].

2.2 대칭키 암호화 방식

대칭키 암호화 방식은 암호화와 복호화에 같은 대칭 키를 사용하는 암호화 알고리즘이다. 그림 1 과 같이 사용자와 수신자가 대칭키를 이용하여 암호화 통신을 하는 과정을 나타낸다[3][4].

Fig. 1.

Encryption using symmetric keys

사용자가 우선적으로 대칭키를 생성하고 안전한 방법으로 상대방에게 공유를 해야 한다. 이후 공유한 대칭키를 이용하여 데이터를 암호화 한 후 사용자에게 전송을 하고 암호화된 데이터를 수신한 수신자는 송시자로부터 공유된 대칭키를 이용하여 암호화된 데이터를 복호화 할 수 있다. 송신자와 수신자 간 암호화 된 데이터는 서로 간의 공유된 대칭키가 있어야만 복호화를 할 수 있기 때문에 해커가 중간에서 데이터를 가로채더라도 공유 된 대칭키가 없는 이상 데이터의 내용을 알 수 없다. 하지만 대칭키를 공유하는 과정에서 해커로 인해 대칭키를 탈취당할 수 있다면 해커는 탈취한 대칭키를 이용하여 암호화된 데이터의 내용을 모두 알 수 있다는 취약점이 발생한다[4].

2.3 비대칭키 암호화 방식

비대칭키 암호화 방식은 비밀키(Private key), 공개키(Public key)라 불리는 서로 다른 키 쌍을 사용해서 암호화와 복호화를 수행한다. 기본적으로 공개키는 외부에 공개할 수 있고, 비밀 키는 주인이 안전하게 보관해야 하며 절대 유출해선 안 되며, 비밀키로 암호화를 수행하면 데이터 송신자 에 대한 사용자 인증이 가능하다. 그리고 공개키로 암호화를 수행하면 데이터 암호화가 가능하다. 그림 2는 공개키와 비밀키를 이용해서 사용자 인증과 데이터 암호화 구현 방법을 나타낸다[4].

Fig. 2.

Encrtption using asymmetric keys

우선, 송신자는 자신의 비밀키를 이용해서 전송할 데이터를 암호화한 후 파일을 수신자에게 전송한다. 송신자의 비밀키로 암호화된 파일은 오직 송신자의 공개키로 복호화가 가능하기 때문에 만약 암호화된 파일이 복호화가 되지 않는다면 해당 데이터는 송신자가 보낸 것이 아니게 된다. 하지만 비대칭키에도 다음과 같은 취약점이 존재한다. 송신자에서 본인의 비밀키로 공개키를 만들고 수신자에게 보내게 될 때, 수신자에게 전달하기 전에 해커가 패킷을 가로채 자신의 공개키를 송신측에 전달한다. 그리고 수신자는 해커의 공개키로 데이터를 암호화해서 보내면, 이 때 해커가 또 패킷을 가로채서 본인의 개인키로 데이터를 복호화하면 원본 데이터를 알아낼 수 있다.

2.4 SSL/TLS 프로토콜

앞부분과 같이 비 대칭키 암호화 방식만 이용해서 암호화를 수행하면 보안에 취약하다. 이를 방지하기 위해 CA(Certificate Authority, 인증기관)라고 부르는 인증노드를 활용한 SSL/TLS 프로토콜을 사용한다. SSL/TLS를 사용하면 클라이언트/서버 간 통신을 암호화하기 때문에 안전하게 통신할 수 있다. 또한 CA에서 발행한 서버 인증서를 사용해 서버의 신뢰성을 증명할 수 있다. 서버 인증서는 CA가 서버의 신뢰성을 증명하기 위한 디지털 데이터로, 서버의 공개 키와 사용자의 정보가 합쳐져 있다. 서버 인증서에는 CA가 전자 서명을 하고 있으며, 웹 브라우저(클라이언트)에 Root CA 인증서를 사용해 확인할 수 있다. SSL/TSL 데이터 흐름은 그림 3과 같다[5].

Fig. 3.

SSL/TLS protocol data flow

2.5 블록체인

블록체인 기술은 누구나 열람할 수 있는 분산 원장 환경의 장부에 거래 내역을 투명하게 기록하고, 모든 참여자가 동일하게 관리 할 수 있는 분산형 데이터 저장 기술이다. 기존의 중앙 집중 시스템에서 데이터를 위변조를 하기 위해서는 중앙 서버를 공격하면 가능했지만 블록체인은 여러 참여자가 동일한 데이터를 나눠 가지고 있기 때문에 무결성을 지킨다[6][7].

2.6 스마트 컨트랙트

스마트 컨트랙트는 1996년 Nick Szabo에 의해 고안된 개념으로 당사자들이 다른 약속에 따라 수행하는 프로토콜을 포함하여 디지털 형식으로 지정된 일련의 약속이라고 정의했다. 블록체인에서 스마트 컨트랙트는 일반적으로 솔리디티 같은 고급 언어로 작성되며 트랜잭션을 저장하고 사용할 수 있다[7].

3.1 DID 구조

기존 사람의 주민등록번호나 상품 일련번호 등의 중앙화된 식별자는 중앙 기관을 통해 발급받고 통제되는 구조이다. 반면 DID는 사용하는 사람 스스로 생성하고 제어할 수 있는 분산형 식별자이다[8].

그림 4는 플랫폼의 DID 주소 예시를 나타낸다. DID는 DID scheme, DID method, Method-specific identifier 3가지로 구성되어 있다. DID scheme은 URI(Uniform Resource Identifier)가 어떤 프로토콜을 사용해서 자원에 접근하는지 명시한다. URI scheme는 사람들이 흔히 사용하는 http 및 https를 포함한 다양한 프로토콜이 정의되어 있는데, DID scheme에 did가 들어가므로 정의한 자원 접근 방식에 따라 자원을 찾아 간다[8][9].

Fig. 4.

Platform DID structure example

DID method는 DID document가 어떤 저장소에 저장되어 있는지 보여준다. 다음 그림과 같이 DID method에 gsmc가 명시되어 있는데 gsmc는 이더리움 기반 프라이빗 네트워크이다. 따라서 gsmc 이름을 가진 이더리움 기반 프라이빗 네트워크에 접근하여 DID document를 검색한다. 마지막으로 DID method가 가리키는 저장소 내 DID document가 저장된 정확한 위치를 검색하기 위해서는 Method-specific identifier가 필요하다. DID method를 참조해서 프라이빗 이더리움 블록체인에 접근한 후 Method-specific identifier를 이용해 검색하면 DID document를 불러올 수 있다. 여기서 Method-specific identifier 부분은 DID method가 gsmc이므로, 어카운트 주소가 Method-specific이다[8][9].

3.2 플랫폼 DID document 구조

DID document에는 DID의 소유권을 증명할 수 있는 인증 방법이 포함되어 있다. 아래 그림 5는 DID document의 구조를 보여준다. 전체 구조에서 DID document는 @context, id, verification Method 그리고 authentication으로 구성된다. 먼저 id 항목은 id를 통해 식별되는 객체의 DID가 들어가는 항목으로, 일반적으로 DID와 DID document를 생성 혹은 생성 요청을 하고 등록한 사람의 DID가 id 항목에 들어간다. verification Method 항목에는 id, type, controller, signature라는 4가지 세부 항목들로 구성된다. id는 verification Method내 사용할 수 있는 인증키의 위치를 나타낸다. type 항목은 id의 인증 방식이 들어가는데, 여기서는 RSA 비대칭키 인증이 사용된다. signature는 소유권 인증에 사용될 데이터가 저장돼 있으며, 해당 DID document 구조에서 저장소가 이더리움 기반이기 때문에 서명 값이 비대칭키 인증 방식에 사용되는 공개키로 저장된다. 마지막으로 controller 항목에는 해당 공개키와 쌍으로 이루는 비밀키를 가진 사람의 DID가 저장된다[10][11].

Fig. 5.

Platform DID document structure

3.3 VC 데이터 모델 구조

사용자는 발행인으로부터 자신의 ID 속성을 증명할 수 있는 자격증명을 발급받을 수 있다. 이러한 자격증명을 VC(Verifiable Credential)라고 부르는데, 주민등록증과 같은 신분증부터 졸업증명서, 재직증명서 등 자신을 표현할 수 있는 모든 ID 속성이 VC에 포함될 수 있다. VC는 Credential metadata, Claim(s), Proof(s)로 구성된다. 우선 Credential metadata는 VC를 누가 발행했는지, VC가 명시하고 있는 객체(Credentail subject)를 나타낸다[12].

Claim(s)에는 객체의 ID 속성 정보가 Subject-Property-Value 방식으로 저장된다. 따라서 어떤 Subject에 대한 ID 속성이 포함되어 있는지, 그리고 해당 Subject가 어떤 Property를 가지고 있으며, Property의 값으로 어떤 value값을 취하는 것에 관한 정보를 포함한다. 마지막으로 Proof(s)에는 VC에 대한 진위 여부 검증에 필요한 값이 포함되는데 여기에는 다양한 암호 기법이 사용될 수 있다[12][13].

3.4 VC 구성요소

VC에 포함되는 데이터 항목은 @context, id, type, issuer, issuance Date, credential Subject, proof로 구성되어 있다. 플랫폼의 VC 구성요소는 그림 6과 같다. @context는 통신하는 서로 간의 정확한 통신을 위해 데이터가 어떤 값을 가지는지 정의를 내리는 역할을 한다. 플랫폼에서 사용한 @context 항목은 하나로, 해당 URL은 VC의 공식 콘텍스트가 명시된 위치를 가리킨다. W3C 표준에 따르면 VC 데이터를 원활하게 교환하기 위해서는 VC 공식 콘텍스트를 VC 내에 들어가야 한다. type 항목은 어떤 데이터가 사용될 것인지 명시하는 항목이다. 속성 중 Verifiable Credential의 역할은 VC는 공식 콘텍스트 내 정의된 VC 데이터 기본 구조에 따라 VC를 생성할 것이라는 의미이고, Project Contract Credential은 자체 제작한 콘텍스트 내 정의된 데이터 구조에 따라 프로젝트 및 체결에 필요한 데이터를 생성할 것이라는 의미이다. proof에는 공식 콘텍스트 내 정의된 RsaSignature2018 암호화 방식에 따라 검증 데이터를 생성할 것이라고 명시된다. id 항목은 VC 내 다양한 종류의 식별자가 들어갈 수 있다.

Fig. 6.

Examples of contracts and project VC structure

그림에서 볼 수 있는 VC 구조에서는 두 종류의 id가 사용되고 있다. 첫 번째로 나오는 id는 VC를 식별하기 위한 일련번호이다.VC에는 VC를 식별하기 위한 id가 존재한다. id에는 다양한 종류의 URI가 사용될 수 있는데, 첫 번째 명시된 id는 HTTP 기반의 URL이 사용되었고, 두 번째 명시된 id는 DID 기반의 URI가 사용되었다. 다음으로 issuer는 VC를 발행한 사람 혹은 기관을 뜻한다[12][13].

아래와 같이 DID 기반의 URI 형식으로 나타낼 수 있고, 다른 URI를 식별자로 사용할 수 있다. credential Subject는 Claim(s) 데이터를 포함하고 있는 항목으로 VC가 가리키는 객체의 실질적인 ID 속성이 포함되어 있다. 마지막으로 proof는 VC의 무결성을 검증할 수 있는 항목이다. proof는 VC를 발급할 때 필수적으로 포함되어야 하는 항목이다. VC의 무결성을 보장하기 위해 VC 정보에 대한 발행인의 서명이 proof 항목에 추가된다. proof에 포함된 verification Method 속성은 발행인의 공개키 등 디지털 서명을 검증할 수 있는 값이 위치하는 URL을 나타내고 jws 속성은 해당 VC 디지털 서명 값을 나타낸다. 예시와 같이, 계약 및 프로젝트 VC 뿐만 아니라 VC를 통해 원하는 정보로 목적에 맞게 VC를 만들 수 있다[13].

3.5 SSI 기반 인증 및 생성 시나리오

DID 사용자가 직접 DID를 생성해야 하는 것은 아니다. DID로 식별되는 사용자 대신 다른 사람이 DID를 생성하고 인증하는 것이 가능하다. 플랫폼에서 사용하는 DID는 당사자가 직접 DID를 생성하는 것이 아닌, 플랫폼에서 사용자의 DID를 생성하고 인증해주는 방식이다.

플랫폼에서 DID 생성은 대신 해두더라도, DID 관리는 사용자가 직접 모바일 전자지갑 애플리케이션이나 브라우저 전자지갑을 통해 관리를 할 수 있다.

그림 7에서 사용자는 플랫폼 서비스에 DID와 DID document를 생성 요청한 후. 플랫폼 서비스에서 DID와 DID document를 생성을 완료하고 DID document는 DID method에 명시된 저장소에 저장한다. 그리고 사용자가 로그인 요청을 하고 DID에 명시된 저장소와 DID 내 Method-specific identifier가 가리키는 위치에 저장된 DID document를 통해 로그인을 가능하다. 그림 8은 기존의 생성된 DID를 통해 웹 플랫폼에 로그인을 하여 플랫폼에 VC 발급을 받는 과정이다. 여기서 VC의 기능은 플랫폼 서비스의 기능을 요청하거나 서비스 제공이 필요할 때만 일회성 통신으로 데이터를 교환하며 사용자 본인이 직접 데이터를 소유하고 관리하는 인증서이다.

Fig. 7.

SSI-based authentication and creation scenarios

Fig. 8.

SSI-based verifiable credentials creation scenarios