블록체인, 아이덴티티, 자주적신원

Blockchain and Identity

아이덴티티 (identity)는 블록체인 업계에서 자주 등장하는 주제다. 주로 ‘인증’이란 용어로 대체되기도 하지만 이는 틀렸다. 피상적으로 이해하는 개념과 현실에서 작동하는 방식이 많이 달라서 아이덴티티를 이해하려면 이를 구성하는 요소들을 알아야 한다. 많은 사람들이 혼동해서 사용하지만, 보통 아이덴티티는 확인, 증명, 인증으로 나뉜다. 확인은 신원정보를 ‘식별’하는 것이고, 증명은 식별된 신원정보와 본인을 매치하는 절차며, 인증은 증명된 신원을 ‘사용’하는 행위다.

예를 들어 은행에 계좌를 개설하고자 한다면, 은행은 내 신분증 요구할 거고, 주민등록번호를 경찰청의 데이터베이스를 통해 올바른지 확인한다. 여기서 중요한 사실은 내가 제출한 주민등록번호가 경찰청 데이터베이스의 번호와 같은지만 조회하지, 그 주민등록번호가 “나의” 주민등록번호인지는 아직 모른다. (주민등록증에 있는 얼굴이 나와 같은지 가늠이 가능함으로 증명 가능한 것이다.) 그래서 은행은 주민등록증 이외 다른 형태의 확인 가능한 증거를 요구한다. 즉 확인이 가능한 정보들을 모아서 ‘증명’해야 인증이 가능해진다.

즉 본인확인/증명은 다수의 확인 가능한 증거들을 모아 본인의 신원을 증명할 수 있는 ‘가능성’을 높이는 절차다. 여기서 가능성이라고 표현한 이유는 인증의 개념이 절대 확정적 (definitive) 일 수 없기 때문이다. 신원이란 "내가 나입니다"가 아니라 "나는 다른 이들이 공통적으로 동의하는 나입니다"이다. "내가 나입니다"는 신원을 주장하는 자 (=나)를 의존해야 하기 때문에 신원증명이 될 수 없다. 

다시 말해 현실에서 나 스스로를 증명하려면, 내가 나임을 확인해주는 이들 (경찰청, 외교부, 세무서, 통신사 등)이 필요하다. 이러한 인증의 자연적 법칙에 대해 금융 암호학자인 이안 그릭 (Ian Grigg)은 엣지 프로토콜 (edge protocol)이라 표현했다. 네트워크 그래프 이론에서 노드와 엣지의 관계를 인증에 대입해볼 때 신원(=노드)은 엣지(노드 간 연결)의 수를 높임으로써 인증의 정확도를 높일 수 있기 때문이다.

엣지 프로토콜로서의 신원증명

오프라인에서의 이러한 절차가 그나마 수월하지만, 디지털 세상이 도래하면서 더더욱 복잡해졌다. 먼저 많은 나라에서 본인확인을 위한 식별정보를 제공해주는 주체들이 연결되어있지 않다. 이는 API를 통해 충분히 개선 가능하고, 우리나라는 대부분 제공한다. 경찰청은 은행이나 지자체를 위해 주민등록번호를 확인할 수 있는 시스템을 제공하고, 외교부는 여권, 통신사는 휴대번호 확인을 위해 정보를 제공한다. 

문제는 신원증명이다. 오프라인 환경에선 ‘얼굴’이란 가장 명확한 물리적 정보가 있으니 쉽지만, 디지털 환경에선 전자기기가 나를 대신 표현해야 한다. 물리적인 ‘나’의 모습을 사람 대 사람으로 증명할 수 없기 때문에 디지털 환경에서 신원증명을 위해선 최대한 많은 식별정보를 모아 증명의 가능성을 높여야 한다.

그래서 인증이 어렵다. 신원증명을 위해선 여러 식별정보를 제공받아야 하는데, 그러면 사용자 경험이 떨어진다. 사용자 경험을 위해 식별정보를 덜 받으면, 신원확인의 정확도가 떨어지고 신원위조/사기가 가능해진다. 금융과 같은 보수적인 산업에선 인증이 더 명확해야 하고, 비대면으로 진출은 하였지만 신분증사본, 영상통화, 카드 전달 시 확인, 기존 계좌 활용 등 다양한 식별 방식 중 최소 몇 개를 이용해야 하는 경험을 제공한다.  

온라인 아이덴티티

신원증명이 중요한 금융과 달리 온라인 환경에서는 인증은 실명의 인증(Identification)보다 온라인 신원의 인증(authentication)이 더 주목받는다. 신원을 확인/증명한다기보다 온라인 신원이 고유성 (authenticity)을 가지는가를 인증하는 것이다. 페이스북이나 구글이 이 영역을 점령했다. 이미 수억 명의 사용자를 가진 기업들이기 때문에, 거대한 네트워크 효과를 등에 업고 사용자들의 온라인 신원 고유성 인증을 수월하게 해 준다. 

문제는 온라인 신원 (가명)과 본인신원의 경계가 허물어지면서 생긴다. 이메일 수준의 정보만으로 사용자를 받고, 가명의 온라인 신원만 가지고 있던 기업들은 대부분 광고로 수익을 얻기 때문에 사용자들의 디테일한 정보들을 모으기 시작했다. 이들은 편의성과 보안을 명분으로 휴대전화를 요구하고, 쇼핑 서비스를 위해 주소를, 친구들에게 위치 공유를 한다는 명목으로 휴대폰의 위치 등 더 많은 정보를 수집한다. 은행이 식별정보를 모아 신원증명의 가능성을 높이듯 우리가 인지하지도 못하는 창의적인 방법으로 정보를 모은다. 기업들은 사용자들이 그렇게 쌓인 개인정보들이 광고주들에게 팔린다는 것을 알지 못하도록 사용자의 자발성을 유도한다. 

개인의 정보가 극소수의 글로벌 기업에게 제공되면서 프라이버시 침해는 물론, 개인정보의 보관 리스크가 기하급수적으로 커진다. 중앙집중적 환경과 분산환경의 차이는 공격의 대상이 한 곳 (one place)인가 한 대상 (one individual)인가다. 보안의 거시적 관점에서 당연히 후자가 안전하다. 페이스북에 사용자 정보가 모인 데이터베이스가 해킹하면, 수억 명의 사용자 정보를 얻을 수 있기 때문에 공격의 대상 (=페이스북)이 아주 명확하지만, 비트코인과 같은 사용자 개인이 보안 (=키 관리)을 책임져야 하는 환경에선 공격의 대상이 개인이 돼버린다. 

자주적 인증

중앙집중적 인증이 가져온 프라이버시와 보안 문제로 등장한 게 자주적 인증 (Self-sovereign Identity)이다. 특정 주체가 사용자의 정보를 수집하고 허가(authorize)하는 방식이 아니라 사용자가 본인의 정보를 필요로 하는 대상에게 제공하는 방식이다. 개인키를 이용해 자신의 자산을 자주적으로 보관/사용하는 비트코인과 자주적 인증이 유사하다고 생각한 사람들은 블록체인을 활용하는 방안을 구상하기 시작했고, 다양한 자주적 인증 기업과 프로젝트들이 생겨났다.

결국 온라인 아이덴티티는 내 정보가 어디에 저장되느냐의 문제다. 일반적인 온라인 환경에선, 사용자가 인증절차를 거치는 사이트마다 매번 정보를 제공해야 하고, 각 사이트는 고유의 인증정보를 보관한다. 즉 "나"라는 존재는 디지털상에서 여러 개가 동시에 존재하게 된다. 따라서 정보가 공유되려면 사이트 간 API를 통해 소통해야 한다. 

구글이나 페이스북은 내 정보를 대신 보관하고, 정보에 대한 권한과 정보제공의 편의성을 돕는다. 즉 사기업의 데이터베이스에 내 정보가 저장되는 것이다. "나"의 존재는 동일시될 수 있지만, 사기업이 나를 대신하는 방법이기 때문에 위에서 언급한 프라이버시 문제가 존재한다. 

자주적 인증은 아직까지 이렇다 할 결과가 없고, 개발사마다 인증정보를 저장하는 접근방식이 다르다. 주로 휴대폰 단말기의 시큐어 엔클레이브 (secure enclave)에 저장하거나, 인증정보는 IPFS에, 인증정보의 해시값은 블록체인에 넣는 방식을 사용하기도 한다. 때론 프라이빗 블록체인에 기록하기도 하는데, 이는 결국 중앙 주체가 서버만 분산시키고 불필요한 합의구조만 넣은 잘못된 방법이다. 데이터베이스의 중립성이 없으면, 결국 구글 모델과 다를 바 없어진다. 

휴대폰 단말기 속 시큐어 엔클레이브에 저장하는 방식의 문제는 삼성과 애플의 정책이 다르고, 삼성 스마트폰의 경우 (더 확인이 필요하지만) 엔클레이브에 저장되는 정보가 삼성 서버를 들렸다가기 때문에 GDPR이나 프라이버시 문제가 존재하게 된다. 그래서 삼성은 데이터를 지우는 정책을 세워놓은 듯 보인다.

또한 단말기에 인증정보가 저장된다는 말은 그 정보를 제공해주는 주체가 단말기와 직접 통신해야 한다는 것이고, 이를 구현하기는 쉽지 않다. 또한 기존 방식처럼 정보제공자가 가진 데이터베이스를 조회하는 수준이 아니라 정보제공자가 직접 증명(=서명)까지 해주어야 하는 문제가 존재한다. 

정보제공자가 직접 증명(=서명) 해주어야 하는 이유는 개인정보와 같은 기밀성이 중요한 데이터를 공유할 때 의존과 책임의 문제가 따르기 때문이다. 만약 정보제공자가 직접 증명하지 않고, 기존의 방식처럼 조회만 가능하게 하면서 자주적 인증 형태의 방식을 채택하게 되면, 정보를 제출받는 곳 (예. 은행)은 정보 소스를 의존할 수밖에 없다.

예를 들어 A은행이 고객의 정보를 받아 계좌를 만드려고 할 때 블록체인을 이용하여 다른 은행들과 그 정보를 공유하게 되면, 은행 B와 C는 은행 A가 인증한 사용자의 정보를 그대로 의존하여 믿을 수밖에 없다. 만약 믿지 못한다면 다시 인증절차를 거쳐야 하기 때문에 자주적 인증이 필요 없어진다. 즉 정보의 첫 제안자 (initiator)를 믿지 못하는 문제가 발생한다.

만약 첫 번째 제안자 (=은행 A)를 의존하기로 정책을 정하면, 책임소재의 문제가 또 발생한다. 만약 제안자의 정보가 올바르지 않거나 (예. 신원 사기, 대포통장 등) 실수가 있었다면 (예. 오타) 누가 책임을 질 것인가? 정보를 제대로 검증/입력하지 못한 은행 A가 잘못인가, 아님 그 은행을 의존하여 데이터를 가져다 쓴 은행 B와 C의 책임인가? 이러한 의존/책임 문제는 (정보제공자가 직접 검증하지 않은 형태의) 자주적 인증의 적용을 어렵게 만든다. 

의료의 영역에서도 책임과 의존의 문제는 존재한다. 몇몇 블록체인 스타트업들이 의료업계의 비효율성을 고쳐보겠다고 등장했지만, 이 문제를 전혀 인지하지 못한 듯 보인다. 병원은 아주 기본적인 정보를 제외하고 환자 대부분의 의료정보를 다른 병원과 공유할 수 없다. 생명을 다루는 병원들은 서로 의존 할 수 없고, 문제가 생겼을 경우의 책임소재가 불분명하기 때문이다. 

적용의 어려움 (=현실성의 부재)
결국 문제는 적용이다. API 형태의 정보공유는 정보제공자에게 어떠한 이해관계도 강제하지 않기 때문에 부담이 없다. 구글이나 페이스북의 인증방식은 구글과 페이스북의 어마어마한 네트워크 효과를 그대로 얻을 수 있기 때문에 인센티브가 존재한다. 자주적 인증의 가장 큰 문제는 정보제공자들이 적용을 해서 얻을 게 없다. 오히려 일이 많아질 뿐이다.