KR102220599B1 - 통합 인증을 위한 블록체인 시스템 및 그것의 제어 방법 - Google Patents

Abstract

본 발명은 블록체인 기술에 기초하여 통합인증을 수행하기 위한 시스템에 있어서, 복수 개의 통합인증 기관으로부터 발생하는 인증 절차를 통합하는 통합 인증 서버, 상기 통합된 인증 절차에 대한 메인 트랜잭션을 수신하는 적어도 두 개의 메인 노드(Node), 및 상기 적어도 두 개의 메인 노드는 메인 블록체인의 노드로 참여하고, 통합인증 절차에 대한 서브 트랜잭션을 수신하는 적어도 두 개의 서브 노드를 포함하되, 상기 적어도 두 개의 서브 노드는 트랜잭션이 기설정된 일부 주체에게만 한정적으로 공개되는 서브 블록체인의 노드로 참여하는 것을 특징으로 하는, 통합인증 시스템에 관한 것이다.

Description

통합 인증을 위한 블록체인 시스템 및 그것의 제어 방법{BLOCKCHAIN SYSTEM FOR COMBINED AUTHENTICATION AND CONTROL METHOD THEREOF}

본 발명은 증명 시스템에 관한 것으로, 보다 구체적으로는 사용자 인증이나 문서 제 증명에 관한 동작들을 블록체인의 트랜잭션으로 기록하고 열람하여 신뢰성을 향상시킬 수 있는 인증 시스템에 관한 것이다.

블록체인 기술이란, 네트워크에 참여하는 모든 사용자가 관리 대상이 되는 모든 데이터를 분산하여 저장하는 데이터 분산처리기술을 말한다. 거래 정보가 담긴 원장(原帳)을 거래 주체나 특정 기관에서 보유하는 것이 아니라 네트워크 참여자 모두가 나누어 가지는 기술이라는 점에서 '분산원장기술(DLC；distributed ledger technology)' 또는 '공공거래장부'라고도 한다. 블록체인은 거래 내용이 담긴 블록(Block)을 사슬처럼 연결(chain)한 것이라 하여 붙여진 명칭이다.

이러한 블록체인은 퍼블릭 블록체인(Public blockchain)과 프라이빗 블록체인(Private blockchain)으로 구분될 수 있다. 퍼블릭 블록체인은 앞에서 설명한 공공거래장부에 해당하며, 통상 블록체인이라 하면 퍼블릭 블록체인을 지칭한다. 프라이빗 블록체인은 이와 상대적 개념으로, 주로 기업에서 활용한다 하여 엔터프라이즈 블록체인(Enterprise blockchain)이라고도 한다. 여러 기업(또는 기관)이 공동으로 참여하는 컨소시엄 블록체인(Consortium blockchain)도 넓은 의미에서 프라이빗 블록체인의 범주에 속한다.

누구에게나 개방되고 누구나 트랜잭션을 생성할 수 있는 퍼블릭 블록체인과 달리, 프라이빗 블록체인은 서비스 제공자(기업 또는 기관)의 승인을 받아야만 참여할 수 있고 법적 책임을 지는 기관만 트랜잭션을 생성할 수 있다. 또한 트랜잭션 내역이 모두에게 공개되어 네트워크에 참여한 모든 노드(Node)가 이를 검증하고 거래를 승인하는 퍼블릭 블록체인과는 달리, 프라이빗 블록체인에서는 승인된 기관만 트랜잭션을 검증하고 거래를 승인한다.

퍼블릭 블록체인은 누구나 참여할 수 있고 모든 참여자의 상호 검증을 거쳐 신뢰도가 높지만, 모든 참여자의 거래 기록을 남기고 이를 공유하느라 처리 속도가 느리다는 단점이 있다. 이에 비하여 프라이빗 블록체인은 승인 받은 노드만 참여하고, 다른 노드의 검증을 구할 필요가 없기 때문에 처리 속도가 훨씬 빠르다. 하지만 프라이빗 블록체인의 사용자는 서비스 제공자에게 전적으로 의존하여야 하기 때문에 퍼블릭 블록체인에 비하여 신뢰성에 한계가 있다.

이러한 블록체인은 다양한 산업분야에 활용될 수 있으며, 특히 위변조에 대한 신뢰성이 확보되어야 하는 분야에 가장 적합할 것이다. 사용자에 대한 인증이나 문서의 제 증명 등의 증명 업무는, 위조나 변조의 위험에 지속적으로 노출될 수 밖에 없는 업무로서, 신뢰성 확보가 다른 산업 분야의 업무들 보다 시급할 것이다. 그럼에도 불구하고, 블록체인 기술을 활용하여 이러한 증명 시스템에 대한 연구가 제대로 이루어지지 못하고 있는 실정이다.

본 발명은 전술한 문제 및 다른 문제를 해결하는 것을 목적으로 한다. 또 다른 목적은 사용자의 인증이나 문서의 제 증명에 대한 신뢰도를 향상시킬 수 있는 증명 시스템을 제공하는 것을 그 목적으로 한다.

