KR101806070B1 - 사물인터넷을 위한 인증 시스템 - Google Patents

사물인터넷을 위한 인증 시스템 Download PDF

Info

Publication number
KR101806070B1
KR101806070B1 KR1020170056231A KR20170056231A KR101806070B1 KR 101806070 B1 KR101806070 B1 KR 101806070B1 KR 1020170056231 A KR1020170056231 A KR 1020170056231A KR 20170056231 A KR20170056231 A KR 20170056231A KR 101806070 B1 KR101806070 B1 KR 101806070B1
Authority
KR
South Korea
Prior art keywords
server
authentication
token
client server
client
Prior art date
Application number
KR1020170056231A
Other languages
English (en)
Inventor
정승욱
Original Assignee
건양대학교산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 건양대학교산학협력단 filed Critical 건양대학교산학협력단
Priority to KR1020170056231A priority Critical patent/KR101806070B1/ko
Application granted granted Critical
Publication of KR101806070B1 publication Critical patent/KR101806070B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/06009—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking
    • G06K19/06037—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking multi-dimensional coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

본 발명은 다양한 사물인터넷 환경에서 종래의 OAuth를 개량하여 다양한 단말기를 인증서버로 활용하고 이를 대형이면서 소수인 OAuth 클라이언트에 등록하는 방식으로 인증토큰을 푸쉬하는 형태로 안전하게 인증 및 인가함으로 외부 기기에서 사물인터넷 디바이스의 정보에 안전하게 접근할 수 있도록 하는 사물인터넷을 위한 인증 시스템에 관한 것이다.

Description

