KR102578441B1 - 사물 인증 시스템 및 방법 - Google Patents

Abstract

본 발명의 일 실시예에 의한 사물 인증 시스템은, 복수 개의 장치와 통신이 연결된 클라우드 도메인을 제어하는 클라우드 서버, 복수 개의 장치와 통신이 연결된 홈 도메인을 제어하는 홈 서버, 새로운 장치인 제1 장치 및 상기 홈 서버에서 인증이 완료되고, 상기 홈 도메인과 통신이 연결된 루트 사용자의 제2 장치를 포함하고, 사전 배치(Pre-deployment) 단계에서 상기 제1 장치는, 상기 클라우드 서버의 암호화 재료를 상기 클라우드 서버로부터 로드하고, 상기 암호화 재료는, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디 기반 암호화 시스템의 제1 개인 키, 상기 클라우드 서버 내에서 상기 제1 장치의 제1 쌍대 키 및 상기 제1 장치의 카운터를 적어도 포함하고, 상기 클라우드 서버는, 상기 제1 장치가 거래자에게 운송된 경우 상기 제1 개인 키를 상기 클라우드 서버에서 삭제한다.

Description

사물 인증 시스템 및 방법{A SYSTEM AND METHOD FOR AUTHENTICATION OF THINGS}

본 발명은 사물 인증 시스템 및 사물 인증 방법에 관한 것이다.

사물 인터넷이라 함은 만물이 정보통신기술을 이용하여 지능적 관계를 형성하는 사물 공간 연결망을 의미한다. 즉 언제 어디서나 무엇이든 인터넷을 통해 연결되며 인간의 명시적 개입 없이도 주변 상황을 감지하고 통신하며 상호 협력하여 적절한 정보 처리와 제어를 수행하는 기술과 서비스를 의미한다. 여기서, 사물 인터넷의 주요 구성 요소인 사물은 유무선 네트워크에서의 통신 장치(end-device) 뿐만 아니라, 인간, 차량, 교량, 각종 전자장비, 문화제, 자연 환경을 구성하는 물리적 사물 등도 포함된다.

현재 가전 업계에서는 일상 가전 제품부터 복잡한 바이오 센서까지 서로 다른 네트워크 전역에 걸쳐서 사물 인터넷(Internet of Things, IOT) 장치가 급증하고 있다. 즉, 현재 사물 인터넷 장치는 일상 생활의 일 부분이 되었다. 그리고, 우리는 곧 10억만의 사물 인터넷 장치들에 둘러 쌓여질 것으로 예상된다. 하지만, 기존의 인증 및 접근 제어 메커니즘들은 사물 인터넷의 증가하는 수요를 충족하지 못한다.

즉, 사물 인터넷 장치의 수요가 증가하면서 더 강력한 인증 및 접근 제어 메커니즘의 필요성이 커지고 있다. 특히, 사물 인터넷 장치의 라이프 사이클(예를 들어, 장치 생산에서부터 장치 폐기까지) 전반적으로 인증 및 접근 제어를 실행하는 메커니즘이 절실히 필요하다.

사물 인터넷에 쓰이는 센서들은 초소형, 저전력의 특징을 갖고 있기 때문에 컴퓨팅 파워가 충분하지 않아 저전력에서도 원활하게 작동하는 인증 및 접근 제어 메커니즘이 필요하다.

사물 인터넷은 센서들을 갖는 물리적 객체(예를 들어, 차량들 및 가전들)와 사이버 물리 시스템(예를 들어, 스마트 도시, 스마트 집 등)에서의 작동 장치들을 결합한다.

여기서, 인증 메커니즘은 메시지를 발송한 사람을 확실히 인식하는 것뿐만 아니라 위조된 데이터와 기존의 데이터를 구분할 수 있는 것을 의미한다. 인증은 보안에서 다른 무엇보다 중요하다.

특히, 사물 인터넷에서 인증은 접근 제어를 가능하게 하고 어떤 한 공격자가 여러 개의 식별자를 갖고 시스템이나 네트워크를 공격하는 시빌 어택(Sybil attack)을 막을 수 있고, 서비스 거부 공격(Denial of Service, Dos)의 시도를 경감시킬 수 있다. 인증 메커니즘은 인증을 사물 인터넷에서의 키 보안 성질로 만든다.

사물 인터넷에서 보안은 연구 단체로부터 많은 관심을 받고 있지만 기존 접근법은 사물 인터넷에서 활용하기에는 적절하지 않다.

첫째로, 공개 키 기반 구조(Public Key Infrastructure, PKI) 및 증명서에 기초하는 전통적인 스키마들(Schemes)은 CPU, 메모리, 저장 공간, 통신 및 관리 오버헤드를 상당히 초래할 수 있어, 사물 인터넷 장치에 맞지 않는다.

둘째로, 사물 인터넷에서 특정 도메인의 장치들이 다수의 다른 도메인에 존재하는 다른 장치들과 안전하게 상호 작용하는 것이 요청된다. 리소스가 제한된(resource-constrained) 장치들을 타겟으로 하는 많은 인증 스키마들은 하나의 도메인에 존재하는 장치들에 관한 것이므로, 사물 인터넷에 바로 적용할 수 없다.

셋째로, 현재 사물 인터넷 장치의 라이프 사이클 동안 인증을 전체적으로 제공할 수 있는 메커니즘은 존재하지 않는다.

결과적으로, 사물 인터넷 인증 요구를 충족하는 딱 맞는 사물 인증 시스템 및 사물 인증 방법이 요구된다.

또한, 사물 인터넷 장치들에 공개 키 암호 체계(Public-Key Cryptosystem, PKS)를 이용하여 인증 및 접근 제어를 수행할 수는 있지만, 상기 공개 키 암호 체계는 값이 비싸기 때문에 사물 인터넷 장치들에 적용하기는 사실상 어렵다.

따라서, 이러한 종래 기술의 문제점을 해결한 사물 인증 시스템 및 방법을 개발할 필요성이 절실한 실정이다.

본 발명의 전술한 문제 및 다른 문제를 해결하는 것을 목적으로 한다. 본 발명의 일 실시예가 이루고자 하는 기술적 과제는, 사물 인터넷에 적합한 인증 및 접근 제어 솔루션을 제공하는 것을 그 목적으로 한다.

본 발명의 일 실시예가 이루고자 하는 기술적 과제는, 사물 인터넷 장치의 전체 라이프 사이클 동안 인증 및 접근 제어를 제공하는 한 묶음의 프로토콜들을 제공하는 것을 그 목적으로 한다.

본 발명의 일 실시예가 이루고자 하는 기술적 과제는, 클라우드 도메인 및 홈 도메인에서의 인증 및 접근 제어를 제공하는 것을 그 목적으로 한다.

본 발명의 일 실시예가 이루고자 하는 기술적 과제는 게스트 디바이스가 다른 외부 도메인으로부터 자신을 스스로 인증하는 것을 그 목적으로 한다.

본 발명의 일 실시예가 이루고자 하는 기술적 과제는, 특정 장치가 자신이 갖고 있는 도메인과 다른 도메인에 가입하고, 상기 특정 장치가 자신 스스로를 인증하여 외부 장치들의 작업들에 대한 접근을 수행하는 것을 그 목적으로 한다.

본 발명의 일 실시예가 이루고자 하는 기술적 과제는, 장치의 소유권을 안전하게 전송하는 것을 그 목적으로 한다.

본 발명의 일 실시예가 이루고자 하는 기술적 과제는, 보다 강력한 보안을 제공하는 인증 및 접근 제어를 실행하는 것을 그 목적으로 한다.

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

본 발명의 일 실시예에 의한 사물 인증 시스템은, 복수 개의 장치와 통신이 연결된 클라우드 도메인을 제어하는 클라우드 서버, 복수 개의 장치와 통신이 연결된 홈 도메인을 제어하는 홈 서버, 새로운 장치인 제1 장치 및 상기 홈 서버에서 인증이 완료되고, 상기 홈 도메인과 통신이 연결된 루트 사용자의 제2 장치를 포함하고, 사전 배치(Pre-deployment) 단계에서 상기 제1 장치는, 상기 클라우드 서버의 암호화 재료를 상기 클라우드 서버로부터 로드하고, 상기 암호화 재료는, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디 기반 암호화 시스템의 제1 개인 키, 상기 클라우드 서버 내에서 상기 제1 장치의 제1 쌍대 키 및 상기 제1 장치의 카운터를 적어도 포함하고, 상기 클라우드 서버는, 상기 제1 장치가 거래자에게 운송된 경우 상기 제1 개인 키를 상기 클라우드 서버에서 삭제한다.

또한, 본 발명의 일 실시예에 의한 사물 인증 방법은, 사전 배치(Pre-deployment) 단계에서, 새로운 장치인 제1 장치가 클라우드 도메인을 제어하는 클라우드 서버의 암호화 재료를 상기 클라우드 서버로부터 로드하는 단계 및 상기 제1 장치가 거래자에게 운송된 경우, 상기 클라우드 서버가 상기 제1 개인 키를 상기 클라우드 서버에서 삭제하는 단계를 포함하고, 상기 암호화 재료는, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디 기반 암호화 시스템의 제1 개인 키, 상기 클라우드 서버 내에서 상기 제1 장치의 제1 쌍대 키 및 상기 제1 장치의 카운터를 적어도 포함한다.

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

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

본 발명의 실시예들 중 적어도 하나에 의하면, 사물 인터넷에 적합한 인증 및 접근 제어 솔루션을 제공할 수 있다.

또한, 본 발명의 실시예들 중 적어도 하나에 의하면, 사물 인터넷 장치의 라이프 사이클 동안의 모든 단계에서 인증 및 접근 제어를 제공하는 한 묶음의 프로토콜들을 제공할 수 있다.

또한, 본 발명의 실시예들 중 적어도 하나에 의하면, 클라우드 도메인 및 홈 도메인에서의 인증 및 접근 제어를 제공할 수 있다.

또한, 본 발명의 실시예들 중 적어도 하나에 의하면, 게스트 디바이스가 다른 외부 도메인으로부터 자신을 스스로 인증할 수 있다.

또한 본 발명의 실시예들 중 적어도 하나에 의하면, 특정 장치가 자신이 갖고 있는 도메인과 다른 도메인에 가입하고, 상기 특정 장치가 자신 스스로를 인증하여 외부 장치들의 작업들에 대한 접근을 수행할 수 있다..

또한 본 발명의 실시예들 중 적어도 하나에 의하면, 장치의 소유권을 안전하게 전송할 수 있다.

또한 본 발명의 실시예들 중 적어도 하나에 의하면, 보다 강력한 보안을 제공하는 인증 및 접근 제어를 실행할 수 있다.

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

도 1은 본 발명의 일 실시예에 의한 사물 인증 시스템이 적용되는 사물 인터넷 장치의 라이프 사이클을 설명하기 위한 도면이다.
도 2는 본 발명의 일 실시예에 의한 사물 인증에서 두 도메인 아키텍쳐를 설명하기 위한 도면이다.
도 3은 본 발명의 일 실시예에 따른 보조 절차인 세션 키 절차의 일례를 설명하기 위한 도면이다.
도 4는 본 발명의 일 실시예에 따른 보조 프로토콜인 키 합의 프로토콜의 일례를 설명하기 위한 도면이다.
도 5는 본 발명의 일 실시예에 따른 보조 프로토콜인 키 발행 프로토콜의 일례를 설명하기 위한 도면이다.
도 6은 본 발명의 일 실시예에 따른 보조 프로토콜인 바인딩 프로토콜의 일례를 설명하기 위한 도면이다.
도 7은 본 발명의 일 실시예에 따라 사전 배치 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.
도 8은 본 발명의 일 실시예에 따라 주문 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.
도 9는 본 발명의 일 실시예에 따라 배치 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.
도 10은 본 발명의 일 실시예에 따른 작동 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.
도 11은 본 발명의 일 실시예에 의한 폐기 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.
도 12는 본 발명의 일 실시예에 따른 사물 인증 시스템에서 장치의 소유권을 재할당하는 방법의 일례를 설명하기 위한 도면이다.
도 13은 본 발명의 일 실시예에 따른 사물 인증 시스템에서 인터도메인 작업을 하는 방법의 일례를 설명하기 위한 도면이다.
도 14는 본 발명의 일 실시예에 따른 아키텍쳐를 설명하기 위한 도면이다.
도 15는 본 발명의 일 실시예에 따른 사물 인증 구성 요소들의 소프트웨어 스택을 설명하기 위해 도시한 도면이다.
도 16은 사물 인증의 수행 시간 및 통신 오버헤드의 비교 결과를 설명하기 위한 테이블이다.
도 17은 본 발명의 일 실시예에 의한 사물 인증을 평가하기 위해 사용되는 장치들의 성능을 나타내는 테이블이다.
도 18은 본 발명의 일 실시예에 의한 사물 인증에서 사용되는 비대칭 암호화 알고리즘들의 실행 시간을 나타내는 도면이다.
도 19는 본 발명의 일 실시예에서 사용되는 다른 보안 레벨 및 구성들(configurations)에서의 실행 시간을 나타내는 도면이다.
도 20은 특정 그룹에서 스칼라 포인트 곱셈의 실행 시간들 및 페어링 산출의 실행 시간을 나타낸 테이블이다.
도 21은 본 발명의 일 실시예에 따른 사물 인증에서 다른 프레디킷 구조들의 속성 기반 인증의 서명 확인 실행 시간을 평가한 결과를 나타낸 도면이다.
도 22는 본 발명의 일 실시예에 따른 사물 인증에서 속성 기반 인증 확인 실행 시간들 및 메모리 사용률을 설명하기 위한 도면이다.
도 23은 본 발명의 일 실시예에 따른 암호화 알고리즘이 제1 제품 및 제2 제품에서 실행되는 실행 시간의 실험 결과를 나타내는 도면이다.
도 24는 다양한 프레디킷 구조들을 제1 장치에서 분석적이고 실험적으로 실행한 실행 시간을 나타낸 도면이다.

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

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

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

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

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

이하에서는 첨부된 도면들을 참조하여 본 발명에 따른 사물 인증 시스템 및 사물 인증 방법의 바람직한 실시예에 대해 상세하게 설명한다.

본 발명은 사물 인터넷 장치의 라이프 사이클 동안 전체적인 인증 메커니즘을 제공하기 위한 사물 인증 시스템, 즉 사물 인터넷 장치의 라이프 사이클 동안의 인증 및 접근 제어를 제공하는 한 묶음의 암호화된 프로토콜들을 설명한다.

본 발명의 일 실시예에 의한 사물 인증은 주로 속성 기반 접근 제어(Attribute-Based Access Control, ABAC)를 암호를 사용하여 실행하기 위해 ID 기반 암호화 방식 및 속성 기반 암호화 방식에 의지할 수 있다.

본 발명의 일 실시예에 의한 사물 인증은 원활한 방법으로 새로운 게스트 장치들의 안전한 무선 상호 운용을 보장할 수 있다.

도 1은 본 발명의 일 실시예에 의한 사물 인증 시스템이 적용되는 사물 인터넷 장치의 라이프 사이클을 설명하기 위한 도면이다.

도 1을 참조하면, 사물 인터넷 장치의 라이프 사이클은 사전 배치(Pre-deployment), 주문(Ordering), 배치(Deployment), 작동(Funtioning) 및 폐기(Retirement)로 구성된다.

사물 인증은 다수의 별개 도메인들의 디바이스를 인증하는 것을 의미한다.

사물 인증은 인증된 장치가 다수의 도메인과 연동될 수 있도록 해준다.

구체적으로, 장치는 외부 도메인(예를 들어, 자신의 도메인과 다른 도메인)에 가입(join)할 수 있고, 외부 도메인 안에 장치들의 작업들에 대한 접근을 위해 자신을 스스로 안전하게 인증할 수 있다. 또한, 사물 인증은 장치 소유권의 전송을 안전하게 수행할 수 있게 해준다. 그리고, 사물 인증은 모든 무선 매체에서 인증 및 접근 제어를 수행할 수 있지만 오늘날 널리 배치된 무선 인증 메커니즘(예를 들어, WPA2)보다 더 강력한 보안을 제공한다.

본 발명의 일 실시예에 의한 사물 인증은 ID 기반 암호화 방식(Identity-Based Cryptography)에 의존하여 키들을 분배하고 장치들을 인증할 뿐만 아니라, 속성 기반 암호화 방식(Attribute-Based Crpytography)에 의존하여 속성 기반 접근 제어(Attribute-Based Access Control)을 암호적으로 적용할 수 있다.

상기 암호 시스템들을 선택한 이유는 상기 암호 시스템들이 자유 인증서(certificate-free)이고, 암호 시스템들이 자유 인증서이면 장치들의 오버헤드와 관련된 인증서(certificate-related overheads)를 도입하지 않는다.

인증(Authentication)

인증은 사물 인터넷 내 보안 속성에서 가장 중요하다. 인증의 주된 목표 중 하나는 네트워크 활동들에 참여하는 것으로부터 불법 노드들을 방지하는 것이다. 불법 노드들에 노출되지 않는다면 대부분의 네트워크 작업들을 보호할 수 있다.

인증은 소스 인증 및 데이터 인증으로 구성된다.

상기 소스 인증은 수신자에게 메시지가 진짜 요청된 사용자로부터 발생한 것인지를 보장한다.

상기 데이터 인증은 무결성(integrity) 위반을 막고, 수신된 메시지가 생생(fresh)하다는 것을 보장한다.

인증은 대칭 키 암호화 시스템 또는 비대칭 키 암호화 시스템을 이용하여 성취될 수 있다. 더 정확히 말하면, 인증은 메시지 인증 코드(Message Authentication Codes, MACs) 및 디지털 서명 각각을 사용함으로써 이루어질 수 있다.

사물 인증과 관련된 한 묶음의 프로토콜들에서 인증을 위해 메시지 인증 코드 및 디지털 서명을 활용한다.

속성 기반 접근 제어(Attribute-Based Access Control)

접근 제어는 누가 또는 무엇이 오브젝트(예를 들어, 파일)의 작업(예를 들어, 읽기 또는 쓰기)을 실행하는지를 통제할 수 있다.

전통적인 접근 제어 모델들은 사물 인터넷에서 불편하다. 예를 들어, 강제적인 접근 제어(Mandatory Access Control), 임의의 접근 제어(Discretionary Access Control) 및 역할 기반 접근 제어(Role-Based Access Control)는 사용자 중심적이고, 사용자(예를 들어, 요청자)와 리소스 제공자 간의 관계 및 동적인 정보(예를 들어, 현재 시간 및 사용자 ID)와 같은 요인들을 고려하지 못한다. 또한, 사물 인터넷 배치와 같은 큰 규모의 네트워크에서는 전통적인 접근 제어 모델을 이용해서 누가 무엇에 접근이 허락되는지에 대한 리스트를 유지하는 것이 힘들다.

반면, 속성 기반 접근 제어는 자유 재량에 의한 허가를 속성에 기반한 정책으로 대체함으로써 접근 제어를 간소화한다. 속성 기반 접근 제어 모델은 상황에 맞는 정보 및 자원 특징들과 같은 속성들에 기반하여 사용자들에게 권리를 부여한다. 이는, 단체 내에서 허가가 사용자들의 ID 보다 사용자들의 속성에 따라 할당된다는 것에 기초한 것이다. 속성은 사용자들의 책임 또는 자격 요건에 따라 차례대로 사용자들에게 할당된다. 속성 기반 접근 제어에서 속성의 성질은 접근 구조의 수정 없이 쉽게 바뀔 수 있다. 그리고, 새로운 허가는 새로운 오브젝트에 대한 속성에 편리하게 부여될 수도 있고 작업들이 시스템을 통합시킬 수도 있다.

사물 인증은 사물 인터넷에서 접근 제어를 실행하는 패러다임으로써 속성 기반 접근 제어를 채택할 수 있다.

ID 기반 암호화 방식(Identity-Based Crptography , IBC )

ID 기반 암호화 방식의 개념은 Shamir의 기존 논문이래 계속해서 존재하였다. 하지만, 페어링 기반 암호화 방식의 출현으로 실용적으로 되었다. ID 기반 암호화는 분명한 공개 키 인증을 요구하지 않는다는 장점이 있다. ID 기반 암호화 방식에서 사용자들은 비트(bit)의 랜덤 문자열 보다 중요한 공개 키를 갖는다. 그리고, 상기 공개 키들은 사용자들의 공개 정보에서 유래된다. 상기 공개 정보는 사용자를 그들의 공개 키로 본질적으로 묶고, 디지털 서명과 같은 다른 방법을 통해 사용자를 그들의 공개 키로 묶는 것을 불필요하게 만든다. 마침내, ID 기반 암호화 방식은 사용자와 다른 ID 기반 암호화 방식의 도메인들간의 안전한 통신이 가능하게 한다.

하지만, ID 기반 암호화는 방식에서 개인 키들은 그들 각각의 사용자로부터 생성되어지지 않고 개인 키 생성자들로부터 생성된다. 따라서, 상기 개인 키들은 사실상 비밀로 유지되지 않는다. 그리고, 개인 키 생성자들이 만약 시스템 내에서 어느 사용자인척 가장하길 원하면 그렇게 할 수 있다는 문제점이 있다. 즉, ID 기반 암호화 방식의 암호 키 위탁 문제(key escrow problem)가 발생하게 된다.

ID 기반 암호화 방식에서는 개인 키들은 반드시 안전한 채널을 통해 사용자에게 전달되어야 한다. ID 기반 암호화 방식에서 부트스트랩 안전이 사용된다.

ID 기반 암호화 방식에서 인증을 제공하는 암호화 알고리즘(Cryptographic Primitive)은 ID 기반 서명이다. 사물 인증은 한 묶음의 프로토콜에서 ID 기반 서명을 사용한다.

속성 기반 암호화 방식(Attribute-Based Cryptography)

속성 기반 암호화 방식은 Fuzzy의 ID 기반 암호화 방식으로 잘 알려져 있다. 따라서, 속성 기반 암호화도 암호 키 위탁 문제가 발생한다. ID 기반 암호화 방식과 비교했을 때, 속성 기반 암호화는 개인 사용자의 ID 보다 그룹 사용자들에 포커스를 맞추고 있다. 상기 암호화 방식은 개인 키 소유권을 제어하는 사용자 속성들의 부분 집합에 의존한다.

속성 기반 암호화 스키마들(schemes)은 두가지 분류가 있다. 하나는 키 정책 속성 기반 암호화 방식(Key-Policy Attribute-Based Cryptography, KP)이고 다른 하나는 암호문 정책 속성 기반 암호화 방식(Ciphertext-Policy Attribute-Based Cryptography, CP)이다. 상기 키 정책 속성 기반 암호화 방식에서 상기 정책은 개인 키들에 부착된다. 그리고, 속성들은 메시지들에 주석을 단다. 상기 암호문 정책 속성 기반 암호화는 메시지들이 정책을 옮기고, 사용자들은 그들의 각각의 속성에 대한 키를 소유한다. 상기 키 정책 암호화 방식에서 메시지 전송자는 누가 또는 무엇이 그의 메시지들의 컨텐츠에 대한 접근이 가능한지에 대한 전체적인 제어권을 갖지 못한다. 반면, 상기 암호문 정책 속성 기반 암호화 방식은 상기 제어권이 부여된다.

서명 스키마들의 문맥에서 암호문 정책 속성 기반 암호화 방식은 일반적으로 정책을 지지하는 속성 기반 암호화 서명(Policy-Endorsing Attribute-Based Signature)을 공통적으로 참조한다. 여기서, 사용자들은 속성과 개인 키에 상응하는 것들의 세트를 할당 받는다. 사용자의 메시지 전체적으로 작업들을 실행하는 능력(예를 들어, 메시지에 서명하는 능력)은 사용자와 관련된 속성 세트뿐만 아니라 메시지와 관련된 정책에도 의존한다. 구체적으로, 메시지들은 서명 정책 또는 메시지의 프레디킷(predicate)이라 불리는 속성들의 2진수 표현을 운반한다. 서명을 정확하게 확인하기 위해서, 사용자는 반드시 프레디킷을 만족하는 속성의 부수 세트와 관련된 키를 사용하여 메시지에 서명 해야 한다.

한편, 속성 기반 암호화 방식 및 속성 기반 접근 제어 사이에 시너지 효과가 발생할 수 있다. 한편으로는 속성 기반 암호화 방식과 속성 기반 접근 제어는 사용자 속성들을 기초로 한다는 점에서 유사하다. 하지만, 속성 기반 암호화 방식 및 속성 기반 접근 제어는 서로 상호 보완적이다. 속성 기반 암호화 방식과 속성 기반 접근 제어는 서로 결합되어 있다. 속성 기반 암호화 방식이 속성 기반 접근 제어를 암호적으로 실행한다.

본 발명의 일 실시예에 의하면 사물 인증에서의 접근 제어 메커니즘의 근본적인 암호화 구조로 암호문 정책 속성 기반 암호화 방식을 채택한다.

구체적으로, 사물 인증은 속성 기반 암호화 서명을 가장 빈번한 작업 동안 이용하고, 속성 기반 암호화 방식 프레디킷에서의 속성 기반 접근 제어 정책들을 보여준다.

페어링 기반 암호화 방식(Pairing-Based Cryptography)

페어링 기반 암호화 방식은 현존하는 암호화 프로토콜들을 효율적이고 편리하게 만든다.

겹선형 페어링(bilinear pairing)은 페어링 기반 암호화의 주된 암호화 알고리즘이다. 패어링은 암호 해독의 문맥에서 처음 사용되었다. 하지만, 페어링 기반 암호 시스템은 Saki, Ohgishi 및 kasahara의 논문, Boneh 및 Franklin의 논문 및 Joux의 논문에서 선구적으로 사용되었다.

일반적으로, 겹선형 페어링은 산출 가능하고, 정상적인 함수이다.

상기 정상적인 함수는 다음과 같다.

상기 수학식 1에서 제1 그룹() 및 제2 그룹()은 부가적으로 쓰여진 ID 0에서 n번째 순서(order)의 그룹들이다. 그리고, 상기 제3 그룹()은 곱셈으로 쓰여진 ID 1에서 n번째 순서(order)의 그룹이다.

상기 제1 그룹() 및 상기 제2 그룹()은 타원 곡선들에서 포인트들의 그룹을 사용하여 구현된다. 그리고, 상기 제3 그룹()은 무한으로 팽창하는 필드의 증가하는 서브 그룹을 사용하여 구현된다.

상기 제1 그룹() 및 상기 제2 그룹()이 같을 때 페어링은 대칭이다. 다만, 대칭 패어링 구조는 많이 효율적이지 않다.

페어링 기반 암호화 방식에서 페어링의 중대한 자원은 이선형성(bilinearity)이다.

사물 인증은 페어링 기반 암호화에 매우 의존한다. 예를 들어, 사물 인증은 속성 기반 인증을 실행하고 키를 분배하기 위해 페어링을 사용한다.

이하에서 본 발명의 실시 예에 의한 사물 인증을 설명하기 위해 몇 가지 사항들을 가정한다. 첫째, 모든 메시지는 번호가 매겨져 있고, 담당 기관은 담당 기관의 식별자를 전송한다. 둘째, 암호화를 위해 사용되는 재료(material)는 제조자의 기관의 장치에서 안전하게 불러들여질 수 있다. 셋째, PIN(Personal Identification Number)은 집에 있는 장치에서 안전하게 입력될 수 있다. 넷째, 암호화 알고리즘들(Cryptographic primitives)은 흠이 없는 이상적인 요소이고, 블랙 박스처럼 취급된다.

본 발명의 일 실시예에 의한 사물 인증 시스템은 기존에 존재하는 방법과는 다른 새로운 방법으로 키 분배(key distribution) 및 접근 제어를 수행할 수 있다. 여기서, 상기 키 분배는 보안을 부트스트랩(bootstrap)을 하기 위한 키 분배이고, 상기 접근 제어는 장치의 작업들의 허가를 통제하기 위한 접근 제어이다.

본 발명의 일 실시예에 의한 사물 인증 시스템은 상기 키 분배를 수행하기 위해 ID 기반 암호화 방식(Identity-Based Cryptography, IBC)을 이용할 수 있고, 장치의 작업들에 대한 접근 제어를 위해 속성 기반 암호화 방식(Attribute-Based Cryptography, ABC)을 이용할 수 있다.

한편, ID 기반 암호화의 키 위탁 문제를 해결하기 위해 두 도메인 아키텍쳐(two-domain architecture)를 이용할 수 있다. 이는 도 2를 참조하여 좀더 자세히 설명한다.

도 2는 본 발명의 일 실시예에 의한 사물 인증에서 두 도메인 아키텍쳐를 설명하기 위한 도면이다.

도 2와 같이 2개의 도메인이 존재하는 아키텍쳐를 이용하면 암호 키 위탁 문제를 해결할 수 있다.

더 정확히 말하면, 서로 다른 두 개의 ID 기반 암호화 방식 셋업들(setups)을 이용하여 상기 암호 키 위탁 문제를 해결할 수 있다. 여기서, 상기 서로 다른 두 개의 ID 기반 암호화 셋업은 제조자(Cloud) 셋업 및 로컬(Home) 셋업일 수 있다.

상기 제조자 셋업은 제조자와 장치 간의 신뢰할 수 있는 관계라고 정의할 수 있다. 그리고, 상기 로컬 셋업은 장치와 장치 간의 신뢰할 수 있는 관계라고 정의할 수 있다. 즉, 상기 제조자 셋업에서는 제조자와 장치 간의 신뢰할 수 있는 관계가 형성될 수 있고, 상기 로컬 셋업에서는 장치와 장치 간의 신뢰할 수 있는 관계가 형성될 수 있다.

여기서, 상기 신뢰할 수 있는 관계는 서로 중복되지 않는다. 구체적으로, 클라우드 도메인 내에서 생성된 가공품은 홈 도메인에서 효력이 없고 그 역도 마찬가지가 된다. 다만, 상기 제조자 셋업에서 제조자와 장치 간의 암호 키 위탁이 여전히 유지될 수 있고, 상기 로컬 셋업에서도 장치와 장치간의 암호 키 위탁이 여전히 유지될 수 있다.

하지만, 상기 2개의 도메인 아키텍쳐에서는 더 이상 종전과 같은 암호 키 위탁 문제가 발생하지 않는다.

구체적으로, 클라우드의 ID 기반 암호화 키들의 위탁 중에 클라우드 도메인에서 발생한 요청은 홈 도메인에서는 무효가 되어 사용자들의 프라이버시가 보존될 수 있기 때문이다. 또한, 집의 ID 기반 암호화 방식 및 속성 기반 암호화 방식의 키들의 위탁은 집 주인 및 집의 멤버들이 소유하고 관리하는 홈 디바이스에서 유지된다. 따라서 위탁은 신뢰할 수 있게 된다.

본 발명의 일 실시예에 따른 사물 인증의 한 묶음의 프로토콜들은 전체적인 무선 매체에서 암호로 인증 및 접근 제어를 제공한다.

본 발명의 일 실시예에 의한 사물 인증 시스템에서의 주요 특징 중 하나는 케이블 연결에 의존함이 없이 장치를 배치할 수 있다는 능력이다. 사물 인증은 집의 물리적 보호 및 믿을 수 있는 장치(예를 들어, 홈 도메인 관리자의 스마트 폰)를 새로운 장치와 홈 서버 사이 간의 보안을 부트스트랩하기 위한 최초 통신을 연결하기 위해 활용할 수 있다.

본 발명의 일 실시예에 의한 사물 인증은 속성 기반 접근 제어 및 속성 기반 암호화 방식을 혼합함으로써 접근 제어를 수행할 수 있다. 구체적으로, 속성 기반 접근 제어는 암호적으로 속성 기반 암호화 방식을 실행할 수 있다.

여기서, 장치를 작동시키는 것에 대한 허가는 속성 기반 암호화에서의 요청자의 속성들과 연관이 있다. 그리고, 속성 기반 암호화 방식에서의 속성 및 프레디킷(predicate)들은 좀더 높은 레벨의 속성 기반 접근 제어 정책에 의해 좌우된다.

한편, 본 발명의 일 실시예에 의한 사물 인증 시스템은 추가적인 특징을 가질 수 있다. 예를 들어, 사물 인증은 다른 홈 도메인들에 있는 장치들 사이에 인터도메인 상호 작용(interdomain interaction)을 가능하게 할 수 있다. 여기서, 상기 다른 홈 도메인에 있는 장치들은 그들 각각의 홈 서버가 이전 파라미터들을 허용하는 동안 다른 홈 도메인에서 균일하게 상호 작용을 수행할 수 있다.

본 발명의 일 실시예에 의한 사물 인증에서 한 묶음의 프로토콜들은 장치를 재할당하거나 사용자들이 장치를 거래하는 것을 가능하게 하거나 하나 또는 그 이상의 장치들을 나누어 주는 것을 가능하게 한다. 이는 후술할 키 폐기에서 달성될 수 있다.

보조 절차(Auxiliary Procedure) 및 보조 프로토콜(Auxiliary Protocols)

본 발명의 일 실시예에 의한 사물 인증에서 사용되는 보조 절차 및 보조 프로토콜은 사물 인증에서 사용되는 메인 프로토콜을 도울 수 있다.

일례로, 사물 인증 시스템에서 사용되는 보조 절차 및 보조 프로토콜 중 적어도 하나는 메인 프로토콜이 세션 키(Session key)를 얻는 것을 도울 수 있다.

다른 일례로, 사물 인증 시스템에서 사용되는 보조 절차 및 보조 프로토콜 중 적어도 하나는 메인 프로토콜이 공통되는 쌍대 키를 교환하는 것을 도울 수 있다.

또 다른 일례로, 사물 인증 시스템에서 사용되는 보조 절차 및 보조 프로토콜 중 적어도 하나는 메인 프로토콜이 개인 키(private key)를 배포하는 것을 도울 수 있다. 여기서, 상기 개인 키는 속성 기반 인증 키이다.

또 다른 일례로, 사물 인증 시스템에서 사용되는 보조 절차 및 보조 프로토콜 중 적어도 하나는 메인 프로토콜이 클라우드 도메인에서 장치를 사용자에 바인딩하거나 언바인딩하는 것을 도울 수 있다. 여기서, 상기 바인딩이라 함은 묶는 것을 의미할 수 있고, 상기 언바인딩이라 함은 묶는 것을 해제하는 것을 의미할 수 있다. 예를 들어, 장치를 사용자에게 바인딩한다는 것은 장치와 상기 사용자가 하나로 묶이는 것을 의미할 수 있고, 장치를 사용자에게 언바인딩한다는 것은 장치와 상기 사용자가 하나로 묶인 것이 해제되는 것을 의미할 수 있다.

여기서, 상기 보조 절차에는 세션 키 절차(Session Key procedure)가 포함될 수 있고, 상기 보조 프로토콜에는 키 합의 프로토콜(Key Agreement protocol), 키 발행 프로토콜(Key Issue protocol), 바인딩 프로토콜(Binding protocol), 언바인딩 프로토콜(Unbinding protocol)이 포함될 수 있다. 이하에서는, 도 3 내지 도 6를 참조하여 상기 보조 절차 및 상기 보조 프로토콜에 대해 설명하도록 한다.

속성 기반 암호화 방식에서 다수의 장치들은 같은 속성 기반 인증 키를 가질 수 있다. 그러므로, 속성 기반 인증 키들은 종종 개인 키들 보다 서명된 키들로서 참조된다. 하지만, 이하에서는 설명의 편의를 위해 속성 기반 인증 키들을 개인 키라고 명한다.

도 3은 본 발명의 일 실시예에 따른 보조 절차인 세션 키 절차의 일례를 설명하기 위한 도면이다.

본 발명의 일 실시예에 의한 세션 키(Session key)라 함은 통신을 하는 상대방끼리 하나의 통신 세션 동안에만 사용하는 암호화 키를 의미한다.

본 발명의 일 실시예에 의한 사물 인증 시스템에서 이용되는 보조 절차인 세션 키 절차에서는 난수 작업(PRF()), 이전에 공유된 키(K) 및 현재 카운터(i)가 가장 최신 상태의 세션 키를 유지하는데 있어서 매우 중요하다.

본 발명의 일 실시예에 의한 세션 키 절차는 Perrig 논문에 기초한다.

세션 키 절차에 대해 좀더 구체적으로 살펴보면 다음과 같다.

본 발명의 일 실시예에 의한 세션 키 절차에서 현재 카운터(i)에 해당하는 세션 키()는 상기 이전에 공유된 키(k)를 이용하여 현재 카운터(i)에서 난수 작업을 수행함으로써 얻을 수 있다(step 1).

한편, 현재 카운터에 대응하는 세션 키()를 얻은 경우, 상기 현재 카운터(i)를 1 증가시킬 수 있다(step 2).

상기 현재 카운터(i)가 1 증가한 경우, 1 증가한 현재 카운터(i)를 이용하여 step 1의 작업을 다시 수행할 수 있다.

즉, 본 발명의 일 실시예에 따른 세션 키 절차에 따르면 카운터가 하나씩 증가함에 따라 각 카운터에 대응하는 세션 키가 난수 작업을 통해 생성될 수 있다.

도 4는 본 발명의 일 실시예에 따른 보조 프로토콜인 키 합의 프로토콜의 일례를 설명하기 위한 도면이다.

본 발명의 일 실시예에 의한 키 합의는 세션 키의 전송자 및 수신자가 직접 만나지 않고도 공개된 통신 채널을 통해 특정한 방법으로 세션 키를 안전하게 공유하는 방식을 의미한다.

본 발명의 일 실시예에 의한 키 합의는 Sakai, Ohgishi 및 Kasahara의 논문에 기초한다.

본 발명의 일 실시예에 의한 키 합의 프로토콜은 같은 홈 도메인()에 존재하는 두 장치 사이에서 실행된다. 이하에서는, 동일한 홈 도메인()에 제1 장치(A) 및 제2 장치(B)가 존재한다고 가정하고 이하 설명한다.

본 발명의 일 실시예에 의한 키 합의 프로토콜은 제1 장치(A) 및 제2 장치(B) 간의 쌍대 키(pairwise key)를 산출하기 위한 페어링 및 독특한 세션 키들을 생성하기 위한 카운터를 활용할 수 있다.

본 발명의 일 실시예에 의한 키 합의 포로토콜은 상기 제1 장치(A) 및 상기 제2 장치(B) 간의 시도 응답 메시지 교환을 실행할 수 있다(step 1, 6 and 8).

본 발명의 일 실시예에 의한 키 합의 프로토콜은 신선함(freshness)을 보장하기 위해 다른 사물 인증 프로토콜과의 이런 종류의 시도 응답 메시지 교환을 재생산 할 수 있고, 재전송 공격을 막을 수 있다.

본 발명의 일 실시예에 의한 키 합의 프로토콜을 좀더 자세히 살펴보면 다음 과 같다.

먼저, 본 발명의 일 실시예에 의한 키 합의 프로토콜에서 제1 장치(A)는 제1 장치(A)에서 생성된 제1 임의 비표(nounce, ) 및 세션 요청(session_req)을 제2 장치(B)로 전송할 수 있다(step 1).

제2 장치(B)는 상기 홈 도메인에서의 제1 장치의 공개 키()를 획득할 수 있다. 여기서, 상기 공개 키()는 ID 기반 암호화 시스템에서의 공개 키이다. 구체적으로, 제2 장치는 상기 홈 도메인안에서의 제1 장치의 아이디()를 맵핑함으로써 상기 공개 키()를 획득할 수 있다(step 2).

제2 장치(B)는 제1 장치(A) 및 제2 장치(B)가 서로 공유하는 제1 쌍대 키(pairwise key, )를 획득할 수 있다.

구체적으로, 상기 제1 쌍대 키()는 상기 홈 도메인안에서 제2 장치의 개인 키()와 상기 공개 키()를 암호 친화적인 쌍일차식 페어링(bilinear pairing)을 수행함으로써 획득할 수 있다(step 3). 여기서, 상기 개인 키()는 ID 기반 암호화 시스템에서의 개인 키이다.

제2 장치(B)는 상기 카운터()를 0으로 설정할 수 있다(step 4).

제2 장치(B)는 제1 장치 및 제2 장치간 상기 카운터()에 대응하는 i번째 세션에서 서로 공유되는 제2 쌍대 키()를 획득할 수 있다.

구체적으로, 제2 장치(B)는 도 3에서 상술한 세션 키 절차에서 상기 제1 쌍대 키() 및 상기 카운터()를 이용하여 상기 제2 쌍대 키()를 획득할 수 있다(step 5). 즉, 제2 장치(B)는 상기 제1 쌍대 키()를 이용하여 상기 카운터()에서의 난수 작업을 수행함으로써 상기 제2 쌍대 키()를 획득할 수 있다.

예를 들어, 상기 카운터()가 0으로 설정되어 있으므로, 제2 장치(B)는 상기 제1 쌍대 키()를 이용하여 카운터 0에서의 난수 작업을 수행함으로써 0번째 세션에서 제1 장치(A) 및 제2 장치(B)간 쌍대 키를 획득할 수 있다.

한편, 제2 장치(B)는, 상기 제2 쌍대 키()를 사용하여 상기 제1 임의 비표()가 첨부된 메시지의 제1 메시지 인증 코드를 제1 장치(A)에 전송할 수 있다. 그리고, 제2 장치(B)는 제2 장치에서 생성된 제2 임의 비표도 제1 장치(A)에 전송할 수 있다(step 6).

한편, 제1 장치(A)는 상기 제2 쌍대 키()를 유사하게 산출할 수 있다(step 7).

제1 장치(A)는 상기 제1 임의 비표 및 상기 제2 임의 비표를 연접(concatenation)하여 특정 값을 생성할 수 있다. 그리고, 제1 장치(A)는 제2 메시지 인증 코드를 제2 장치(B)에 전송할 수 있다. 여기서, 상기 제2 메시지 인증 코드는, 상기 유사하게 산출된 제2 쌍대 키()를 사용하여 상기 특정 값이 첨부된 메시지의 메시지 인증 코드일 수 있다(step 8).

제2 장치(B)는 상기 세션 요청(session_req)에 대응하는 세션 응답(session_ack)을 제1 장치(A)에 전송할 수 있다. 또한, 제2 장치(B)는 제3 메시지 인증 코드를 제1 장치(A)에 전송할 수 있다. 여기서, 상기 제3 메시지 인증 코드는, 상기 제2 쌍대 키()를 사용하여 상기 제1 임의 비표에 1을 추가한 값이 첨부된 메시지의 메시지 인증 코드일 수 있다(step 9).

도 5는 본 발명의 일 실시예에 따른 보조 프로토콜인 키 발행 프로토콜의 일례를 설명하기 위한 도면이다.

본 발명의 일 실시예에 의하면, 키 발행(KeyIssue)은 암호 시스템(Y), 도메인(z) 및 서버(s)에 있는 장치(D)를 위한 개인 키를 발행한다. 키 발행은 이전에 장치(D)와 서버(S) 사이에 공유되었던 쌍대 키로부터 얻어진 세션 키를 사용하여 보호된다.

본 발명의 일 실시예에 의한 키 발행을 좀더 자세히 살펴보면 다음과 같다.

장치(D)는 제1 임의 비표()를 생성할 수 있다. 장치(D)는 서버(S)에 상기 제1 임의 비표() 및 키 발행 요청(issue_req)을 전송할 수 있다(step 1).

서버(S)는 제1 메시지 인증 코드를 장치(D)에 전송할 수 있다. 여기서, 상기 제1 메시지 인증 코드는, 장치(D)와 서버(S)간에 i번째 세션에서 서로 공유되는 쌍대 키()를 이용하여 상기 제1 임의 비표()가 첨부된 메시지의 메시지 인증 코드일 수 있다. 그리고, 서버(S)는 서버(S)에서 생성된 제2 임의 비표()도 장치(D)에 전송할 수 있다(step 2).

장치(D)는 상기 제1 임의 비표 및 상기 제2 임의 비표를 연접(concatenation)하여 특정 값을 생성할 수 있다. 그리고, 장치(D)는 제2 메시지 인증 코드를 서버(S)에 전송할 수 있다(step 3). 여기서, 상기 제2 메시지 인증 코드는, 상기 쌍대 키()를 이용하여 상기 특정 값이 첨부된 메시지의 메시지 인증 코드일 수 있다.

서버(S)는 상기 도메인(Z)안에서 장치(D)의 개인 키()를 상기 쌍대 키()를 이용하여 암호화된 특정 값을 생성할 수 있다. 여기서, 상기 개인 키()는 상기 암호화 방식(Y)의 개인 키이다. 그리고, 서버(S)는 제3 메시지 인증 코드를 장치(D)에 전송할 수 있다여기서, 상기 제3 메시지 인증 코드는 상기 제1 임의 비표()에 1을 더한 값을 상기 쌍대 키()를 이용하여 첨부한 메시지의 메시지 인증 코드일 수 있다. 또한, 서버(S)는 상기 암호화된 특정 값 및 발행 요청에 대응하는 답변(issue_ack)도 장치(D)에 전송할 수 있다(step 4).

도 6은 본 발명의 일 실시예에 따른 보조 프로토콜인 바인딩 프로토콜의 일례를 설명하기 위한 도면이다.

본 발명에 일 실시예에 의한 바인딩(Binding)은 클라우드 도메인에서 사용자(U)를 장치(D)에 묶을 수 있다. 간단히 말해서, 장치(D)는 장치(D)가 사용자(U)에게 묶이도록 클라우드 서버(C)에게 요청할 수 있다. 클라우드 서버(C)부터 장치(D)까지의 통신은 메시지 인증 코드들을 사용함으로써 안전이 보증된다(step 2 and 5).

역으로, 장치(D)는 장치(D) 스스로가 클라우드 서버(C)에서 인증되도록 ID 기반 암호화 방식의 디지털 서명들을 이용한다.

본 발명의 일 실시예에 따른 바인딩 프로토콜을 좀더 구체적으로 살펴보면 다음과 같다.

장치(D)는 제1 임의 비표()를 생성할 수 있다. 그리고, 장치(D)는 상기 제1 임의 비표() 및 바인딩 요청을 클라우드 서버(C)에 전송할 수 있다(step 1).

클라우드 서버(C)는 제2 임의 비표()를 생성할 수 있다. 클라우드 서버(C)는 제1 메시지 인증 코드 및 상기 제2 임의 비표()를 장치(D)에 전송할 수 있다. 여기서, 상기 제1 메시지 인증 코드는 클라우드 서버(C)와 장치(D) 사이의 i번째 세션에서 서로 공유되는 쌍대 키()를 이용하여 상기 제1 임의 비표()가 첨부된 메시지의 메시지 인증 코드일 수 있다(step 2).

장치(D)는 상기 제1 임의 비표() 및 상기 제2 임의 비표()를 연접(concatenation)하여 특정 값을 생성할 수 있다. 그리고, 장치(D)는 클라우드 서버(C)안에서 장치(D)의 개인 키()를 이용하여 상기 특정 값이 첨부된 메시지의 서명, 클라우드 서버(C)에서 사용자의 아이디() 및 바인드 명령을 클라우드 서버(C)에 전송할 수 있다(step 3). 여기서, 상기 개인 키()는 ID 기반 암호화 시스템(I)에서의 개인 키이다.

클라우드 서버(C)는 장치(D)에 상기 사용자(U)를 묶을 수 있다(step 4).

그리고, 클라우드 서버(C)는 바인딩 요청에 대응하는 바인딩 답변(bind_ack) 및 제2 메시지 인증 코드를 장치(D)에 전송할 수 있다. 여기서, 상기 제2 메시지 인증 코드는 상기 제1 임의 비표()에 1을 더한 값을 상기 쌍대 키()를 이용하여 첨부된 메시지의 메시지 인증 코드일 수 있다(step 5).

한편, 본 발명의 일 실시예에 의한 사물 인증 시스템에 사용되는 프로토콜인 언바인딩 프로토콜은 바인딩 프로토콜과 유사한 단계로 실행된다. 언바인딩 프로토콜은 상기 사용자(U)와 장치(D)가 묶인 것을 해제한다는 것만 상기 바인딩 프로토콜과 다르다.

한편, 사물 인터넷 장치의 라이프 사이클은, 사전 배치(Pre-deployment) 단계, 주문(Ordering) 단계, 배치(Deployment) 단계, 작동(Functioning) 단계 및 폐기(Retirement) 단계를 적어도 포함한다.

사전 배치(Pre-deployment)

본 발명의 일 실시예에 의하면, 사전 배치는 주로 공장에서 이루어진다. 사전 배치에 이용되는 메인 프로토콜에 대해서는 도 7을 참조하여 좀더 자세히 살펴본다.

도 7은 본 발명의 일 실시예에 따라 사전 배치 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.

사전 배치 단계에서는 장치들이 클라우드 도메인의 암호화 재료(Cryptographic material)를 로드한다.

사전 배치 단계에서 클라우드 서버(C)는 클라우드 서버(C) 내에서 장치(D)의 아이디()를 생성한다(step 1). 구체적으로, 상기 아이디()는 장치의 시리얼 넘버일 수 있다.

클라우드 서버(C)는 클라우드 서버(C) 안에서 장치(D)의 개인 키()를 얻는다. 여기서, 상기 개인 키()는 ID 기반 암호화 시스템에서의 개인 키이다(step 2). 구체적으로, 상기 개인 키()는 상기 아이디()를 맵핑(MAP())한 결과와 클라우드 서버(C) 도메인에서의 암호화 체계인 ID 기반 암호화 시스템(I)에서의 비밀 파라미터(secret parameter)를 이용하여 생성될 수 있다.

클라우드 서버(C)는 클라우드 서버(C)와 장치(D)사이에서 서로 공유되는 쌍대 키()를 생성할 수 있다. 클라우드 서버(C)는 카운터()를 생성하고 카운터를 0으로 설정할 수 있다. 그리고, 클라우드 서버(C)는 남아있는 암호화 재료와 협력하여 상기 생성된 쌍대 키(), 상기 카운터(), 상기 아이디() 및 상기 개인 키()를 장치(D)에 로드할 수 있다(step 3). 여기서, 상기 로드는 물리적 채널(physical channel)에 의해 보호될 수 있고, 통신은 기밀성과 인증이 보장될 수 있다.

마지막으로, 클라우드 서버(C)는 상기 개인 키()를 삭제한다. 그리고, 클라우드 서버(C)는 장치(D)를 장치(D)의 거래자(T_D)에게 안전하게 운송할 수 있다(step 4). 즉, 장치(D)의 제조자는 거래자(T_D)에게 안전하게 장치(D)를 운송하여 줄 수 있다.

사전 배치 단계에 대해 좀더 간략히 설명하면 다음과 같다.

사전 배치 단계에서 장치(D)는 클라우드 서버(C)의 암호화 재료를 클라우드 서버로부터 로드할 수 있다. 그리고, 클라우드 서버(C)는 장치(D)가 거래자에게 운송된 경우 상기 암호화 재료 중 상기 클라우드 서버(C) 내에서 상기 암호화 재료 중 상기 개인 키()를 상기 클라우드 서버에서 삭제할 수 있다.

주문(Ordering)

주문은 사용자(U)가 장치(D)를 거래자(T_d)로부터 주문하는 단계이다. 이는 도 8을 참조하여 좀더 자세히 설명한다.

도 8은 본 발명의 일 실시예에 따라 주문 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.

본 발명의 일 실시예에 의하면 모든 디지털 통신은 전송 계층 보안(Transport Layer Security, TLS)을 통해 보호된다.

사용자(U)는 장치(D)를 주문하고, 장치(D)에 대한 돈을 지불할 수 있다(step 1).

거래자(T_d)는, 단계(S710)에서 사용자(U)로부터 주문 요청 및 돈의 지불을 받은 경우, 사용자(U)에게 PIN(Personal Identification Number)을 전송할 수 있다(step 2).

거래자(T_d)는 상기 사용자가 주문한 장치(D)를 사용자(U)의 집으로 운송할 수 있다(step 3).

PIN()은 사물 인터넷 장치의 배치 단계에서 장치에 대한 접근을 부여하기 위해 사용된다. 이는 도 9를 참조하여 좀더 자세히 살펴본다.

배치(Deployment)

배치는 홈 도메인들에서 장치들의 안전을 부트스트랩할 수 있다. 사물 인증에서 가장 중요한 단계는 배치 단계이다. 이에 대해 도 9를 참조하여 좀더 자세히 설명한다.

도 9는 본 발명의 일 실시예에 따라 배치 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.

배치 단계에서 루트 사용자()와 루트 사용자의 개인 장치()가 가장 중요한 역할을 수행한다. 구체적으로, 루트 사용자의 개인 장치()는 홈 서버와 상기 홈 서버에 배치된 장치간에 신뢰할 수 있는 다리 역할을 수행한다.

본 발명의 일 실시예에 의한 사물 인증 시스템은 새로운 장치(D)를 셋업하기 위해 루트 사용자()는 상기 장치(D)의 PIN()을 상기 장치(D) 자체에 입력할 수 있다(step 1).

루트 사용자의 개인 장치()는 홈 도메인()에서 루트 사용자의 제1 아이디(), 홈 도메인()에서 홈 서버(H)의 공개 키() 및 홈 도메인에 포함된 장치들의 카운터()를 상기 장치(D)에 전송할 수 있다(step 2). 여기서, 상기 공개 키()는 ID 기반 암호화 시스템의 공개 키이고, 상기 카운트()는 홈 서버(H)로부터 생성된 브로드캐스트의 생생함(freshness)을 제공할 수 있다.

한편, 상기 장치(D)는 매우 짧은 기간 동안에만 유효한 상기 장치(D)와 상기 홈 서버(H)간 공유하는 제1 쌍대 키()를 생성할 수 있다. 여기서, 상기 장치(D)는 상기 공개 키()를 이용하여 상기 제1 쌍대 키()를 암호화할 수 있다. 그리고, 상기 장치(D)는 루트 사용자의 개인 장치()에 상기 암호화된 제1 쌍대 키()의 암호문을 전송할 수 있다(step 3).

구체적으로, 상기 장치(D)는 상기 제1 쌍대 키의 암호문(), 상기 홈 도메인()에서 상기 장치(D)의 제2 아이디() 및 상기 장치(D)의 타입과 상기 장치(D)에서 지원되는 작업들에 대한 정보()를 상기 루트 사용자의 장치()에 전송할 수 있다.

한편, 상기 루트 사용자()는 장치(D)의 속성()과 장치의 프레디킷()을 설정하기 위해 상기 루트 사용자의 개인 장치()를 이용할 수 있다(step 4). 여기서, 상기 속성() 및 상기 프레디킷()은 장치(D)에서 작업들을 실행하기 위해 만족되어야 하는 것들이다.

step 1 내지 step 4에서 사용되는 통신은 특정 채널을 통해 이루어진다. 여기서, 상기 특정 채널은 안전할 뿐만 아니라 장치(D)를 배치하기에 적합하다.

본 발명의 일 실시예에 의한 배치 프로토콜은 닫힌 공간(예를 들어, 장치의 집과 같은 공간)에서 실행되기 때문에, 전송 메커니즘(예를 들어, QR 코드들을 스캔하는 것)은 안전하게 데이터를 교환하기 위해 조심스럽게 사용되야 한다.

본 발명의 일 실시예에 의한 배치 프로토콜은 캐이블 연결에 의지하거나 홈 서버에 가까운 물리적 장치에 요청하지 않고 부피가 큰 장치(예를 들어, 냉장고)를 셋업하는 것을 허용할 수 있다.

상기 배치 프로토콜은 루트 사용자의 개인 장치()가 홈 서버(H)에 장치(D)의 배치를 요청하면서 진행된다.

구체적으로, 루트 사용자의 개인 장치()는 상기 루트 사용자의 개인 장치에서 생성된 제1 임의 비표() 및 배치 요청(deploy_req)을 홈 서버(H)에 전송할 수 있다(step 5). 루트 사용자의 개인 장치()가 상기 배치 요청(deploy_req)을 홈 서버(H)에 전송하면서 상기 배치 프로토콜이 계속 진행될 수 있다.

홈 서버(H)는 루트 사용자의 개인 장치() 및 홈 서버(H)간 i번째 세션에서 서로 공유되는 제2 쌍대 키()를 생성할 수 있다. 그리고, 상기 홈 서버(H)는 상기 홈 서버에서 생성된 제2 임의 비표() 및 제1 메시지 인증 코드를 상기 루트 사용자의 개인 장치()에 전송할 수 있다. 여기서, 상기 제1 메시지 인증 코드는 상기 제2 쌍대 키()를 사용하여 상기 제1 임의 비표()가 첨부된 메시지의 메시지 인증 코드일 수 있다(step 6).

루트 사용자의 개인 장치()는 홈 서버에 장치(D) 및 루트 사용자()로부터 수신된 정보를 전송할 수 있다(step 7). 이 단계에서 루트 사용자의 개인 장치()는 새로운 장치인 상기 장치(D)와 홈 서버 사이의 인증 다리로서의 역할을 수행한다. 특히, 루트 사용자의 개인 장치()는 암호화를 수행하고, 최근에 생성된 홈 서버(D)와 장치(D)간의 쌍대 키를 눈먼 사인(blindly sings)할 수 있다. 마침내, 루트 사용자의 개인 장치()는 암호문 결과를 홈 서버에 전송할 수 있다(step 5-7).

좀더 구체적으로 살펴보면, 상기 루트 사용자의 개인 장치()는 상기 제1 임의 비표() 및 상기 제2 임의 비표()를 연접(concatenation)하여 특정 값을 생성할 수 있다. 그리고, 상기 루트 사용자의 개인 장치()는 상기 홈 도메인()안에서 상기 루트 사용자의 개인 장치()의 제1 개인 키()를 이용하여 상기 특정 값이 첨부된 메시지의 서명()을 생성할 수 있다. 여기서, 상기 제1 개인 키()는 ID 기반 암호화 시스템(I)에서의 개인키 이다. 그리고, 상기 루트 사용자의 개인 장치()는 배치 명령(deploy), 상기 제2 아이디(), 상기 속성(), 상기 프레디킷(), 상기 정보(), 상기 암호문() 및 상기 서명()을 홈 서버(H)에 전송할 수 있다. 즉, 루트 사용자의 개인 장치()는 새로운 장치와 루트 유저로부터 수신된 정보를 홈 서버(H)에 전송할 수 있다.

비록, 장치(D)는 상기 루트 사용자의 개인 장치()에 의존하여 통신을 수행하기는 하지만, 장치(D)는 상기 루트 사용자의 개인 장치()를 신뢰하지 않기 때문에 암호화된 재료를 서로 교환한다.

한편, 홈 서버(H)는 step 8부터 step 11까지에서 ID 기반 암호화 시스템의 개인 키 및 속성 기반 암호화 시스템의 개인 키를 장치(D)에 발행(issue)할 수 있다. 여기서, 상기 발행은 상기 제1 쌍대 키()를 안전하게 사용할 수 있다. 좀더 구체적으로 살펴보면 다음과 같다.

홈 서버(H)는 홈 도메인()에서 사용자의 장치()의 제2 개인 키()를 획득할 수 있다. 여기서, 상기 제2 개인 키()는 ID 기반 암호화 시스템의 개인 키이다. 구체적으로, 상기 제2 개인 키()는 상기 홈 도메인()에서 상기 사용자의 장치()의 제3 아이디()를 맵핑(MAP())한 결과와 홈 도메인()에서의 ID 기반 암호화 시스템(I)의 비밀 파라미터(secret parameter)를 이용하여 생성될 수 있다(step 8).

홈 서버(H)는 홈 도메인()에서 상기 사용자의 장치()의 제3 개인 키()를 획득할 수 있다. 여기서, 상기 제3 개인 키()는 속성 기반 암호화 시스템(A)의 개인 키이다. 구체적으로, 상기 제3 개인 키()는 상기 사용자의 장치()의 속성()을 맵핑(MAP())한 결과와 홈 도메인()에서의 속성 기반 암호화 시스템(A)의 비밀 파라미터(secret parameter)를 이용하여 생성될 수 있다(step 9).

한편, 상기 장치(D)가 도 5의 키 발행 프로토콜(KeyIssue protocol)을 이용하여 ID 기반 암호화 시스템(I)에서의 키 발행을 수행할 수 있다. 여기서, 도 5의 서버(S)는 상기 홈 서버(H)에 대응되고, 도메인(Z)는 상기 홈 도메인()에 대응되고, 암호화 방식(Y)은 상기 ID 기반 암호화 시스템(I)에 대응될 수 있다(step 10).

한편, 상기 장치(D)는 도 5의 키 발행 프로토콜을 이용하여 속성 기반 암호화 시스템(A)에서의 키 발행을 수행할 수도 있다. 여기서, 도 5의 서버(S)는 상기 홈 서버(H)에 대응되고, 도메인(Z)는 상기 홈 도메인()에 대응되고, 암호화 방식(Y)은 상기 속성 기반 암호화 시스템(A)에 대응될 수 있다(step 11).

한편, 홈 서버(H)는 상기 장치(D)를 포함하는 홈 서버 내의 모든 장치들에게 상기 홈 서버 내의 모든 장치들 각각의 속성 및 프레디킷을 포함하는 정보를 브로드캐스트(broadcast)할 수 있다(step 12). 여기서, 상기 장치(D)는 홈 도메인의 Wi-Fi 라우터를 통하여 인터넷에 대한 접근이 허여될 수 있다.

구체적으로, 홈 서버(H)는 홈 서버를 구성하는 장치들의 프레디킷(), 홈 서버를 구성하는 장치들의 타입과 상기 장치들에서 지원되는 작업들에 대한 정보(), 상기 카운터() 및 홈 도메인 내에서 홈 서버의 제4 개인 키()를 이용하여 인식된 메시지의 서명()을 홈 서버에 포함된 장치들()에게 브로드캐스트 전송(broadcast transmission)할 수 있다. 여기서, 상기 제4 개인 키()는 ID 기반 암호화 시스템의 개인 키이다.

한편, 장치(D)는 상기 루트 사용자()를 상기 장치(D)에 스스로 바인딩할 수 있다(step 13). 여기서, 장치(D)는 홈 가전 또는 공유된 장치라고 가정하면, 장치(D)는 상기 루트 사용자()와 묶일 수 있다. 여기서, 상기 바인딩은 도 6에서 상술한 바인딩 프로토콜을 통해 이루어질 수 있다. 즉, 도 6의 장치는 상기 장치(D)에 대응되고, 사용자는 상기 루트 사용자()에 대응될 수 있다.

한편, 상기 홈 서버(H)는 배치 요청에 대응하는 배치 답변(deploy_ack) 및 제2 메시지 인증 코드를 상기 루트 사용자의 개인 장치()에 전송할 수 있다. 여기서, 상기 제2 메시지 인증 코드는 상기 제1 임의 비표()에 1을 더한 값이 상기 제2 쌍대 키()를 사용하여 첨부된 메시지의 메시지 인증 코드일 수 있다(step 14).

본 실시예에 의하면 루트 사용자의 개인 장치()는 배치 단계의 전체 프로세스에서 매우 중요한 역할을 수행한다. 따라서, 루트 사용자의 개인 장치()는 안전한 채널을 이용하여 홈 서버(H)에 배치되어야 한다. 따라서, 루트 사용자의 개인 장치()는 USB와 같은 케이블 연결을 이용하여 서버에 연결되어 배치되어야 한다. 이 절차는 단 한번 이루어질 수 있다.

배치 단계에 대해 좀더 간략히 설명하면 다음과 같다.

장치(D)가 상기 장치의 PIN을 입력 받은 경우, 장치(D)는 상기 제1 아이디(), 상기 공개 키() 및 상기 카운터들()을 루트 사용자의 개인 장치()로부터 수신할 수 있다. 장치(D)는 기 설정된 기간 동안 유효한 상기 제1 쌍대 키()를 생성하고, 상기 제1 쌍대 키()를 상기 공개 키()를 이용하여 암호화하고, 상기 암호화된 제1 쌍대 키의 암호문()을 루트 사용자의 개인 장치()에 전송할 수 있다. 루트 사용자의 개인 장치()는 장치(D)의 속성() 및 장치(D)의 프레디킷()에 대한 제1 정보를 사용자로부터 입력 받고, 장치(D)의 배치 명령, 상기 제1 정보 및 상기 암호문()을 홈 서버(H)에 전송할 수 있다. 홈 서버(H)는 상기 제2 개인 키() 및 상기 제3 개인 키()를 장치(D)에 발행할 수 있다. 그리고, 홈 서버(H)는 홈 도메인에 통신이 연결된 복수 개의 장치들 및 장치(D)의 속성 및 프레디킷을 포함하는 제2 정보를 상기 장치(D) 및 상기 복수 개의 장치에 브로드캐스트할 수 있다. 여기서, 장치(D)는 상기 제2 정보를 수신한 후에 상기 루트 사용자를 장치(D)에 바인딩할 수 있다.

작동(Functioning)

본 발명의 일 실시예에 따른 사물 인증 시스템은 작동 단계에서 장치들의 보통 작업을 지배할 수 있다. 이는 도 10을 참조하여 좀더 자세히 설명한다.

도 10은 본 발명의 일 실시예에 따른 작동 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다.

프로토콜 내에서, 사용자(U)는 제1 장치(A)를 이용하여 제2 장치(B)에서 특정 작업을 수행하도록 요청할 수 있다(step 1). 예를 들어, 사용자(U)는 스마트 냉장고의 내부 카메라로 촬영된 영상을 자신의 스마트 폰을 이용하여 보기 위한 요청을 자신의 스마트 폰에 입력할 수 있다.

제1 장치(A)는 상기 사용자(U)의 요청에 따라 제1 장치에서 생성된 제1 임의 비표() 및 상기 특정 작업의 요청(op_req)을 제2 장치(B)에 전송할 수 있다(step 2).

한편, 제2 장치(B)는 상기 특정 작업의 요청에 대한 답변으로 상기 특정 작업의 프레디킷을 전송할 수 있다(step 3). 구체적으로, 제2 장치(B)는 상기 특정 작업의 프레디킷 (), 제2 장치에서 생성된 제2 임의 비표() 및 제1 메시지 인증 코드를 제1 장치(A)로 전송할 수 있다. 여기서, 상기 제1 메시지 인증 코드는 제1 장치(A) 및 제2 장치(B)간 i번째 세션에서 서로 공유되는 쌍대 키()를 사용하여 상기 제1 임의 비표()가 첨부된 메시지의 메시지 인증 코드일 수 있다.

제1 장치(A)는 상기 프레디킷()을 만족하는 속성 서브 셋(sub set)의 요청을 사인함으로써 상기 특정 작업의 실행 권한을 입증할 수 있다.

구체적으로, 제1 장치(A)는 상기 제1 임의 비표() 및 상기 제2 임의 비표()를 연접(concatenation)하여 특정 값을 생성할 수 있다. 그리고, 제1 장치(A)는 홈 도메인()안에서 제1 장치(A)의 개인 키()를 이용하여 상기 특정 값이 첨부된 메시지의 서명() 및 상기 특정 작업을 수행하는 명령을 제2 장치(B)로 전송할 수 있다. 여기서, 상기 개인 키()는 속성 기반 암호화 시스템(A)의 개인 키이다(step 4).

제2 장치(B)는 제1 장치(A)에서 전송된 서명이 프레디킷을 만족하는지 여부를 확인하고, 상기 프레디킷을 만족하는 경우 상기 요청된 특정 작업을 실행할 수 있다(step 5).

제2 장치(B)는 상기 특정 작업을 실행한 후에, 상기 작업에 대한 답변(op_ack) 및 제2 메시지 인증 코드를 제1 장치(A)에 전송할 수 있다. 여기서, 상기 제2 메시지 인증 코드는 상기 제1 임의 비표()에 1을 더한 값이 상기 쌍대 키()를 사용하여 첨부된 메시지의 메시지 인증 코드일 수 있다(step 6).

작동 단계에 대해 좀더 간략히 설명하면 다음과 같다.

제1 장치(A)가 특정 작업을 제2 장치(B)에서 수행하라는 입력을 수신한 경우, 제1 장치(A)는 제2 장치에 상기 특정 작업을 수행하는 요청을 전송할 수 있다. 제2 장치(B)는 특정 작업의 요청에 대응하여 특정 작업의 프레디킷()을 제1 장치(A)에 전송할 수 있다. 제1 장치(A)는 상기 프레디킷()을 만족하는 서명()을 상기 특정 작업의 실행 명령과 함께 제2 장치(B)에 전송할 수 있다. 제2 장치(B)는 상기 수신된 서명()이 상기 프레디킷을 만족하는 경우, 상기 특정 작업의 실행 명령에 따라 상기 특정 작업을 실행할 수 있다.

폐기(Retirement)

본 발명의 일 실시예에 의하면, 폐기 단계는 간단하고 특별한 단계이다. 그리고, 상기 폐기 단계에서의 프로토콜은 작동 단계와 유사할 수 있다. 이는 도 11을 참조하여 좀더 자세히 살펴본다.

도 11은 본 발명의 일 실시예에 의한 폐기 단계에서 이용되는 메인 프로토콜의 일례를 설명하기 위한 도면이다. 폐기 단계는 작동 단계와 유사한 프로토콜을 가지며, 도 10과 다른 내용을 중심으로 이하 살펴본다.

폐기를 실행하기 위해 사용자(U)는 제1 장치(A)를 사용하여 제2 장치(B)의 폐기를 요청해야 한다(step 1). 제1 장치(A)의 속성이 프레디킷을 만족하는 경우, 제2 장치(B)의 폐기가 진행된다. 여기서, 제2 장치(B)가 상기 사용자(U)의 소유임을 가정하고 이하 설명한다.

제2 장치(B)는 상기 사용자(U)로부터 묶임이 해제될 수 있다(step 2). 이는, 상술한 언바인딩 프로토콜에 의해 이루어질 수 있다.

한편, 제2 장치(B)는 클라우드 도메인(C), 홈 도메인()에서의 모든 키들을 제2 장치(B)에서 삭제할 수 있다(step 3). 구체적으로, 제2 장치(B)는 클라우드 서버(C) 내에서 제2 장치의 제1 개인 키(), 홈 도메인 안에서 제2 장치의 제2 개인 키(), 홈 도메인 안에서 제2 장치의 제3 개인 키() 및 제2 장치(B)의 쌍대 키 링(pairwise key ring)을 홈 도메인() 및 상기 클라우드 도메인(C)에서 삭제할 수 있다. 여기서, 상기 제1 개인 키 및 상기 제2 개인 키는 ID 기반 암호화 시스템에서의 개인 키이고, 상기 제3 개인 키는 속성 기반 암호화 시스템에서의 개인 키이다.

제2 장치(B)는 폐기를 완료한 때(즉, 상기 삭제가 완료된 때)에 '폐기됨'이라는 메시지를 스크린 상에 디스플레이할 수 있다(step 4). 즉, 상기 메시지는 폐기 응답의 역할을 수행할 수 있다.

제2 장치(B)에 대한 폐기가 완료된 경우, 상기 홈 도메인() 내에서 제2 장치(B)는 더 이상 사용될 수 없다.

폐기 단계에 대해 좀더 자세히 설명하면 다음과 같다.

제1 장치(A)가 제2 장치의 폐기 요청을 사용자로부터 수신한 경우, 제1 장치(A)는 제2 장치(B)에 폐기 요청을 전송할 수 있다. 제2 장치는 폐기 진행과 관련된 프레디킷을 제1 장치에 전송할 수 있다. 제1 장치는, 상기 프레디킷을 만족하는 서명을 폐기 명령과 함께 제2 장치에 전송할 수 있다. 제2 장치는 상기 수신된 서명이 상기 프레디킷을 만족하는 경우 상기 폐기 명령에 따라 상기 사용자 및 상기 제2 장치(B)의 묶음을 해제(unbinding)할 수 있다. 제2 장치(B)는 상기 제1 개인 키(), 상기 제2 개인 키(), 상기 제3 개인 키() 및 상기 쌍대 키 링을 홈 도메인() 및 클라우드 도메인(C)에서 삭제할 수 있다. 그리고, 제2 장치는 상기 삭제가 완료된 때 상기 폐기가 완료되었음을 나타내는 메시지를 화면에 출력할 수 있다.

추가적인 특징들(Extra Features)

한편, 본 발명의 일 실시예에 의한 사물 인증 시스템은 장치의 소유권을 전송할 수도 있고, 접근을 취소(revocation)할 수도 있고, 게스트 접근을 수행할 수도 있다. 이는 이하에서 좀더 자세히 설명한다.

장치 소유권 재할당(Device Ownership Reassignment)

도 12은 본 발명의 일 실시예에 따른 사물 인증 시스템에서 장치의 소유권을 재할당하는 방법의 일례를 설명하기 위한 도면이다.

본 발명의 일 실시예에 의하면 장치 소유권의 재할당은 제1 사용자(U)가 제2 장치(B)의 소유권을 상기 제1 사용자(U)와 다른 제2 사용자(V)에게 전송하는 것을 의미한다.

상기 소유권 재할당과 관련된 프로토콜은 도 11에서 상술한 폐기 단계와 유사하다. 그러나, 상기 소유권 재할당에서는 제2 장치(B)에 저장되어 있는 클라우드 도메인 키들은 제2 장치(B)에서 삭제되지 않는다.

구체적으로, 상기 제1 사용자(U)는 제1 장치(A)를 이용하여 제2 장치(B)의 소유권을 재할당하도록 요청할 수 있다(step 1).

제2 장치(B)는 상기 제1 사용자(U)로부터 제2 장치(B)를 언바인딩할 수 있다. 이는 상술한 언바인딩 프로토콜에 의해 이루어질 수 있다(step 2).

제2 장치(B)는 상기 홈 도메인() 내에서의 키들을 상기 홈 도메인()에서 전부 삭제할 수 있다(step 3). 구체적으로, 제2 장치(B)는 홈 도메인() 내에서 제2 장치(B)의 제1 개인 키 (), 홈 도메인() 내에서 제2 장치(B)의 제2 개인 키() 및 제2 장치(B)의 쌍대 키 링(pairwise key ring)을 삭제할 수 있다. 여기서, 상기 제1 개인 키()는 ID 기반 암호화 시스템에서의 개인 키이고, 상기 제2 개인 키()는 속성 기반 암호화 시스템의 개인 키이다.

제2 장치(B)는 상기 홈 도메인() 내에서의 키들을 전부 삭제한 경우, 소유권 재할당이라는 메시지를 스크린에 디스플레이할 수 있다(step 4). 상기 메시지의 출력은 상기 소유권 재할당 요청에 대한 답변으로서의 역할을 수행할 수 있다.

한편, 재할당 시 상기 제1 사용자(U)는 상기 제2 사용자(V)에게 새로운 접근 PIN()을 전송할 수 있다. 여기서, 상기 제2 사용자(V)에게 전송된 PIN()은 제2 장치(B)에 대한 접근을 위한 PIN일 수 있다(step 5).

마지막으로, 상기 제1 사용자(U)는 제2 장치(B)를 상기 제2 사용자(V) 에게 안전하게 운송할 수 있다(step 6).

장치 소유권 재할당에 대해 좀더 자세히 설명하면 다음과 같다.

제1 장치(A)가 제2 장치(B)의 소유권 재할당 요청을 사용자로부터 수신한 경우, 제1 장치(A)는 제2 장치(B)에 소유권 재할당 요청을 전송할 수 있다. 제2 장치는 소유권 재할당의 프레디킷을 만족하는 서명을 소유권 재할당 명령과 함께 제2 장치에 전송할 수 있다. 제2 장치(B)는 상기 수신된 서명이 상기 프레디킷을 만족하는 경우 상기 소유권 재할당 명령에 따라 상기 제1 사용자(U) 및 상기 제2 장치(B)의 묶음을 해제(unbinding)할 수 있다. 상기 제2 장치(B)는 상기 제1 개인 키(), 상기 제2 개인 키() 및 상기 쌍대 키 링을 상기 홈 도메인()에서 삭제할 수 있다. 그리고, 상기 제1 장치는 상기 소유권 재할당이 완료되었음을 나타내는 메시지를 화면에 출력할 수 있다.

키 취소(Key Revocation)

한편, 키 취소(Key Revocation)는 사물 인증 시스템에서 주된 특징은 아니다. 하지만, 사물 인증에서 취소 메커니즘으로서 우리는 Boneh 및 Franklin이 제안하고 Boldyreva로부터 향후 개선된 스키마(scheme)를 따른다.

키 취소는 각각의 만료되는 데이터(예를 들어, 타임 스탬프)와 연관된 키로 구성된다. 따라서, 상기 데이터들은 주어진 기간이 경과한 때 무효가 된다.

장치(D)의 공개 키는 타임 스탬프와 연결된 X 도메인에서의 장치의 아이디의 맵이 된다(예를 들어, ). 좀더 구체적으로 살펴보면, X 도메인에서 공개 키는 X 도메인에서 장치(D)의 아이디와 타임 스탬프가 맵핑된 것일 수 있다. 여기서, 상기 공개 키는 ID 기반 암호화 시스템(I)의 공개 키이다.

상기 타임 스탬프의 입자(granularity)는 홈 서버 또는 클라우드 서버로부터 설정된다. 예를 들어, 키들은 매일 새롭게 갱신될 수 있다.

키 취소(Key Revocation)에서 키들은 타임 스탬프가 만료되자마자 키들이 즉시 폐기된다..

인터도메인 ( 게스트 ) 작업( Interdomain (Guest) Operation)

도 13은 본 발명의 일 실시예에 따른 사물 인증 시스템에서 인터도메인 작업을 하는 방법의 일례를 설명하기 위한 도면이다. 이하에서는 제1 장치(A)가 게스트 장치로서 제2 장치(B)의 작업들에 접근을 수행하고자 하는 장차라고 가정하고, 상기 제2 장치(B)는 상기 제1 장치(A)와 서로 다른 도메인에 속한 장치라고 가정하고 이하 설명한다.

본 발명의 일 실시예에 의한 인터도메인 작업은 외부 홈 도메인의 게스트 장치인 제1 창치(A)에게 키를 합의하도록 하고, 상기 제1 장치(A)가 로컬 홈 도메인의 장치들과 상호 작용하도록 할 수 있다.

인터도메인 작업 프로토콜은 McCullagh 및 Barreto의 논문에 기초한다.

인터도메인 키 합의 프로토콜은 두 홈 도메인들이 ID 기반 암호화 시스템들의 공개 파라미터를 합의할 뿐만 아니라, 인터도메인 통신이 발생하기 전 제1 그룹 생성 포인트(Group generator point, )와 제2 그룹 생성 포인트()를 합의할 수도 있다.

상기 인터도메인 키 합의 프로토콜은 상기 제1 장치(A)가 인증된 방법으로 방문한 홈 도메인의 공개 키를 얻는 것을 요청할 수 있다.

제1 장치(A)는 제2 장치의 도메인에서의 제2 장치(B)의 공개된 ID 기반 암호화 방식 파라미터들을 획득할 수 있다. 그리고, 상기 제1 장치(A)는 인터도메인 세션 요청을 전송할 수 있다(step 1-2).

제2 장치(B)는 상기 제1 장치(A)의 공개된 ID 기반 암호화 방식 파라미터들을 사용하여 세션 키를 산출할 수 있다(step 3-6). 그리고, 제2 장치(B)는 시도 응답을 제1 장치(A)에 돌려 보낼 수 있다(step 7).

제1 장치(A)는 세션 키를 산출하기 위한 작업을 반복할 수 있다(step 8). 그리고, 제1 장치(A)는 시도 응답 교환을 종료할 수 있다(step 9).

인터도메인 키 합의 프로토콜은 첫 번째 메시지의 합법성을 확인하기 위해 내포된 키 인증을 활용한다. 여기서, 첫 번째 메시지가 위조된 메시지인 경우, 인터도메인 키 합의 프로토콜은 실패한다.

세션 키가 설정되면, 제1 장치(A)는 제2 장치(B)에게 작업들을 요청할 수 있다. 제1 장치(A)는 상기 제2 장치(B)의 작업들을 실행하기 위해서 도 10과 관련하여 상술한 작동(Functioning) 프로토콜과 비슷한 프로토콜을 반드시 따라야 한다. 왜냐하면, 게스트 사용자들은 그들이 방문한 도메인에서 속성이 없고, 도메인들은 게스트 사용자들을 게스트라는 속성으로 정의해야 한다. 여기서, 상기 게스트라는 속성은 게스트 장치들에게 도메인 내에서 제한된 허가들의 세트를 부여하는 속성을 의미한다. 외부 작업 요청들은 간단한 작업 요청들과 비슷하게 완료된다.

게스트 장치인 제1 장치(A)는 속성 세트의 소유를 입증해야 할 필요가 없다는 것은 예외이다. 다만, 제1 장치(A)가 작업을 실행하는 것이 허용되면, 요청된 작업은 허용된다. 즉, 만약 작업을 수행하는 프레디킷이 게스트 속성에 의해 만족되면, 상기 요청된 작업을 상기 제1 장치(A)가 실행하는 것이 허용된다.

인터도메인 작업 프로토콜에 대해 좀더 구체적으로 살펴보면 다음과 같다.

제1 장치(A)는 인터도메인에서 제2 장치(B)의 제1 공개 키( )를 획득할 수 있다. 여기서, 상기 제1 공개 키( )는 ID 기반 암호화 시스템의 공개 키이다. 구체적으로, 제1 장치(B)는 홈 도메인 ()에서의 제2 장치(B)의 아이디()를 맵핑하고, 상기 제2 그룹 생성 포인트() 및 상기 제2 장치(B)의 홈 도메인의 ID 기반 암호화 시스템의 공개 키()를 이용하여 상기 제1 공개 키( )를 획득할 수 있다(step 1).

제1 장치(A)는 인터도메인 세션 요청(inter_session_req)을 제2 장치(B)에 전송할 수 있다. 이 경우, 제1 장치(A)는 제1 장치(A)에서 생성된 제1 임의 비표(), 제1 장치(A)에서 무작위(random)로 생성된 제1 숫자() 및 상기 제1 공개 키()를 제2 장치(B)에게 함께 전송할 수 있다(step 2).

제2 장치(B)는 제1 장치(A) 및 제2 장치(B)간 공유하는 제1 쌍대 키()를 획득할 수 있다. 상기 제1 쌍대 키()는 상기 수신된 제1 공개 키(), 상기 제1 숫자() 및 인터도메인에서 제2 장치(B)의 제1 개인 키()를 제2 장치(B)에서 무작위로 획득된 제2 숫자()를 이용하여 암호 친화적인 쌍일차식 페어링(bilinear pairing)을 수행함으로써 획득할 수 있다(step 3). 상기 제1 개인 키()는 ID 기반 암호화 시스템에서의 개인 키이다. 상기 제1 쌍대 키()를 산출하기 위해 페어링()을 활용할 수 있고, 독특한 세션 키들을 생성하기 위한 카운터()를 활용할 수도 있다.

제2 장치(B)는 제2 장치에서 생성된 카운터()를 0으로 설정할 수 있다(step 4)

제2 장치(B)는 제1 장치(A)와 제2 장치(B) 사이에서 i번째 세션에서 서로 공유하는 제2 쌍대 키()를 획득할 수 있다(step 5). 구체적으로, 제2 장치(B)는 상기 제2 쌍대 키()를 획득하기 위해 도 2에서 상술한 세션 키 프로토콜을 이용할 수 있다. 제2 장치(B)는 도 2에서 상술한 세션 키 프로토콜에서 상기 제1 쌍대 키() 및 상기 카운터()를 이용하여 상기 제2 쌍대 키()를 획득할 수 있다.

한편, 제2 장치(B)는 인터도메인(Interdomain)에서의 제1 장치(A)의 공개된 ID 기반 암호화 파라미터를 획득할 수 있다. 즉, 제2 장치(B)는 인터도메인에서 제1 장치(A)의 제2 공개 키()를 획득할 수 있다. 여기서, 상기 제2 공개 키( )는 ID 기반 암호화 시스템의 공개 키이다. 구체적으로, 제2 장치(B)는 홈 도메인 ()에서의 제1 장치(A)의 아이디()를 맵핑하고, 상기 제1 그룹 생성 포인트() 및 상기 제1 장치(B)의 홈 도메인의 ID 기반 암호화 시스템의 공개 키()를 이용하여 상기 제2 공개 키()를 획득할 수 있다(step 6).

제2 장치(B)는 시도 응답을 제1 장치(A)에 전송할 수 있다. 구체적으로, 제2 장치(B)는 제2 장치(B)에서 생성된 제2 임의 비표(), 상기 제2 숫자(), 상기 제2 공개 키() 및 제1 메시지 인증 코드를 제1 장치(A)에 전송할 수 있다(step 7). 여기서, 상기 제1 메시지 인증 코드는 상기 제2 쌍대 키()를 사용하여 상기 제1 임의 비표()가 첨부된 메시지의 메시지 인증 코드일 수 있다.

제1 장치(A)는 세션 키를 산출하기 위한 작업을 반복할 수 있다. 구체적으로, 제1 장치(A)는, 단계(S1207)에서 수신된 재료(material)를 이용하여 상기 제2 쌍대 키()를 유사하게 산출할 수 있다(step 8).

제1 장치(A)는 제1 임의 비표() 및 제2 임의 비표()를 연접하여 특정 값을 생성할 수 있다. 그리고, 제1 장치(A)는 상기 제2 쌍대 키()를 사용하여 상기 특정 값이 첨부된 메시지의 제2 메시지 인증 코드를 제2 장치(B)에 전송할 수 있다(step 9). 여기서, 제1 장치(A)는 상기 제2 메시지 인증 코드를 제2 장치(B)에 전송함으로써 시도 응답 교환을 종료할 수 있다.

제2 장치(B)는 상기 인터도메인 세션 요청에 대응하는 인터도메인 세션 응답(inter_session_ack)를 제1 장치(A)에 전송할 수 있다. 또한, 제2 장치(B)는 상기 제2 쌍대 키()를 사용하여 상기 제1 임의 비표()에 1을 더한 값이 첨부된 메시지의 제3 메시지 인증 코드를 제1 장치에 전송할 수 있다(step 10).

인터도메인 작업에 대해 좀더 자세히 설명하면 다음과 같다.

게스트 장치인 제1 장치(A)가 제2 장치(B)의 특정 작업에 접근하는 경우, 제1 장치(A)는 상기 2 장치(B)의 홈 도메인 내에서 상기 제2 장치의 공개된 아이디 기반 암호화 방식 파라미터들을 획득할 수 있고, 인터도메인 세션 요청을 제2 장치(B)에 전송할 수 있다. 제2 장치(B)는 제1 장치의 공개된 아이디 기반 암호화 방식 파라미터들을 이용하여 세션 키를 산출하고 시도 응답을 제1 장치(A)에 전송할 수 있다. 제1 장치(A)는 세션 키 산출을 위한 작업을 반복하고, 시도 응답 교환을 종료하고, 세션키가 설립된 경우 제2 장치(B)에서 상기 특정 작업을 수행하라는 요청을 제2 장치(B)에 전송할 수 있다. 제2 장치(B)는 특정 작업의 요청에 대응하여 특정 작업에 대응하여 상기 특정 작업의 프레디킷을 제1 장치(A)에 전송할 수 있다. 제1 장치(A)는 상기 프레디킷을 만족하는 서명을 특정 작업의 실행 명령과 함께 제2 장치(B)에 전송할 수 있다. 제2 장치(B)는 상기 수신된 서명이 상기 프레디킷을 만족하는 경우 상기 특정 작업의 실행 명령에 따라 상기 특정 작업을 실행할 수 있다. 여기서, 상기 프레디킷은 게스트 장치의 속성이 게스트를 만족하는 경우 특정 작업을 실행할 수 있도록 설정된 속성 프레디킷일 수 있다.

개발품(Development)

이하에서는 사물 인증이 적용될 개발품이 장치 ID 들과 속성들을 사용하여 인증 및 접근 제어를 제공하는 방법을 설명한다. 사물 인증이 여기서, 클라우드 도메인 및 홈 도메인은 고립되어 있고, 사용자들 및 제조자들은 장치들을 각각 제어할 수 있고, 사물 인증은 용량이 작으며, 소스가 제한된 엠베디드 장치들에 제공되고, 다른 플랫폼에도 제공될 수 있다고 가정하고 이하 설명한다.

아키텍쳐 (Architecture)

도 14는 본 발명의 일 실시예에 따른 아키텍쳐를 설명하기 위한 도면이다.

도 14에는 본 발명의 일 실시예에 따른 아키텍쳐에서의 구성들이 개시되어 있다. 본 발명의 일 실시예에 따르면, 상기 구성들은 아키텍쳐는 클라우드 서버(1), 홈 서버(2) 및 장치(3)를 적어도 포함한다.

아키텍쳐는 제조자의 클라우드 도메인을 제어하는 하나의 클라우드 서버(1)를 포함한다. 상기 클라우드 서버(1)는 클라우드 환경의 전형적인 온 디맨드 식의 자원 배당(on-demand resource allocation)을 갖는다.

또한, 상기 아키텍쳐는 각각의 홈 도메엔을 위한 다수의 홈 서버(2)들을 포함한다. 비록, 홈 서버들은 클라우드 서버(1)들과 같이 큰 규모를 필요로 하지는 않지만, 홈 서버(2)는 수 많은 그들의 도메인의 장치들을 제어하기 위한 충분한 리소스들을 갖고 있고, 유지되고 있다고 가정한다. 홈 서버(2)들은 비디오 게임 콘솔들, 데스트탑 PC들, 네트워크 게이트 웨어들 또는 Hardware Secure Modules(HSMs)에서 실행될 수 있다.

각각의 장치(3)들은 홈 도메인 및 제조자의 클라우드 도메인과 통신이 연결될 수 있다. 상기 아키텍쳐는 장치들이 서로 다르고(예를 들어, 파워 처리, 가능한 메모리 용량, 통신 기술들, 사이즈 및 무게 등이 다름), 제한된 자원을 갖을 수 있다는 것을 고려한다. 아키텍쳐 내에서 구성들은 사용자와 상호 작용을 위한 인터페이스를 제공할 수 있다.

상기 아키텍쳐에서 구성들은 도 15에서의 왼쪽에 존재하는 소프트웨어 스택(software stack)을 실행한다. 사물 인증 프로토콜의 실행은 상기 소프트웨어 스택의 중앙 부분에서 실행된다.

실행(Implementation)

이하에서는 도 14를 참조하여 본 발명의 일 실시예에 따른 소프트웨어 스택들을 설명한다.

도 14에서 상술한 아키텍쳐는 여러 종류로 이루어진 하드웨어 및 각각의 특정 소프트웨어 스택을 갖는 다른 작업 시스템들을 실행하는 장치들로 구성된다.

본 발명의 일 실시예에 의하면, 클라우드 서버 및 홈 서버는 Linux, Apache, MySQL(My Structured Query Language) 및 PHP(Hypertext Preprocessor)에서 실행된다. 사물 인증인 안드로이드 어플리케이션을 이용하는 스마트 폰에서 실행된다. 상기 클라우드 서버 및 홈 서버에서의 소프트웨어 스택은 도 15의 가운데에 도시되어 있으며, 안드로이드 어플리케이션을 이용하는 스마트 폰에서의 소프트웨어 스택은 도 15의 오른쪽에 도시되어 있다.

클라우드 서버 및 홈 서버는 장치들과 HTTP 프로토콜을 이용하여 통신을 수행한다. 웹 서버들은 PHP로부터 사물 인증의 암호 알고리즘을 실행하는 2진법을 부를 수 있다.

안드로이드 장치들에서, 사용자는 안드로이드의 기본 인터페이스를 이용하여 사용자 인터페이스가 실행할 수 있고, Java Native Interface(JNL)을 이용하여 암호 라이브러리에 크로스 콤파일(cross-compiled)된 기능들이 불러낼 수 있다.

스택 안에서 레이어 하나의 수정은 다른 레이어들의 변화를 암시하지는 않는다. 예를 들어, HTTP는 다른 전송 암호화 라이버리 전송 이용으로 교환될 수 있다.

본 발명의 일 실시예에 의한 통신에 대해 설명하면 다음과 같다.

암호화 코드는 메시지 엔코딩 및 전송에 종속되지 않는다. 두 장치들은 상호 지원 엔코딩 및 프로토콜을 사용하는 정보를 교환할 수 있다. 일례로, 사물 인증에서 냉장고를 홈 도메인에 배치할 때 QR codes를 이용하여 데이터를 교환할 수 있다. 다른 일례로, 사물 인증에서 스마트 폰으로부터 사용자 속성을 변경할 때 HTTP를 이용하여 데이터를 교환할 수 있다.

본 발명의 일 실시예에 의한 사용자 인터페이스에 대해 설명하면 다음과 같다.

비록 아키텍쳐 내에서 구성들은 같은 사물 인증 프로토콜의 기본적인 실행을 공유하지만, 상기 구성요소들은 어플리케이션 코드와 네이티브 라이브러리들(native libraries)을 이용하여 사용자 인터페이스를 실행한다. 예를 들어, 안드로이드 어플레키이션들은 안드로이드의 Dalvik 가상 기계(Dalvik virtual machaine)에서 실행되고, Java Native Interface(JNI)를 낮은 레벨의 사물 인증 암호화 작업들을 불러오기 위해 사용한다.

암호

본 발명의 일 실시예에 의한 사물 인증 개발품의 아키텍쳐에서 구성들(클라우드 서버들, 홈 서버들, 장치들)은 같은 사물 인증 프로토콜의 기본적인 실행을 공유하지만, 렐릭 암호 라이브러리(RELIC crypto library)의 확장된 버전을 사용한다. 상기 렐릭(RELIC)은 리소스 제한 장치들을 타겟으로 하고, 여러 커브 기반 암호화 알고리즘들(curve-based cryptographic algorithms)을 다른 보안 레벨들에서 효과적으로 실행할 수 있다. 대부분의 알고리즘들은 RAM의 4KiB하에서 8bit 및 16bit 엠베디드 프로세서들이 사용되는 렐릭(RELIC)에서 실행된다.

본 발명의 일 실시예에 의하면, 렐릭의 실행이 개선된다. 구체적으로, 조심스럽게 만들어진 ARM 구조를 위한 어셈블리의 도움으로 새로운 아키텍쳐에 종속하는 최적화를 포함하는 렐릭(RELIC)의 실행을 개선했다.

수학적인 후단부(artimetic backend)는 Karatsuba-Comba 곱셈, 적산(squaring) 및 몽고메리 모듈식 추론을 실행하기 위한 넓은 32-bit 승수 명령 UMLAL를 활용하여 사물 인증에 사용되는 알고리즘을 가속화할 수 있다.

리소스가 제한된 플랫폼에서 128 비트 보안 레벨을 타겟팅하는 것은 흔하지 않는다. 본 발명에 의하면, 접근 제어 메커니즘의 핵심인 속성 기반 인증 방식을 렐릭의 가장 꼭대기에서 실행할 수 있다. 여기서, 속성 기반 인증 방식의 실행은 Maji, Prabhakaran 및 Rosul다의 논문에 기초한다. 즉, 마스터 키 생성, 속성 생성, 인증 생성 및 인증 확인과 관련된 4개의 메인 알고리즘은 상기 논문에 따른다.

본 발명에 의한 사물 인증에서, 접근 제어가 실행될 때면 언제든 인증 생성 및 인증 확인이 장치들에서 실행되는 동안 마스터 키 생성 및 속성 생성은 홈 서버에서 실행된다.

본 발명에 의하면 실행은 상술한 페어링 기반 암호화 및 모노스톤 스팸 프로그램들(Monostone Spam Programs, 이하 MSP)에 의존한다. 상기 MSP들은 단조로운 불룬 함수로서 AOD 정책을 대표한다. 비공식적으로, 단조로운 불린 표현이 제로 부정(zero negotiation)을 포함하는 것을 의미한다. 본 발명에 의하면, 상기 제한을 속성을 반전(예를 들어, 속성을 18 이상 및 18 이하와 같이 생성하는 것)함으로써 극복할 수 있다.

대부분의 속성 기반 인증 알고리즘은 컴퓨터를 사용한 복잡성이 페어링 기반 암호화 방식 작업에 의존한다. 비록, 작업들이 리소스 제한 장치에서 실행되더라도, 속성 기반 인증은 장치에게 산출 시간 및 메모리 소비를 증가시킬 수 있다. 하지만, 한쌍의 제품을 동시에 계산하기 위해 렐릭을 최대한 적합하게 활용하면 문제는 해결될 수 있다. 쌍 계산은 두가지 국면으로 나뉜다. 상기 두가지 국면은, 제곱 및 곱셈 알고리즘으로 구성된 밀러 루프(Miller loop) 및 파이널 누승법(final exponentiation)이다. 멀티 페어링 작업 시에 모든 확대체(full extension field)에서 누승법 및 파이널 누승법은 밀러 루프 안에서 특정 결과들을 축적하는 단일 변수를 유지하는 모든 페어링들을 공유할 수 있다.

본 발명의 일 실시예에 따른 사물 인증의 실행은 이하에서 설명할 암호화 프로토콜 및 알고리즘을 따를 수 있다.

1) Saki-Ohgishi-Kasahara(SOK): 통신의 필요 없이 대칭키를 얻도록 허용하는 상호 작용 없는 키 분배 시키마

2) Boneh-Frankilin(BF-IBE): 비대칭 패어링 구조를 채택한 아이디 기반 암호화 스키마

3) Bellare-Namprempre-Nevem(vBNN-IBS): 짧은 서명 및 빠른 확인을 하는 페어링 자유 아이디 기반 서명

4) Maji-Prabhakaran-Rosulek(MPR-ABS): 속성 개인 공모 저항과 함께하는 속성 기반 서명

5) keyed-Hash Message Authentication code(HMAC): SHA 256을 사용하는 암호화 해쉬 기능의 메시지 인증 코드의 특정 타입

6) Advanced Encrtption Standard (AES): CBS 모드를 사용하는 비대칭 암호화의 표준

이하에서는 본 발명의 일 실시예에 따른 모수화(Parameterization)을 설명한다.

본 발명의 일 실시예에 의한 사물 인증에서의 암호화 프로토콜은 80bit 및 120bit 보안 레벨에 어울리는 엠베딩 차수(embedding degree)와 쌍친화 곡선들(pairing-friendly curves)을 사용하여 실행될 수 있다. 특히, 본 발명에 의하면 이하 수학식 3 또는 이하 수학식 4의 함수(integer)로부터 파라미터화된 Barreto-Naehrig 곡선들이 채택된다. 여기서, 수학식 3은 80bit에서의 함수이고 수학식 4는 120bit에서의 함수이다.

상기 커브들은 이하 수학식 5와 같은 최초의 계수 및 이하 수학식 6과 같은 그룹 순서로 정의된다.

그리고, 상기 커브들은 효과적인 최적의 페어링 구조를 지원한다.

변수 기준 그리고 고정 기준 스칼라 곱셈은 NAF 윈도우 및 싱글 테이블 콤브 방법(single-table comb methods)을 각각 사용하여 실행된다. 80 bit 암호화 파라미터는 기존 시스템과 더 한정된 장치를 다룰 수 있다. 반면, 128 비트 암호화 파라미터는 현재 표준화의 후보이며 긴 기간의 암호화 및 효율성을 보장할 수 있다.

이하에서는 본 발명에 의한 사물 인증의 안정성을 살펴본다.

사물 인증의 안정성은 작은 양의 계산 자원을 요구하기 때문에 리소스가 제한된 엠베디드(embedded) 장치들내에서의 배치를 서포트한다.

사물 인증은 인증, 비밀, 신선함(freshness), 무결성 및 부인 방지와 같은 보안 성질을 제공할 수 있다. 정확하게 사물 인증은, 1)인증을 위한 메시지 인증 코드들 및 디지털 서명, 2) 비밀 암호, 3)신선함(freshness)를 위한 임시 값 및 카운터, 4) 무결성을 위한 메시지 인증 코드들, 디지털 서명들 및 해쉬 기능, 및 5)부인 방지를 위한 디지털 서명을 이용한다.

이하에서는 보안 프로토콜들의 자동 확인을 위한 툴인 Scyther를 이용하여 상기 사물 인증의 특징을 살펴본다. 다만, 사물 인증 프로토콜들 중 세션 키, 사전 배치 및 주문 단계에서의 프로토콜은 제외한다. Scyther는 통신 관점으로부터 프로토콜들을 비교하는데 세션 키는 메시지를 교환하지 않기 때문이다. 그리고 사전 배치 및 주문 단계는 안전한 채널들을 통해서 보호되어 지기 때문이다.

Scyther는 프로토콜들이 보안 특성을 위반하는 공격을 알아차리기 쉬운지 여부를 확인할 수 있다. 이하에서는, Scyther는 암호화 알고리즘들이 보안 관점에서 이상적이고, 프로토콜의 메시지 교환들로부터 발생하는 흠들을 찾을 수 있다고 가정하고 이하 설명한다. 프로토콜들은 반드시 Scyther의 보안 프로토콜 설명 언어(Security Protocol Description Language, SPDL)을 설명하여 설명된다. 상기 SPDL은 프로토콜들을 역할의 세트로 설명한다. 각각의 역할은 프로토콜 내에서 하나의 물질로 분류한다.

인터도메인 키 협정 프로토콜에서 인증을 제외하고 모든 사물 인증의 보안 성질은 성공적이라고 확인할 수 있다. Scyther는 인터도메인 키 협정 프로토콜에서 실패 알람을 출력한다.

이에 대해 도 13을 다시 참조하여 설명한다. Scther는 내포된 키 인증을 구별할 수 없고, 프로토콜의 첫번째 메시지가 반드시 진짜임을 인증할 수 없기 때문이다(step 2). 문제의 메시지는 분명한 인증 메커니즘 없이 보내진다. 대신, 상기 문제의 메시지는 이후 메시지들의 메시지 인증 코드들에 의해 인증된다(steps 7 and 9). 상기 메시지 인증 코드들은 제1 장치(A) 및 제2 장치(B)간 i번째 세션에서 공유되는 쌍대 키()를 이용하여 산출된다. 상기 쌍대 키()는 파리미터인 상기 제1 장치(A)에서 무작위로 생성된 제1 숫자()에 의존하여 생성된다. 상기 제1 숫자() 및 인터도메인(I)에서 상기 제2 장치의 ID 기반 암호화 방식의 공개 키()는 심지어 상기 공개 키()가 공개된 것이라고 하더라도 Scyther가 상기 제1 숫자()를 얻는 것이 불가능 하다. 그러므로, 이것은 공객을 수행하고자 하는 상대방이 상기 쌍대 키()를 얻는 것이 불가능 하다는 것이다. 대체적으로, 상기 상대방은 상기 제1 장치(A)의 메시지를 가로채고, 실패 파라미타인 상기 제1 숫자와 관련된 숫자를 사용하여 제2 장치(B)에게 위장 공격을 시작할 수 있다. 그러나, step 3-5 and 8 각각에서 상기 제1 장치(A) 및 상기 제2 장치(B)에서 산출된 세션 키들과 일치하지 않고, 상기 제1 장치(A) 및 상기 제2 장치(B)로부터 생성된 메시지 인증 코드들의 확인은 실패하고, 프로토콜은 중단된다. 결론적으로, 상술한 보안 성질들은 인터도메인 키 협정 프로토콜에서도 유지될 수 있다.

이하에서는 사물 인증의 수행 시간 및 통신 오버헤드에 대해 비교해 본다.

암호화 알고리즘들 안에서 가장 시간이 오래 걸리는 암호화 작업들의 작업으로서 사물 인증의 수행 시간을 수량화할 수 있다. 특히, 페어링 숫자 및 타원 곡선 스칼라 곱셈을 특히 살펴본다. 다른 작업들은 무시해도 될 정도의 시간 내에 실행되어 지기 때문이다. 암호화 기술에서 야기되는 오버 헤드 또는 인증에서 통신 오버헤드는 bytes의 양으로서 수량화 한다.

도 16은 사물 인증의 수행 시간 및 통신 오버헤드의 비교 결과를 설명하기 위한 테이블이다.

도 16에 의하면, 속성 기반 인증이 가장 시간이 오래 걸리는 암호화 알고리즘이다. 또한, 작동 단계 내에서 접근 제어 메커니즘의 핵심이며, 사물 인증에서 알고리즘으로 자주 사용된다. 속성 기반 인증의 산출 시간은 프레디킷으로부터 생성된 스판 프로그램 매트릭스(span program matrix)의 사이즈에 따라 커진다. 상기 스판 프로그램 매트릭스는 l*t의 차수를 가진다. 여기서, l은 속성의 숫자이고, t는 일을 더한 프레디킷에서 'and' 작업들의 숫자이다.

대부분의 알고리즘들의 통신 오버해드는 정수이다. 오버헤드는 8byte 임의 비표들 및 1byte 라벨들을 고려하여 산출된다. 속성 기반 인증에서 통신 오버헤드는 스팬 프로그램 메트릭스의 사이즈에 의존한다. 하지만, 속성 기반 인증은 하나 또는 여러 개의 네트워크 패킷들에서 적용되기 위해서 충분히 작다. 네트워크 전송 딜레이 및 사물 인증에서 유도된 에너지 소비는 CPU 작업 시간 및 에너지 소비와 비교했을 때 무시해도 될 정도이다.

도 17은 본 발명의 일 실시예에 의한 사물 인증을 평가하기 위해 사용되는 장치들의 성능을 나타내는 테이블이다.

도 17을 참조하면, 제1 장치(A)는 G3와 같은 장치이고, 제2 장치(B)는 Edison과 같은 장치이고, 제3 장치(C)는 Arduino Due와 같은 자원이 많이 제한된 장치이다.

이하 도 18 내지 도 22에서는, 가장 자원이 제한된 상기 제3 장치(C)를 이용하여 여러 가지를 평가한 결과를 설명한다.

도 18은 본 발명의 일 실시예에 의한 사물 인증에서 사용되는 비대칭 암호화 알고리즘들의 실행 시간을 나타내는 도면이고, 도 19는 본 발명의 일 실시예에서 사용되는 다른 보안 레벨 및 구성들(configurations)에서의 실행 시간을 나타내는 도면이다.

도 18을 참조하면 모든 암호화 알고리즘은 합리적인 시간에서 실행된다.

속성 기반 인증(ABS)는 가장 비싼 알고리즘이다. 그리고, 속성 기반 인증은 서명을 생성하기 위해 1.6초 미만의 시간이 걸린다. 그리고, 속성 기반 인증은 하기 수학식 7과 같은 폼의 프레디킷들의 서명들을 인증하기 위해 3초 미만의 시간이 걸린다.

도 18 및 도 19를 비교하면 상기 수학식 7과 같은 폼의 프레디킷들을 위한 제3 장치의 다른 속성 기반 인증 구성들의 실행 시간들을 확인할 수 있다. 도 19에 의하면, 80 bit 및 128 bit의 보안 레벨의 결과를 확인할 수 있다. 본 발명에 의하면, 짧은 실행 시간 동안 보안을 트래이드 오프(trade-off)할 수 있다.

한편, 연장된 렐릭 라이브러리 및 사물 인증 실행은 147KB의 메모리만 이용한다. 따라서, 제3 장치와 같이 자원이 제한된 장치에서도 사용되기 적합하다.

사물 인증의 대부분의 비싼 암호화 알고리즘은 속성 기반 인증이다. 속성 기반 인증은 사물 인증에서 종종 사용된다.

도 20은 특정 그룹에서 스칼라 포인트 곱셈의 실행 시간들 및 페어링 산출의 실행 시간을 나타낸 테이블이다.

스칼라 포인트 곱셈 및 페어링 산출은 사물 인증에 사용되는 암호화 알고리즘의 주요 요소들이다.

도 21은 본 발명의 일 실시예에 따른 사물 인증에서 다른 프레디킷 구조들의 속성 기반 인증의 서명 확인 실행 시간을 평가한 결과를 나타낸 도면이고, 도 22는 본 발명의 일 실시예에 따른 사물 인증에서 속성 기반 인증 확인 실행 시간들 및 메모리 사용률을 설명하기 위한 도면이다.

도 21에 따르면, x 축은 속성의 숫자를 나타낸다. 속성 기반 확인 실행 시간은 분해적으로 평가된다. 도 21을 살펴보면 제3 장치(C)는 속성이 9개 이상인 복잡한 프레디킷들의 서명들을 확인할 수 있음을 볼 수 있다. 그리고, 'AND' 작업들이 1분 미만의 시간이 소요됨을 알 수 있다. 또한, 속성의 숫자가 1 내지 3인 보통의 프레디킷들에서 서명 확인은 6초 미만의 시간이 소요된다.

도 22에서는 최악의 경우의 프레디킷들을 가정한다. 예를 들어, 오로지 'and' 작업들만 포함하는 것을 가정한다. 도 22에 의하면 80 bit 및 128 bit의 보안 레벨들에서 결정론적 및 확률적 확인을 나타내는 4개의 커브들이 도시되어 있다.

도 21 및 도 22를 비교하면, 분석적 실행 시간이 실행 시간들을 충분히 과대평가하였음을 볼 수 있다. 여기에는 두가지 요인이 존재한다. 첫째로, 멀티 페어링들을 동시에 산출하기위해 코드를 최적화하였기 때문이다. 둘째로, 분석적 시간은 프레디킷의 MSP에서 t*ㅣ계수 메트릭스는 0을 포함하지 않는 것을 고려하였기 때문이다.

도 22의 (a)를 살펴보면, 사물 인증에서 보안 레벨을 감소시키던지 확률적 확인을 이용해서 사물 인증에서 속성 기반 인증의 실행 시간을 감소시킬 수 있음을 확인할 수 있다. 특히, 80bit 레벨에서 확률적 확인은 대략 1.2 초 내에 서명 확인이 가능하게 한다. 이는, 어플리케이션간에 상호 작용하기 위해 충분한 시간이다. 또한, 프레디킷에서 or 작업들은 적은 산출을 요구하고 확인 시간을 감소시킬 수 있다.

도 22의 (b)를 살펴보면, 최대 메모리 사용률을 측정한 결과를 나타내는 도면이다. 속성 기반 인증은 리소스가 제한된 장치들 예를 들어 Due와 같은 제3 장치(C)에 적합하다. 9개의 속성들 및 8개의 'and' 작업들의 프레디킷의 메모리는 19 KB 이하를 요구하기 때문이다.

이하에서는 사물 인증이 더 자원이 풍부한 아키텍쳐에서 어떻게 실행되는지를 살펴본다. 메모리 및 저장 공간들은 intel의 Edison 제품과 같은 제1 장치(A) 및 LG의 G4와 같은 제2 장치(B)에서 RAM과 메모리 용량에 비해 무시할 수 있을 정도로 매우 작은 양을 차지하므로, 실행 시간에 포커스를 두고 이하 살펴본다.

도 23은 본 발명의 일 실시예에 따른 암호화 알고리즘이 제1 제품 및 제2 제품에서 실행되는 실행 시간의 실험 결과를 나타내는 도면이다.

도 23에서 살펴본 바와 같이 제1 장치(A) 및 제2 장치(B)는 도 18 내지 도 22에서 평가하는데 이용한 제3 장치(C)보다 더 강력한 제어부들을 갖고 있음을 확인할 수 있다.

도 24는 다양한 프레디킷 구조들을 제1 장치에서 분석적이고 실험적으로 실행한 실행 시간을 나타낸 도면이다.

도 24를 살펴보면, 제1 장치는 다양한 속성들을 포함하는 복잡한 프레디킷들을 2초 이내로 확인할 수 있음을 확인할 수 있다.

상술한 본 발명의 실시예들 중 적어도 하나에 의하면, 사물 인터넷에 적합한 인증 및 접근 제어 솔루션을 제공할 수 있다. 또한, 사물 인터넷 장치의 라이프 사이클 동안의 모든 단계에서 인증 및 접근 제어를 제공하는 한 묶음의 프로토콜들을 제공할 수 있다. 또한, 클라우드 도메인 및 홈 도메인에서의 인증 및 접근 제어를 제공할 수 있다. 또한, 게스트 디바이스가 다른 외부 도메인으로부터 자신을 스스로 인증할 수 있다. 또한 특정 장치가 자신이 갖고 있는 도메인과 다른 도메인에 가입하고, 상기 특정 장치가 자신 스스로를 인증하여 외부 장치들의 작업들에 대한 접근을 수행할 수 있다. 또한 장치의 소유권을 안전하게 전송할 수 있다. 또한 보다 강력한 보안을 제공하는 인증 및 접근 제어를 실행할 수 있다.

각 도면은 설명의 편의를 위해 나누어 설명하였으나, 각 도면에서 서술되어 있는 실시예들은 병합하여 새로운 실시예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.

한편, 본 명세서의 사물 인증 시스템 및 사물 인증 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록 매체에 포로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록 매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, 자기 테이프, 플로피디스크, 광 데이터 자장 장치 등이 있으며, 또한, 인터넷을 통한 송신 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

또한, 이상에서는 본 명세서의 바람직한 실시예에 대하여 도시하고 설명하였지만, 본 명세서는 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 명세서의 요지를 벗어남이 없이 당해 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형 실시들은 본 명세서의 기술적 사상이나 전망으로부터 개별적으로 이해되어서는 안될 것이다.

1: 클라우드 서버
2: 홈 서버
3: 장치

Claims (20)

1. 사물 인증 시스템에 있어서,
   복수 개의 장치와 통신이 연결된 클라우드 도메인을 제어하는 클라우드 서버;
   복수 개의 장치와 통신이 연결된 홈 도메인을 제어하는 홈 서버;
   새로운 장치인 제1 장치; 및
   상기 홈 서버에서 인증이 완료되고, 상기 홈 도메인과 통신이 연결된 루트 사용자의 제2 장치;를 포함하고,
   사전 배치(Pre-deployment) 단계에서 상기 제1 장치는, 상기 클라우드 서버의 암호화 재료를 상기 클라우드 서버로부터 로드하고,
   상기 암호화 재료는, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디 기반 암호화 시스템의 제1 개인 키, 상기 클라우드 서버 내에서 상기 제1 장치의 제1 쌍대 키 및 상기 제1 장치의 카운터를 적어도 포함하고,
   상기 클라우드 서버는, 상기 제1 장치가 거래자에게 운송된 경우 상기 제1 개인 키를 상기 클라우드 서버에서 삭제하는, 사물 인증 시스템.
2. 제 1 항에 있어서,
   배치(deployment) 단계에서 상기 제1 장치가 상기 제1 장치의 PIN(Personal Identification Number)을 입력 받은 경우, 상기 제1 장치는 상기 홈 도메인에서 상기 제2 장치의 아이디, 상기 홈 도메인에서 상기 홈 서버의 아이디 기반 암호화 방식의 공개 키 및 상기 홈 도메인에 포함된 장치들의 카운터들을 상기 제2 장치로부터 수신하고,
   상기 제1 장치는, 기 설정된 기간 동안 유효한 상기 제1 장치와 상기 홈 서버간 공유하는 제2 쌍대 키를 생성하고, 상기 제2 쌍대 키를 상기 제1 장치로부터 수신된 공개 키를 이용하여 암호화하고, 상기 암호화된 제2 쌍대 키의 암호문을 상기 제2 장치에 전송하고,
   상기 제2 장치는 상기 제1 장치의 속성 및 상기 제1 장치의 제1 프레디킷(predicate)에 대한 제1 정보를 사용자로부터 입력 받고, 상기 제1 장치의 배치 명령, 상기 제1 정보 및 상기 암호문을 상기 홈 서버에 전송하고,
   상기 홈 서버는 상기 홈 도메인에서 상기 제1 장치의 아이디 기반 암호화 시스템의 제2 개인 키 및 상기 홈 도메인에서 상기 제1 장치의 속성 기반 암호화 시스템의 제3 개인 키를 상기 제 1 장치에 발행하고, 상기 복수 개의 장치들 및 상기 제1 장치의 속성 및 프레디킷을 포함하는 제2 정보를 상기 제1 장치 및 상기 복수 개의 장치에 브로드캐스트(broadcast)하는, 사물 인증 시스템.
3. 제 2 항에 있어서,
   상기 제1 장치는,
   상기 제2 정보를 수신한 후에 상기 루트 사용자를 상기 장치에 바인딩(binding)하는, 사물 인증 시스템.
4. 제 1 항에 있어서,
   상기 제2 장치는,
   상기 홈 서버에서 인증이 완료되기 위해, 케이블 연결을 통해 상기 홈 서버와 통신이 연결되어 상기 홈 서버에 배치된 장치인, 사물 인증 시스템.
5. 제 2 항에 있어서,
   상기 복수 개의 장치는 제3 장치를 포함하고,
   상기 제1 장치가 상기 홈 서버에 배치가 완료된 후 사용자로부터 상기 제3 장치에서 특정 작업을 수행하라는 입력을 수신한 경우, 상기 제1 장치는 상기 제3 장치에 상기 특정 작업을 수행하는 요청을 전송하고,
   상기 제3 장치는 특정 작업의 요청에 대응하여 상기 특정 작업의 제2 프레디킷을 상기 제1 장치에 전송하고,
   상기 제1 장치는, 상기 제2 프레디킷을 만족하는 제1 서명을 상기 특정 작업의 실행 명령과 함께 상기 제3 장치에 전송하고,
   상기 제3 장치는, 상기 수신된 제1 서명이 상기 제2 프레디킷을 만족하는 경우 상기 특정 작업의 실행 명령에 따라 상기 특정 작업을 실행하는, 사물 인증 시스템.
6. 제 3 항에 있어서,
   상기 제2 장치가 상기 제1 장치의 폐기(retirement) 요청을 사용자로부터 수신한 경우, 상기 제2 장치는 상기 제1 장치에 폐기 요청을 전송하고,
   상기 제1 장치는 폐기 진행과 관련된 제3 프레디킷을 상기 제2 장치에 전송하고,
   상기 제2 장치는, 상기 제3 프레디킷을 만족하는 제2 서명을 폐기 명령과 함께 상기 제1 장치에 전송하고,
   상기 제1 장치는, 상기 수신된 제2 서명이 상기 제3 프레디킷을 만족하는 경우 상기 폐기 명령에 따라 상기 루트 사용자 및 상기 제1 장치의 묶음을 해제하고,
   상기 제1 장치는 상기 제1 개인 키, 상기 제2 개인 키, 상기 제3 개인 키 및 상기 제1 장치의 쌍대 키 링(pairwise key ring)을 상기 상기 홈 도메인 및 상기 클라우드 도메인에서 삭제하고,
   상기 제1 장치는, 상기 키들의 삭제가 완료된 때, 상기 폐기가 완료되었음을 나타내는 메시지를 화면에 출력하는, 사물 인증 시스템.
7. 제 3 항에 있어서,
   상기 제2 장치가 상기 제1 장치의 소유권 재할당(ownership reassignment) 요청을 사용자로부터 수신한 경우, 상기 제2 장치는 상기 제1 장치에 소유권 재할당 요청을 전송하고,
   상기 제1 장치는 소유권 재할당의 제4 프레디킷을 만족하는 제3 서명을 소유권 재할당 명령과 함께 상기 제1 장치에 전송하고,
   상기 제1 장치는, 상기 수신된 제3 서명이 상기 제4 프레디킷을 만족하는 경우 상기 소유권 재할당 명령에 따라 상기 루트 사용자 및 상기 제1 장치의 묶음을 해제하고,
   상기 제1 장치는, 상기 제2 개인 키, 상기 제3 개인 키, 상기 제2 쌍대 키를 상기 홈 도메인에서 삭제하는, 사물 인증 시스템.
8. 제 7 항에 있어서,
   상기 제1 장치는, 상기 키들의 삭제가 완료된 때, 상기 소유권 재할당이 완료되었음을 나타내는 메시지를 화면에 출력하는, 사물 인증 시스템.
9. 제 5 항에 있어서,
   상기 홈 서버와 다른 홈 서버에 속하는 게스트 장치인 제4 장치가 상기 제3 장치의 특정 작업에 접근하는 경우, 상기 제4 장치는 상기 홈 도메인 내에서 상기 제3 장치의 공개된 아이디 기반 암호화 방식 파라미터들을 획득하고,
   상기 제4 장치는 인터도메인 세션 요청을 상기 제3 장치에 전송하고,
   상기 제3 장치는 상기 제4 장치의 공개된 아이디 기반 암호화 방식 파라미터들을 이용하여 세션 키를 산출하고, 시도 응답을 상기 제4 장치에 전송하고,
   상기 제4 장치는 세션 키 산출을 위한 작업을 반복하고, 시도 응답 교환을 종료하고,
   세션 키가 설립된 경우, 제4 장치는 상기 제3 장치에서 상기 특정 작업을 수행하라는 요청을 상기 제3 장치에 전송하고,
   상기 제3 장치는 특정 작업의 요청에 대응하여 상기 제2 프레디킷을 상기 제4 장치에 전송하고,
   상기 제4 장치는 상기 제2 프레디킷을 만족하는 제4 서명을 상기 특정 작업의 실행 명령과 함께 상기 제3 장치에 전송하고,
   상기 제3 장치는, 상기 수신된 제4 서명이 상기 제2 프레디킷을 만족하는 경우 상기 특정 작업의 실행 명령에 따라 상기 특정 작업을 실행하고,
   상기 제2 프레디킷은,
   게스트 장치의 속성이 게스트를 만족하는 경우 상기 특정 작업을 실행할 수 있도록 설정된 프레디킷인, 사물 인증 시스템.
10. 사물 인증 방법에 있어서,
    사전 배치(Pre-deployment) 단계에서, 새로운 장치인 제1 장치가 클라우드 도메인을 제어하는 클라우드 서버의 암호화 재료를 상기 클라우드 서버로부터 로드하는 단계;
    상기 제1 장치가 거래자에게 운송된 경우, 상기 클라우드 서버가 제1 개인 키를 상기 클라우드 서버에서 삭제하는 단계;를 포함하고,
    상기 암호화 재료는, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디, 상기 클라우드 서버 내에서 상기 제1 장치의 아이디 기반 암호화 시스템의 상기 제1 개인 키, 상기 클라우드 서버 내에서 상기 제1 장치의 제1 쌍대 키 및 상기 제1 장치의 카운터를 적어도 포함하는, 사물 인증 방법.
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images