또 다른 목적은 증명의 대상이 되는 문서의 발급, 유통 및 파기까지의 전 과정에 대한 증명을 수행하고, 누구든지 해당 과정을 확인할 수 있는 증명 시스템을 제공하는 것을 그 목적으로 한다.

본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

상기 또는 다른 목적을 달성하기 위해 본 발명의 일 측면에 따르면, 블록체인 기술에 기초하여 통합인증을 수행하기 위한 시스템에 있어서, 복수 개의 통합인증 기관으로부터 발생하는 인증 절차를 통합하는 통합 인증 서버; 상기 통합된 인증 절차에 대한 메인 트랜잭션을 수신하는 적어도 두 개의 메인 노드(Node); 및 상기 적어도 두 개의 메인 노드는 메인 블록체인의 노드로 참여하고, 통합인증 절차에 대한 서브 트랜잭션을 수신하는 적어도 두 개의 서브 노드를 포함하되, 상기 적어도 두 개의 서브 노드는 트랜잭션이 기설정된 일부 주체에게만 한정적으로 공개되는 서브 블록체인의 노드로 참여하는 것을 특징으로 하는, 통합인증 시스템을 제공한다.

본 발명에 따른 인증 시스템의 효과에 대해 설명하면 다음과 같다.

본 발명의 실시 예들 중 적어도 하나에 의하면, 블록체인 기술에 기초하여 사용자 인증의 신뢰성을 향상시킬 수 있다는 장점이 있다.

또한, 본 발명의 실시 예들 중 적어도 하나에 의하면, 인증 요청 기관으로부터의 인증 절차를 블록체인 트랜잭션으로 기록하는데 있어서, 인증 요청 기관의 수가 방대해 지더라도 병목 현상 없이 효과적이고 문제 없이 기록할 수 있다는 장점이 있다.

본 발명의 적용 가능성의 추가적인 범위는 이하의 상세한 설명으로부터 명백해질 것이다. 그러나 본 발명의 사상 및 범위 내에서 다양한 변경 및 수정은 당업자에게 명확하게 이해될 수 있으므로, 상세한 설명 및 본 발명의 바람직한 실시 예와 같은 특정 실시 예는 단지 예시로 주어진 것으로 이해되어야 한다.

도 1은 본 발명의 일실시예에 따른 블록체인의 구조를 도시하는 도면이다.
도 2는 본 발명의 일실시예에 따른 메인 블록체인과 서브 블록체인의 확장 관계를 설명하는 도면이다.
도 3은 본 발명의 일실시예에 따른 문서의 제 증명 절차를 도시하는 도면이다.
도 4는 본 발명의 일실시예에 따라, 증명 기관들 간의 증명서 요청 과정을 도시하는 도면이다.
도 5는 본 발명의 일실시예에 따른 사용자 인증 절차를 도시하는 도면이다.

이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시 예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시 예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시 예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시 예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.

본 출원에서, "포함한다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

블록체인 기술은, 현재 금융 시스템에서 활발하게 사용되고 있다. 이하에서, 금융 시스템에서 적용되고 있는 방식에 대하여 설명한다.

블록체인은 금융기관 등에서 모든 거래를 담보하고 관리하는 기존의 금융 시스템에서 벗어나 P2P(Peer to Peer；개인 대 개인) 거래를 지향하는, 탈(脫)중앙화를 핵심 개념으로 한다. P2P란 서버나 클라이언트 없이 개인 컴퓨터 사이를 연결하는 통신망을 말하며, 연결된 각각의 컴퓨터가 서버이자 클라이언트 역할을 하며 정보를 공유하는 방식이다.

기존 금융 시스템에서는 금융회사들이 중앙 서버에 거래 기록을 보관해 온 반면, P2P 방식을 기반으로 하는 블록체인에서는 거래 정보를 블록에 담아 차례대로 연결하고 이를 모든 참여자가 공유한다.

금융 시스템에서 거래 과정(트랜잭션, transaction)에 대한 블록체인 기술의 처리는, 다음과 같이 이루어진다. ① A가 B에게 송금 희망 등의 거래 요청을 한다. ② 해당 거래 정보가 담긴 블록이 생성된다. ③ 블록이 네트워크상의 모든 참여자에게 전송되면, 참여자들은 거래 정보의 유효성을 상호 검증한다. ④ 참여자 과반수의 데이터와 일치하는 거래 내역은 정상 장부로 확인하는 방식으로 검증이 완료된 블록은 이전 블록에 연결되고, 그 사본이 만들어져 각 사용자의 컴퓨터에 분산 저장된다. ⑤ A가 B에게 송금하여 거래가 완료된다. 이때 기설정된 주기 내에(예를 들면 약 10분) 발생된 모든 트랜잭션을 하나의 블록으로 생성할 수 있다.

이와 같은 과정에 의해서, 참여자 과반수의 데이터와 일치하는지 여부를 확인함으로서 블록의 생성 시에도 그 신뢰성을 확보할 수 있을 뿐만 아니라, 완성된 블록들의 사본을 각 컴퓨터(노드)에 개별적으로 저장하여 위변조를 실질적으로 불가능하게 한다.

본 발명에서의 증명 시스템은, 위와 같이 금융 시스템에서 활용하는 거래의 증명 대신, 사용자의 인증 및/또는 전자 문서의 제 증명에 관한 다양한 동작(이하, 블록체인에 기록되는 모든 동작을 트랜잭션이라 호칭한다)에 적용하고자 하는 것이다.

이하, 블록체인 관련 용어에 대하여 설명한다.

· 블록(block)

블록은 데이터를 저장하는 단위로, 바디(body)와 헤더(header)로 구분된다. 바디에는 거래 내용이, 헤더에는 머클해시(머클루트)나 넌스(nounce, 암호화와 관련되는 임의의 수) 등의 암호코드가 담겨 있다. 블록은 약 10분을 주기로 생성되며, 거래 기록을 끌어 모아 블록을 만들어 신뢰성을 검증하면서 이전 블록에 연결하여 블록체인 형태가 된다. 여기서 처음 시작된 블록을 제네시스 블록이라고 부른다. 즉, 제네시스 블록은 그 앞에 어떤 블록도 생성되지 않은 최초의 블록을 말한다.

· 노드(node)

블록체인은 중앙 집중형 서버에 거래 기록을 보관, 관리하지 않고 거래에 참여하는 개개인의 서버들이 모여 네트워크를 유지 및 관리한다. 이 개개인의 서버, 즉 참여자를 노드라고 한다. 중앙 관리자가 없기 때문에 블록을 배포하는 노드의 역할이 중요하며, 참여하는 노드들 가운데 절반 이상의 동의가 있어야 새 블록이 생성된다. 노드들은 블록체인을 컴퓨터에 저장해 놓고 있는데, 일부 노드가 해킹을 당해 기존 내용이 틀어져도 다수의 노드에게 데이터가 남아 있어 계속적으로 데이터를 보존할 수 있다.

· 해시함수

어떤 데이터를 입력해도 같은 길이의 결과를 도출하는 함수이다. 도출되는 결과가 중복될 가능성이 낮고, 결과 값으로 입력 값을 역으로 추정하기 어렵다. 이 때문에 해시 값을 비교하면 데이터의 변경이 발생했는지 파악할 수 있다. 해시함수는 SHA(Secure Hash Algorithm)-1이 처음 고안된 후 더 발전된 형태의 SHA-2(SHA 256)가 나왔는데, 이것을 블록체인에서 사용하고 있다. SHA-2는 어떤 길이의 값을 입력해도 결과가 256비트로 도출된다.

도 1은 본 발명의 일실시예에 따른 블록체인의 구조를 도시하는 도면이다. 도 2는 본 발명의 일실시예에 따른 메인 블록체인과 서브 블록체인의 확장 관계를 설명하는 도면이다.

본 발명의 일실시예에 따른 증명 시스템은, 적어도 두 개의 메인 노드(111-1 ~ 111-3)가 참여하는 메인 블록체인(110) 및 적어도 두 개의 서브 노드(121-1 ~ 121-4)가 참여하는 서브 블록체인(120)을 포함할 수 있다.

메인 블록체인(110)은 상기 메인 트랜잭션에 기초하여 기설정된 주기로 메인 블록을 형성하고, 상기 서브 블록체인(120)은 상기 서브 트랜잭션에 기초하여 기설정된 주기로 서브 블록을 형성할 수 있을 것이다. 즉, 메인 블록체인(110)과 서브 블록체인(120)간에 생성되는 블록 간에는 서로 연결되거나 검증 절차가 이루어지지 않는다.

다만, 메인 블록체인(110)과 서브 블록체인(120)은 선택적으로 연결될 수 있으며, 선택적으로 연결 시에는 검증 절차가 요구될 수 있다.

예를 들어, 이하에서 상세히 후술하겠지만, 메인 블록체인(110)에서 증명서 생성 트랜잭션 발생 시, 서브 블록체인에 해당 트랜잭션에 대한 정보가 공유될 수 있다. 이와 같이 공유 받은 증명서 생성 트랜잭션에 기초하여, 서브 블록체인(120)은 트랜잭션에 대한 검증 쿼리를 수행할 수 있다.

이와 같이 블록 간에 관계는 차단되어 있는 대신, 메인 블록체인(110)과 서브 블록체인(120)은, 연결 노드에 의해서 데이터가 송수신될 수 있다. 메인 블록체인(110)에 참여하는 메인 노드(111-1 ~ 111-3) 중에서 적어도 하나는 메인 연결 노드(111-3)이고, 서브 블록체인(120)에 참여하는 서브 노드(121-1 ~ 121-4) 중에서 적어도 하나는 서브 연결 노드(121-1)이며, 메인 및 서브 연결 노드(111-3, 121-1)는, 상기 메인 및 서브 블록 체인을 서로 연결하기 위하여 구비된다.

이때 서로 연결된다는 것은, 데이터를 주고 받는 것을 의미할 수 있다.

본 발명의 일실시예에서는, 특정 조건 하에서만 상기 연결 노드들 간에 데이터를 주고 받도록 제안한다. 왜냐하면, 메인 블록체인은 프라이빗 블록체인으로서, 메인 블록체인에 저장되어 있는 정보는 외부에 공개되어서는 안되기 때문이다.

예를 들어서, 서브 블록체인(120)으로부터 기설정된 쿼리(Query)만을 수신하거나, 상기 기설정된 쿼리에 대한 회신을 하는 경우의 데이터 송수신만을 상기 연결 노드를 통하여 수행할 수 있을 것이다. 기설정된 쿼리 및 이에 대한 회신에 대해서는 이하에서 상세하게 후술하기로 한다.

본 발명의 일실시예에 따르면, 메인 블록체인(110)은 프라이빗 블록체인일 수 있다. 즉, 메인 블록체인(110)의 노드인 메인 노드(111-1 ~ 111-3)는 누구에게나 공개되지 않으며, 승인되거나 지정된 기관만이 참여할 수 있다.

반면, 서브 블록체인(120)은, 프라이빗 블록체인일 수도 있고, 퍼블릭 블록체인일 수도 있다. 완전하게 차단되지는 않지만, 확인되거나 인증된 주체(기설정된 일부 주체)만이 한정적으로 참여할 수 있는, 넓은 의미의 프라이빗 블록체인일 수도 있다. 이에 따라, 서브 블록체인(120)의 노드인 서브 노드(121-1 ~ 121-4)는 추가 서브 노드(122-1, 122-2, ...)가 참여할 수 있을 것이다.

이와 같이, 메인 블록체인(110)과 서브 블록체인(120)이 분리되는 이유는, 증명 시스템에 대한 보안이 요구되기 때문이다. 블록체인 기술에 의하면 모든 트랜잭션이 공중(public)에게 공개되는데, 사용자 인증이나 문서의 제 증명 내용 자체는 공중(public)에 공개되어서는 안되기 때문이다. 예를 들어, 졸업 증명 문서는 요청인(예를 들어 기업의 지원자)이 요청한 수령 기관(예를 들어 지원자에 대한 증명서를 수령하고자 하는 기업 등)에게만 공개되어야 되고, 그 수령 기관을 제외한 다른 기업, 금융기관이나 타인 등의 제3자에게는 공개되어서는 안되는 정보이기 때문이다.

메인 블록체인(110)과 서브 블록체인(120)이 분리되는 또 다른 이유는, 수령 기관의 확장성을 확보하기 위함이다. 메인 블록체인(110)의 경우에는 내용이 공개되어서는 안되는 프라이빗 블록체인이기 때문에, 그 확장성 측면에서 제한적일 수 밖에 없다.

블록체인의 노드로 참여하고자 하는 기업이 추가적으로 발생한다면, 본 발명의 일실시예에 따른 시스템에서는, 서브 블록체인의 노드에 참여할 수 있도록 구비된다.

사용자 인증에 대한 요청이나, 문서의 제 증명을 요청하는 복수 개의 기관(이하 수령 기관이라 함)은 상기 서브 노드(121-1 ~ 121-4)에 대응될 수 있다. 즉 수령 기관은 하나의 서브 노드에 매칭되어 연결되며, 하나의 서브 노드에는 하나의 수령 기관이 연결되어 있을 수 있다.

이에 반하여, 메인 블록체인(110)에는 증명 기관이 복수 개의 메인 노드(111-1 ~ 111-3) 중 적어도 하나의 노드에 연결되어 있을 수 있다. 즉, 하나의 통합 증명 기관이 복수 개의 노드를 사용할 수 있다는 것이다.

더 나아가, 서브 블록체인(120)은 블록체인 자체 개수의 확장이 가능하다. 도 2에 도시된 바와 같이, 하나의 메인 블록체인(110)에 복수 개의 서브 블록체인(120-1, 120-2, 120-3, ...)이 연결되어 동작할 수 있다. 이때, 메인 블록체인(110)의 메인 연결 노드(111-3)는, 복수 개의 서브 연결 노드(도 2에서의 121-1, 130-1, 130-2)들과 '1 to many' 관계로 각각 연결될 수 있을 것이다.

이하에서는, 본 발명의 이러한 구조에 기초하여 문서의 제 증명 및 사용자 인증을 수행하는 구체적인 방법에 대해서 설명한다.

도 3은 본 발명의 일실시예에 따른 문서의 제 증명 절차를 도시하는 도면이다.

증명서 요청 서버(391)란, 요청인(390)에 관한 문서의 진위 여부를 확인하고자 하는 수령 기관(또는 개인)에서 관리하는 서버를 의미할 수 있으며, 예를 들면, 증명서 요청 서버(391)는 기업에서 운영하는 서버이고, 요청인(390)은 해당 기업에 취업하고자 지원하는 지원자일 수 있으며, 해당 기업에서 증명서 요청 서버(391)를 통하여 요청인(390)의 학적사항을 확인하고자 졸업 증명 문서에 대한 진위 여부를 확인하고자 하는 상황을 가정할 수 있다.

증명 기관(393)은, 해당하는 증명을 수행하는 주체를 의미하며, 위 예시에서 요청인(390)이 졸업한 대학교 학사증명 또는 학적증명 시스템이 될 수 있을 것이다. 본 발명에서 사용하는 증명 기관(393)이라는 용어는, 개념을 이해하기 쉽도록 사용하는 용어일 뿐, 증명 기관(393)에서 운영하는 장치, 시스템이나 서버로 해석할 수 있음은 자명할 것이다.

증명서 발급 서버(392)란, 복수 개의 증명 기관(393)의 증명 관련 절차를 일괄적으로 관리하기 위한 기관으로, 증명 기관(393)에 의해서 증명된 사항을 암호화한 문서로 발급하는 주체를 의미한다. 예를 들어, 수많은 대학교 각각이 증명 기관(393)이라 한다면, 증명서 발급 서버(392)는 수많은 대학교에서 확인/증명된 내용을 통합하고 이를 암호화하여 증명서로 발급해 주는 역할을 수행할 수 있다.

다만, 본 발명은 증명서 발급 서버(392)가 직접 증명서 생성하는 것에 한정되지 않으며, 복수 개의 증명 기관(393)에서 증명서가 발급 되고 그 발급된 증명서의 취합 및 관리를 수행하는 경우도 본 발명에 포함될 것이다.

또한, 이러한 증명서 발급 서버(392)는 증명 기관(393)과 별도로 구비될 수도 있지만 증명 기관(393)과 구분되지 않고 하나의 기관으로 구비될 수도 있을 것이다.

본 발명을 실시하기 위한 구체적인 내용에서 사용하는 서버라는 용어는 온오프라인으로 데이터를 송수신할 수 있는 장치를 모두 포함하는 용어로서, 서버라는 용어 자체에 본 발명의 내용이 한정되지는 않는다.

또한, 본 발명을 실시하기 위한 구체적인 내용에서 증명서라는 용어는, 전자적으로 발급, 유통 및 저장될 수 있는 전자문서를 모두 포괄하는 용어이다.

기존의 증명 시스템에 의하면, 요청인(390)이 직접 증명 기관(393)이나 증명서 발급 서버(392)에 졸업 증명 문서를 요청하여 졸업 증명 문서를 프린터로 출력 및 수령 기관에 출력된 졸업 증명 문서를 제출하는 방식으로 확인하였다.

이와 같은 기존 증명 시스템에 의하면, 요청인이 문서를 출력하고 수령 기관에 제출하는 과정에서 위변조 위험성이 항상 존재하였다.

하지만, 본 발명의 일실시예에서는, 요청인(390)의 요청에 기초하여, 블록체인 기술을 활용하여 증명서를 확인하고자 하는 기관(예를 들면, 요청자의 학적사항을 확인하고자 하는 기업 등)에서 직접 증명서 발급에 관한 요청을 수행하고 전달하는 방식을 제안한다.

S301 단계에서 요청인(390)은 자신이 증명하고자 하는 문서(증명서)를 생성해 줄 것을 증명서 요청 서버(391)에 요청한다. S302 단계에서 증명서 요청 서버(391)는, 증명서 발급 서버(392)에 요청을 전달한다. S303 단계에서 증명서 발급 서버(392)는, 생성될 증명서 파일명을 지정하고, 지정된 파일명을 증명서 요청 서버(391)에 회신해 준다.

S304 단계에서 증명서 발급 서버(392)는 증명기관(393)에게 증명서 생성에 대한 요청을 전달한다. 증명기관(393)은 전달 받은 요청에 기초하여, 증명서를 생성할 수 있다. 이어서 증명서 발급 서버(392)는 증명서 생성에 대한 트랜잭션을 메인 블록체인(110)의 노드에 전달(S305)한다. 이렇게 전달된 트랜잭션은, 상술한 바와 같이 메인 블록에 저장될 수 있으며, 더 나아가 서브 블록체인(120)에 선택적으로 전달되어 서브 블록에 저장될 수도 있을 것이다.

더 나아가, 본 발명의 일실시예에 따른 상기 트랜잭션은, 서브 체인에 전달되어 서브 블록으로 저장되도록 제안한다. 왜냐하면, 후술하는 S307 단계에서 검증을 수행하기 위함이다. 이때, 상기 트랜잭션은, 메인 연결 노드(111-3)와 서브 연결 노드(121-1)간에 연결을 통하여 전달될 수 있을 것이다. 즉, 상기 증명서 생성에 대한 트랜잭션은, 메인 연결 노드(111-3) 및 서브 연결 노드(121-1)를 순차적으로 통하여 서브 블록체인의 서브 블록에 기록될 수 있다.

S306 단계에서 증명서 요청 서버(391)는, 증명서 발급 서버(392)에 지속적으로 생성 컨트랙트를 확인한다. 즉, S303 단계에서 회신 받은 파일명에 기초하여, 해당 파일명을 가지는 증명서가 생성되었는지 지속적으로 체크하는 것이다. 만약, 증명서 생성이 확인되었다면, 서브 블록체인(120)을 통하여 해당 증명서가 생성되었는지 검증 쿼리를 전달(S307)한다. 즉, 올바르게 생성된 증명서인지 확인하는 것이다.

이때 확인하는 과정(S307)은, 상기 서브 블록에 저장되어 있는 내용에 기초하여 수행될 수 있다. 즉, 증명서 생성에 대한 트랜잭션이 서브 블록에 저장되어 있는데, 그 서브 블록에 기록되어 있는 트랜잭션을 확인하여 검증을 수행하는 것이다.

해당 쿼리에 대한 응답인 확인 결과는, 상기 증명서 요청 서버(391)에 다시 회신될 수 있다.

그리고, 생성된 증명서는 S308, S309 단계를 통하여 증명 기관(393), 증명서 발급 서버(392) 및 증명서 요청 서버(391)에게 전달되어, 증명서 요청 서버(391)가 수령(다운로드)할 수 있다. 증명서 수령을 완료할 경우 증명서 요청 서버(391)는, S310 단계에서 수령 완료에 대한 트랜잭션을 서브 노드(121-4)에 전송한다. 이렇게 전송된 트랜잭션은, 서브 블록체인(120)의 서브 블록에 저장될 것이다.

이어서 S311단계에서 요청인(390)은, 증명서 요청 서버(391)로부터 증명서를 수신(다운로드) 받는다. 증명서 요청 서버(391)는 증명서의 발급(즉, 요청인에게 전달 완료)에 대한 트랜잭션을 서브 블록체인(120)의 서브 노드(121-4)에 전달(S312 단계)하여 서브 블록에 저장시킬 수 있을 것이다. 또한, 상기 증명서의 전달 완료 뿐만 아니라, 증명서의 복제, 파기나 이전 등의 모든 동작에 대하여 트랜잭션으로 하여 서브 노드(121-4)에 전달할 수 있을 것이다.

도 3에서의 절차에 의하면, 증명서를 수령하는 증명서 요청 서버(391)는 전달 받은 증명서가 올바르게 생성되었는지 높은 신뢰도로 검증할 수 있을 뿐만 아니라, 요청인(390)은 생성된 증명서를 수령 기관이 수령했는지 여부, 제3자에게 전달되었는지 여부나 파기 여부에 대하여 높은 신뢰도로 확인할 수 있다는 장점이 있다.

도 4는 본 발명의 일실시예에 따라, 증명 기관들 간의 증명서 요청 과정을 도시하는 도면이다.

경우에 따라서는 증명 기관들 간에 증명서 발급이 필요한 경우도 존재한다. 예를 들면, A 대학교에 다니고 있는 학생이 B 대학교에 학점 교류를 신청하거나, B 대학교의 대학원에 진학을 하는 경우, B 대학교에서는 A 대학교에 다니고 있는지 여부에 대한 증명서가 필요할 수 있을 것이다. 증명 기관들은 상술한 증명서 발급 서버(392)를 통하여 증명서 발급에 관한 내용을 통합적으로 관리하기 때문에, 도 3의 절차와는 조금 다르게 진행될 수 있다.

도 4에서는 요청인의 요청에 기반하여 제 1 증명 기관(393-1)이 제 2 증명 기관(393-2)에게 증명서를 요청하는 과정을 도시한다. 즉 위의 예시에서, 학점 교류를 신청하고자 하는 학생이 요청인으로서 B 대학교에 요청을 수행하면, B 대학교가 제 1 증명 기관(393-1)이 될 수 있고, 요청인이 현재 재학 중인 A 대학교가 제 2 증명 기관(393-2)가 될 수 있는 것이다.

S401 단계에서 제 1 증명 기관(393-1)은 증명서 발급 서버(392)에 증명서 생성을 요청을 전송한다. 이어서 증명서 발급 서버(392)는, 생성될 증명서 파일명을 지정하고, 지정된 파일명을 제 1 증명 기관(393-1)에게 회신하여 준다. S403 단계에서 증명서 발급 서버(392)는 제 2 증명 기관(393-2)에게 증명서 생성 요청을 전달하고, 제 2 증명 기관(393-2)은 요청 받은 증명서를 생성한다.

증명서가 생성되면, 증명서 발급 서버(392)는 메인 블록체인(110)의 메인 노드에 상기 증명서 생성에 대한 트랜잭션을 전달할 수 있다.

S405 단계에서 제 1 증명 기관(393-1)은, 증명서 발급 서버(392)에 지속적으로 생성 컨트랙트를 확인한다. S402 단계에서 회신 받은 파일명에 기초하여, 해당 파일명을 가지는 증명서가 생성되었는지 지속적으로 체크하는 것이다.

S406 단계에서 제 2 증명 기관(393-2)은 증명서 발급 서버(392)에 생성된 증명서를 전송한다. 증명서 발급 서버(392)는, 증명서를 수신 받으면 증명서 수신에 대한 트랜잭션을 생성하고, 이를 메인 블록체인(110)의 메인 노드에 전달(S407 단계)한다.

이어서, 증명서 발급 서버(392)는 제 1 증명 기관에게 수신 받은 증명서를 전달(S408 단계)한다. 그리고, 증명서 전달이 완료되면, 증명서 전달에 대한 트랜잭션을 생성하여 메인 블록체인(110)의 메인 노드에 전달(S409 단계)한다.

이하에서는, 블록체인 기술을 활용하여 사용자 인증을 수행하는 과정에 대해서 설명한다.

도 5는 본 발명의 일실시예에 따른 사용자 인증 절차를 도시하는 도면이다.

인증 요청 서버(591)란, 요청인(390)에 대한 인증을 수행하고자 하는 서버를 의미할 수 있으며, 예를 들어 요청인(390)이 가입하고자 하는 홈페이지의 서버를 의미할 수 있을 것이다.

인증 기관(393')은, 요청인(390)에 대한 인증을 수행하는 주체를 의미하며, 예를 들어 인증 요청 서버(591)가 요청인(390)에 대한 학적 사항(대학에 재학, 졸업 등) 인증을 인증 기관(393')에 요청할 수 있을 것이다. 이 경우 인증 기관(393')은 요청인(390)이 졸업한 대학교 학사증명 또는 학적증명 시스템이 될 수 있을 것이다. 인증 기관(393')은 도 3 및 4에서 상술한 증명 기관(393)에 속해 있는 기관일 수도 있고, 증명 기관(393)과는 별도의 기관일 수도 있다.

통합 인증 서버(592)란, 복수 개의 인증 기관(393')의 사용자 인증 관련 절차를 일괄적으로 관리하기 위한 주체를 의미한다. 예를 들어, 수많은 대학교 각각이 인증 기관(393')이라 한다면, 통합 인증 서버(592)는 수많은 대학교에서 수행된 인증을 통합하고 이를 암호화하여 사용자 식별 정보로 발급해 주는 역할을 수행할 수 있다.

S501 단계에서 요청인(390)은 인증 요청 서버(591)에 사용자 식별 정보에 대한 생성을 요청할 수 있으며, S502 단계에서 인증 요청 서버(591)은 이 요청을 통합 인증 서버(592)로 전달해 줄 수 있다.

통합 인증 서버(592)는 위 요청에 대한 트랜잭션을 상기 메인 블록체인(110)에 전달(S503 단계)할 수 있다.

사용자 식별 정보 생성 요청을 받은 통합 인증 서버(592)는 인증 기관(393')에 이 요청을 다시 전달하고, 인증 기관(393')은 전달 받은 요청 내용에 기초하여 사용자 인증(S504 단계)을 수행할 수 있다. S504의 사용자 인증 단계에서 인증 기관(393')은 요청자(390)에 대한 데이터 베이스를 검색하여, 인증 작업을 수행해 줄 수 있을 것이다. 예를 들어서, 요청자(390)가 대학교 학생이고, 인증 기관(393')은 해당 대학교 학적 시스템으로, 학적 데이터 베이스 조회를 통하여 요청자(390)에 대한 학적 인증을 수행하고 그 수행 결과를 통합 인증 서버(592)에 전달할 수 있는 것이다.

통합 인증 서버(592)는 인증이 완료된 사용자에 대한 사용자 식별 정보를 생성하고, 사용자 식별 정보의 생성에 대한 트랜잭션을 메인 블록체인의 메인 노드에 전달(S505 단계)할 수 있다. 여기서 사용자 식별 정보란, 요청인(390)에게 할당된 고유의 코드를 의미할 수 있으며, 사용자 ID(Identication information)이나 토큰값(token value) 등을 의미할 수 있다. 이때 사용자 식별 정보를 생성하는 주체는 통합 인증 서버(592)가 될 수도 있지만, 인증 기관(393')에서 사용자 식별 정보를 생성하여 이것을 통합 인증 서버(592)에 전달해 줄 수도 있을 것이다.

한편 본 발명의 일실시예에 따른 시스템은, 상기 S503 단계에서와 같이 요청에 대한 트랜잭션은 제 1 메인 노드(111-1)에, 그리고, 식별 정보 생성에 대한 트랜잭션은 제 2 메인 노드(111-2)에 전달하여 블록화 하도록 제안한다. 식별 정보 생성에 대한 트랜잭션은 결국 S503 요청에 대한 인증 회신(Authentication response)일 수 있다.

블록체인 시스템에서는, 기본적으로 적어도 3 개의 노드가 요구된다. 왜냐하면, 새로 생성된 블록의 검증을 모든 노드에서 함께 수행하게 되는데, 검증 결과 과반수가 넘어야 새로운 블록이 생성될 수 있으며, 2 개의 노드로는 과반수의 결과를 형성할 수 없기 때문이다. 따라서, 도 5에 도시된 메인 블록체인(110) 역시 적어도 세 개의 노드가 필수적이다.

통합 인증 서버(592)는 수많은 인증 기관(393')에 대한 인증 절차를 통합하는 역할을 수행하다 보니, 병목 현상이 발생할 우려가 존재한다. 따라서, 본 발명에서는, 통합 인증 서버(592)에서 발생할 수 있는 트랜잭션의 종류를 구분하여, 어느 한 종류의 트랜잭션은 제 1 메인 노드(111-1)에, 다른 종류의 트랜잭션은 제 2 메인 노드(111-2)에 전달하도록 제안하는 것이다. 즉, 적어도 세 개의 노드가 형성되어야 하는 블록체인의 특성 상, 병목 현상을 완화시키기 위하여 노드 들에 역할을 분담하고자 하는 것이다.

통합 인증 서버(592)는, S506 단계에서 생성된 사용자 식별 정보를 인증 요청 서버(591)에게 전달할 수 있다. 인증 요청 서버(591)는 사용자 식별 정보의 수신에 대한 트랜잭션을 상기 서브 블록체인의 서브 노드에 전달(S507 단계)할 수 있다.

그리고, S508 단계에서는, 요청인(390)에게 사용자 식별 번호를 전달하거나, 사용자 식별 번호가 발급되었다는 사실에 대하여 통지(안내)해 줄 수 있다.

이상으로 본 발명에 따른 증명 시스템 및 그것의 제어 방법의 실시예를 설시하였으나 이는 적어도 하나의 실시예로서 설명되는 것이며, 이에 의하여 본 발명의 기술적 사상과 그 구성 및 작용이 제한되지는 아니하는 것으로, 본 발명의 기술적 사상의 범위가 도면 또는 도면을 참조한 설명에 의해 한정／제한되지는 아니하는 것이다. 또한 본 발명에서 제시된 발명의 개념과 실시예가 본 발명의 동일 목적을 수행하기 위하여 다른 구조로 수정하거나 설계하기 위한 기초로써 본 발명이 속하는 기술분야의 통상의 지식을 가진 자에 의해 사용되어질 수 있을 것인데, 본 발명이 속하는 기술분야의 통상의 지식을 가진 자에 의한 수정 또는 변경된 등가 구조는 특허청구범위에서 기술되는 본 발명의 기술적 범위에 구속되는 것으로서, 특허청구범위에서 기술한 발명의 사상이나 범위를 벗어나지 않는 한도 내에서 다양한 변화, 치환 및 변경이 가능한 것이다.

Claims (6)

1. 블록체인 기술에 기초하여 통합인증을 수행하기 위한 시스템에 있어서,
   복수 개의 통합인증 기관으로부터 발생하는 인증 절차를 통합하는 통합 인증 서버;
   상기 통합 인증 서버에 사용자 식별 정보 생성을 요청하기 위한 인증 요청 서버;
   상기 통합된 인증 절차에 대한 메인 트랜잭션을 수신하는 적어도 두 개의 메인 노드(Node); 및
   상기 적어도 두 개의 메인 노드는 메인 블록체인의 노드로 참여하고,
   통합인증 절차에 대한 서브 트랜잭션을 수신하는 적어도 두 개의 서브 노드;
   상기 메인 블록체인에 참여하는 메인 연결 노드; 및
   서브 블록체인에 참여하는 서브 연결 노드를 포함하되,
   상기 적어도 두 개의 서브 노드는 트랜잭션이 기설정된 일부 주체에게만 한정적으로 공개되는 서브 블록체인의 노드로 참여하고,
   상기 통합 인증 서버는,
   상기 인증 요청 서버로부터 상기 사용자 식별 정보 생성에 대한 요청을 수신하고,
   상기 수신된 요청에 대한 트랜잭션을 상기 적어도 두 개의 메인 노드 중 제 1 메인 노드에 할당하고,
   상기 수신된 요청에 대응되는 인증 기관에서 사용자 인증을 수행하고, 상기 사용자 인증이 완료된 사용자에 대해 사용자 식별 정보를 생성하며,
   상기 사용자 식별 정보의 생성에 관련된 트랜잭션을 상기 적어도 두 개의 메인 노드 중 제 2 메인 노드에 할당하고,
   상기 생성된 사용자 식별 정보를 상기 인증 요청 서버로 회신하며,
   상기 인증 요청 서버는 상기 사용자 식별 정보를 수신하면, 수신에 대한 트랜잭션을 상기 적어도 두 개의 서브 노드 중 하나에 할당하고,
   상기 메인 블록체인은 상기 메인 트랜잭션에 기초하여 기설정된 주기로 메인 블록을 형성하고, 상기 서브 블록체인은 상기 서브 트랜잭션에 기초하여 기설정된 주기로 서브 블록을 형성하고,
   상기 제 1 및 제 2 메인 노드는 서로 다른 노드이고,
   상기 메인 블록체인은 트랜잭션이 공개되지 않는 프라이빗 블록체인(Private Blockchain)인 것을 특징으로 하는,
   통합인증 시스템.
   
2. 삭제
3. 삭제
4. 삭제
5. 제 1 항에 있어서,
   상기 서브 블록체인은 복수 개로 구비될 수 있으며,
   상기 메인 연결 노드는, 상기 복수 개의 서브 블록체인의 각 서브 연결 노드와 각각 연결되는 것을 특징으로 하는,
   통합인증 시스템.
6. 삭제

Images