사물인터넷을 위한 인증 시스템 {Authorization system for Internet of Things}
본 발명은 사물인터넷 보안에 관한 것으로, 자세하게는 다양한 사물인터넷 환경에서 종래의 OAuth를 개량하여 다양한 단말기를 인증서버로 활용하고 이를 대형이면서 소수인 OAuth 클라이언트에 등록하는 방식으로 인증토큰을 푸쉬하는 형태로 안전하게 인증 및 인가함으로 외부 기기에서 사물인터넷 디바이스의 정보에 안전하게 접근할 수 있도록 하는 사물인터넷을 위한 인증 시스템에 관한 것이다.
인터넷에서 가장 성공적인 인증 프로토콜로 알려진 OAuth는 먼저, 사용자가 OAuth 인증서버(Authorization Server)에 해당하는 Google, Facebook과 같은 거대 인터넷 서비스 제공자에게 등록한 상태에서, 생성된 정보(친구 목록 등)를 외부의 인터넷 서비스 제공자인 OAuth 클라이언트가 읽기 위해서 사용자에게 요청(Facebook으로 로그인하기)하면 사용자가 Facebook에 인증을 하고 해당 정보 읽기를 허락함으로 OAuth 토큰을 OAuth 클라이언트에게 발급한다. 이후 OAuth 클라이언트는 OAuth 토큰을 Facebook에 제시하고 해당 사용자의 해당 정보를 읽어 가는 방식으로 진행된다.
도 1은 종래 OAuth의 개념도이다. 종래의 OAuth는 google, facebook과 같은 거대 기업이 OAuth Authorization 서버로 동작하면서 google, facebook에 저장된 개인정보를 접근하고자 하는 OAuth 클라이언트가 등록하고 사용자가 허락을 하면 OAuth 클라이언트가 google, facebook에서 정보를 읽어가는 형태로 도 1은 이러한 개념을 개략적으로 보여주고 있다.
한편, 최근 활발히 확산되는 IoT 환경에서 이러한 인증 프로토콜을 적용한 IOT-OAS와 같은 기술에서 IoT 개발자는 OAuth를 신경 쓰지 않도록 모든 기능을 신뢰할 수 있는 제3의 OAuth 인증서버를 제안하고 있다.
하지만, 개인 생활과 밀접한 IoT 디바이스, 특히 건강관리(Health-care) IoT와 같은 경우 개인의 민감한 신체정보를 다루고 있으므로 이렇게 민감한 정보의 접근 제어를 수행할 만한 신뢰할 수 있는 제3자가 있는지의 문제가 제기되고 있다. 또한, 종래의 기술은 IoT 디바이스 정보를 IoT 제조사에 디폴트(default)로 전송하고 있어 사용자에게 어떤 선택권도 없는 바 이는 정보가 한 회사에 국한(lock in)되는 문제가 있으며, 건강관리 IoT의 경우, 여러 장치를 착용했을 때 개별 제조사로 정보가 전송되어 통합적인 정보 및 상태확인이 이루어질 수 없는 문제가 있다.
특히 건강관리 IoT 제품은 수집정보를 주치의 등 전문가가 있는 병원에 전송하여 주로 판독하게 되므로 정보를 제조사에 전송하는 것은 합리적이지 않은 점도 문제로 지적되고 있다.
대한민국 등록특허공보 제10-1494097호(2015.02.17.)
본 발명은 상기와 같은 문제점을 해결하기 위하여 창출된 것으로, 본 발명의 목적은 OAuth를 변형하여 IoT 디바이스와 통신하면서 원거리 서버에 정보를 전달하는 장치를 OAuth 인증서버로 활용하고 이를 OAuth 클라이언트에 등록하면서 OAuth 토큰을 발급받도록 하여 개인이 직접 자신의 IoT 디바이스 정보를 제공할 곳을 선택하고 인가할 수 있어 개인정보보호 및 보안 측면에서 향상된 사물인터넷을 위한 인증 시스템을 제공하는 것이다.
상기와 같은 목적을 위해 본 발명은 인터넷 통신 기반의 인증 시스템에 있어서, 센서를 활용한 측정정보를 수집하는 감지부와, 상기 측정정보를 송신하는 전송부를 구비하는 IoT 디바이스; 개인인증서버를 등록받고 관리하는 등록부와, 등록된 개인인증서버로 인증토큰을 발급하는 발급부를 구비하는 RM 서버; 상기 IoT 디바이스와의 연동을 통해 전송된 측정정보를 수신하는 연동부와, 상기 RM 서버 및 클라이언트서버로의 등록과 인증토큰을 보유한 클라이언트서버와의 접속관리를 수행하는 인증관리부와, 등록된 클라이언트서버로 인증토큰을 인가하고 클라이언트서버가 보유한 인증토큰을 검증하는 토큰관리부와, 상기 IoT 디바이스로부터 수신된 측정정보를 인증토큰이 검증된 클라이언트서버로 전송하는 중계부를 구비하는 개인인증서버; 개인인증서버 및 인가된 인증토큰을 등록하고 관리하는 제1PAS관리부와, 등록된 개인인증서버로부터 인증토큰 검증에 따라 전송된 측정정보를 수신하여 저장하는 제1수집부를 구비하는 제1클라이언트서버; 로 이루어지는 것을 특징으로 한다.
이때 상기 제1클라이언트서버는 인증토큰을 보유한 제2클라이언트서버로부터의 인증토큰을 검증하고 정보요청을 관리하는 클라이언트관리부와, 상기 제1수집부에 저장된 측정정보를 정보를 요청하고 인증토큰이 검증된 제2클라이언트서버로 전송하는 정보전달부를 더 포함하고, 개인인증서버 및 인가된 인증토큰을 등록하고 관리하는 제2PAS관리부와, 상기 제1클라이언트서버로 인증토큰과 함께 정보를 요청하는 정보요청부와, 상기 제1클라이언트서버로부터 인증토큰 검증에 따라 전송된 측정정보를 수신하여 저장하는 제2수집부를 구비하는 제2클라이언트서버; 를 더 포함할 수 있다.
또한, 상기 제1클라이언트서버 및 제2클라이언트서버는 업체정보와 서버유형과 인증토큰 및 정보 송수신을 위한 URL 주소정보를 포함한 QR 코드를 제공하되, 상기 개인인증서버는 상기 QR 코드를 인식하여 클라이언트서버로의 등록 및 접속관리를 지원하는 스캔부를 더 포함할 수 있다.
또한, 상기 QR 코드의 내용은 상기 제1클라이언트서버 및 제2클라이언트서버와 개인인증서버로부터 전자서명되어 제공되며, 상기 개인인증서버는 상기 제1클라이언트서버 및 제2클라이언트서버로부터 공개키를 제공받아 상기 QR 코드를 검증할 수 있다.
또한, 상기 제1클라이언트서버와 제2클라이언트서버와 상기 개인인증서버는 인터넷 메시징 서비스를 이용하여 인증토큰 및 정보를 주고받을 수 있다.
또한, 상기 토큰관리부는 메시징 아이디와 측정정보 취득 주소와 토큰의 발급 및 유효시간과 상기 IoT 디바이스의 아이디를 포함한 인증토큰 티켓을 상기 제1클라이언트서버로 푸쉬하여 인증토큰을 인가하도록 구성될 수 있다.
또한, 상기 토큰관리부는 메시징 아이디와 제1클라이언트서버의 저장정보 취득 주소와 토큰의 발급 및 유효시간을 포함한 인증토큰 티켓을 상기 제2클라이언트서버로 푸쉬하여 인증토큰을 인가할 수 있다..
또한, 상기 토큰관리부는 상기 제1클라이언트서버가 보유한 인증토큰을 분석하여 푸쉬된 인증토큰을 대조하고, 발급 및 유효시간을 현재시간과 비교함으로 유효성을 검증할 수 있다.
또한, 상기 토큰관리부는 상기 제2클라이언트서버가 보유한 인증토큰을 분석하여 푸쉬된 인증토큰을 대조하고, 발급 및 유효시간을 현재시간과 비교함으로 유효성을 검증할 수 있다.
도 1은 종래 OAuth의 개념도,
도 2는 본 발명의 제1개념도,
도 3은 본 발명의 제2개념도,
도 4는 본 발명의 1 실시예에 다른 구성 및 연결관계를 나타낸 블록도,
도 5는 본 발명의 제2개념도,
도 6은 본 발명의 1 실시예에 다른 구성 및 연결관계를 나타낸 블록도이다.
이하, 첨부된 도면을 참조하여 본 발명 사물인터넷을 위한 인증 시스템의 구성을 구체적으로 설명한다.
사물인터넷은 사물에 센서를 부착해 실시간으로 데이터를 인터넷으로 주고받는 기술이나 환경을 일컫는다. 본 발명은 인터넷 통신 기반의 인증 시스템을 다루는 기술로 최근 웨어러블, 스마트홈, 커넥티드 카, 스마트 병원, 공장, 교통 등 다양한 분야에서 실제 생활과 밀접하게 적용되어 빠르게 보급중인 사물인터넷(Internet of things, IoT) 디바이스의 다양한 보안 위험을 방지하기 위한 용도로 활용 가능한 기술이다.
이를 위해 본 발명에서는 종래의 OAuth 개념을 일부 차용 및 개량하여 IoT 환경에 OAuth를 접목함에 있어 민감한 개인 정보를 제3자에 의해 인증 및 인가하는 것을 개선하여 개인이 보유한 스마트폰을 비롯하여 유무선 인터넷 통신이 가능한 게이트웨이, 라우터 등과 같은 다양한 단말기를 서버로 활용하는 개인인증서버(Personal authorization server)를 제안한다. 본 발명에서는 이러한 개인인증서버의 실시예로 스마트폰을 주고 언급하고 있으나, 이에 국한되지 않고 게이트웨이, 라우터 등의 동등한 기능의 다양한 단말기가 적용될 수 있다.
기존의 OAuth는 Facebook이나 google 등 대형 사업자가 OAuth 인증서버 역할을 하고 작고 많은 웹 서비스가 OAuth 클라이언트 역할을 하면서 Face-book이나 google 등에 먼저 OAuth 클라이언트로 등록해야 했고 OAuth 클라이언트가 OAuth 토큰을 먼저 OAuth 인증서버에 요청하고 수신한 OAuth 토큰으로 인가를 받아 정보에 접근하였다.
하지만, 본 발명에서는 언급한 개인 보유 단말기를 OAuth 인증서버로 사용하게 됨으로 매우 많은 작은 OAuth authorization server가 형성되고 소수의 대형 IoT 디바이스 제조사나 이를 활용하는 다양한 업체 및 기관 등이 OAuth 클라이언트 역할을 하게 된다.
즉 기존의 OAuth의 환경과 반대 환경을 가지게 된다. 또한, 개인인증서버로 스마트폰이나 개인이 보유한 장비를 사용하는 경우 IP가 지속적으로 변함에 따라 대형 제조사나 기관이 매우 많은 OAuth 인증서버 역할을 하는 개인인증서버를 파악할 수가 없으므로, 본 발명에서는 개인인증서버가 먼저 OAuth 클라이언트에 등록하고 OAuth 토큰, 즉 인증토큰을 Push하는 방식이 적용된다.
도 2는 본 발명의 제1개념도, 도 3은 본 발명의 제2개념도, 도 4는 본 발명의 1 실시예에 다른 구성 및 연결관계를 나타낸 블록도로서, IoT 디바이스(110)와, RM 서버(120)와, 개인인증서버(130)와, 제1클라이언트서버(140)의 기본 구성을 구비하고 있다.
상기 IoT 디바이스(110)는 사물인터넷 기술이 적용된 다양한 장치로 기본적으로 인터넷 기반의 통신이 가능하며, 센서를 활용한 측정정보를 수집하는 감지부(111)와, 상기 측정정보를 송신하는 전송부(112)를 구비하게 된다.
IoT에서 가장 광범위하게 활용되는 분야 중 하나는 건강관리(health-care) 분야로서 본 발명에서는 이를 주요 실시예로 설명하고 있으나, 이외에도 다양한 분야에 접목될 수 있다.
예를 들어, 맥박을 측정하는 손목에 착용하는 밴드와 심장박동 측정기 등 다양한 분야에서 활용되고 있거나 활용될 수 있는 디바이스가 적용 가능하며, 보안이나 시설관리 등의 분야에서 전기나 가스, 에너지, 물의 사용량이나 인원출입 현황을 측정할 수 있는 디바이스도 적용가능하다.
본 발명의 실시예로서 상기 IoT 디바이스(110)는 사용자의 신체에 착용 가능하되, 상기 감지부(111)는 사용자의 생체정보를 획득하는 센서로 이루어질 수 있으나 이에 한정하지 않음을 밝혀둔다.
이러한 수집정보는 매우 민감한 정보로 이를 악의적으로 지속적으로 수집하고 판매하는 등의 행위가 발생할 수 있으므로 안전하게 수집정보를 보호하는 것이 중요한 이슈가 되고 있다. 따라서, 인증 및 인가된 서버만 수집정보를 수집하고 수집정보를 안전하게 보호할 필요가 있으므로 인터넷에서 가장 널리 사용되고 있는 OAuth의 개념을 일부 활용 및 변형하여 본 발명을 구현하게 된다.
예를 들어 맥박을 측정하는 밴드의 경우 측정정보는 기본적으로 밴드 제조사에 전송될 것이며, 심장 박동기의 경우 측정정보는 심장 박동기 제조사 또는 병원에 전송될 것이다. 이외에도 다양한 장치로 부터 수집된 정보가 금융, 보안, 에너지 및 시설관리를 위한 업체나 기관에 전송죌 수 있을 것이다.
즉 측정정보가 여러 곳으로 전송될 것이며, 이러한 측정정보를 원거리에 있는 서버로 전송하기 위해서 IoT 디바이스(110)는 개인인증서버(130) 역할의 단말기로 측정정보를 전송하고 상기 개인인증서버(130)는 원거리 서버, 즉 클라이언트서버에 이를 전송할 것이다.
상기 RM 서버(120)는 종래의 OAuth 방식에서의 OAuth 인증을 위한 서버로 Resource Manage 역할을 하는 Facebook 이나 google 등이 이에 해당하며, 개인인증서버(130)를 등록받고 관리하는 등록부(121)와, 등록된 개인인증서버(130)로 인증토큰을 발급하는 발급부(122)를 구비한다. 실질적으로 개인인증서버(130)의 소유는 개인이 되므로 개인인증서버(130)를 등록한다는 의미는 개인이 자신의 정보와 함께 소유한 단말기를 RM 서버(120)에 등록하고 이를 관리한다는 것과 동일하게 인지될 수 있다.
상기 개인인증서버(130)는 사용자가 소지하며 인터넷 통신이 가능한 다양한 단말기로서 본 발명에서는 스마트폰을 예로 설명하게 되며 앞서 언급한 IoT 디바이스(110)로부터 측정정보 전송을 위한 중계기 역할을 하게 된다.
구체적으로 상기 개인인증서버(130)는 상기 IoT 디바이스(110)와의 연동을 통해 전송된 측정정보를 수신하는 연동부(131)와, 상기 RM 서버 및 클라이언트서버로의 등록과 인증토큰을 보유한 클라이언트서버와의 접속관리를 수행하는 인증관리부(132)와, 등록된 클라이언트서버로 인증토큰을 인가하고 클라이언트서버가 보유한 인증토큰을 검증하는 토큰관리부(133)와, 상기 IoT 디바이스(110)로부터 수신된 측정정보를 인증토큰이 검증된 클라이언트서버로 전송하는 중계부(134)를 구비한다.
인증토큰을 발급하는 구조는 첨부된 도 2와 같다. 일련의 절차는 OAuth 2.0과 마찬가지 안전을 위해서 TLS를 이용하게 되며, 개인인증서버(130)에서 인증토큰을 클라이언트인 제1클라이언트서버(140)로 푸쉬(push)한다.
상기 제1클라이언트서버(140)는 상기 IoT 디바이스(110)의 측정정보를 활용하게 되는 업체 또는 기관으로 건강관리 분야를 예로 디바이스의 제조사를 비롯하여 병원이나 다양한 의료기관이 될 수 있으며, 에너지, 시설, 보안 등의 관리를 위한 다양한 업체가 될 수 있다.
이러한 제1클라이언트서버(140)는 개인인증서버(130) 및 인가된 인증토큰을 등록하고 관리하는 제1PAS관리부(141)와, 등록된 개인인증서버(130)로부터 인증토큰 검증에 따라 전송된 측정정보를 수신하여 저장하는 제1수집부(142)를 구비하게 된다.
상기 측정정보는 주기적으로 업체나 기관, IoT 디바이스 제조사로 전송되는 구조로 운용되나 긴급상황에서는 정보요청을 통해 IoT 디바이스(110)로부터 측정정보를 수집할 수 있어야 한다. 즉 헬스케어 분야에서 의사가 사용자의 생체측정 정보를 요청하거나 보안업체에서 관련 측정 정보를 요청, 열람하는 상황에서 IoT 디바이스(110)의 측정 정보를 요청할 수 있다.
또한, 저장된 측정정보를 주기적으로 제3자(thrid party)가 읽는 방식의 운용도 가능하여야 할 것이다. 예를 들어 IoT 디바이스(110) 제조사에 주기적으로 수집한 측정정보를 병원, 보안, 관리 업체 등에서 읽어들여 업무에 활용할 수 있을 것이다. 즉 실시간으로 측정정보를 주기적으로 전송할 수 있고, 요청에 따라 긴급하게 읽거나 저장된 측정정보를 읽는 것도 가능하다.
본 발명에서 저장된 측정정보를 제3자에게 주기적으로 전송하는 것은 보안상으로 적절하지 않을 수 있기 때문에 고려하지 않으며, 저장된 정보는 필요시에만 제3자가 수집하여 읽도록 하게 된다.
OAuth를 응용하여 본 발명과 같은 사물인터넷 보안을 위해 활용할 경우 종래의 OAuth 인증서버를 누구로 할 것인지 고려해야 하며, 이때 신체정보나 에너지나 비용 정보 등 매우 민감한 정보가 될 수 있는 측정정보에 접근을 허용하는 것을 제3자에게 맡기는 것이 과연 안전한가, 그만큼 신뢰할 수 있는지의 문제와 주기적으로 정보를 전송하는 IoT 디바이스(110) 제조사나 주치의가 있는 병원이나 계약된 보안·관리업체 등을 인증서버로 할 수 있는가 하는 점을 고려할 수 있다.
이 경우 디바이스 제조사나 관련 업체, 기관에 정보가 lock-in 되는 문제가 있으므로 사용자가 소유하고 직접 제어할 수 있는 스마트폰, 소유한 게이트웨이, 라우터 등의 단말기가 인증서버 역할을 함으로 모든 문제를 해결할 수 있다.
따라서, 본 발명의 실시예에서는 스마트폰이 개인인증서버(130)로 제시되고 있으며, 이는 개인이 소유한 인증서버이므로 Personal OAuth AS(PAS)로 칭하고, 본 발명의 실시예로 설명되는 병원이나, 헬스케어를 비롯한 다양한 분야의 IoT 디바이스 제조사가 클라이언트가 된다.
이때 상기 개인인증서버(130)는 개인이 소유한 서버이므로 그 숫자가 수백만 개가 될 수도 있으므로, 예를 들어 보험사(클라이언트)가 개인의 심장 측정정보에 접근하는 것을 가정하에, 클라이언트 측에서 개인인증서버(130)를 모두 인지할 수 없는 현실이므로 역으로 개인인증서버(130)가 대형이면서 소수인 클라이언트, 즉 클라이언트서버에 등록하면서 인증토큰을 푸쉬하는 방법을 사용하게 된다.
도 5는 본 발명의 제2개념도, 도 6은 본 발명의 1 실시예에 다른 구성 및 연결관계를 나타낸 블록도로서, 1 실시예와 동일한 구성 및 원리하에서 측정정보가 제1클라이언트서버(140)의 제1수집부(142)에 저장되는 상태에서 제2의 클라이언트인 제2클라이언트서버(150)에서 이를 읽을 수 있는 구성이 부가되고 있다. 이하 2 실시예의 설명에서는 앞서 설명한 1 실시예와 동일한 구성의 자세한 설명은 생략한다.
본 발명의 2 실시예에서 상기 제1클라이언트서버(140)는 인증토큰을 보유한 제2클라이언트서버(150)로부터의 인증토큰을 검증하고 정보요청을 관리하는 클라이언트관리부(143)와, 상기 제1수집부(142)에 저장된 측정정보를 정보를 요청하고 인증토큰이 검증된 제2클라이언트서버(150)로 전송하는 정보전달부(144)를 더 포함하게 된다.
상기 제2클라이언트서버(150)는 상기 제1클라이언트서버(140)에 저장된 측정정보를 활용할 수 있는 제2의 클라이언트가 구비한 서버로서, 개인인증서버(130) 및 인가된 인증토큰을 등록하고 관리하는 제2PAS관리부(151)와, 상기 제1클라이언트서버(140)로 인증토큰과 함께 정보를 요청하는 정보요청부(153)와, 상기 제1클라이언트서버(140)로부터 인증토큰 검증에 따라 전송된 측정정보를 수신하여 저장하는 제2수집부(152)를 구비하게 된다.
본 발명에서 언급하는 건강관리 분야를 예로 들어 상기 제1클라이언트서버(140)는 병원 및 IoT 디바이스(110)의 제조사가, 상기 제2클라이언트서버(150)는 보험회사가 보유하는 것이 될 수 있을 것이다.
즉 제1클라이언트서버(140)에 저장된 측정정보 활용을 위해서 상기 개인인증서버(130)에서 제2클라이언트서버(150)로 인증토큰을 푸쉬하면 제2클라이언트서버(150)는 인증토큰을 상기 제1클라이언트서버(140)에 전달하여 상기 제1수집부(142)에 저장된 측정정보를 얻게 된다.
이때 주기적으로 측정정보를 수집하여 저장하고 있는 제1클라이언트서버(140)를 보유한 클라이언트를 primary 클라이언트로, 상기 primary 클라이언트로부터 저장된 측정정보를 읽어가는 클라이언트를 secondary 클라이언트로 칭할 수 있다.
도 6은 개인인증서버로부터 발급받은 인증토큰을 이용하여 Primary 클라이언트가 개인인정서버에 정보를 요청하는 것과 Secondary 클라이언트가 Primary 클라이언트에 인증토큰을 이용하여 저장된 측정정보를 요청하는 모습을 나타낸다.
Primary 클라이언트가 개인인증서버(130)에 인증토큰을 제시할 때, 문제는 클라이언트의 IP가 지속적으로 변하기 때문에 기존의 HTTP 통신으로는 전달할 수 없다. 따라서, GCM(Google Cloud Messaging)같은 메시징 서비스를 이용하여 인증토큰을 개인인증서버에 전달할 수 있을 것이다.
이 경우 제1클라이언트서버(140)와 제2클라이언트서버(150)는 Json 형식으로 통신을 한다. 또한, 제1클라이언트서버(140)와 제2클라이언트서버(150)와 개인인증서버(120)도 Json 형식으로 메지시를 주고받으며 메시징 서비스를 위한 일례로 GCM 9.2.0을 이용할 수 있다. 제1클라이언트서버(140)는 주기적으로 인증토큰 정보를 GCM 메시지로 보내고 개인인증서버(120)는 GCM 메시지를 받으면 제1클라이언트서버(140)로 해당 IoT 디바이스(110)의 정보를 전송한다.
이때 Primary 클라이언트에 이를테면 Primary Push 인증토큰을 발급하고 측정정보를 제공할 시 이를 발급할 URL 등을 알아야 한다. 이를 위해 본 발명에서는 QR코드로 Primary 클라이언트의 정보를 읽어들일 수 있다.
즉 IoT 디바이스(110)를 구매하였을 때 제조사를 Primary 클라이언트로 하는, 즉 제1클라이언트서버(140) 등록을 위한 QR 코드가 동봉될 수 있고, 긴급상황에서 병원에 내원 하였을 때는 병원이 Secondary 클라이언트가 되는 상황에서는 병원에서 Secondary 클라이언트를 위한, 즉 제2클라이언트서버(150) 등록을 위한 QR 코드를 제공할 수 있다.
이와 같이 본 발명의 2 실시예에서 상기 제1클라이언트서버(140) 및 제2클라이언트서버(150)는 업체정보와 서버유형과 인증토큰 및 정보 송수신을 위한 URL 주소정보를 포함한 QR 코드를 제공하게 된다.
또한, 이에 대응하여 상기 개인인증서버(130)인 스마트폰은 상기 QR 코드를 인식하여 클라이언트서버로의 등록 및 접속관리를 지원하는 스캔부(135)를 더 포함하게 된다.
본 발명에서 사용되는 QR 코드의 형식은 다음의 [표 1]로 정리될 수 있다.
Company Name 병원이나 health-care device 제조사의 이름
Company Type Primary Client이면 Primary이고 Secondary이면 Secondary이다
register URL OAuth ticket을 push 할 URL
realTimeInfoURL Access Token을 GCM으로 받았을 때 real-time 정보를 전송할 URL
storedInfoURL Secondary client가 primary client에 stored information을 요청할 때 호출하는 URL
ResourceID IoT device의 identifier이다. secondary client에게 제공받은 QR코드에는 없다.
언급한 바와 같이 병원이 클라이언트이면 QR 코드는 병원에서 제공되고, IoT 디바이스 제조사가 클라이언트이면 IoT 디바이스(110)를 구입했을 때 QR 코드가 동봉되므로 QR 코드는 신뢰할 수 있는 곳에서 받았다고 가정할 수 있다.
만약 QR 코드의 안전성을 더 고려한다면 QR 코드의 내용을 전자 서명하여 공개키를 병원에서 제공받거나, 제조사의 홈페이지 등에서 공개키를 받아서 검증할 수도 있다.
또한, 상기 토큰관리부(133)는 메시징 아이디와 측정정보 취득 주소와 토큰의 발급 및 유효시간과 상기 IoT 디바이스(110)의 아이디를 포함한 인증토큰 티켓을 상기 제1클라이언트서버(140)로 푸쉬하여 인증토큰을 인가하도록 구성될 수 있다.
마찬가지로 상기 토큰관리부(133)는 메시징 아이디와 제1클라이언트서버(140)의 저장정보 취득 주소와 토큰의 발급 및 유효시간을 포함한 인증토큰 티켓을 상기 제2클라이언트서버(150)로 푸쉬하여 인증토큰을 인가할 수 있다. 이를 위해 본 발명에서는 JSON (JavaScript Object Notation) 방식의 포멧을 사용할 수 있으며 상기 티켓에 부여되는 속성은 다음 [표 2]로 정리될 수 있다.
client_id 클라이언트을 구별하기 위한 identifier로 OAuth 표준을 따른다.
hash (client's URL|resourceID)을 이용할 수 있다.
client_secret 클라이언트를 인증하기 위해서 사용하는 비밀값으로 OAuth 표준을 따른다.
token_type Token Type은 bear type일 수 있으며 OAuth 표준을 따른다.
access_token 본 발명에서는 JWT token을 예로 제시한다
expire_in 유효 시간을 초 단위로 나타낸 것으로 OAuth 표준을 따른다.
refresh_token 인증토큰이 만료되었을 때 인증토큰을 재발급하기 위한 토큰으로 OAuth표준을 따른다.
info_type OAuth 표준에 없는 추가된 필드이며 실시간 측정 정보를 위해서는 RealTime이라는 값을 가지며 저장정보를 위해서는 Stored라는 값을 가진다.
redirect_url Primary 클라이언트로 티켓푸쉬를 위해서는 GCM registration ID등 메시징 identifier이다, Secondary 클라이언트로 티켓 푸쉬에서는 secondary 클라이언트가 priamry 클라이언트로 저장정보를 요청할 URL이다.
또한, 본 발명에서 인증토큰이 JSON Web Token(JWT Token)의 포멧 및 속성은 [표 3]과 같이 정리될 수 있다. Push OAuth를 위해서 추가된 필드는 rID이며 나머지는 JWT 표준과 동일하다.
iss(issuer) 발급자를 나타내는 것으로 메시징 ID이다.
sub(subject) 정보를 읽어가는 subject를 나타낸다. primary 클라이언트에게 발급할 때는 realTimeInfoURL이 값이며 secondary 클라이언트에게 발급할 때는 secondary client의 IP address이다.
aud(audience) Aud는 JWT token을 수신하는 자이다. Primary 클라이언트에게 발급할 때는 PAS의 메시징 ID가 audience이며 secondary 클라이언트에게 발급할 때는 primary client의 storedInfoURL이 된다.
exp(expiration time) 발급한 시간으로 부터 유효한 시간을 초단위로 나타낸다.
nbf(not before) 해당 시간전에는 JWT token이 유효하지 않다.
iat(issued at) JWT가 발급된 시간
jti (JWT ID) JWT identifier
rID (Resource ID) 정보를 생산해내는 IoT 디바이스의 ID이다.
JWT token은 IETF RFC 7519에 나와 있는 것처럼 JWT header를 포함할 것이며 보안을 위하여 JSON Web Sig-nature를 이용하여 서명하여 전송한다. 따라서, primary 클라이언트를 위해서 제1클라이언트서버(140)로 티켓을 발급하면 제1클라이언트서버(140)가 자신의 client secret로 검증을 할 것이다. 또한, 제2클라이언트서버(150)가 제1클라이언트서버(140)로 저장정보의 접근을 위해서 인증토큰을 제시하여도 제1클라이언트서버(140)은 자신의 client secret으로 검증을 하여 자신이 받도록 된 JWT인지 확인가능하다.
상기 토큰관리부(133)는 상기 제1클라이언트서버(140)가 보유한 인증토큰을 분석하여 푸쉬된 인증토큰을 대조하고, 발급 및 유효시간을 현재시간과 비교함으로 유효성을 검증하게 되고, 마찬가지로 상기 제2클라이언트서버(150)가 보유한 인증토큰을 분석하여 푸쉬된 인증토큰을 대조하고, 발급 및 유효시간을 현재시간과 비교함으로 유효성을 검증하게 된다.
이러한 티켓 발송 및 인증토큰 검증에 대한 구체적인 절차로 제1클라이언트서버(140) 또는 제2클라이언트서버(150)에서 티켓을 registerURL로 수신받으면 JWT Token을 decode하여, JWT.iat + JWT.exp 가 현재시간보다 큰지 확인한다.
만약 크다면 JWT.nbf가 현재시간보다 큰지 확인하고 작다면 종료한다.
즉 JWT token이 만료되지 않았다면 Ticket.info_type이 RealTime인지 StoredInfo인지에 따라 다르게 처리한다.
Ticket.info_type이 RealTime인 경우 JWT.sub이 client의 realTimeInofURL과 일치하는지 즉 자신에게 발급된 JWT token인지 확인하여 자신에게 발급되지 않았다면 종료하고 자신에게 발급되었다면 Signature를 Ticket.client_secret으로 확인하여 그렇지 않다면 종료한다. 만약 맞다면 Ticket.client_id가 DB에 있는지 확인한다. 있다면 이미 발급받았지만 JWT token을 재발급한 것으로 DB에 있는 기존 JWT token를 새로운 JWT token으로 갱신하고 DB에서 info_type이 RealTime인 티켓들을 읽어들인다.
만약 DB에 없다면 DB에 수신한 티켓을 저장부터 한다.
이후 DB로 읽은 티켓의 JWT.iat + JWT.exp가 현재시간보다 크면 GCM message {code:JWT, client_ID, to-ken:JWT token}를 ticket.redirect_url로 전송, 즉 JWT to-ken이 유효하므로 JWT token을 전송한다. 그렇지 않으면 GCM message {code:Refresh, client_ID, to-ken:Refresh_token}을 전송하고 종료한다.
Ticket.info_type이 StoredInfo인 경우 JWT.sub이 자신의 IP인지 확인하고, 맞다면 자신에게 전송된 것으로 인정하고 그렇지 않다면 종료한다.
이후 ticket.redirect_url에 HTTPS 통신을 시도하여 JWT token을 redirect_url로 전송하고, HTTPS 통신의 결과값을 읽는다.(결과값은 JSON형식의 stored Info 정보) 이후 stored Info 정보를 DB에 저장한다.
또한, 개인인증서버(120)에서 GCM message를 받으면 다음과 같은 절차로 처리한다.
1. Code가 JWT 인지 확인, 만약 맞다면 2-1부터 수행하고 아니라면 3-1부터 수행한다.
2-1. JWT token을 decode하고, 2-2. DB에서 client_ID를 가지고 JWT token을 읽어 들인다. 2-3. 읽은 JWT token과 수신한 JWT token이 동일하지 비교하여, 2-4. 만약 동일하지 않다면 변조된 JWT token이므로 종료하고, 그렇지 않으면 다음으로 진행한다.
2-5. JWT.iat + JWT.exp가 현재시간보다 큰지 확인하여, 만약 크다면 유효한 JWT token이므로 다음으로 진행하고 그렇지 않으면 종료한다.
2-6. JWT.nbf가 현재시간보다 작은지 확인하여, 작다면 유효한 JWT token으로 다음으로 진행하고 그렇지 않으면 종료한다.
2-7. DB에서 client_ID가 일치하는 client_secert 을 읽어, 2-8. 서명이 유효한지 확인하고 만약 그렇다면 다음으로 진행하고 그렇지 않으면 종료한다.
2-9. DB에서 JWT.rID와 일치하는 information을 읽어서 JWT.sub으로 정보를 전송하고 기존의 infor-mation을 삭제 (information은 주기적으로 IoT device로 부터 읽어서 저장함)
3-1 DB에서 client_ID로 refresh_token을 읽어들인다. 3-2. 수신한 refresh_token과 DB에 저장된 re-fresh_token이 동일하면 다음으로 진행하고 그렇지 않으면 종료한다.
3-3. DB에서 client_ID로 registerUR를 읽어서 새로운 JWT token을 registerURL로 전송한다.
본 발명을 요약하면 스마트폰이 개인인증서버(130)이며 사용자가 먼저 자신의 IoT 디바이스(110)의 측정정보를 읽어갈 클라이언트를 정하고 개인인증서버(130)가 먼저 클라이언트서버(예를 들어, 병원, 각종 업체 또는 기관, 디바이스 제조사), 즉 제1클라이언트서버(140) 및 제2클라이언트서버(150)에 등록한다. 이때 Push 인증토큰을 제1클라이언트서버(140) 및 제2클라이언트서버(150) 측으로 발급한다.
각 클라이언트서버는 발급받은 Push 인증토큰으로 IoT 디바이스의 측정정보를 읽어간다. 만약 주치의가 있는 병원이 제1클라이언트서버(Primary 클라이언트)일 때 보험사가 병원에 저장된 정보를 읽기 위해서는 개인인증서버가 보험사인 제2클라이언트서버(Secondary 클라이언트)를 등록하고 제1클라이언트서버(140)에서 측정정보를 읽을 수 있는 Push 인증토큰을 발급한다. Secondary 클라이언트인 제2클라이언트서버(150)는 발급받은 인증토큰을 Primary 클라이언트에 제시하고 정보를 읽어 간다.
본 발명의 권리는 위에서 설명된 실시 예에 한정되지 않고 청구범위에 기재된 바에 의해 정의되며, 본 발명의 분야에서 통상의 지식을 가진 자가 청구범위에 기재된 권리범위 내에서 다양한 변형과 개작을 할 수 있다는 것은 자명하다.
110: IoT 디바이스 111: 감지부
112: 전송부 120: RM 서버
121: 등록부 122: 발급부
130: 개인인증서버 131: 연동부
132: 인증관리부 133: 토큰관리부
134: 중계부 135: 스캔부
140: 제1클라이언트서버 141: 제1PAS관리부
142: 제1수집부 143: 클라이언트관리부
144: 정보전달부 150: 제2클라이언트서버
151: 제2PAS관리부 152: 제2수집부
153: 정보요청부

Claims (9)

  1. 인터넷 통신 기반의 인증 시스템에 있어서,
    센서를 활용한 측정정보를 수집하는 감지부(111)와, 상기 측정정보를 송신하는 전송부(112)를 구비하는 IoT 디바이스(110);
    개인인증서버를 등록받고 관리하는 등록부(121)와, 등록된 개인인증서버(130)로 인증토큰을 발급하는 발급부(122)를 구비하며, OAuth 인증을 위한 서버로 리소스 관리자(Resource Manage) 역할을 하는 RM 서버(120);
    상기 IoT 디바이스(110)와의 연동을 통해 전송된 측정정보를 수신하는 연동부(131)와, 상기 RM 서버(120) 및 클라이언트서버로의 등록과 인증토큰을 보유한 클라이언트서버와의 접속관리를 수행하는 인증관리부(132)와, 등록된 클라이언트서버로 인증토큰을 인가하고 클라이언트서버가 보유한 인증토큰을 검증하는 토큰관리부(133)와, 상기 IoT 디바이스(110)로부터 수신된 측정정보를 인증토큰이 검증된 클라이언트서버로 전송하는 중계부(134)를 구비하는 개인 보유 단말기로 이루어지는 개인인증서버(130);
    상기 IoT 디바이스(110)의 측정정보를 활용하게 되는 업체 또는 기관에 구비되며, 개인인증서버(130) 및 인가된 인증토큰을 등록하고 관리하는 제1PAS관리부(141)와, 등록된 개인인증서버(130)로부터 인증토큰 검증에 따라 전송된 측정정보를 수신하여 저장하는 제1수집부(142)를 구비하는 제1클라이언트서버(140); 로 이루어지는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  2. 제1항에 있어서,
    상기 제1클라이언트서버(140)는 인증토큰을 보유한 제2클라이언트서버(150)로부터의 인증토큰을 검증하고 정보요청을 관리하는 클라이언트관리부(143)와, 상기 제1수집부(142)에 저장된 측정정보를 정보를 요청하고 인증토큰이 검증된 제2클라이언트서버(150)로 전송하는 정보전달부(144)를 더 포함하고,
    개인인증서버(130) 및 인가된 인증토큰을 등록하고 관리하는 제2PAS관리부(151)와, 상기 제1클라이언트서버(140)로 인증토큰과 함께 정보를 요청하는 정보요청부(153)와, 상기 제1클라이언트서버(140)로부터 인증토큰 검증에 따라 전송된 측정정보를 수신하여 저장하는 제2수집부(152)를 구비하는 제2클라이언트서버(150); 를 더 포함하는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  3. 제2항에 있어서,
    상기 제1클라이언트서버(140) 및 제2클라이언트서버(150)는 업체정보와 서버유형과 인증토큰 및 정보 송수신을 위한 URL 주소정보를 포함한 QR 코드를 제공하되,
    상기 개인인증서버(130)는 상기 QR 코드를 인식하여 클라이언트서버로의 등록 및 접속관리를 지원하는 스캔부(135)를 더 포함하는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  4. 제3항에 있어서,
    상기 QR 코드의 내용은 상기 제1클라이언트서버(140) 및 제2클라이언트서버(150)와 개인인증서버(130)로부터 전자서명되어 제공되며, 상기 개인인증서버(130)는 상기 제1클라이언트서버(140) 및 제2클라이언트서버(150)로부터 공개키를 제공받아 상기 QR 코드를 검증하는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  5. 제2항에 있어서,
    상기 제1클라이언트서버(140)와 제2클라이언트서버(150)와 상기 개인인증서버(130)는 인터넷 메시징 서비스를 이용하여 인증토큰 및 정보를 주고받는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  6. 제5항에 있어서,
    상기 토큰관리부(133)는 메시징 아이디와 측정정보 취득 주소와 토큰의 발급 및 유효시간과 상기 IoT 디바이스(110)의 아이디를 포함한 인증토큰 티켓을 상기 제1클라이언트서버(140)로 푸쉬하여 인증토큰을 인가하도록 구성되는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  7. 제5항에 있어서,
    상기 토큰관리부(133)는 메시징 아이디와 제1클라이언트서버(140)의 저장정보 취득 주소와 토큰의 발급 및 유효시간을 포함한 인증토큰 티켓을 상기 제2클라이언트서버(150)로 푸쉬하여 인증토큰을 인가하는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  8. 제6항에 있어서,
    상기 토큰관리부(133)는 상기 제1클라이언트서버(140)가 보유한 인증토큰을 분석하여 푸쉬된 인증토큰을 대조하고, 발급 및 유효시간을 현재시간과 비교함으로 유효성을 검증하는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
  9. 제7항에 있어서,
    상기 토큰관리부(133)는 상기 제2클라이언트서버(150)가 보유한 인증토큰을 분석하여 푸쉬된 인증토큰을 대조하고, 발급 및 유효시간을 현재시간과 비교함으로 유효성을 검증하는 것을 특징으로 하는 사물인터넷을 위한 인증 시스템.
KR1020170056231A 2017-05-02 2017-05-02 사물인터넷을 위한 인증 시스템 KR101806070B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020170056231A KR101806070B1 (ko) 2017-05-02 2017-05-02 사물인터넷을 위한 인증 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020170056231A KR101806070B1 (ko) 2017-05-02 2017-05-02 사물인터넷을 위한 인증 시스템

Publications (1)

Publication Number Publication Date
KR101806070B1 true KR101806070B1 (ko) 2017-12-07

Family

ID=60920701

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170056231A KR101806070B1 (ko) 2017-05-02 2017-05-02 사물인터넷을 위한 인증 시스템

Country Status (1)

Country Link
KR (1) KR101806070B1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101878314B1 (ko) * 2018-02-12 2018-07-16 (주)케이사인 사물 인터넷 네트워크의 사용자 인증 시스템 및 방법
KR20200105706A (ko) * 2018-01-17 2020-09-08 가부시키가이샤 사이게임스 통신을 행하기 위한 시스템, 프로그램, 방법 및 서버
KR102199136B1 (ko) * 2019-09-23 2021-01-06 (주)드림시큐리티 데이터 출처 인증 장치 및 방법

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200105706A (ko) * 2018-01-17 2020-09-08 가부시키가이샤 사이게임스 통신을 행하기 위한 시스템, 프로그램, 방법 및 서버
KR102374887B1 (ko) 2018-01-17 2022-03-16 가부시키가이샤 사이게임스 통신을 행하기 위한 시스템, 프로그램, 방법 및 서버
KR101878314B1 (ko) * 2018-02-12 2018-07-16 (주)케이사인 사물 인터넷 네트워크의 사용자 인증 시스템 및 방법
KR102199136B1 (ko) * 2019-09-23 2021-01-06 (주)드림시큐리티 데이터 출처 인증 장치 및 방법

Similar Documents

Publication Publication Date Title
US10685526B2 (en) Architecture for access management
ES2961812T3 (es) Sistema proxy de autenticación de dos canales capaz de detectar la manipulación de una aplicación y el método para ello
RU2638741C2 (ru) Способ и система аутентификации пользователя посредством мобильного устройства с применением сертификатов
EP2401838B1 (en) System and methods for online authentication
EP1792437B1 (en) Authenticating a client using linked authentication credentials
US10115243B2 (en) Near field communication system
KR20050008627A (ko) 정보 처리 시스템 및 방법, 정보 처리 장치 및 방법, 기록매체, 및 프로그램
KR101806070B1 (ko) 사물인터넷을 위한 인증 시스템
CN110692103A (zh) 系统的登录方法
JP5090425B2 (ja) 情報アクセス制御システム及び方法
US10541813B2 (en) Incorporating multiple authentication systems and protocols in conjunction
US11915507B2 (en) Location- and identity-referenced authentication method and communication system
KR20180041508A (ko) 유헬스 환경에서의 에이전트와 데이터매니저간의 상호 인증방법
EP2960842A1 (en) Time entry recording system
KR101681457B1 (ko) 금융 이체를 위한 2채널 인증 시스템 및 그 방법
KR101714332B1 (ko) 스마트 전자건강보험증 관리시스템
EP4050579A1 (en) Systems and methods of access validation using distributed ledger identity management
WO2022024281A1 (ja) 認証サーバ、認証システム、認証要求処理方法及び記憶媒体
JP5919497B2 (ja) ユーザ認証システム
KR20220128813A (ko) 백신 접종의 인증 및 접종 후 사후 관리를 제공하기 위한 방법 및 그 시스템
Agbede Strong Electronic Identification: Survey & Scenario Planning
KR102478963B1 (ko) 백신 접종 디지털 인증서를 발급하고 증명하는 방법 및 그 시스템
WO2018207079A1 (en) Method and system for universal access control management to an entity with inconsistent internet access
US20220269770A1 (en) Information processing system, server apparatus, information processing method, and computer program product
JP2023041390A (ja) 情報処理装置、認証方法、認証プログラムおよび患者認証システム

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant