KR20190013867A

KR20190013867A - 사물 인터넷(IoT) 디바이스와 보안 통신 채널을 설정하기 위한 시스템 및 방법

Info

Publication number: KR20190013867A
Application number: KR1020187037117A
Authority: KR
Inventors: 샤논 홀랜드; 로베이 포인터; 스테판 세버리넥; 니콜라스 헤크만; 크리스 아유토; 루카스 핀켈스테인; 스코트 짐머만
Original assignee: 어페로, 인크.
Priority date: 2016-05-27
Filing date: 2017-05-26
Publication date: 2019-02-11
Also published as: KR102303689B1; JP2022048140A; JP7305734B2; JP2019524013A; WO2017205770A1; JP7080829B2

Abstract

보안 통신 채널들을 설정하기 위한 시스템 및 방법이 설명된다. 예를 들어, 시스템의 일 실시예는 IoT 서비스로 송신될 마스터 비밀을 생성하는 비밀/카운터 처리 로직/회로를 포함하는 IoT 디바이스; IoT 서비스로부터 제1 보안 통신 채널을 통해 마스터 비밀을 수신하는 하나 이상의 IoT 허브들 - IoT 허브들 중 적어도 하나는 마스터 비밀을 사용하여 IoT 디바이스와 제2 보안 통신 채널을 설정함 - 을 포함한다.

Description

사물 인터넷(IoT) 디바이스와 보안 통신 채널을 설정하기 위한 시스템 및 방법

본 발명은 일반적으로 컴퓨터 시스템의 분야에 관한 것이다. 더 구체적으로, 본 발명은 사물 인터넷(IoT) 디바이스와 보안 통신 채널을 설정하기 위한 시스템 및 방법에 관한 것이다.

"사물 인터넷"은 인터넷 기반구조 내의 고유하게 식별 가능한 임베디드 디바이스들의 상호접속을 지칭한다. 궁극적으로, IoT는, 사실상 임의의 타입의 물리적인 물건이 그 자체 또는 그의 주변에 대한 정보를 제공할 수 있고 그리고/또는 인터넷을 통하여 클라이언트 디바이스를 통해 원격으로 제어될 수 있는 새로운 광범위한 타입의 애플리케이션을 생성할 것으로 예상된다.

아래의 도면들과 관련된 아래의 상세한 설명으로부터 본 발명의 더 양호한 이해가 얻어질 수 있다.
도 1a 및 도 1b는 IoT 시스템 아키텍처의 상이한 실시예들을 예시한다.
도 2는 본 발명의 일 실시예에 따른 IoT 디바이스를 예시한다.
도 3은 본 발명의 일 실시예에 따른 IoT 허브를 예시한다.
도 4a 및 도 4b는 IoT 디바이스들로부터 데이터를 제어 및 수집하고 통지를 생성하기 위한 본 발명의 실시예들을 예시한다.
도 5는 IoT 디바이스들로부터 데이터를 수집하고 IoT 허브 및/또는 IoT 서비스로부터 통지를 생성하기 위한 본 발명의 실시예들을 예시한다.
도 6은 중개 모바일 디바이스가 고정 IoT 디바이스로부터 데이터를 수집하고 데이터를 IoT 허브에 제공하는 시스템의 일 실시예를 예시한다.
도 7은 본 발명의 일 실시예에서 구현되는 중개 접속 로직을 예시한다.
도 8은 본 발명의 일 실시예에 따른 방법을 예시한다.
도 9a는 프로그램 코드 및 데이터 업데이트들이 IoT 디바이스에 제공되는 실시예를 예시한다.
도 9b는 프로그램 코드 및 데이터 업데이트들이 IoT 디바이스에 제공되는 방법의 실시예를 예시한다.
도 10은 보안 아키텍처의 일 실시예의 고레벨 도면을 예시한다.
도 11은 IoT 디바이스 상에 키를 저장하기 위해 가입자 식별 모듈(SIM)이 사용되는 아키텍처의 일 실시예를 예시한다.
도 12a는 IoT 디바이스가 바코드 또는 QR 코드를 사용하여 등록되는 일 실시예를 예시한다.
도 12b는 바코드 또는 QR 코드를 사용하여 페어링이 수행되는 일 실시예를 예시한다.
도 13은 IoT 허브를 사용하여 SIM을 프로그래밍하는 방법의 일 실시예를 예시한다.
도 14는 IoT 디바이스를 IoT 허브 및 IoT 서비스에 등록하는 방법의 일 실시예를 예시한다.
도 15는 IoT 디바이스로 송신될 데이터를 암호화하는 방법의 일 실시예를 예시한다.
도 16a 및 도 16b는 IoT 서비스와 IoT 디바이스 사이에서 데이터를 암호화하는 본 발명의 상이한 실시예들을 예시한다.
도 17은 보안 키 교환을 수행하고, 공통 비밀을 생성하고, 비밀을 사용하여 키 스트림을 생성하는 본 발명의 실시예들을 예시한다.
도 18은 본 발명의 일 실시예에 따른 패킷 구조를 예시한다.
도 19는 IoT 디바이스와 정식으로 페어링함이 없이 IoT 디바이스에 데이터를 기입하고 그로부터 데이터를 판독하기 위해 일 실시예에서 사용되는 기술을 예시한다.
도 20은 본 발명의 일 실시예에서 사용되는 예시적인 커맨드 패킷 세트를 예시한다.
도 21은 커맨드 패킷들을 사용하는 예시적인 트랜잭션 시퀀스를 예시한다.
도 22는 본 발명의 일 실시예에 따른 방법을 예시한다.
도 23a 내지 도 23c는 본 발명의 일 실시예에 따른 보안 페어링을 위한 방법을 예시한다.
도 24는 데이터 전송 조건을 식별하기 위해 광고 간격을 조정하는 본 발명의 일 실시예를 예시한다.
도 25는 본 발명의 일 실시예에 따른 방법을 예시한다.
도 26a 내지 도 26c는 다수의 IoT 허브가 IoT 디바이스에 데이터/커맨드를 송신하려고 시도하는 일 실시예의 동작을 예시한다.
도 27은 본 발명의 일 실시예에 따른 방법을 예시한다.
도 28은 보안 IoT 디바이스 프로비저닝을 위한 시스템의 일 실시예를 예시한다.
도 29는 본 발명의 일 실시예에 따른 방법을 예시한다.
도 30은 복수의 IoT 디바이스에 대한 흐름 제어를 수행하기 위한 시스템의 일 실시예.
도 31은 본 발명의 일 실시예에 따른 방법을 예시한다.
도 32는 애플리케이션 속성들, 시스템 속성들, 및 우선 순위 통지 속성들을 관리하기 위한 시스템의 일 실시예를 예시한다.
도 33은 보안 무선 통신을 위한 시스템 및 대응하는 방법의 일 실시예를 예시한다.
도 34 및 도 35는 거짓 접속들을 검출하기 위한 본 발명의 실시예들을 예시한다.
도 36은 래치된 속성들을 구현하기 위한 본 발명의 일 실시예를 예시한다.

아래의 설명에서, 설명의 목적으로, 아래에 설명되는 본 발명의 실시예의 완전한 이해를 제공하기 위해 다수의 특정 상세들이 기재된다. 그러나, 본 발명의 실시예는 이러한 특정 상세들 중 일부 없이도 실시될 수 있다는 것이 당업자에게 명백할 것이다. 다른 경우에서, 잘 알려진 구조 및 디바이스는 본 발명의 실시예의 기본 원리를 불명확하게 하는 것을 피하기 위해 블록도 형태로 도시된다.

본 발명의 일 실시예는 새로운 IoT 디바이스 및 애플리케이션을 설계 및 구축하기 위해 개발자에 의해 이용될 수 있는 사물 인터넷(IoT) 플랫폼을 포함한다. 특히, 일 실시예는 IoT 디바이스들이 그것을 통해 인터넷에 결합되는 미리 정의된 네트워킹 프로토콜 스택 및 IoT 허브를 포함한 IoT 디바이스들을 위한 기반 하드웨어/소프트웨어 플랫폼을 포함한다. 부가적으로, 일 실시예는 IoT 허브들 및 접속된 IoT 디바이스들이 그것을 통해 아래에 설명되는 바와 같이 액세스 및 관리될 수 있는 IoT 서비스를 포함한다. 부가적으로, IoT 플랫폼의 일 실시예는 IoT 서비스, 허브 및 접속된 디바이스들에 액세스하고 그들을 구성하기 위한 (예를 들어, 클라이언트 디바이스 상에서 실행되는) IoT 앱 또는 웹 애플리케이션을 포함한다. 기존의 온라인 소매상 및 다른 웹사이트 운영자는 고유 IoT 기능을 기존의 사용자 기반에 쉽게 제공하기 위해 본 명세서에 설명된 IoT 플랫폼을 레버리징할 수 있다.

도 1a는 본 발명의 실시예가 구현될 수 있는 아키텍처 플랫폼의 개요를 예시한다. 특히, 예시된 실시예는 그 자체가 인터넷(220)을 통해 IoT 서비스(120)에 통신 가능하게 결합된 중앙 IoT 허브(110)에 로컬 통신 채널(130)을 통해 통신 가능하게 결합된 복수의 IoT 디바이스(101 내지 105)를 포함한다. IoT 디바이스(101 내지 105) 각각은 로컬 통신 채널들(130) 각각을 가능하게 하기 위해 (예를 들어, 아래에 설명되는 페어링 기술을 사용하여) IoT 허브(110)에 초기에 페어링될 수 있다. 일 실시예에서, IoT 서비스(120)는 각각의 사용자의 IoT 디바이스로부터 수집된 사용자 계정 정보 및 데이터를 유지하기 위한 최종 사용자 데이터베이스(122)를 포함한다. 예를 들어, IoT 디바이스가 센서(예를 들어, 온도 센서, 가속도계, 열 센서, 모션 검출기 등)를 포함하면, 데이터베이스(122)는 IoT 디바이스(101 내지 105)에 의해 수집된 데이터를 저장하도록 계속 업데이트될 수 있다. 이어서, 데이터베이스(122)에 저장된 데이터는 사용자의 디바이스(135) 상에 설치된 IoT 앱 또는 브라우저를 통해(또는 데스크톱 또는 다른 클라이언트 컴퓨터 시스템을 통해) 최종 사용자에 의해 그리고 (예를 들어, IoT 서비스(120)에 가입한 웹사이트(130)와 같은) 웹 클라이언트에 의해 액세스 가능하게 될 수 있다.

IoT 디바이스(101 내지 105)에는 그들 및 그들의 주변에 대한 정보를 수집하고 수집된 정보를 IoT 허브(110)를 통해 IoT 서비스(120), 사용자 디바이스(135) 및/또는 외부 웹사이트(130)에 제공하기 위한 다양한 타입의 센서가 탑재될 수 있다. IoT 디바이스(101 내지 105) 중 일부는 IoT 허브(110)를 통해 전송된 제어 커맨드에 응답하여 지정된 기능을 수행할 수 있다. IoT 디바이스(101 내지 105)에 의해 수집된 정보 및 제어 커맨드의 다양한 특정 예가 아래에서 제공된다. 아래에 설명된 일 실시예에서, IoT 디바이스(101)는, 사용자 선택을 기록하고 사용자 선택을 IoT 서비스(120) 및/또는 웹사이트에 전송하도록 설계된 사용자 입력 디바이스이다.

일 실시예에서, IoT 허브(110)는 4G(예를 들어, 모바일 WiMAX, LTE) 또는 5G 셀룰러 데이터 서비스와 같은 셀룰러 서비스(115)를 통해 인터넷(220)에 대한 접속을 설정하기 위한 셀룰러 라디오를 포함한다. 대안적으로 또는 부가적으로, IoT 허브(110)는 (예를 들어, 인터넷 서비스를 최종 사용자에게 제공하는 인터넷 서비스 제공자를 통해) IoT 허브(110)를 인터넷에 결합시키는 WiFi 액세스 포인트 또는 라우터(116)를 통해 WiFi 접속을 설정하기 위한 WiFi 라디오를 포함할 수 있다. 물론, 본 발명의 기본 원리는 임의의 특정 타입의 통신 채널 또는 프로토콜로 제한되지 않는다는 것에 유의하여야 한다.

일 실시예에서, IoT 디바이스(101 내지 105)는 배터리 전력으로 장기간(예를 들어, 수년) 동안 동작할 수 있는 초 저전력 디바이스이다. 전력을 보전하기 위해, 로컬 통신 채널(130)은 블루투스 저에너지(LE)와 같은 저전력 무선 통신 기술을 사용하여 구현될 수 있다. 이러한 실시예에서, IoT 디바이스(101 내지 105) 각각 및 IoT 허브(110)에는 블루투스 LE 라디오 및 프로토콜 스택이 탑재된다.

언급된 바와 같이, 일 실시예에서, IoT 플랫폼은 사용자가 접속된 IoT 디바이스(101 내지 105), IoT 허브(110), 및/또는 IoT 서비스(120)에 액세스하고 그들을 구성하도록 허용하기 위해 사용자 디바이스(135) 상에서 실행되는 IoT 앱 또는 웹 애플리케이션을 포함한다. 일 실시예에서, 앱 또는 웹 애플리케이션은 IoT 기능을 그의 사용자 기반에 제공하도록 웹사이트(130)의 운영자에 의해 설계될 수 있다. 예시된 바와 같이, 웹사이트는 각각의 사용자에 관련된 계정 기록을 포함하는 사용자 데이터베이스(131)를 유지할 수 있다.

도 1b는 복수의 IoT 허브(110, 111, 190)에 대한 추가의 접속 옵션들을 예시한다. 이러한 실시예에서, 단일 사용자는 단일 사용자 구내(premises)(180)(예를 들어, 사용자의 집 또는 사업체)에 현장 설치된 다수의 허브(110, 111)를 가질 수 있다. 이것은 예를 들어 IoT 디바이스(101 내지 105) 모두를 접속시키기 위해 필요한 무선 범위를 확장시키기 위해 행해질 수 있다. 표시된 바와 같이, 사용자가 다수의 허브(110, 111)를 갖는 경우, 그것들은 로컬 통신 채널(예를 들어, Wifi, 이더넷, 전력 라인 네트워킹 등)을 통해 접속될 수 있다. 일 실시예에서, 허브(110, 111) 각각은 (도 1b에 명시적으로 도시되지 않은) 셀룰러(115) 또는 WiFi(116) 접속을 통해 IoT 서비스(120)에 대한 직접 접속을 설정할 수 있다. 대안적으로 또는 부가적으로, IoT 허브(110)와 같은 IoT 허브들 중 하나는 (IoT 허브(110)와 IoT 허브(111)를 연결하는 점선에 의해 표시된 바와 같이) IoT 허브(111)와 같은, 사용자 구내(180) 상의 다른 IoT 허브들 모두에 접속성 및/또는 로컬 서비스를 제공하는 "마스터" 허브로서 동작할 수 있다. 예를 들어, 마스터 IoT 허브(110)는 IoT 서비스(120)에 대한 직접 접속을 설정하기 위한 유일한 IoT 허브일 수 있다. 일 실시예에서, "마스터" IoT 허브(110)에만 IoT 서비스(120)에 대한 접속을 설정하기 위한 셀룰러 통신 인터페이스가 탑재된다. 그렇기 때문에, IoT 서비스(120)와 다른 IoT 허브(111) 사이의 모든 통신은 마스터 IoT 허브(110)를 통해 흐를 것이다. 이러한 역할에서, 마스터 IoT 허브(110)는 다른 IoT 허브(111)와 (예를 들어, 가능한 경우 로컬식으로 일부 데이터 요청들을 서비스하는) IoT 서비스(120) 사이에서 교환되는 데이터에 대해 필터링 동작을 수행하기 위한 추가 프로그램 코드를 제공받을 수 있다.

IoT 허브(110, 111)가 어떻게 접속되는지에 관계없이, 일 실시예에서, IoT 서비스(120)는 앱이 설치된 사용자 디바이스(135)를 통해 액세스 가능한 단일의 포괄적인 사용자 인터페이스 (및/또는 브라우저-기반 인터페이스)하에서 허브를 사용자와 논리적으로 연관시키고 부착된 IoT 디바이스(101 내지 105) 모두를 결합시킬 것이다.

이러한 실시예에서, 마스터 IoT 허브(110) 및 하나 이상의 슬레이브 IoT 허브(111)는 WiFi 네트워크(116), 이더넷 네트워크, 및/또는 사용 전력-라인 통신(PLC) 네트워킹일 수 있는 로컬 네트워크를 통해 접속될 수 있다(예를 들어, 여기서 네트워크의 전부 또는 일부가 사용자의 전력 라인을 통해 구동됨). 부가적으로, IoT 허브(110, 111)에 대해, IoT 디바이스(101 내지 105) 각각은, 몇몇 예를 들자면, WiFi, 이더넷, PLC 또는 블루투스 LE와 같은 임의의 타입의 로컬 네트워크 채널을 사용하여 IoT 허브(110, 111)와 상호접속될 수 있다.

도 1b는 또한 제2 사용자 구내(181)에 설치된 IoT 허브(190)를 도시한다. 사실상 제한되지 않는 수의 그러한 IoT 허브(190)가 전세계의 사용자 구내에서 IoT 디바이스(191, 192)로부터 데이터를 수집하도록 설치 및 구성될 수 있다. 일 실시예에서, 2개의 사용자 구내(180, 181)가 동일한 사용자에 대해 구성될 수 있다. 예를 들어, 하나의 사용자 구내(180)는 사용자의 주된 집일 수 있고, 다른 사용자 구내(181)는 사용자의 별장일 수 있다. 그러한 경우에, IoT 서비스(120)는 앱이 설치된 사용자 디바이스(135)를 통해 액세스 가능한 단일의 포괄적인 사용자 인터페이스 (및/또는 브라우저-기반 인터페이스)하에서 IoT 허브(110, 111, 190)를 사용자와 논리적으로 연관시키고 부착된 IoT 디바이스(101 내지 105, 191, 192) 모두를 결합시킬 것이다.

도 2에 예시된 바와 같이, IoT 디바이스(101)의 예시적인 실시예는 프로그램 코드 및 데이터(201 내지 203)를 저장하기 위한 메모리(210) 및 프로그램 코드를 실행하고 데이터를 처리하기 위한 저전력 마이크로제어기(200)를 포함한다. 메모리(210)는 동적 랜덤 액세스 메모리(DRAM)와 같은 휘발성 메모리일 수 있거나, 플래시 메모리와 같은 비-휘발성 메모리일 수 있다. 일 실시예에서, 비-휘발성 메모리는 영속적인 저장을 위해 사용될 수 있고, 휘발성 메모리는 런타임 시에 프로그램 코드 및 데이터의 실행을 위해 사용될 수 있다. 또한, 메모리(210)는 저전력 마이크로제어기(200) 내에 통합될 수 있거나, 버스 또는 통신 패브릭(fabric)을 통해 저전력 마이크로제어기(200)에 결합될 수 있다. 본 발명의 기본 원리는 메모리(210)의 임의의 특정 구현으로 제한되지 않는다.

예시된 바와 같이, 프로그램 코드는 IoT 디바이스(201)에 의해 수행될 기능들의 애플리케이션-특정 세트를 정의하는 애플리케이션 프로그램 코드(203), 및 IoT 디바이스(101)의 애플리케이션 개발자에 의해 이용될 수 있는 미리 정의된 빌딩 블록(building block)들의 세트를 포함하는 라이브러리 코드(202)를 포함할 수 있다. 일 실시예에서, 라이브러리 코드(202)는 각각의 IoT 디바이스(101)와 IoT 허브(110) 사이의 통신을 가능하게 하기 위한 통신 프로토콜 스택(201)과 같은, IoT 디바이스를 구현하는 데 요구되는 기본 기능들의 세트를 포함한다. 언급된 바와 같이, 일 실시예에서, 통신 프로토콜 스택(201)은 블루투스 LE 프로토콜 스택을 포함한다. 이러한 실시예에서, 블루투스 LE 라디오 및 안테나(207)는 저전력 마이크로제어기(200) 내에 통합될 수 있다. 그러나, 본 발명의 기본 원리는 임의의 특정 통신 프로토콜로 제한되지 않는다.

도 2에 도시된 특정 실시예는 또한 사용자 입력을 수신하고 사용자 입력을 저전력 마이크로제어기에 제공하기 위한 복수의 입력 디바이스 또는 센서(210)를 포함하며, 저전력 마이크로제어기는 애플리케이션 코드(203) 및 라이브러리 코드(202)에 따라 사용자 입력을 처리한다. 일 실시예에서, 입력 디바이스들 각각은 최종 사용자에게 피드백을 제공하기 위한 LED(209)를 포함한다.

부가적으로, 예시된 실시예는 저전력 마이크로제어기에 전력을 공급하기 위한 배터리(208)를 포함한다. 일 실시예에서, 비-충전 가능 코인 셀 배터리가 사용된다. 그러나, 대안적인 실시예에서, 통합된 재충전 가능 배터리가 사용될 수 있다(예를 들어, IoT 디바이스를 AC 전력 공급부(도시되지 않음)에 접속시킴으로써 재충전 가능함).

오디오를 생성하기 위한 스피커(205)가 또한 제공된다. 일 실시예에서, 저전력 마이크로제어기(299)는 스피커(205)에서 오디오를 생성하기 위해 (예를 들어, MPEG-4/어드밴스드 오디오 코딩(AAC) 스트림과 같은) 압축된 오디오 스트림을 디코딩하기 위한 오디오 디코딩 로직을 포함한다. 대안적으로, 저전력 마이크로제어기(200) 및/또는 애플리케이션 코드/데이터(203)는 사용자가 입력 디바이스(210)를 통해 선택을 입력할 때 언어 피드백을 최종 사용자에게 제공하기 위한 오디오의 디지털 샘플링된 단편(snippet)을 포함할 수 있다.

일 실시예에서, 하나 이상의 다른/대안적인 I/O 디바이스 또는 센서(250)가, IoT 디바이스(101)가 그것을 위해 설계되는 특정 애플리케이션에 기초하여 IoT 디바이스(101) 상에 포함될 수 있다. 예를 들어, 온도, 압력, 습도 등을 측정하기 위해 환경 센서가 포함될 수 있다. IoT 디바이스가 보안 디바이스로서 사용되는 경우 보안 센서 및/또는 도어록 오프너가 포함될 수 있다. 물론, 이들 예는 단지 예시의 목적으로 제공된다. 본 발명의 기본 원리는 IoT 디바이스의 임의의 특정 타입으로 제한되지 않는다. 사실, 라이브러리 코드(202)가 탑재된 저전력 마이크로제어기(200)의 고도로 프로그래밍 가능한 속성을 고려해 볼 때, 애플리케이션 개발자는 사실상 임의의 타입의 IoT 애플리케이션을 위한 저전력 마이크로제어기와 인터페이싱하기 위해 새로운 애플리케이션 코드(203) 및 새로운 I/O 디바이스(250)를 쉽게 개발할 수 있다.

일 실시예에서, 저전력 마이크로제어기(200)는 또한 통신을 암호화하고/하거나 서명을 생성하기 위한 암호화 키를 저장하기 위한 보안 키 저장소를 포함한다. 대안적으로, 키는 가입자 식별 모듈(SIM)에서 보안될 수 있다.

일 실시예에서, IoT 디바이스가 사실상 어떠한 전력도 소비하고 있지 않은 초 저전력 상태로부터 그 IoT 디바이스를 웨이크하기 위해 웨이크업 수신기(207)가 포함된다. 일 실시예에서, 웨이크업 수신기(207)는 도 3에 도시된 바와 같이 IoT 허브(110) 상에 구성된 웨이크업 송신기(307)로부터 수신된 웨이크업 신호에 응답하여 IoT 디바이스(101)로 하여금 이러한 저전력 상태를 빠져나가게 하도록 구성된다. 특히, 일 실시예에서, 송신기(307) 및 수신기(207)는 테슬라 코일과 같은 전기 공진 변압기 회로를 함께 형성한다. 동작 시에, 허브(110)가 매우 낮은 전력 상태로부터 IoT 디바이스(101)를 웨이크할 필요가 있을 때 에너지가 라디오 주파수 신호를 통해 송신기(307)로부터 수신기(207)로 송신된다. 에너지 전달 때문에, IoT 디바이스(101)는 그것이 그것의 저전력 상태에 있을 때 사실상 어떠한 전력도 소비하지 않도록 구성될 수 있는데, 왜냐하면 (디바이스가 네트워크 신호를 통해 어웨이크되도록 허용하는 네트워크 프로토콜에서 그러한 바와 같이) 그것이 허브로부터의 신호를 계속 "청취"할 필요가 없기 때문이다. 오히려, IoT 디바이스(101)의 마이크로제어기(200)는 송신기(307)로부터 수신기(207)로 전기적으로 송신된 에너지를 사용함으로써 사실상 전력 차단된 후에 웨이크 업하도록 구성될 수 있다.

도 3에 예시된 바와 같이, IoT 허브(110)는 또한 프로그램 코드 및 데이터(305)를 저장하기 위한 메모리(317), 및 프로그램 코드를 실행하고 데이터를 처리하기 위한 마이크로제어기와 같은 하드웨어 로직(301)을 포함한다. 광역 네트워크(WAN) 인터페이스(302) 및 안테나(310)가 IoT 허브(110)를 셀룰러 서비스(115)에 결합시킨다. 대안적으로, 위에서 언급된 바와 같이, IoT 허브(110)는 또한 근거리 네트워크 통신 채널을 설정하기 위한 WiFi 인터페이스(및 WiFi 안테나) 또는 이더넷 인터페이스와 같은 로컬 네트워크 인터페이스(도시되지 않음)를 포함할 수 있다. 일 실시예에서, 하드웨어 로직(301)은 또한 통신을 암호화하고 서명을 생성/검증하기 위한 암호화 키를 저장하기 위한 보안 키 저장소를 포함한다. 대안적으로, 키는 가입자 식별 모듈(SIM)에서 보안될 수 있다.

로컬 통신 인터페이스(303) 및 안테나(311)가 IoT 디바이스(101 내지 105) 각각과 로컬 통신 채널을 설정한다. 위에서 언급된 바와 같이, 일 실시예에서, 로컬 통신 인터페이스(303)/안테나(311)는 블루투스 LE 표준을 구현한다. 그러나, 본 발명의 기본 원리는 IoT 디바이스(101 내지 105)와 로컬 통신 채널을 설정하기 위한 임의의 특정 프로토콜로 제한되지 않는다. 도 3에서 별개의 유닛으로서 예시되지만, WAN 인터페이스(302) 및/또는 로컬 통신 인터페이스(303)는 하드웨어 로직(301)과 동일한 칩 내에 임베딩될 수 있다.

일 실시예에서, 프로그램 코드 및 데이터는 로컬 통신 인터페이스(303) 및 WAN 인터페이스(302)를 통해 통신하기 위한 별개의 스택을 포함할 수 있는 통신 프로토콜 스택(308)을 포함한다. 부가적으로, IoT 허브가 새로운 IoT 디바이스와 페어링하도록 허용하기 위해 디바이스 페어링 프로그램 코드 및 데이터(306)가 메모리에 저장될 수 있다. 일 실시예에서, 각각의 새로운 IoT 디바이스(101 내지 105)는 페어링 프로세스 동안 IoT 허브(110)에 통신되는 고유 코드를 할당받는다. 예를 들어, 고유 코드는 IoT 디바이스 상의 바코드에 임베딩될 수 있으며, 바코드 판독기(106)에 의해 판독될 수 있거나 로컬 통신 채널(130)을 통해 통신될 수 있다. 대안적인 실시예에서, 고유 ID 코드는 IoT 디바이스 상에 자기적으로 임베딩되며, IoT 허브는 IoT 디바이스(101)가 IoT 허브(110)로부터 수 인치 이내로 이동될 때 코드를 검출하기 위한 라디오 주파수 ID(RFID) 또는 근거리장 통신(NFC) 센서와 같은 자기 센서를 갖는다.

일 실시예에서, 일단 고유 ID가 통신되면, IoT 허브(110)는 로컬 데이터베이스(도시되지 않음)에 질의하고/하거나, 코드가 수용 가능한지를 검증하기 위해 해시(hash)를 수행하고/하거나, ID 코드를 확인하기 위해 IoT 서비스(120), 사용자 디바이스(135) 및/또는 웹사이트(130)와 통신함으로써 고유 ID를 검증할 수 있다. 일단 확인되면, 일 실시예에서, IoT 허브(110)는 IoT 디바이스(101)를 페어링하고, (언급된 바와 같이, 비-휘발성 메모리를 포함할 수 있는) 메모리(317)에 페어링 데이터를 저장한다. 일단 페어링이 완료되면, IoT 허브(110)는 본 명세서에 설명된 다양한 IoT 기능을 수행하기 위해 IoT 디바이스(101)와 접속할 수 있다.

일 실시예에서, IoT 서비스(120)를 구동하는 조직은 개발자가 새로운 IoT 서비스를 용이하게 설계하도록 허용하기 위해 IoT 허브(110) 및 기본적인 하드웨어/소프트웨어 플랫폼을 제공할 수 있다. 특히, IoT 허브(110)에 더하여, 개발자는 허브(110) 내에서 실행되는 프로그램 코드 및 데이터(305)를 업데이트하기 위한 소프트웨어 개발 키트(SDK)를 제공받을 수 있다. 부가적으로, IoT 디바이스(101)에 대해, SDK는 다양한 상이한 타입의 애플리케이션(101)의 설계를 용이하게 하기 위하여 기반 IoT 하드웨어(예를 들어, 도 2에 도시된 저전력 마이크로제어기(200) 및 다른 컴포넌트)에 대해 설계된 광범위한 세트의 라이브러리 코드(202)를 포함할 수 있다. 일 실시예에서, SDK는 개발자가 단지 IoT 디바이스에 대한 입력 및 출력만을 지정할 필요가 있는 그래픽 설계 인터페이스를 포함한다. IoT 디바이스(101)가 허브(110) 및 서비스(120)에 접속하도록 허용하는 통신 스택(201)을 포함한 모든 네트워킹 코드가 이미 개발자를 위해 제 위치에 있다. 부가적으로, 일 실시예에서, SDK는 또한 모바일 디바이스(예를 들어, 아이폰 및 안드로이드 디바이스)를 위한 앱의 설계를 용이하게 하기 위한 라이브러리 코드 기반을 포함한다.

일 실시예에서, IoT 허브(110)는 IoT 디바이스(101 내지 105)와 IoT 서비스(120) 사이의 데이터의 연속적인 양방향 스트림을 관리한다. IoT 디바이스(101 내지 105)로의/로부터의 업데이트가 실시간으로 요구되는(예를 들어, 사용자가 보안 디바이스 또는 환경 측정의 현재 상태를 볼 필요가 있는) 상황에서, IoT 허브는 정기 업데이트를 사용자 디바이스(135) 및/또는 외부 웹사이트들(130)에 제공하기 위한 개방형 TCP 소켓을 유지할 수 있다. 업데이트를 제공하는 데 사용되는 특정 네트워킹 프로토콜은 기본 애플리케이션의 필요에 기초하여 미세조정될 수 있다. 예를 들어, 연속적인 양방향 스트림을 갖는 것이 타당하지 않을 수 있는 일부 경우에, 간단한 요청/응답 프로토콜이 필요할 경우 정보를 수집하는 데 사용될 수 있다.

일 실시예에서, IoT 허브(110) 및 IoT 디바이스(101 내지 105) 둘 모두는 네트워크를 통해 자동적으로 업그레이드 가능하다. 특히, 새로운 업데이트가 IoT 허브(110)에게 이용 가능한 경우, 그것은 IoT 서비스(120)로부터 업데이트를 자동적으로 다운로드 및 설치할 수 있다. 그것은 먼저 업데이트된 코드를 로컬 메모리에 복사하고, 구동하고, 구형 프로그램 코드를 교체하기 전에 업데이트를 검증할 수 있다. 유사하게, 업데이트가 IoT 디바이스(101 내지 105) 각각에게 이용 가능한 경우, 업데이트는 초기에 IoT 허브(110)에 의해 다운로드되고 IoT 디바이스(101 내지 105) 각각에 푸시 아웃될 수 있다. 그 후, 각각의 IoT 디바이스(101 내지 105)는 IoT 허브에 대해 위에서 설명된 것과 유사한 방식으로 업데이트를 적용하고 업데이트의 결과를 IoT 허브(110)에 다시 보고할 수 있다. 업데이트가 성공적이면, IoT 허브(110)는 그것의 메모리로부터 업데이트를 삭제하고 (예를 들어, 그것이 각각의 IoT 디바이스에 대한 새로운 업데이트를 계속 체크할 수 있도록) 각각의 IoT 디바이스 상에 설치된 코드의 최신 버전을 기록할 수 있다.

일 실시예에서, IoT 허브(110)는 A/C 전력을 통해 전력공급된다. 특히, IoT 허브(110)는 A/C 전력 코드를 통해 공급된 A/C 전압을 더 낮은 DC 전압으로 변압시키기 위한 변압기를 갖는 전력 유닛(390)을 포함할 수 있다.

도 4a는 IoT 시스템을 사용하여 범용 원격 제어 동작을 수행하기 위한 본 발명의 일 실시예를 예시한다. 특히, 이 실시예에서, IoT 디바이스들(101 내지 103)의 세트에는 (몇 개만 예로 들자면) 에어컨/히터(430), 조명 시스템(431) 및 시청각 장비(432)를 포함한 다양한 상이한 타입의 전자 장비를 제어하기 위해 원격 제어 코드를 송신하기 위한 적외선(IR) 및/또는 라디오 주파수(RF) 블라스터들(401 내지 403)이 각각 탑재된다. 도 4a에 도시된 실시예에서, IoT 디바이스들(101 내지 103)에는 또한 후술되는 바와 같이 그들이 제어하는 디바이스들의 동작을 검출하기 위한 센서들(404 내지 406)이 각각 탑재된다.

예를 들어, IoT 디바이스(101) 내의 센서(404)는 현재의 온도/습도를 감지하고, 그에 응답하여 현재의 원하는 온도에 기초하여 에어컨/히터(430)를 제어하기 위한 온도 및/또는 습도 센서일 수 있다. 이 실시예에서, 에어컨/히터(430)는 원격 제어 디바이스(전형적으로 그 자체가 임베딩된 온도 센서를 갖는 리모트 컨트롤)를 통해 제어되도록 설계된 것이다. 일 실시예에서, 사용자는 사용자 디바이스(135) 상에 설치된 앱 또는 브라우저를 통해 IoT 허브(110)에 원하는 온도를 제공한다. IoT 허브(110) 상에서 실행되는 제어 로직(412)은 센서(404)로부터 현재 온도/습도 데이터를 수신하고, 그에 응답하여 원하는 온도/습도에 따라 IR/RF 블라스터(401)를 제어하기 위해 IoT 디바이스(101)에 커맨드를 송신한다. 예를 들어, 온도가 원하는 온도보다 낮으면, 제어 로직(412)은 IR/RF 블라스터(401)를 통해 에어컨/히터에 커맨드를 송신하여 (예를 들어, 에어컨을 턴오프하거나 히터를 턴온함으로써) 온도를 높일 수 있다. 커맨드는 IoT 허브(110) 상의 데이터베이스(413) 내에 저장된 필요한 원격 제어 코드를 포함할 수 있다. 대안적으로 또는 추가적으로, IoT 서비스(421)는 지정된 사용자 선호 및 저장된 제어 코드(422)에 기초하여 전자 장비(430 내지 432)를 제어하기 위한 제어 로직(421)을 구현할 수 있다.

예시된 예의 IoT 디바이스(102)는 조명(431)을 제어하는 데 사용된다. 특히, IoT 디바이스(102) 내의 센서(405)는 조명 설비(431)(또는 다른 조명 장치)에 의해 생성되는 광의 현재 밝기를 검출하도록 구성된 광센서 또는 광검출기일 수 있다. 사용자는 사용자 디바이스(135)를 통해 IoT 허브(110)에 원하는 조명 레벨(온 또는 오프의 지시를 포함함)을 지정할 수 있다. 이에 응답하여, 제어 로직(412)은 IR/RF 블라스터(402)에 커맨드를 송신하여, 발광체(431)의 현재 밝기 레벨을 제어할 것이다(예를 들어, 현재 밝기가 너무 낮으면 조명을 높이거나 현재 밝기가 너무 높으면 조명을 낮추거나; 단순히 발광체를 턴온 또는 턴오프함).

예시된 예의 IoT 디바이스(103)는 시청각 장비(432)(예를 들어, 텔레비전, A/V 수신기, 케이블/위성 수신기, 애플(Apple)TV™ 등)를 제어하도록 구성된다. IoT 디바이스(103) 내의 센서(406)는 현재의 주위 볼륨 레벨을 검출하기 위한 오디오 센서(예를 들어, 마이크로폰 및 관련 로직) 및/또는 텔레비전에 의해 생성된 광에 기초하여 (예를 들어, 지정된 스펙트럼 내의 광을 측정함으로써) 텔레비전이 온 또는 오프 상태인지를 검출하기 위한 광센서일 수 있다. 대안적으로, 센서(406)는 검출된 온도에 기초하여 오디오 장비가 온 또는 오프 상태인지를 검출하기 위해 시청각 장비에 접속된 온도 센서를 포함할 수 있다. 다시 한번, 사용자 디바이스(135)를 통한 사용자 입력에 응답하여, 제어 로직(412)은 IoT 디바이스(103)의 IR 블라스터(403)를 통해 시청각 장비에 커맨드를 송신할 수 있다.

전술한 내용은 단지 본 발명의 일 실시예의 예시적인 예에 불과하다는 점에 유의해야 한다. 본 발명의 기본 원리는 IoT 디바이스에 의해 제어될 임의의 특정 타입의 센서 또는 장비로 제한되지 않는다.

IoT 디바이스들(101 내지 103)이 블루투스 LE 접속을 통해 IoT 허브(110)에 결합되는 실시예에서, 센서 데이터 및 커맨드는 블루투스 LE 채널을 통해 전송된다. 그러나, 본 발명의 기본 원리는 블루투스 LE 또는 임의의 다른 통신 표준으로 제한되지 않는다.

일 실시예에서, 각각의 전자 장비를 제어하는 데 필요한 제어 코드는 IoT 허브(110) 상의 데이터베이스(413) 및/또는 IoT 서비스(120) 상의 데이터베이스(422)에 저장된다. 도 4b에 예시된 바와 같이, 제어 코드는 IoT 서비스(120) 상에서 유지되는 상이한 장비들에 대한 제어 코드들(422)의 마스터 데이터베이스로부터 IoT 허브(110)에 제공될 수 있다. 최종 사용자는 사용자 디바이스(135) 상에서 실행되는 앱 또는 브라우저를 통해 제어될 전자(또는 다른) 장비의 타입을 지정할 수 있으며, 그에 응답하여 IoT 허브 상의 원격 제어 코드 학습 모듈(491)은 IoT 서비스(120) 상의 원격 제어 코드 데이터베이스(492)에서 (예를 들어, 고유 ID를 갖는 각각의 전자 장비를 식별하는) 필요한 IR/RF 코드를 검색할 수 있다.

또한, 일 실시예에서, IoT 허브(110)에는 원격 제어 코드 학습 모듈(491)이 전자 장비와 함께 제공된 원래의 리모트 컨트롤(495)로부터 직접 새로운 원격 제어 코드를 "학습"하는 것을 가능하게 하는 IR/RF 인터페이스(490)가 탑재된다. 예를 들어, 에어컨(430)과 함께 제공된 원래의 리모트 컨트롤에 대한 제어 코드가 원격 제어 데이터베이스에 포함되어 있지 않으면, 사용자는 사용자 디바이스(135) 상의 앱/브라우저를 통해 IoT 허브(110)와 상호 작용하여, 원래의 리모트 컨트롤에 의해 생성된 다양한 제어 코드(예를 들어, 온도 증가, 온도 감소 등)를 IoT 허브(110)에게 교시할 수 있다. 원격 제어 코드가 학습되면, 이들은 IoT 허브(110) 상의 제어 코드 데이터베이스(413)에 저장되고/되거나, IoT 서비스(120)로 역전송되어 중앙 원격 제어 코드 데이터베이스(492)에 포함될 수 있다(그리고 후속하여 동일한 에어컨 유닛(430)을 갖는 다른 사용자에 의해 사용됨).

일 실시예에서, IoT 디바이스들(101 내지 103) 각각은 극히 작은 폼 팩터를 가지며, 양면 테이프, 작은 못, 자석 부착 등을 사용하여 그들 각자의 전자 장비(430 내지 432) 상에 또는 그 부근에 부착될 수 있다. 에어컨(430)과 같은 장비의 제어를 위해, 센서(404)가 집 안의 주위 온도를 정확하게 측정할 수 있도록 IoT 디바이스(101)를 충분히 멀리 배치하는 것이 바람직할 것이다(예를 들어, 에어컨 상에 직접 IoT 디바이스를 배치하는 것은 에어컨이 작동 중일 때 너무 낮거나 히터가 작동 중일 때 너무 높을 온도 측정치를 초래할 것임). 대조적으로, 조명을 제어하는 데 사용되는 IoT 디바이스(102)는 센서(405)가 현재 조명 레벨을 검출하기 위해 조명 설비(431) 상에 또는 그 부근에 배치될 수 있다.

설명된 바와 같은 일반적인 제어 기능을 제공하는 것 외에도, IoT 허브(110) 및/또는 IoT 서비스(120)의 일 실시예는 각각의 전자 장비의 현재 상태와 관련된 통지를 최종 사용자에게 송신한다. 텍스트 메시지 및/또는 앱-특정 통지일 수 있는 통지는 이어서 사용자의 모바일 디바이스(135)의 디스플레이 상에 표시될 수 있다. 예를 들어, 사용자의 에어컨이 장기간 동안 켜져 있었지만 온도가 변하지 않은 경우, IoT 허브(110) 및/또는 IoT 서비스(120)는 에어컨이 적절히 기능하고 있지 않다는 통지를 사용자에게 전송할 수 있다. 사용자가 집에 있지 않고(이는 모션 센서를 통해 또는 사용자의 현재 검출된 위치에 기초하여 검출될 수 있음), 센서(406)가 시청각 장비(430)가 켜져 있다는 것을 지시하거나, 센서(405)가 발광체가 켜져 있다는 것을 지시하는 경우, 사용자가 시청각 장비(432) 및/또는 발광체(431)를 턴오프하기를 원하는지를 묻는 통지가 사용자에게 전송될 수 있다. 임의의 장비 타입에 대해 동일한 타입의 통지가 전송될 수 있다.

사용자가 통지를 수신하면, 그/그녀는 사용자 디바이스(135) 상의 앱 또는 브라우저를 통해 전자 장비(430 내지 432)를 원격 제어할 수 있다. 일 실시예에서, 사용자 디바이스(135)는 터치 스크린 디바이스이고, 앱 또는 브라우저는 장비(430 내지 432)를 제어하기 위해 사용자가 선택할 수 있는 버튼을 갖는 리모트 컨트롤의 이미지를 표시한다. 통지를 수신하면, 사용자는 그래픽 리모트 컨트롤을 열고 다양한 상이한 장비를 턴오프하거나 조정할 수 있다. IoT 서비스(120)를 통해 접속되는 경우, 사용자의 선택은 IoT 서비스(120)로부터 IoT 허브(110)로 전송될 수 있으며, 이어서 IoT 허브(110)는 제어 로직(412)을 통해 장비를 제어할 것이다. 대안적으로, 사용자 입력은 사용자 디바이스(135)로부터 IoT 허브(110)로 직접 전송될 수 있다.

일 실시예에서, 사용자는 전자 장비(430 내지 432)에 대한 다양한 자동 제어 기능을 수행하도록 IoT 허브(110) 상의 제어 로직(412)을 프로그래밍할 수 있다. 전술한 바와 같이 원하는 온도, 밝기 레벨 및 볼륨 레벨을 유지하는 것 이외에, 제어 로직(412)은 소정 조건이 검출되면 전자 장비를 자동으로 턴오프할 수 있다. 예를 들어, 제어 로직(412)이 사용자가 집에 없고 에어컨이 기능하고 있지 않다는 것을 검출하면, 그것은 자동으로 에어컨을 턴오프할 수 있다. 유사하게, 사용자가 집에 없고, 센서(406)가 시청각 장비(430)가 켜져 있음을 지시하거나 센서(405)가 발광체가 켜져 있음을 지시하면, 제어 로직(412)은 IR/RF 블라스터(403, 402)를 통해 커맨드를 자동 송신하여, 시청각 장비 및 발광체를 각각 턴오프할 수 있다.

도 5는 전자 장비(530, 531)를 모니터링하기 위한 센서(503, 504)가 탑재된 IoT 디바이스(104, 105)의 추가 실시예를 예시한다. 특히, 이 실시예의 IoT 디바이스(104)는 스토브가 켜진 채로 있을 때를 검출하기 위해 스토브(530) 상에 또는 그 부근에 배치될 수 있는 온도 센서(503)를 포함한다. 일 실시예에서, IoT 디바이스(104)는 온도 센서(503)에 의해 측정된 현재 온도를 IoT 허브(110) 및/또는 IoT 서비스(120)로 송신한다. 스토브가 (예를 들어, 측정된 온도에 기초하여) 임계 기간을 초과하여 켜져 있는 것으로 검출되면, 제어 로직(512)은 사용자에게 스토브(530)가 켜져 있음을 알리는 통지를 최종 사용자의 디바이스(135)로 송신할 수 있다. 또한, 일 실시예에서, IoT 디바이스(104)는, 사용자로부터 명령을 수신하는 것에 응답하여 또는 (제어 로직(512)이 사용자에 의해 그렇게 하도록 프로그래밍된 경우) 자동으로, 스토브를 턴오프하기 위한 제어 모듈(501)을 포함할 수 있다. 일 실시예에서, 제어 로직(501)은 스토브(530)에 대한 전기 또는 가스를 차단하는 스위치를 포함한다. 그러나, 다른 실시예에서, 제어 로직(501)은 스토브 자체 내에 통합될 수 있다.

도 5는 또한 세탁기 및/또는 건조기와 같은 소정 타입의 전자 장비의 모션을 검출하기 위한 모션 센서(504)를 갖는 IoT 디바이스(105)를 예시한다. 사용될 수 있는 다른 센서는 주위 볼륨 레벨을 검출하기 위한 오디오 센서(예를 들어, 마이크로폰 및 로직)이다. 전술한 다른 실시예에서와 같이, 이 실시예는 소정의 지정된 조건이 충족되면(예를 들어, 모션이 장기간 동안 검출되어, 세탁기/건조기가 턴오프되지 않았음을 지시하는 경우) 최종 사용자에게 통지를 송신할 수 있다. 도 5에 도시되지 않지만, IoT 디바이스(105)에는 자동으로 그리고/또는 사용자 입력에 응답하여 (예를 들어, 전기/가스를 스위치 오프함으로써) 세탁기/건조기(531)를 턴오프하는 제어 모듈이 또한 탑재될 수 있다.

일 실시예에서, 제어 로직 및 스위치를 갖는 제1 IoT 디바이스는 사용자의 집 안의 모든 전력을 턴오프하도록 구성될 수 있고, 제어 로직 및 스위치를 갖는 제2 IoT 디바이스는 사용자의 집 안의 모든 가스를 턴오프하도록 구성될 수 있다. 이어서, 센서를 갖는 IoT 디바이스가 사용자의 집에 있는 전자 또는 가스 구동 장비 상에 또는 그 부근에 배치될 수 있다. 사용자가 특정 장비(예를 들어, 스토브(530))가 켜진 채로 있다는 통지를 받으면, 사용자는 손상을 방지하기 위해 집 안의 모든 전기 또는 가스를 턴오프하기 위한 커맨드를 전송할 수 있다. 대안적으로, IoT 허브(110) 및/또는 IoT 서비스(120) 내의 제어 로직(512)은 그러한 상황에서 전기 또는 가스를 자동으로 턴오프하도록 구성될 수 있다.

일 실시예에서, IoT 허브(110) 및 IoT 서비스(120)는 주기적인 간격으로 통신한다. IoT 서비스(120)가 (예를 들어, 지정된 지속시간 동안 IoT 허브로부터 요청 또는 응답을 수신하지 못함으로써) IoT 허브(110)에 대한 접속이 손실된 것을 검출하면, (예를 들어, 텍스트 메시지 또는 앱-특정 통지를 전송함으로써) 이러한 정보를 최종 사용자의 디바이스(135)로 통신할 것이다.

중개 디바이스를 통해 데이터를 통신하기 위한 장치 및 방법

상기에 언급된 바와 같이, 블루투스 LE와 같은 IoT 디바이스들을 상호접속하는 데 사용되는 무선 기술들은 일반적으로 단거리 기술들이기 때문에, IoT 구현을 위한 허브가 IoT 디바이스의 범위 밖에 있는 경우, IoT 디바이스는 데이터를 IoT 허브로 송신할 수 없을 것이다(그리고 그 반대도 마찬가지다).

이러한 결함을 해결하기 위해, 본 발명의 일 실시예는 IoT 허브의 무선 범위 밖에 있는 IoT 디바이스가 모바일 디바이스들이 범위 내에 있을 때 하나 이상의 모바일 디바이스와 주기적으로 접속하기 위한 메커니즘을 제공한다. 일단 접속되면, IoT 디바이스는 IoT 허브에 제공될 필요가 있는 임의의 데이터를 모바일 디바이스로 송신할 수 있으며, 이어서 모바일 디바이스는 데이터를 IoT 허브로 전송한다.

도 6에 예시된 바와 같이, 일 실시예는 IoT 허브(110), IoT 허브(110)의 범위 밖에 있는 IoT 디바이스(601), 및 모바일 디바이스(611)를 포함한다. 범위 밖에 있는 IoT 디바이스(601)는 데이터를 수집 및 통신할 수 있는 임의의 형태의 IoT 디바이스를 포함할 수 있다. 예를 들어, IoT 디바이스(601)는 냉장고에서 이용 가능한 음식 아이템들, 음식 아이템들을 소비하는 사용자들, 및 현재 온도를 모니터링하기 위해 냉장고 내에 구성된 데이터 수집 디바이스를 포함할 수 있다. 물론, 본 발명의 기본 원리는 IoT 디바이스의 임의의 특정 타입으로 제한되지 않는다. 본 명세서에서 설명되는 기술들은, 단지 몇 가지 예를 들자면, 스마트 미터, 스토브, 세탁기, 건조기, 조명 시스템, HVAC 시스템 및 시청각 장비에 대한 데이터를 수집 및 송신하는 데 사용되는 것들을 포함한 임의의 타입의 IoT 디바이스를 사용하여 구현될 수 있다.

더욱이, 도 6에 예시된 모바일 디바이스(611)는 데이터를 통신 및 저장할 수 있는 임의의 형태의 모바일 디바이스일 수 있다. 예를 들어, 일 실시예에서, 모바일 디바이스(611)는 본 명세서에서 설명되는 기술들을 촉진하기 위한 앱이 설치된 스마트폰이다. 다른 실시예에서, 모바일 디바이스(611)는 목걸이 또는 팔찌에 부착된 통신 토큰, 스마트워치 또는 피트니스 디바이스와 같은 웨어러블 디바이스를 포함한다. 스마트폰 디바이스를 소유하지 않은 노년 사용자들 또는 다른 사용자들에게 웨어러블 토큰이 특히 유용할 수 있다.

동작 시, 범위 밖에 있는 IoT 디바이스(601)는 모바일 디바이스(611)와의 접속성을 주기적으로 또는 계속적으로 체크할 수 있다. (예를 들어, 사용자가 냉장고의 부근 내에서 이동하는 결과로서) 접속이 설정되면, IoT 디바이스(601) 상의 임의의 수집된 데이터(605)가 모바일 디바이스(611) 상의 임시 데이터 저장소(615)로 자동 송신된다. 일 실시예에서, IoT 디바이스(601) 및 모바일 디바이스(611)는 BTLE와 같은 저전력 무선 표준을 사용하여 로컬 무선 통신 채널을 설정한다. 그러한 경우, 모바일 디바이스(611)는 공지된 페어링 기술들을 이용하여 초기에 IoT 디바이스(601)와 페어링될 수 있다.

일단 데이터가 임시 데이터 저장소로 전송되면, (예를 들어, 사용자가 IoT 허브(110)의 범위 내에서 걸을 때) 일단 IoT 허브(110)와의 통신이 설정되면 모바일 디바이스(611)는 데이터를 송신할 것이다. 이어서, IoT 허브는 데이터를 중앙 데이터 저장소(413)에 저장하고/하거나, 데이터를 인터넷을 통해 하나 이상의 서비스 및/또는 다른 사용자 디바이스로 전송할 수 있다. 일 실시예에서, 모바일 디바이스(611)는 상이한 타입의 통신 채널(잠재적으로는 WiFi와 같은 고전력 통신 채널)을 사용하여 데이터를 IoT 허브(110)에 제공할 수 있다.

범위 밖에 있는 IoT 디바이스(601), 모바일 디바이스(611) 및 IoT 허브는 모두가 본 명세서에서 설명되는 기술들을 구현하기 위한 프로그램 코드 및/또는 로직으로 구성될 수 있다. 도 7에 예시된 바와 같이, 예를 들어, 본 명세서에서 설명되는 동작들을 수행하기 위해, IoT 디바이스(601)는 중개 접속 로직 및/또는 애플리케이션으로 구성될 수 있고, 모바일 디바이스(611)는 중개 접속 로직/애플리케이션으로 구성될 수 있고, IoT 허브(110)는 중개 접속 로직/애플리케이션(721)으로 구성될 수 있다. 각각의 디바이스 상의 중개 접속 로직/애플리케이션은 하드웨어, 소프트웨어 또는 이들의 임의의 조합으로 구현될 수 있다. 일 실시예에서, IoT 디바이스(601)의 중개 접속 로직/애플리케이션(701)은 (디바이스 앱으로서 구현될 수 있는) 모바일 디바이스 상의 중개 접속 로직/애플리케이션(711)과의 접속을 검색 및 설정하여 데이터를 임시 데이터 저장소(615)로 전송한다. 이어서, 모바일 디바이스(611) 상의 중개 접속 로직/애플리케이션(701)은 데이터를 IoT 허브 상의 중개 접속 로직/애플리케이션으로 전송하며, IoT 허브는 데이터를 중앙 데이터 저장소(413)에 저장한다.

도 7에 예시된 바와 같이, 각각의 디바이스 상의 중개 접속 로직/애플리케이션(701, 711, 721)은 가까운 곳에 있는 응용에 기초하여 구성될 수 있다. 예를 들어, 냉장고의 경우, 접속 로직/애플리케이션(701)은 소수의 패킷을 주기적으로 송신하는 것만이 필요할 수 있다. 다른 응용들(예를 들어, 온도 센서들)의 경우, 접속 로직/애플리케이션(701)은 더 빈번한 업데이트들을 송신하는 것이 필요할 수 있다.

모바일 디바이스(611)보다는, 일 실시예에서, IoT 디바이스(601)는 IoT 허브(110)의 범위 내에 위치되는 하나 이상의 중개 IoT 디바이스와의 무선 접속을 설정하도록 구성될 수 있다. 이 실시예에서, IoT 허브의 범위 밖에 있는 임의의 IoT 디바이스들(601)은 다른 IoT 디바이스들을 사용하여 "체인"을 형성함으로써 허브에 링크될 수 있다.

또한, 도 6 및 도 7에는 간략함을 위해 단일 모바일 디바이스(611)만이 예시되지만, 일 실시예에서, 상이한 사용자들의 다수의 그러한 모바일 디바이스가 IoT 디바이스(601)와 통신하도록 구성될 수 있다. 더욱이, 동일한 기술들이 다수의 다른 IoT 디바이스에 대해 구현될 수 있으며, 이에 의해 집 전체에 걸친 중개 디바이스 데이터 수집 시스템이 형성될 수 있다.

더욱이, 일 실시예에서, 본 명세서에서 설명되는 기술들은 다양한 상이한 타입의 적절한 데이터를 수집하는 데 사용될 수 있다. 예를 들어, 일 실시예에서, 모바일 디바이스(611)가 IoT 디바이스(601)와 접속할 때마다, 사용자의 아이덴티티가 수집된 데이터(605)에 포함될 수 있다. 이러한 방식으로, IoT 시스템은 집 안의 상이한 사용자들의 거동을 추적하는 데 사용될 수 있다. 예를 들어, 냉장고 안에서 사용되는 경우, 수집된 데이터(605)는 냉장고 옆을 지나가는 각각의 사용자, 냉장고를 여는 각각의 사용자, 및 각각의 사용자에 의해 소비되는 특정 음식 아이템들의 아이덴티티를 포함할 수 있다. 상이한 타입의 데이터가 다른 타입의 IoT 디바이스들로부터 수집될 수 있다. 이러한 데이터를 사용하여, 시스템은 예를 들어 어느 사용자가 옷을 세탁하는지, 어느 사용자가 주어진 날에 TV를 시청하는지, 각각의 사용자가 자러 가고 일어나는 시간 등을 결정할 수 있다. 이어서, 이러한 크라우드 소싱된(crowd-sourced) 데이터 모두가 IoT 허브의 데이터 저장소(413) 내에 집계되고/되거나 외부 서비스 또는 사용자에게 전송될 수 있다.

본 명세서에서 설명되는 기술들의 다른 유리한 응용은 도움을 필요로 할 수 있는 노년 사용자들을 모니터링하는 것이다. 이러한 응용을 위해, 모바일 디바이스(611)는 사용자의 집의 상이한 방들에서 정보를 수집하기 위해 노년 사용자에 의해 착용되는 매우 작은 토큰일 수 있다. 예를 들어, 사용자가 냉장고를 열 때마다, 이러한 데이터가 수집된 데이터(605)에 포함되어 토큰을 통해 IoT 허브(110)로 전송될 것이다. 이어서, IoT 허브는 데이터를 하나 이상의 외부 사용자(예를 들어, 노년 사용자를 돌보는 자식들 또는 다른 개인들)에게 제공할 수 있다. 데이터가 지정된 기간(예를 들어, 12시간) 동안 수집되지 않은 경우, 이것은 노년 사용자가 집 주위에서 이동하지 않았고/않았거나 냉장고를 열지 않았음을 의미한다. 이어서, IoT 허브(110) 또는 IoT 허브에 접속된 외부 서비스가 경고 통지를 이러한 다른 개인들에게 송신하여, 그들이 노년 사용자를 체크해야 한다는 것을 그들에게 알릴 수 있다. 또한, 수집된 데이터(605)는 사용자에 의해 소비되고 있는 음식 및 식료품 가게에 가는 것이 필요한지, 노년 사용자가 TV를 시청하고 있는지 그리고 얼마나 자주 시청하는지, 노년 사용자가 옷을 세탁하는 빈도 등과 같은 다른 적절한 정보를 포함할 수 있다.

다른 구현에서, 세탁기, 냉장고, HVAC 시스템 등과 같은 전자 디바이스에 관한 문제가 있는 경우, 수집된 데이터는 교체가 필요한 부품의 지시를 포함할 수 있다. 그러한 경우, 문제 해결의 요청과 함께 통지가 기술자에게 전송될 수 있다. 이어서, 기술자는 필요한 교체 부품을 갖고서 집에 도착할 수 있다.

본 발명의 일 실시예에 따른 방법이 도 8에 예시된다. 방법은 상기에 기술된 아키텍처들의 맥락 내에서 구현될 수 있지만, 임의의 특정 아키텍처로 제한되지 않는다.

801에서, IoT 허브의 범위 밖에 있는 IoT 디바이스가 데이터(예를 들어, 냉장고 문의 개방, 사용된 음식 아이템 등)를 주기적으로 수집한다. 802에서, IoT 디바이스는 (예를 들어, BTLE 표준에 의해 지정된 것들과 같은, 접속을 설정하기 위한 표준 로컬 무선 기술들을 사용하여) 모바일 디바이스와의 접속성을 주기적으로 또는 계속적으로 체크한다. 모바일 디바이스에 대한 접속이 설정된 것으로 802에서 결정되면, 803에서, 수집된 데이터가 803에서 모바일 디바이스로 전송된다. 804에서, 모바일 디바이스는 데이터를 IoT 허브, 외부 서비스 및/또는 사용자에게 전송한다. 언급된 바와 같이, 모바일 디바이스는 (예를 들어, WiFi 링크를 통해) 이미 접속된 경우에는 즉시 데이터를 송신할 수 있다.

IoT 디바이스들로부터 데이터를 수집하는 것에 더하여, 일 실시예에서, 본 명세서에서 설명되는 기술들은 데이터를 IoT 디바이스들에 업데이트하거나 달리 제공하는 데 사용될 수 있다. 일례가 도 9a에 도시되며, 이 도면은 IoT 디바이스(601)(또는 그러한 IoT 디바이스들의 그룹) 상에 설치될 필요가 있는 프로그램 코드 업데이트들(901)을 갖는 IoT 허브(110)를 도시한다. 프로그램 코드 업데이트들은 IoT 디바이스가 사용자에 의해 요구되는 대로 동작하는 데 필요한 시스템 업데이트들, 패치들, 구성 데이터 및 임의의 다른 데이터를 포함할 수 있다. 일 실시예에서, 사용자는 모바일 디바이스 또는 컴퓨터를 통해 IoT 디바이스(601)에 대한 구성 옵션들을 지정할 수 있으며, 이어서 이들은 IoT 허브(110) 상에 저장되고, 본 명세서에서 설명되는 기술들을 사용하여 IoT 디바이스에 제공된다. 구체적으로, 일 실시예에서, IoT 허브(110) 상의 중개 접속 로직/애플리케이션(721)은 모바일 디바이스(611) 상의 중개 접속 로직/애플리케이션(711)과 통신하여, 프로그램 코드 업데이트들을 임시 저장소(615) 내에 저장한다. 모바일 디바이스(611)가 IoT 디바이스(601)의 범위에 들어갈 때, 모바일 디바이스(611) 상의 중개 접속 로직/애플리케이션(711)은 IoT 디바이스(601) 상의 중개 접속 로직/애플리케이션(701)과 접속하여 프로그램 코드 업데이트들을 디바이스에 제공한다. 일 실시예에서, 이어서, IoT 디바이스(601)는 자동화된 업데이트 프로세스에 들어가서, 새로운 프로그램 코드 업데이트들 및/또는 데이터를 설치할 수 있다.

IoT 디바이스를 업데이트하기 위한 방법이 도 9b에 도시된다. 방법은 상기에 기술된 시스템 아키텍처의 맥락 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

900에서, 새로운 프로그램 코드 또는 데이터 업데이트들이 (예를 들어, 인터넷을 통해 모바일 디바이스에 결합된) IoT 허브 및/또는 외부 서비스 상에서 이용 가능해진다. 901에서, 모바일 디바이스는 IoT 디바이스를 대신하여 프로그램 코드 또는 데이터 업데이트들을 수신 및 저장한다. IoT 디바이스 및/또는 모바일 디바이스는 902에서 접속이 설정되었는지를 결정하기 위해 주기적으로 체크한다. 접속이 설정된 것으로 903에서 결정되면, 904에서, 업데이트들이 IoT 디바이스로 전송되어 설치된다.

개선된 보안을 위한 실시예들

일 실시예에서, 각각의 IoT 디바이스(101)의 저전력 마이크로제어기(200) 및 IoT 허브(110)의 저전력 로직/마이크로제어기(301)는 후술되는 실시예에 의해 사용되는 암호화 키를 저장하기 위한 보안 키 저장소를 포함한다(예를 들어, 도 10 내지 도 15 및 관련 텍스트 참조). 대안적으로, 키는 아래에서 논의되는 바와 같이 가입자 식별 모듈(SIM)에서 보안될 수 있다.

도 10은 IoT 서비스(120), IoT 허브(110) 및 IoT 디바이스(101, 102) 간의 통신을 암호화하기 위해 공개 키 기반구조(PKI) 기술 및/또는 대칭 키 교환/암호화 기술을 사용하는 고레벨 아키텍처를 예시한다.

공개/비공개 키 쌍을 사용하는 실시예가 먼저 설명될 것이고, 이어서 대칭 키 교환/암호화 기술을 사용하는 실시예가 설명될 것이다. 특히, PKI를 사용하는 실시예에서는, 고유 공개/비공개 키 쌍이 각각의 IoT 디바이스(101, 102), 각각의 IoT 허브(110) 및 IoT 서비스(120)와 관련된다. 일 실시예에서, 새로운 IoT 허브(110)가 설정될 때, 그것의 공개 키가 IoT 서비스(120)에 제공되고, 새로운 IoT 디바이스(101)가 설정될 때, 그것의 공개 키가 IoT 허브(110) 및 IoT 서비스(120) 둘 모두에 제공된다. 디바이스들 사이에서 공개 키를 안전하게 교환하기 위한 다양한 기술이 아래에서 설명된다. 일 실시예에서, 임의의 수신 디바이스가 서명을 확인함으로써 공개 키의 유효성을 검증할 수 있도록 모든 수신 디바이스에 알려진(즉, 인증서 형태의) 마스터 키에 의해 모든 공개 키가 서명된다. 따라서, 단지 원시 공개 키만을 교환하기보다는 이러한 인증서가 교환될 것이다.

예시된 바와 같이, 일 실시예에서, 각각의 IoT 디바이스(101, 102)는 각각의 디바이스의 비공개 키를 보안 저장하기 위한 보안 키 저장소(1001, 1003)를 각각 포함한다. 이어서, 보안 로직(1002, 1304)은 안전하게 저장된 비공개 키를 사용하여 본 명세서에 설명된 암호화/해독 동작을 수행한다. 유사하게, IoT 허브(110)는 IoT 허브 비공개 키 및 IoT 디바이스(101, 102) 및 IoT 서비스(120)의 공개 키를 저장하기 위한 보안 저장소(1011)뿐만 아니라, 키를 사용하여 암호화/해독 동작을 수행하기 위한 보안 로직(1012)을 포함한다. 마지막으로, IoT 서비스(120)는 그 자신의 비공개 키, 다양한 IoT 디바이스 및 IoT 허브의 공개 키를 보안 저장하기 위한 보안 저장소(1021), 및 키를 사용하여 IoT 허브 및 디바이스와의 통신을 암호화/해독하기 위한 보안 로직(1013)을 포함할 수 있다. 일 실시예에서, IoT 허브(110)가 IoT 디바이스로부터 공개 키 인증서를 수신할 때, IoT 허브는 (예를 들어, 전술한 바와 같이 마스터 키를 사용하여 서명을 확인함으로써) 그것을 검증할 수 있고, 이어서 그것 내부로부터 공개 키를 추출하여 그 공개 키를 그것의 보안 키 저장소(1011)에 저장할 수 있다.

예로서, 일 실시예에서, IoT 서비스(120)가 커맨드 또는 데이터(예를 들어, 도어를 열기 위한 커맨드, 센서를 판독하기 위한 요청, IoT 디바이스에 의해 처리/표시될 데이터 등)를 IoT 디바이스(101)로 송신할 필요가 있을 때, 보안 로직(1013)은 IoT 디바이스(101)의 공개 키를 사용하여 데이터/커맨드를 암호화하여 암호화된 IoT 디바이스 패킷을 생성한다. 일 실시예에서, 보안 로직은 이어서 IoT 허브(110)의 공개 키를 사용하여 IoT 디바이스 패킷을 암호화하여 IoT 허브 패킷을 생성하고 IoT 허브 패킷을 IoT 허브(110)로 송신한다. 일 실시예에서, 서비스(120)는 암호화된 메시지를 그것의 비공개 키 또는 상기에 언급된 마스터 키로 서명하여, 디바이스(101)는 그것이 신뢰 소스로부터 변경되지 않은 메시지를 수신하고 있는지를 검증할 수 있다. 이어서, 디바이스(101)는 비공개 키 및/또는 마스터 키에 대응하는 공개 키를 사용하여 서명을 확인할 수 있다. 전술한 바와 같이, 공개/비공개 키 암호화 대신에 대칭 키 교환/암호화 기술이 사용될 수 있다. 이들 실시예에서, 하나의 키를 비공개적으로 저장하고 대응하는 공개 키를 다른 디바이스에 제공하기보다는, 디바이스들은 각각 암호화에 사용되고 서명을 확인하는 데 사용되는 동일한 대칭 키의 사본을 제공받을 수 있다. 대칭 키 알고리즘의 일례는 진보된 암호화 표준(AES)이지만, 본 발명의 기본 원리는 임의의 타입의 특정 대칭 키로 제한되지 않는다.

대칭 키 구현을 사용하여, 각각의 디바이스(101)는 IoT 허브(110)와 대칭 키를 교환하기 위해 보안 키 교환 프로토콜에 들어간다. 동적 대칭 키 프로비저닝 프로토콜(DSKPP)과 같은 보안 키 프로비저닝 프로토콜이 보안 통신 채널을 통해 키를 교환하는 데 사용될 수 있다(예를 들어, RFC(Request for Comments) 6063 참조). 그러나, 본 발명의 기본 원리는 임의의 특정 키 프로비저닝 프로토콜로 제한되지 않는다.

일단 대칭 키가 교환되면, 대칭 키는 통신을 암호화하기 위해 각각의 디바이스(101) 및 IoT 허브(110)에 의해 사용될 수 있다. 유사하게, IoT 허브(110) 및 IoT 서비스(120)는 보안 대칭 키 교환을 수행한 다음, 교환된 대칭 키를 사용하여 통신을 암호화할 수 있다. 일 실시예에서, 새로운 대칭 키가 디바이스(101)와 허브(110) 사이에서 그리고 허브(110)와 IoT 서비스(120) 사이에서 주기적으로 교환된다. 일 실시예에서, 새로운 대칭 키가 디바이스(101), 허브(110) 및 서비스(120) 사이에서 각각의 새로운 통신 세션을 이용하여 교환된다(예를 들어, 새로운 키가 생성되고 각각의 통신 세션 동안 안전하게 교환된다). 일 실시예에서, IoT 허브 내의 보안 모듈(1012)이 신뢰되는 경우, 서비스(120)는 허브 보안 모듈(1312)과 세션 키를 협상할 수 있고, 이어서 보안 모듈(1012)은 각각의 디바이스(120)와 세션 키를 협상할 것이다. 이어서, 서비스(120)로부터의 메시지가 디바이스(101)로의 송신을 위해 재암호화되기 전에 허브 보안 모듈(1012)에서 해독 및 검증될 것이다.

일 실시예에서, 허브 보안 모듈(1012) 상의 타협(compromise)을 방지하기 위해, 설치 시에 1회(영구) 설치 키가 디바이스(101)와 서비스(120) 사이에서 협상될 수 있다. 메시지를 디바이스(101)로 전송할 때, 서비스(120)는 먼저 이 디바이스 설치 키로 암호화/MAC하고, 이어서 허브의 세션 키로 암호화/MAC할 수 있다. 이어서, 허브(110)는 암호화된 디바이스 블롭(device blob)을 검증 및 추출하여, 이를 디바이스로 전송할 것이다.

본 발명의 일 실시예에서, 재생 공격을 방지하기 위해 카운터 메커니즘이 구현된다. 예를 들어, 디바이스(101)로부터 허브(110)로의(또는 그 반대로의) 각각의 연속적인 통신이 계속 증가하는 카운터 값을 할당받을 수 있다. 허브(110) 및 디바이스(101) 둘 모두는 이 값을 추적하고 이 값이 디바이스들 간의 각각의 연속적인 통신에서 정확한지를 검증할 것이다. 동일한 기술이 허브(110)와 서비스(120) 사이에서 구현될 수 있다. 이러한 방식으로 카운터를 사용하는 것은 (카운터 값이 부정확할 것이기 때문에) 각각의 디바이스들 간의 통신을 스푸핑(spoofing)하는 것을 더 어렵게 할 것이다. 그러나, 이것 없이도, 서비스와 디바이스 사이의 공유 설치 키가 모든 디바이스에 대한 네트워크(허브) 전반적 공격을 방지할 것이다.

일 실시예에서, 공개/비공개 키 암호화를 사용할 때, IoT 허브(110)는 그것의 비공개 키를 사용하여 IoT 허브 패킷을 해독하고 암호화된 IoT 디바이스 패킷을 생성하여, 이것을 관련 IoT 디바이스(101)로 송신한다. 이어서, IoT 디바이스(101)는 그것의 비공개 키를 사용하여 IoT 디바이스 패킷을 해독하여, IoT 서비스(120)로부터 시작되는 커맨드/데이터를 생성한다. 이어서, IoT 디바이스는 데이터를 처리하고/하거나 커맨드를 실행할 수 있다. 대칭 암호화를 사용하여, 각각의 디바이스는 공유 대칭 키를 사용하여 암호화하고 해독할 것이다. 어느 경우에나, 각각의 송신 디바이스는 또한 메시지를 그것의 비공개 키로 서명할 수 있어서, 수신 디바이스는 그것의 진정성을 검증할 수 있다.

IoT 디바이스(101)로부터 IoT 허브(110)로의 그리고 IoT 서비스(120)로의 통신을 암호화하기 위해 상이한 키 세트가 사용될 수 있다. 예를 들어, 공개/비공개 키 배열을 사용하여, 일 실시예에서, IoT 디바이스(101) 상의 보안 로직(1002)은 IoT 허브(110)의 공개 키를 사용하여, IoT 허브(110)로 전송되는 데이터 패킷을 암호화한다. 이어서, IoT 허브(110) 상의 보안 로직(1012)은 IoT 허브의 비공개 키를 사용하여 데이터 패킷을 해독할 수 있다. 유사하게, IoT 디바이스(101) 상의 보안 로직(1002) 및/또는 IoT 허브(110) 상의 보안 로직(1012)은 IoT 서비스(120)의 공개 키를 사용하여 IoT 서비스(120)로 전송되는 데이터 패킷을 암호화할 수 있다(데이터 패킷은 이어서 IoT 서비스(120) 상의 보안 로직(1013)에 의해 서비스의 비공개 키를 사용하여 해독될 수 있다). 대칭 키를 사용하는 경우, 디바이스(101) 및 허브(110)는 하나의 대칭 키를 공유할 수 있는 반면, 허브 및 서비스(120)는 상이한 대칭 키를 공유할 수 있다.

소정의 특정 상세가 위의 설명에서 기재되지만, 본 발명의 기본 원리는 다양한 상이한 암호화 기술을 사용하여 구현될 수 있다는 점에 유의해야 한다. 예를 들어, 상기에 논의된 일부 실시예는 비대칭 공개/비공개 키 쌍을 사용하지만, 대안적인 실시예는 다양한 IoT 디바이스(101, 102), IoT 허브(110) 및 IoT 서비스(120) 사이에서 안전하게 교환되는 대칭 키를 사용할 수 있다. 더욱이, 일부 실시예에서, 데이터/커맨드 그 자체가 암호화되는 것이 아니라, 키가 데이터/커맨드(또는 다른 데이터 구조)에 대한 서명을 생성하는 데 사용된다. 이어서, 수신자는 그것의 키를 사용하여 서명을 확인할 수 있다.

도 11에 예시된 바와 같이, 일 실시예에서, 각각의 IoT 디바이스(101) 상의 보안 키 저장소는 프로그래밍 가능 가입자 식별 모듈(SIM)(1101)을 사용하여 구현된다. 이 실시예에서, IoT 디바이스(101)는 처음에, IoT 디바이스(101) 상의 SIM 인터페이스(1100) 내에 안착되는 프로그래밍되지 않은 SIM 카드(1101)와 함께 최종 사용자에게 제공될 수 있다. 하나 이상의 암호화 키의 세트를 갖도록 SIM을 프로그래밍하기 위해, 사용자는 SIM 인터페이스(500)로부터 프로그래밍 가능 SIM 카드(1101)를 취하여, 그것을 IoT 허브(110) 상의 SIM 프로그래밍 인터페이스(1102) 안에 삽입한다. 이어서, IoT 허브 상의 프로그래밍 로직(1125)은 SIM 카드(1101)를 안전하게 프로그래밍하여, IoT 디바이스(101)를 IoT 허브(110) 및 IoT 서비스(120)에 대해 등록/페어링한다. 일 실시예에서, 공개/비공개 키 쌍이 프로그래밍 로직(1125)에 의해 무작위로 생성될 수 있고, 이어서 쌍의 공개 키는 IoT 허브의 보안 저장 디바이스(411)에 저장될 수 있는 반면, 비공개 키는 프로그래밍 가능 SIM(1101) 내에 저장될 수 있다. 게다가, 프로그래밍 로직(525)은 IoT 허브(110), IoT 서비스(120) 및/또는 임의의 다른 IoT 디바이스(101)의 공개 키를 (IoT 디바이스(101) 상의 보안 로직(1302)에 의해 발신 데이터를 암호화하는 데 사용되도록) SIM 카드(1401) 상에 저장할 수 있다. 일단 SIM(1101)이 프로그래밍되면, 새로운 IoT 디바이스(101)는 SIM을 보안 식별자로서 사용하여(예를 들어, SIM을 사용하여 디바이스를 등록하기 위한 기존 기술을 사용하여) IoT 서비스(120)로 프로비저닝될 수 있다. 프로비저닝 후에, IoT 허브(110) 및 IoT 서비스(120) 둘 모두는 IoT 디바이스(101)와의 통신을 암호화할 때 사용될 IoT 디바이스의 공개 키의 사본을 안전하게 저장할 것이다.

도 11과 관련하여 전술한 기술은 새로운 IoT 디바이스를 최종 사용자에게 제공할 때 엄청난 유연성을 제공한다. 사용자가 (현재 행해지고 있는 바와 같이) 판매/구매 시에 각각의 SIM을 특정 서비스 제공자에 직접 등록할 것을 요구하기보다는, SIM은 IoT 허브(110)를 통해 최종 사용자에 의해 직접 프로그래밍될 수 있고 프로그래밍의 결과는 IoT 서비스(120)로 안전하게 통신될 수 있다. 결과적으로, 새로운 IoT 디바이스(101)는 온라인 또는 로컬 소매상으로부터 최종 사용자에게 판매될 수 있고, 나중에 IoT 서비스(120)로 안전하게 프로비저닝될 수 있다.

등록 및 암호화 기술이 SIM(가입자 식별 모듈)의 특정 맥락에서 전술되지만, 본 발명의 기본 원리는 "SIM" 디바이스로 제한되지 않는다. 오히려, 본 발명의 기본 원리는 암호화 키 세트를 저장하기 위한 보안 저장소를 갖는 임의의 타입의 디바이스를 사용하여 구현될 수 있다. 또한, 위의 실시예가 이동 가능한 SIM 디바이스를 포함하지만, 일 실시예에서, SIM 디바이스는 이동 가능한 것이 아니라, IoT 디바이스 그 자체가 IoT 허브(110) 상의 프로그래밍 인터페이스(1102) 내에 삽입될 수 있다.

일 실시예에서, 사용자가 SIM(또는 다른 디바이스)을 프로그래밍할 것을 요구하기보다는, SIM은 최종 사용자에게 배포되기 전에 IoT 디바이스(101) 내에 미리 프로그래밍된다. 이 실시예에서, 사용자가 IoT 디바이스(101)를 설정할 때, 본 명세서에서 설명되는 다양한 기술은 IoT 허브(110)/IoT 서비스(120)와 새로운 IoT 디바이스(101) 사이에서 암호화 키를 안전하게 교환하는 데 사용될 수 있다.

예를 들어, 도 12a에 예시된 바와 같이, 각각의 IoT 디바이스(101) 또는 SIM(401)은 IoT 디바이스(101) 및/또는 SIM(1001)을 고유하게 식별하는 바코드 또는 QR 코드(1501)와 함께 패키징될 수 있다. 일 실시예에서, 바코드 또는 QR 코드(1201)는 IoT 디바이스(101) 또는 SIM(1001)에 대한 공개 키의 인코딩된 표현을 포함한다. 대안적으로, 바코드 또는 QR 코드(1201)는 IoT 허브(110) 및/또는 IoT 서비스(120)에 의해 공개 키를 식별하거나 생성하는 데 사용될 수 있다(예를 들어, 보안 저장소에 이미 저장된 공개 키에 대한 포인터로서 사용될 수 있다). 바코드 또는 QR 코드(601)는 (도 12a에 도시된 바와 같이) 별도의 카드 상에 인쇄될 수 있거나 IoT 디바이스 그 자체 상에 직접 인쇄될 수 있다. 바코드가 인쇄되는 곳에 관계없이, 일 실시예에서, IoT 허브(110)에는 바코드를 판독하고 결과적인 데이터를 IoT 허브(110) 상의 보안 로직(1012) 및/또는 IoT 서비스(120) 상의 보안 로직(1013)에 제공하기 위한 바코드 판독기(206)가 탑재된다. 이어서, IoT 허브(110) 상의 보안 로직(1012)은 IoT 디바이스에 대한 공개 키를 그것의 보안 키 저장소(1011) 내에 저장할 수 있고, IoT 서비스(120) 상의 보안 로직(1013)은 공개 키를 (후속 암호화된 통신에 사용되도록) 그것의 보안 저장소(1021) 내에 저장할 수 있다.

일 실시예에서, 바코드 또는 QR 코드(1201)에 포함되는 데이터는 또한 IoT 서비스 제공자에 의해 설계된 IoT 앱 또는 브라우저 기반 애플릿이 설치된 (예를 들어, 아이폰 또는 안드로이드 디바이스와 같은) 사용자 디바이스(135)를 통해 캡처될 수 있다. 일단 캡처되면, 바코드 데이터는 (예를 들어, 보안 소켓 계층(SSL) 접속과 같은) 보안 접속을 통해 IoT 서비스(120)로 안전하게 통신될 수 있다. 바코드 데이터는 또한 보안 로컬 접속을 통해(예를 들어, 로컬 WiFi 또는 블루투스 LE 접속을 통해) 클라이언트 디바이스(135)로부터 IoT 허브(110)로 제공될 수 있다.

IoT 디바이스(101) 상의 보안 로직(1002) 및 IoT 허브(110) 상의 보안 로직(1012)은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 임의의 조합을 사용하여 구현될 수 있다. 예를 들어, 일 실시예에서, 보안 로직(1002, 1012)은 IoT 디바이스(101)와 IoT 허브(110) 사이에 로컬 통신 채널(130)을 설정하는 데 사용되는 칩(예를 들어, 로컬 채널(130)이 블루투스 LE인 경우에 블루투스 LE 칩) 내에 구현된다. 보안 로직(1002, 1012)의 특정 위치에 관계없이, 일 실시예에서, 보안 로직(1002, 1012)은 소정 타입의 프로그램 코드를 실행하기 위한 보안 실행 환경을 설정하도록 설계된다. 이것은 예를 들어 트러스트존(TrustZone) 기술(일부 ARM 프로세서 상에서 이용 가능함) 및/또는 신뢰 실행 기술(Trusted Execution Technology)(인텔(Intel)에 의해 설계됨)을 사용하여 구현될 수 있다. 물론, 본 발명의 기본 원리는 임의의 특정 타입의 보안 실행 기술로 제한되지 않는다.

일 실시예에서, 바코드 또는 QR 코드(1501)는 각각의 IoT 디바이스(101)를 IoT 허브(110)와 페어링하는 데 사용될 수 있다. 예를 들어, 블루투스 LE 디바이스를 페어링하기 위해 현재 사용되는 표준 무선 페어링 프로세스를 사용하기보다는, 바코드 또는 QR 코드(1501) 내에 임베딩되는 페어링 코드가 IoT 허브를 대응하는 IoT 디바이스와 페어링하기 위해 IoT 허브(110)에 제공될 수 있다.

도 12b는 IoT 허브(110) 상의 바코드 판독기(206)가 IoT 디바이스(101)와 관련된 바코드/QR 코드(1201)를 캡처하는 일 실시예를 예시한다. 언급된 바와 같이, 바코드/QR 코드(1201)는 IoT 디바이스(101) 상에 직접 인쇄될 수 있거나, IoT 디바이스(101)가 제공된 별개의 카드 상에 인쇄될 수 있다. 어느 경우에나, 바코드 판독기(206)는 바코드/QR 코드(1201)로부터 페어링 코드를 판독하고 로컬 통신 모듈(1280)에 페어링 코드를 제공한다. 일 실시예에서, 로컬 통신 모듈(1280)은 블루투스 LE 칩 및 관련 소프트웨어이지만, 본 발명의 기본 원리는 임의의 특정 프로토콜 표준으로 제한되지 않는다. 일단 페어링 코드가 수신되면, 그것은 페어링 데이터(1285)를 포함하는 보안 저장소에 저장되고, IoT 디바이스(101) 및 IoT 허브(110)는 자동적으로 페어링된다. IoT 허브가 이러한 방식으로 새로운 IoT 디바이스와 페어링될 때마다, 그러한 페어링을 위한 페어링 데이터는 보안 저장소(685) 내에 저장된다. 일 실시예에서, 일단 IoT 허브(110)의 로컬 통신 모듈(1280)이 페어링 코드를 수신하면, 그것은 IoT 디바이스(101)와의 로컬 무선 채널을 통한 통신을 암호화하기 위한 키로서 코드를 사용할 수 있다.

유사하게, IoT 디바이스(101) 측에서, 로컬 통신 모듈(1590)은 로컬 보안 저장 디바이스(1595) 내에 IoT 허브와의 페어링을 지시하는 페어링 데이터를 저장한다. 페어링 데이터(1295)는 바코드/QR 코드(1201)에서 식별된 미리 프로그래밍된 페어링 코드를 포함할 수 있다. 페어링 데이터(1295)는 또한 보안 로컬 통신 채널을 설정하는 데 필요한, IoT 허브(110) 상의 로컬 통신 모듈(1280)로부터 수신된 페어링 데이터(예를 들어, IoT 허브(110)와의 통신을 암호화하기 위한 추가 키)를 포함할 수 있다.

따라서, 바코드/QR 코드(1201)는 페어링 코드가 무선으로 송신되지 않기 때문에 현재 무선 페어링 프로토콜보다 훨씬 더 안전한 방식으로 로컬 페어링을 수행하는 데 사용될 수 있다. 또한, 일 실시예에서, 페어링에 사용되는 동일한 바코드/QR 코드(1201)는 IoT 디바이스(101)로부터 IoT 허브(110)로의 그리고 IoT 허브(110)로부터 IoT 서비스(120)로의 보안 접속을 구축하기 위한 암호화 키를 식별하는 데 사용될 수 있다.

본 발명의 일 실시예에 따른 SIM 카드를 프로그래밍하는 방법이 도 13에 예시되어 있다. 방법은 전술한 시스템 아키텍처 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

1301에서, 사용자는 블랭크(blank) SIM 카드를 갖는 새로운 IoT 디바이스를 수신하고, 1602에서, 사용자는 블랭크 SIM 카드를 IoT 허브 안에 삽입한다. 1303에서, 사용자는 하나 이상의 암호화 키의 세트를 갖도록 블랭크 SIM 카드를 프로그래밍한다. 예를 들어, 전술한 바와 같이, 일 실시예에서, IoT 허브는 공개/비공개 키 쌍을 무작위로 생성하고, SIM 카드 상에 비공개 키를 저장하고 그것의 로컬 보안 저장소에 공개 키를 저장할 수 있다. 또한, 1304에서, 적어도 공개 키가 IoT 서비스로 송신되어, 그것은 IoT 디바이스를 식별하고 IoT 디바이스와의 암호화된 통신을 설정하는 데 사용될 수 있다. 전술한 바와 같이, 일 실시예에서, "SIM" 카드 이외의 프로그래밍 가능 디바이스가 도 13에 도시된 방법에서 SIM 카드와 동일한 기능을 수행하는 데 사용될 수 있다.

새로운 IoT 디바이스를 네트워크 안에 통합하는 방법이 도 14에 예시되어 있다. 방법은 전술한 시스템 아키텍처 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

1401에서, 사용자는 암호화 키가 미리 할당된 새로운 IoT 디바이스를 수신한다. 1402에서, 키는 IoT 허브에 안전하게 제공된다. 전술한 바와 같이, 일 실시예에서, 이것은 디바이스에 할당된 공개/비공개 키 쌍의 공개 키를 식별하기 위해 IoT 디바이스와 관련된 바코드를 판독하는 것을 포함한다. 바코드는 IoT 허브에 의해 직접 판독되거나 모바일 디바이스를 통해 앱 또는 브라우저를 통해 캡처될 수 있다. 대안적인 실시예에서, 블루투스 LE 채널, 근거리장 통신(NFC) 채널 또는 보안 WiFi 채널과 같은 보안 통신 채널이 IoT 디바이스와 IoT 허브 사이에 설정되어 키를 교환할 수 있다. 키가 송신되는 방식에 상관없이, 일단 수신되면, 그것은 IoT 허브 디바이스의 보안 키 저장소에 저장된다. 전술한 바와 같이, 보안 엔클레이브(Secure Enclave), 신뢰 실행 기술(TXT) 및/또는 트러스트존과 같은 다양한 보안 실행 기술이 키를 저장하고 보호하기 위해 IoT 허브 상에서 사용될 수 있다. 또한, 803에서, 키는 IoT 서비스로 안전하게 송신되며, IoT 서비스는 그 자신의 보안 키 저장소에 키를 저장한다. 이어서, IoT 서비스는 키를 사용하여 IoT 디바이스와의 통신을 암호화할 수 있다. 다시 한번, 교환은 인증서/서명된 키를 사용하여 구현될 수 있다. 허브(110) 내에서, 저장된 키의 변경/추가/제거를 방지하는 것이 특히 중요하다.

공개/비공개 키를 사용하여 커맨드/데이터를 IoT 디바이스로 안전하게 통신하는 방법이 도 15에 예시되어 있다. 방법은 전술한 시스템 아키텍처 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

1501에서, IoT 서비스는 IoT 디바이스 공개 키를 사용하여 데이터/커맨드를 암호화하여 IoT 디바이스 패킷을 생성한다. 이어서 그것은 IoT 허브의 공개 키를 사용하여 IoT 디바이스 패킷을 암호화하여 IoT 허브 패킷을 생성한다(예를 들어, IoT 디바이스 패킷 주위에 IoT 허브 래퍼(wrapper)를 생성함). 1502에서, IoT 서비스는 IoT 허브 패킷을 IoT 허브로 송신한다. 1503에서, IoT 허브는 IoT 허브의 비공개 키를 사용하여 IoT 허브 패킷을 해독하여 IoT 디바이스 패킷을 생성한다. 1504에서, 그것은 이어서 IoT 디바이스 패킷을 IoT 디바이스로 송신하고, IoT 디바이스는 1505에서 IoT 디바이스 비공개 키를 사용하여 IoT 디바이스 패킷을 해독하여 데이터/커맨드를 생성한다. 1506에서, IoT 디바이스는 데이터/커맨드를 처리한다.

대칭 키를 사용하는 실시예에서, 대칭 키 교환은 각각의 디바이스들 사이에서(예를 들어, 각각의 디바이스와 허브 사이에서 그리고 허브와 서비스 사이에서) 협상될 수 있다. 일단 키 교환이 완료되면, 각각의 송신 디바이스는 데이터를 수신 디바이스로 송신하기 전에 대칭 키를 사용하여 각각의 송신을 암호화 및/또는 서명한다.

사물 인터넷(IoT) 시스템에서 보안 통신 채널을 설정하기 위한 장치 및 방법

본 발명의 일 실시예에서, 데이터의 암호화 및 해독은, (예를 들어, 사용자의 모바일 디바이스(611) 및/또는 IoT 허브(110)와 같은) 통신 채널을 지원하는 데 사용되는 중간 디바이스들에 관계없이, IoT 서비스(120)와 각각의 IoT 디바이스(101) 사이에서 수행된다. IoT 허브(110)를 통해 통신하는 일 실시예가 도 16a에 예시되고, IoT 허브를 필요로 하지 않는 다른 실시예가 도 16b에 예시된다.

먼저 도 16a를 참조하면, IoT 디바이스(101)와 IoT 서비스(120) 사이의 통신을 암호화/해독하기 위해, IoT 서비스(120)는 "서비스 세션 키들"(1650)의 세트를 관리하는 암호화 엔진(1660)을 포함하고, 각각의 IoT 디바이스(101)는 "디바이스 세션 키들"(1651)의 세트를 관리하는 암호화 엔진(1661)을 포함한다. 암호화 엔진들은 본 명세서에서 설명되는 보안/암호화 기술들을 수행할 때 (다른 것들 중에서도) 세션 공개/비공개 키 쌍을 생성하고 그 쌍의 비공개 세션 키에 대한 액세스를 방지하기 위한 하드웨어 보안 모듈(1630, 1631) 및 도출된 비밀을 사용하여 키 스트림을 생성하기 위한 키 스트림 생성 모듈(1640, 1641)을 포함한 상이한 하드웨어 모듈들에 의존할 수 있다. 일 실시예에서, 서비스 세션 키들(1650) 및 디바이스 세션 키들(1651)은 관련된 공개/비공개 키 쌍들을 포함한다. 예를 들어, 일 실시예에서, IoT 디바이스(101) 상의 디바이스 세션 키들(1651)은 IoT 서비스(120)의 공개 키 및 IoT 디바이스(101)의 비공개 키를 포함한다. 아래에서 상세히 논의되는 바와 같이, 일 실시예에서, 보안 통신 세션을 설정하기 위해, 공개/비공개 세션 키 쌍들(1650, 1651)은, 각각, 각각의 암호화 엔진(1660, 1661)에 의해 동일한 비밀을 생성하는 데 사용되며, 이 동일한 비밀은 이어서 SKGM들(1640, 1641)에 의해 IoT 서비스(120)와 IoT 디바이스(101) 사이의 통신을 암호화 및 해독하기 위한 키 스트림을 생성하는 데 사용된다. 본 발명의 일 실시예에 따른 비밀의 생성 및 사용과 관련된 추가 상세들이 아래에 제공된다.

도 16a에서, 일단 키들(1650, 1651)을 사용하여 비밀이 생성되면, 클리어 트랜잭션(Clear transaction)(1611)에 의해 표시된 바와 같이, 클라이언트는 항상 IoT 서비스(120)를 통해 IoT 디바이스(101)에 메시지들을 전송할 것이다. 본 명세서에서 사용된 바와 같은 "클리어"는 기본 메시지가 본 명세서에서 설명되는 암호화 기술들을 사용하여 암호화되지 않는다는 것을 지시하도록 의도된다. 그러나, 예시된 바와 같이, 일 실시예에서, 통신을 보호하기 위해 클라이언트 디바이스(611)와 IoT 서비스(120) 사이에 보안 소켓 계층(SSL) 채널 또는 다른 보안 채널(예를 들어, 인터넷 프로토콜 보안(IPSEC) 채널)이 설정된다. 이어서, 1602에서, IoT 서비스(120) 상의 암호화 엔진(1660)은 생성된 비밀을 사용하여 메시지를 암호화하고 암호화된 메시지를 IoT 허브(110)로 송신한다. 비밀을 사용하여 메시지를 직접 암호화하기보다는, 일 실시예에서, 비밀 및 카운터 값은 각각의 메시지 패킷을 암호화하는 데 사용되는 키 스트림을 생성하는 데 사용된다. 이 실시예의 상세들이 도 17과 관련하여 아래에서 설명된다.

예시된 바와 같이, SSL 접속 또는 다른 보안 채널이 IoT 서비스(120)와 IoT 허브(110) 사이에 설정될 수 있다. 1603에서, IoT 허브(110)(일 실시예에서 메시지를 해독하는 능력을 갖지 않음)는 암호화된 메시지를 (예를 들어, 블루투스 저에너지(BTLE) 통신 채널을 통해) IoT 디바이스로 송신한다. 이어서, IoT 디바이스(101) 상의 암호화 엔진(1661)은 비밀을 사용하여 메시지를 해독하고 메시지 내용을 처리할 수 있다. 비밀을 사용하여 키 스트림을 생성하는 실시예에서, 암호화 엔진(1661)은 비밀 및 카운터 값을 사용하여 키 스트림을 생성한 다음 키 스트림을 메시지 패킷의 해독에 사용할 수 있다.

메시지 자체는 IoT 서비스(120)와 IoT 디바이스(101) 사이의 임의의 형태의 통신을 포함할 수 있다. 예를 들어, 메시지는 측정을 행하고 그 결과를 다시 클라이언트 디바이스(611)에 보고하는 것과 같은 특정 기능을 수행하도록 IoT 디바이스(101)에 명령하는 커맨드 패킷을 포함할 수 있거나, IoT 디바이스(101)의 동작을 구성하는 구성 데이터를 포함할 수 있다.

응답이 요구되는 경우, IoT 디바이스(101) 상의 암호화 엔진(1661)은 1604에서 비밀 또는 도출된 키 스트림을 사용하여 응답을 암호화하고 암호화된 응답을 IoT 허브(110)로 송신하며, 이 IoT 허브는 1605에서 응답을 IoT 서비스(120)로 전송한다. 이어서, IoT 서비스(120) 상의 암호화 엔진(1660)은 1606에서 비밀 또는 도출된 키 스트림을 사용하여 응답을 해독하고 (예를 들어, SSL 또는 다른 보안 통신 채널을 통해) 해독된 응답을 클라이언트 디바이스(611)로 송신한다.

도 16b는 IoT 허브를 필요로 하지 않는 실시예를 예시한다. 오히려, 이 실시예에서, IoT 디바이스(101)와 IoT 서비스(120) 사이의 통신은 (예를 들어, 도 6 내지 도 9b와 관련하여 전술한 실시예들에서와 같이) 클라이언트 디바이스(611)를 통해 일어난다. 이 실시예에서, IoT 디바이스(101)로 메시지를 송신하기 위해, 클라이언트 디바이스(611)는 1611에서 메시지의 암호화되지 않은 버전을 IoT 서비스(120)로 송신한다. 암호화 엔진(1660)은 1612에서 비밀 또는 도출된 키 스트림을 사용하여 메시지를 암호화하고 암호화된 메시지를 다시 클라이언트 디바이스(611)로 송신한다. 이어서, 클라이언트 디바이스(611)는 1613에서 암호화된 메시지를 IoT 디바이스(101)에 전송하고, 암호화 엔진(1661)은 비밀 또는 도출된 키 스트림을 사용하여 메시지를 해독한다. 이어서, IoT 디바이스(101)는 본 명세서에서 설명되는 바와 같이 메시지를 처리할 수 있다. 응답이 요구되는 경우, 암호화 엔진(1661)은 1614에서 비밀을 사용하여 응답을 암호화하고 암호화된 응답을 클라이언트 디바이스(611)로 송신하며, 이 클라이언트 디바이스는 1615에서 암호화된 응답을 IoT 서비스(120)에 전송한다. 이어서, 1616에서, 암호화 엔진(1660)은 응답을 해독하고 해독된 응답을 클라이언트 디바이스(611)로 송신한다.

도 17은 IoT 서비스(120)와 IoT 디바이스(101) 사이에서 초기에 수행될 수 있는 키 교환 및 키 스트림 생성을 예시한다. 일 실시예에서, 이러한 키 교환은 IoT 서비스(120) 및 IoT 디바이스(101)가 새로운 통신 세션을 설정할 때마다 수행될 수 있다. 대안적으로, 지정된 기간(예컨대, 하루, 일주일 등) 동안 키 교환이 수행될 수 있고 교환된 세션 키들이 사용될 수 있다. 간략화를 위해 도 17에는 중간 디바이스가 도시되지 않지만, 통신은 IoT 허브(110) 및/또는 클라이언트 디바이스(611)를 통해 일어날 수 있다.

일 실시예에서, IoT 서비스(120)의 암호화 엔진(1660)은 세션 공개/비공개 키 쌍을 생성하기 위해 (예를 들어, 아마존(Amazon)(등록상표)에 의해 제공되는 CloudHSM과 같은 것일 수 있는) HSM(1630)에 커맨드를 전송한다. HSM(1630)은 후속하여 쌍의 비공개 세션 키에 대한 액세스를 방지할 수 있다. 유사하게, IoT 디바이스(101) 상의 암호화 엔진은 세션 공개/비공개 키 쌍을 생성하고 쌍의 세션 비공개 키에 대한 액세스를 방지하는 (예컨대, 아트멜 코포레이션(Atmel Corporation)(등록상표)으로부터의 Atecc508 HSM과 같은) HSM(1631)에 커맨드를 송신할 수 있다. 물론, 본 발명의 기본 원리들은 임의의 특정 타입의 암호화 엔진 또는 제조자로 제한되지 않는다.

일 실시예에서, 1701에서, IoT 서비스(120)는 HSM(1630)을 사용하여 생성된 그의 세션 공개 키를 IoT 디바이스(101)로 송신한다. IoT 디바이스는 그의 HSM(1631)을 사용하여 그 자신의 세션 공개/비공개 키 쌍을 생성하고, 1702에서 그의 쌍의 공개 키를 IoT 서비스(120)로 송신한다. 일 실시예에서, 암호화 엔진들(1660, 1661)은 타원 곡선 공개-비공개 키 쌍을 갖는 두 당사자가 공유 비밀을 설정하도록 허용하는 익명 키 협약인 ECDH(Elliptic Curve Diffie-Hellman) 프로토콜을 사용한다. 일 실시예에서, 이들 기술을 사용하여, 1703에서, IoT 서비스(120)의 암호화 엔진(1660)은 IoT 디바이스 세션 공개 키 및 그 자신의 세션 비공개 키를 사용하여 비밀을 생성한다. 유사하게, 1704에서, IoT 디바이스(101)의 암호화 엔진(1661)은 IoT 서비스(120) 세션 공개 키 및 그 자신의 세션 비공개 키를 사용하여 동일한 비밀을 독립적으로 생성한다. 더 구체적으로, 일 실시예에서, IoT 서비스(120) 상의 암호화 엔진(1660)은 공식 '비밀 = IoT 디바이스 세션 공개 키 * IoT 서비스 세션 비공개 키'에 따라 비밀을 생성하며, 여기서 '*'는 IoT 디바이스 세션 공개 키가 IoT 서비스 세션 비공개 키와 포인트 곱셈된다는 것을 의미한다. IoT 디바이스(101) 상의 암호화 엔진(1661)은 IoT 서비스 세션 공개 키가 IoT 디바이스 세션 비공개 키와 포인트 곱셈되는, 공식 '비밀 = IoT 서비스 세션 공개 키 * IoT 디바이스 세션 비공개 키'에 따라 비밀을 생성한다. 마침내, IoT 서비스(120) 및 IoT 디바이스(101)는 둘 모두가 아래에 설명되는 바와 같이 통신을 암호화하는 데 사용될 동일한 비밀을 생성하였다. 일 실시예에서, 암호화 엔진들(1660, 1661)은 비밀을 생성하기 위한 상기 동작들을 수행하기 위해 각각 KSGM들(1640, 1641)과 같은 하드웨어 모듈에 의존한다.

일단 비밀이 결정되면, 그것은 암호화 엔진들(1660, 1661)에 의해 데이터를 직접 암호화 및 해독하는 데 사용될 수 있다. 대안적으로, 일 실시예에서, 암호화 엔진들(1660, 1661)은 각각의 데이터 패킷을 암호화/해독하기 위해 비밀을 사용하여 새로운 키 스트림을 생성하도록(즉, 새로운 키 스트림 데이터 구조가 각각의 패킷에 대해 생성됨) KSGM들(1640, 1641)에 커맨드를 전송한다. 특히, 키 스트림 생성 모듈(1640, 1641)의 일 실시예는 GCM(Galois/Counter Mode)을 구현하며, 이 모드에서는 카운터 값이 각각의 데이터 패킷에 대해 증가되고, 키 스트림을 생성하기 위해 비밀과 조합되어 사용된다. 따라서, 데이터 패킷을 IoT 서비스(120)로 송신하기 위해, IoT 디바이스(101)의 암호화 엔진(1661)은 비밀 및 현재 카운터 값을 사용하여 KSGM들(1640, 1641)이 새로운 키 스트림을 생성하고 다음 키 스트림의 생성을 위해 카운터 값을 증가시키게 한다. 이어서, 새로 생성된 키 스트림은 IoT 서비스(120)로 송신되기 전에 데이터 패킷을 암호화하는 데 사용된다. 일 실시예에서, 키 스트림은 암호화된 데이터 패킷을 생성하기 위해 데이터와 XOR된다. 일 실시예에서, IoT 디바이스(101)는 암호화된 데이터 패킷과 함께 카운터 값을 IoT 서비스(120)로 송신한다. 이어서, IoT 서비스 상의 암호화 엔진(1660)은 KSGM(1640)과 통신하며, 이 KSGM은 수신된 카운터 값 및 비밀을 사용하여 (동일한 비밀 및 카운터 값이 사용되기 때문에 동일한 키 스트림이어야 하는) 키 스트림을 생성하고 생성된 키 스트림을 사용하여 데이터 패킷을 해독한다.

일 실시예에서, IoT 서비스(120)로부터 IoT 디바이스(101)로 송신되는 데이터 패킷들은 동일한 방식으로 암호화된다. 구체적으로, 카운터가 각각의 데이터 패킷에 대해 증가되고, 새로운 키 스트림을 생성하기 위해 비밀과 함께 사용된다. 이어서, 키 스트림은 데이터를 암호화하는 데 사용되며(예를 들어, 데이터와 키 스트림의 XOR을 수행), 암호화된 데이터 패킷은 카운터 값과 함께 IoT 디바이스(101)로 송신된다. 이어서, IoT 디바이스(101) 상의 암호화 엔진(1661)은 카운터 값 및 비밀을 사용하여 데이터 패킷을 해독하는 데 사용되는 동일한 키 스트림을 생성하는 KSGM(1641)과 통신한다. 따라서, 이 실시예에서, 암호화 엔진들(1660, 1661)은 그들 자신의 카운터 값들을 사용하여 키 스트림을 생성하여서 데이터를 암호화하고, 암호화된 데이터 패킷들과 함께 수신된 카운터 값들을 사용하여 키 스트림을 생성하여서 데이터를 해독한다.

일 실시예에서, 각각의 암호화 엔진(1660, 1661)은 그가 다른 것으로부터 수신한 최종 카운터 값을 기록하며, 카운터 값이 비순차적으로 수신되는지 또는 동일한 카운터 값이 한 번을 초과하여 수신되는지를 검출하는 시퀀싱 로직을 포함한다. 카운터 값이 비순차적으로 수신되는 경우, 또는 동일한 카운터 값이 한 번을 초과하여 수신되는 경우, 이것은 재생 공격이 시도되고 있음을 지시할 수 있다. 이에 응답하여, 암호화 엔진들(1660, 1661)은 통신 채널로부터 접속 해제될 수 있고/있거나, 보안 경고를 생성할 수 있다.

도 18은 4 바이트 카운터 값(1800), 가변 크기의 암호화된 데이터 필드(1801) 및 6 바이트 태그(1802)를 포함하는 본 발명의 일 실시예에서 사용되는 예시적인 암호화된 데이터 패킷을 예시한다. 일 실시예에서, 태그(1802)는 (일단 해독되면) 해독된 데이터를 확인하기 위한 체크섬 값을 포함한다.

언급된 바와 같이, 일 실시예에서, IoT 서비스(120)와 IoT 디바이스(101) 사이에서 교환되는 세션 공개/비공개 키 쌍들(1650, 1651)은 주기적으로 그리고/또는 각각의 새로운 통신 세션의 개시에 응답하여 생성될 수 있다.

본 발명의 일 실시예는 IoT 서비스(120)와 IoT 디바이스(101) 사이의 세션들을 인증하기 위한 추가 기술들을 구현한다. 특히, 일 실시예에서, 마스터 키 쌍, 공장 키 쌍들의 세트, 및 IoT 서비스 키 쌍들의 세트, 및 IoT 디바이스 키 쌍들의 세트를 포함하는 공개/비공개 키 쌍들의 계층 구조가 사용된다. 일 실시예에서, 마스터 키 쌍은 모든 다른 키 쌍들에 대한 신뢰의 루트를 포함하고, (예를 들어, 본 명세서에 설명되는 IoT 시스템들을 구현하는 조직의 제어하에) 단일의 매우 안전한 위치에 유지된다. 마스터 비공개 키는 공장 키 쌍들과 같은 다양한 다른 키 쌍들을 통해 서명들을 생성(그리고 이에 의해 인증)하는 데 사용될 수 있다. 이어서, 서명들은 마스터 공개 키를 사용하여 검증될 수 있다. 일 실시예에서, IoT 디바이스들을 제조하는 각각의 공장은 IoT 서비스 키들 및 IoT 디바이스 키들을 인증하기 위해 후속 사용될 수 있는 그 자신의 공장 키 쌍을 할당받는다. 예를 들어, 일 실시예에서, 공장 비공개 키는 IoT 서비스 공개 키들 및 IoT 디바이스 공개 키들을 통해 서명을 생성하는 데 사용된다. 이어서, 이러한 서명은 대응하는 공장 공개 키를 사용하여 검증될 수 있다. 이러한 IoT 서비스/디바이스 공개 키들은 도 16a 및 도 16b와 관련하여 위에서 설명한 "세션" 공개/비공개 키들과 동일하지 않음에 유의한다. 전술한 세션 공개/비공개 키들은 일시적인 반면(즉, 서비스/디바이스 세션에 대해 생성됨), IoT 서비스/디바이스 키 쌍들은 영구적이다(즉, 공장에서 생성됨).

마스터 키들, 공장 키들, 서비스/디바이스 키들 사이의 전술한 관계들을 염두에 두고, 본 발명의 일 실시예는 다음의 동작들을 수행하여 IoT 서비스(120)와 IoT 디바이스(101) 사이에 인증 및 보안의 추가 계층들을 제공한다:

A. 일 실시예에서, IoT 서비스(120)는 초기에 다음을 포함하는 메시지를 생성한다:

1. IoT 서비스의 고유 ID:

IoT 서비스의 일련번호;

타임스탬프;

이 고유 ID에 서명하는 데 사용되는 공장 키의 ID;

고유 ID의 클래스(즉, 서비스);

IoT 서비스의 공개 키

고유 ID를 통한 서명.

2. 다음을 포함하는 공장 인증서:

타임스탬프

인증서에 서명하는 데 사용되는 마스터 키의 ID

공장 공개 키

공장 인증서의 서명

3. (도 16a 및 도 16b와 관련하여 전술한 바와 같은) IoT 서비스 세션 공개 키

4. IoT 서비스 세션 공개 키 서명(예를 들어, IoT 서비스의 비공개 키로 서명됨)

B. 일 실시예에서, 메시지는 (후술하는) 협상 채널 상에서 IoT 디바이스로 전송된다. IoT 디바이스는 메시지를 분석하고:

1. (메시지 페이로드에 존재하는 경우에만) 공장 인증서의 서명을 검증한다

2. 고유 ID에 의해 식별된 키를 사용하여 고유 ID의 서명을 검증한다

3. 고유 ID로부터의 IoT 서비스의 공개 키를 사용하여 IoT 서비스 세션 공개 키 서명을 검증한다

4. IoT 서비스의 공개 키뿐만 아니라 IoT 서비스의 세션 공개 키를 저장한다

5. IoT 디바이스 세션 키 쌍을 생성한다.

C. 이어서, IoT 디바이스는 다음을 포함하는 메시지를 생성한다:

1. IoT 디바이스의 고유 ID

IoT 디바이스 일련번호

타임스탬프

이 고유 ID에 서명하는 데 사용되는 공장 키의 ID

고유 ID의 클래스(즉, IoT 디바이스)

IoT 디바이스의 공개 키

고유 ID의 서명

2. IoT 디바이스의 세션 공개 키

3. IoT 디바이스의 키로 서명된 (IoT 디바이스 세션 공개 키 + IoT 서비스 세션 공개 키)의 서명

D. 이 메시지는 IoT 서비스로 역전송된다. IoT 서비스는 메시지를 분석하고:

1. 공장 공개 키를 사용하여 고유 ID의 서명을 검증한다

2. IoT 디바이스의 공개 키를 사용하여 세션 공개 키들의 서명을 검증한다

3. IoT 디바이스의 세션 공개 키를 저장한다

E. 이어서, IoT 서비스는 IoT 서비스 키로 서명된 (IoT 디바이스 세션 공개 키 + IoT 서비스 세션 공개 키)의 서명을 포함하는 메시지를 생성한다.

F. IoT 디바이스는 메시지를 분석하고:

1. IoT 서비스의 공개 키를 사용하여 세션 공개 키들의 서명을 검증한다

2. IoT 디바이스 세션 비공개 키 및 IoT 서비스의 세션 공개 키로부터 키 스트림을 생성한다

3. 이어서, IoT 디바이스는 "메시징 이용 가능" 메시지를 전송한다.

G. 이어서, IoT 서비스는 다음을 수행한다:

1. IoT 서비스 세션 비공개 키 및 IoT 디바이스의 세션 공개 키로부터 키 스트림을 생성한다

2. 다음을 포함하는 메시징 채널 상에서 새로운 메시지를 생성한다:

난수 2 바이트 값을 생성하고 저장한다

(아래에 논의되는) 부메랑 속성 Id 및 난수 값을 갖는 속성 메시지를 설정한다

H. IoT 디바이스는 메시지를 수신하고:

1. 메시지를 해독하려고 시도한다

2. 표시된 속성 Id에 대해 동일한 값을 가진 업데이트를 방출한다

I. IoT 서비스는 메시지 페이로드가 부메랑 속성 업데이트를 포함하고 있음을 인식하고:

1. 그의 페어링된 상태를 참으로 설정한다

2. 협상자 채널 상에서 페어링 완료 메시지를 전송한다

J. IoT 디바이스는 메시지를 수신하고 그의 페어링된 상태를 참으로 설정한다

상기의 기술들은 "IoT 서비스" 및 "IoT 디바이스"와 관련하여 설명되지만, 본 발명의 기본 원리들은 사용자 클라이언트 디바이스들, 서버들 및 인터넷 서비스들을 포함하는 임의의 2개의 디바이스 간의 보안 통신 채널을 설정하도록 구현될 수 있다.

상기의 기술들은 (비밀이 한쪽 당사자로부터 다른 당사자에게 송신되는 현재의 블루투스 페어링 기술들과는 대조적으로) 비공개 키들이 결코 무선으로 공유되지 않기 때문에 매우 안전하다. 전체 대화를 듣는 공격자는 공유 비밀을 생성하기에 충분하지 않은 공개 키들만을 가질 것이다. 이러한 기술들은 또한 서명된 공개 키들을 교환함으로써 중간자 공격을 방지한다. 또한, GCM 및 별개의 카운터들이 각각의 디바이스 상에서 사용되기 때문에, 임의의 종류의 "재생 공격"(중간자가 데이터를 캡처하고 그것을 다시 전송함)이 방지된다. 일부 실시예들은 또한 비대칭 카운터들을 사용함으로써 재생 공격을 방지한다.

디바이스들을 정식으로 페어링함이 없이 데이터 및 커맨드들을 교환하기 위한 기술

GATT는 일반 속성 프로파일의 두문자어이며, 그것은 2개의 블루투스 저에너지(BTLE) 디바이스가 데이터를 앞뒤로 전송하는 방식을 정의한다. 그것은 표의 각각의 엔트리에 대한 16 비트 특성 ID들을 사용하는 간단한 탐색표(lookup table) 내에 서비스들, 특성들 및 관련 데이터를 저장하는 데 사용되는, 속성 프로토콜(ATT)이라고 하는 일반 데이터 프로토콜을 사용한다. "특성들"은 때때로 "속성들"로 지칭된다는 점에 유의한다.

블루투스 디바이스들 상에서, 가장 일반적으로 사용되는 특성은 (특성 ID 10752 (0x2A00)을 갖는) 디바이스 "이름"이다. 예를 들어, 블루투스 디바이스는 그의 주변의 다른 블루투스 디바이스들을, GATT를 사용하여 그러한 다른 블루투스 디바이스들에 의해 공개된 "이름" 특성을 판독함으로써 식별할 수 있다. 따라서, 블루투스 디바이스는 디바이스들을 정식으로 페어링/본딩함이 없이 데이터를 교환할 수 있는 고유한 능력을 갖는다("페어링"과 "본딩"은 때때로 상호 교환적으로 사용되며; 본 논의의 나머지는 용어 "페어링"을 사용할 것임에 유의한다).

본 발명의 일 실시예는 BTLE 인에이블드(BTLE-enabled) IoT 디바이스들과 정식으로 페어링함이 없이 이들 디바이스와 통신하기 위해 이러한 능력을 이용한다. 각각의 개별 IoT 디바이스와의 페어링은 각각의 디바이스와 페어링하는 데 필요한 시간의 양 때문에, 그리고 한 번에 단지 하나의 페어링된 접속만이 설정될 수 있기 때문에 극히 비효율적일 것이다.

도 19는 블루투스(BT) 디바이스(1910)가 페어링된 BT 접속을 정식으로 설정함이 없이 IoT 디바이스(101)의 BT 통신 모듈(1901)과 네트워크 소켓 추상화를 설정하는 하나의 특정 실시예를 예시한다. BT 디바이스(1910)는 도 16a에 도시된 바와 같은 IoT 허브(110) 및/또는 클라이언트 디바이스(611)에 포함될 수 있다. 예시된 바와 같이, BT 통신 모듈(1901)은 특성 ID들, 그러한 특성 ID들과 관련된 이름들 및 그러한 특성 ID들에 대한 값들의 리스트를 포함하는 데이터 구조를 유지한다. 각각의 특성에 대한 값은 현재 BT 표준에 따라 특성 ID에 의해 식별되는 20 바이트 버퍼 내에 저장될 수 있다. 그러나, 본 발명의 기본 원리들은 임의의 특정 버퍼 크기로 제한되지 않는다.

도 19의 예에서, "이름" 특성은 "IoT 디바이스 14"의 특정 값을 할당받는 BT 정의 특성이다. 본 발명의 일 실시예는 BT 디바이스(1910)와 보안 통신 채널을 협상하는 데 사용될 추가 특성들의 제1 세트 및 BT 디바이스(1910)와의 암호화된 통신에 사용될 추가 특성들의 제2 세트를 지정한다. 특히, 예시된 예에서 특성 ID <65532>에 의해 식별되는 "협상 기입" 특성은 발신 협상 메시지들을 송신하는 데 사용될 수 있고, 특성 ID <65533>에 의해 식별되는 "협상 판독" 특성은 착신 협상 메시지들을 수신하는 데 사용될 수 있다. "협상 메시지들"은 본 명세서에서 설명되는 바와 같은 보안 통신 채널을 설정하기 위해 BT 디바이스(1910) 및 BT 통신 모듈(1901)에 의해 사용되는 메시지들을 포함할 수 있다. 예로서, 도 17에서, IoT 디바이스(101)는 "협상 판독" 특성 <65533>을 통해 IoT 서비스 세션 공개 키(1701)를 수신할 수 있다. 키(1701)는 IoT 서비스(120)로부터 BTLE 인에이블드 IoT 허브(110) 또는 클라이언트 디바이스(611)로 송신될 수 있으며, 이어서 BTLE 인에이블드 IoT 허브(110) 또는 클라이언트 디바이스(611)는 GATT를 사용하여 특성 ID <65533>에 의해 식별되는 협상 판독 값 버퍼에 키(1701)를 기입할 수 있다. 이어서, IoT 디바이스 애플리케이션 로직(1902)은 특성 ID <65533>에 의해 식별되는 값 버퍼로부터 키(1701)를 판독하고 그것을 전술한 바와 같이 처리할 수 있다(예컨대, 그것을 사용하여 비밀을 생성하고, 비밀을 사용하여 키 스트림을 생성하고, 기타 등등).

키(1701)가 20 바이트(일부 현재 구현들에서의 최대 버퍼 크기)보다 큰 경우, 그것은 20 바이트 부분들에 기입될 수 있다. 예를 들어, 처음 20 바이트는 BT 통신 모듈(1903)에 의해 특성 ID <65533>에 기입되고 IoT 디바이스 애플리케이션 로직(1902)에 의해 판독될 수 있으며, 이어서 IoT 디바이스 애플리케이션 로직(1902)은 특성 ID <65532>에 의해 식별되는 협상 기입 값 버퍼에 수신 확인 메시지를 기입할 수 있다. GATT를 사용하여, BT 통신 모듈(1903)은 특성 ID <65532>로부터 이 수신 확인을 판독하고 그에 응답하여 키(1701)의 다음 20 바이트를 특성 ID <65533>에 의해 식별되는 협상 판독 값 버퍼에 기입할 수 있다. 이러한 방식으로, 특성 ID <65532> 및 <65533>에 의해 정의되는 네트워크 소켓 추상화가 보안 통신 채널을 설정하는 데 사용되는 협상 메시지들을 교환하도록 설정된다.

일 실시예에서, 일단 보안 통신 채널이 설정되면, (IoT 디바이스(101)로부터 암호화된 데이터 패킷들을 송신하기 위한) 특성 ID <65534> 및 (IoT 디바이스에 의해 암호화된 데이터 패킷들을 수신하기 위한) 특성 ID <65533>을 사용하여 제2 네트워크 소켓 추상화가 설정된다. 즉, BT 통신 모듈(1903)이 (예컨대, 도 16a의 암호화된 메시지(1603)와 같은) 송신할 암호화된 데이터 패킷을 가질 때, 그것은 특성 ID <65533>에 의해 식별되는 메시지 판독 값 버퍼를 사용하여 암호화된 데이터 패킷을 한 번에 20 바이트씩 기입하기 시작한다. 이어서, IoT 디바이스 애플리케이션 로직(1902)은 판독 값 버퍼로부터 암호화된 데이터 패킷을 한 번에 20 바이트씩 판독하여, 특성 ID <65532>에 의해 식별되는 기입 값 버퍼를 통해 필요에 따라 수신 확인 메시지들을 BT 통신 모듈(1903)로 전송할 것이다.

일 실시예에서, 후술하는 GET, SET 및 UPDATE의 커맨드들은 2개의 BT 통신 모듈(1901, 1903) 사이에 데이터 및 커맨드를 교환하는 데 사용된다. 예를 들어, BT 통신 모듈(1903)은, 특성 ID <65533>을 식별하고, IoT 디바이스 애플리케이션 로직(1902)에 의해 후속 판독될 수 있는 특성 ID <65533>에 의해 식별되는 값 필드/버퍼 안에 기입할 SET 커맨드를 포함하는 패킷을 전송할 수 있다. IoT 디바이스(101)로부터 데이터를 검색하기 위해, BT 통신 모듈(1903)은 특성 ID <65534>에 의해 식별되는 값 필드/버퍼로 지향되는 GET 커맨드를 송신할 수 있다. GET 커맨드에 응답하여, BT 통신 모듈(1901)은 특성 ID <65534>에 의해 식별되는 값 필드/버퍼로부터의 데이터를 포함하는 UPDATE 패킷을 BT 통신 모듈(1903)로 송신할 수 있다. 또한, UPDATE 패킷들은 IoT 디바이스(101) 상에서의 특정 속성의 변경들에 응답하여 자동으로 송신될 수 있다. 예를 들어, IoT 디바이스가 조명 시스템과 관련되고 사용자가 발광체를 턴온하는 경우, 조명 애플리케이션과 관련된 온/오프 속성에 대한 변경을 반영하기 위해 UPDATE 패킷이 전송될 수 있다.

도 20은 본 발명의 일 실시예에 따른 GET, SET 및 UPDATE에 대해 사용되는 예시적인 패킷 포맷들을 예시한다. 일 실시예에서, 이러한 패킷들은 협상에 이어서 메시지 기입 <65534> 및 메시지 판독 <65533> 채널들을 통해 송신된다. GET 패킷(2001)에서, 제1 1 바이트 필드는 패킷을 GET 패킷으로서 식별하는 값(0X10)을 포함한다. 제2 1 바이트 필드는 현재 GET 커맨드를 고유하게 식별하는(즉, GET 커맨드가 관련된 현재 트랜잭션을 식별하는) 요청 ID를 포함한다. 예를 들어, 서비스 또는 디바이스로부터 송신되는 GET 커맨드의 각각의 인스턴스는 상이한 요청 ID를 할당받을 수 있다. 이것은 예를 들어 카운터를 증가시키고 카운터 값을 요청 ID로서 사용함으로써 행해질 수 있다. 그러나, 본 발명의 기본 원리들은 요청 ID를 설정하기 위한 임의의 특정 방식으로 제한되지 않는다.

2 바이트 속성 ID는 패킷이 지향되는 애플리케이션-특정 속성을 식별한다. 예를 들어, GET 커맨드가 도 19에 예시된 IoT 디바이스(101)로 전송되고 있는 경우, 속성 ID는 요청되는 특정한 애플리케이션-특정 값을 식별하는 데 사용될 수 있다. 위의 예로 되돌아가면, GET 커맨드는 발광체가 파워 온되는지 또는 파워 오프되는지(예컨대, 1 = 온, 0 = 오프)를 식별하는 값을 포함하는 조명 시스템의 전력 상태와 같은 애플리케이션-특정 속성 ID로 지향될 수 있다. IoT 디바이스(101)가 도어와 관련된 보안 장치인 경우, 값 필드는 도어의 현재 상태(예컨대, 1 = 열림, 0 = 닫힘)를 식별할 수 있다. GET 커맨드에 응답하여, 속성 ID에 의해 식별되는 현재 값을 포함하는 응답이 송신될 수 있다.

도 20에 예시된 SET 패킷(2002) 및 UPDATE 패킷(2003)은 또한 패킷의 타입(즉, SET 및 UPDATE)을 식별하는 제1 1 바이트 필드, 요청 ID를 포함하는 제2 1 바이트 필드, 및 애플리케이션 정의 속성을 식별하는 2 바이트 속성 ID 필드를 포함한다. 또한, SET 패킷은 n 바이트 값 데이터 필드에 포함된 데이터를 길이를 식별하는 2 바이트 길이 값을 포함한다. 값 데이터 필드는 IoT 디바이스 상에서 실행될 커맨드 및/또는 소정의 방식으로(예컨대, 원하는 파라미터를 설정하기 위해, IoT 디바이스를 파워 다운시키기 위해, 기타 등등) IoT 디바이스의 동작을 구성하기 위한 구성 데이터를 포함할 수 있다. 예를 들어, IoT 디바이스(101)가 팬의 속도를 제어하는 경우, 값 필드는 현재 팬 속도를 반영할 수 있다.

UPDATE 패킷(2003)은 SET 커맨드의 결과들의 업데이트를 제공하기 위해 송신될 수 있다. UPDATE 패킷(2003)은 SET 커맨드의 결과들과 관련된 데이터를 포함할 수 있는 n 바이트 값 데이터 필드의 길이를 식별하기 위한 2 바이트 길이 값 필드를 포함한다. 또한, 1 바이트 업데이트 상태 필드가 업데이트되는 변수의 현재 상태를 식별할 수 있다. 예를 들어, SET 커맨드가 IoT 디바이스에 의해 제어되는 발광체를 턴오프하려고 시도한 경우, 업데이트 상태 필드는 발광체가 성공적으로 턴오프되었는지를 지시할 수 있다.

도 21은 SET 및 UPDATE 커맨드들을 포함하는 IoT 서비스(120)와 IoT 디바이스(101) 사이의 예시적인 트랜잭션 시퀀스를 예시한다. IoT 허브 및 사용자의 모바일 디바이스와 같은 중개 디바이스들은 본 발명의 기본 원리들을 모호하게 하는 것을 피하기 위해 도시되지 않는다. 2101에서, SET 커맨드(2101)는 IoT 서비스로부터 IoT 디바이스(101)로 송신되고 BT 통신 모듈(1901)에 의해 수신되며, 이 BT 통신 모듈은 2102에서 그에 응답하여 특성 ID에 의해 식별되는 GATT 값 버퍼를 업데이트한다. SET 커맨드는 2103에서 저전력 마이크로제어기(MCU)(200)에 의해(또는 도 19에 도시된 IoT 디바이스 애플리케이션 로직(1902)과 같은 저전력 MCU 상에서 실행되는 프로그램 코드에 의해) 값 버퍼로부터 판독된다. 2104에서, MCU(200) 또는 프로그램 코드는 SET 커맨드에 응답하여 동작을 수행한다. 예를 들어, SET 커맨드는 새로운 온도와 같은 새로운 구성 파라미터를 지정하는 속성 ID를 포함할 수 있거나, (IoT 디바이스가 "온" 또는 저전력 상태에 들어가게 하기 위한) 온/오프와 같은 상태 값을 포함할 수 있다. 따라서, 2104에서, 새로운 값이 IoT 디바이스 안에 설정되고, UPDATE 커맨드가 2105에서 반환되며, 2106에서 실제 값이 GATT 값 필드에서 업데이트된다. 일부 경우에, 실제 값은 원하는 값과 동일할 것이다. 다른 경우에, 업데이트된 값은 상이할 수 있다(즉, 이는 IoT 디바이스(101)가 소정 타입의 값들을 업데이트하는 데 시간이 걸릴 수 있기 때문이다). 마지막으로, 2107에서, GATT 값 필드로부터의 실제 값을 포함하는 UPDATE 커맨드가 다시 IoT 서비스(120)로 송신된다.

도 22는 본 발명의 일 실시예에 따른 IoT 서비스와 IoT 디바이스 사이에 보안 통신 채널을 구현하기 위한 방법을 예시한다. 방법은 전술한 네트워크 아키텍처들의 맥락 내에서 구현될 수 있지만, 임의의 특정 아키텍처로 제한되지 않는다.

2201에서, IoT 서비스는 타원 곡선 디지털 서명 알고리즘(ECDSA) 인증서들을 사용하여 IoT 허브와 통신하기 위한 암호화된 채널을 생성한다. 2202에서, IoT 서비스는 세션 비밀을 사용하여 IoT 디바이스 패킷들 내의 데이터/커맨드를 암호화하여 암호화된 디바이스 패킷을 생성한다. 상기에 언급된 바와 같이, 세션 비밀은 IoT 디바이스 및 IoT 서비스에 의해 독립적으로 생성될 수 있다. 2203에서, IoT 서비스는 암호화된 디바이스 패킷을 암호화된 채널을 통해 IoT 허브로 송신한다. 2204에서, 해독함이 없이, IoT 허브는 암호화된 디바이스 패킷을 IoT 디바이스로 전달한다. 22-5에서, IoT 디바이스는 세션 비밀을 사용하여 암호화된 디바이스 패킷을 해독한다. 언급된 바와 같이, 일 실시예에서, 이것은 (암호화된 디바이스 패킷과 함께 제공된) 비밀 및 카운터 값을 사용하여 키 스트림을 생성한 후에 키 스트림을 사용하여 패킷을 해독함으로써 달성될 수 있다. 이어서, 2206에서, IoT 디바이스는 디바이스 패킷 내에 포함된 데이터 및/또는 커맨드를 추출하여 처리한다.

따라서, 표준 페어링 기술들을 사용하여 BT 디바이스들을 정식으로 페어링함이 없이, 위의 기술들을 사용하여, 2개의 BT 인에이블드 디바이스 사이에 양방향 보안 네트워크 소켓 추상화가 설정될 수 있다. 이러한 기술들은 IoT 서비스(120)와 통신하는 IoT 디바이스(101)와 관련하여 전술되지만, 본 발명의 기본 원리들은 임의의 2개의 BT 인에이블드 디바이스 사이에서 보안 통신 채널을 협상하고 설정하도록 구현될 수 있다.

도 23a 내지 도 23c는 본 발명의 일 실시예에 따른 디바이스들을 페어링하기 위한 상세한 방법을 예시한다. 방법은 상기에 기술된 시스템 아키텍처의 맥락 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

2301에서, IoT 서비스는 IoT 서비스의 일련번호 및 공개 키를 포함하는 패킷을 생성한다. 2302에서, IoT 서비스는 공장 비공개 키를 사용하여 패킷에 서명한다. 2303에서, IoT 서비스는 패킷을 암호화된 채널을 통해 IoT 허브로 전송하고, 2304에서 IoT 허브는 패킷을 암호화되지 않은 채널을 통해 IoT 디바이스로 전송한다. 2305에서, IoT 디바이스는 패킷의 서명을 검증하고, 2306에서 IoT 디바이스는 IoT 디바이스의 일련번호 및 공개 키를 포함하는 패킷을 생성한다. 2307에서, IoT 디바이스는 공장 비공개 키를 사용하여 패킷에 서명하고, 2308에서 IoT 디바이스는 패킷을 암호화되지 않은 채널을 통해 IoT 허브로 전송한다.

2309에서, IoT 허브는 패킷을 암호화된 채널을 통해 IoT 서비스로 전송하고, 2310에서 IoT 서비스는 패킷의 서명을 검증한다. 2311에서, IoT 서비스는 세션 키 쌍을 생성하고, 2312에서 IoT 서비스는 세션 공개 키를 포함하는 패킷을 생성한다. 이어서, IoT 서비스는 2313에서 IoT 서비스 비공개 키로 패킷에 서명하고, 2314에서 IoT 서비스는 패킷을 암호화된 채널을 통해 IoT 허브로 전송한다.

도 23b를 참조하면, IoT 허브는 2315에서 패킷을 암호화되지 않은 채널을 통해 IoT 디바이스로 전송하고, 2316에서 IoT 디바이스는 패킷의 서명을 검증한다. 2317에서, IoT 디바이스는 (예컨대, 전술한 기술을 사용하여) 세션 키 쌍을 생성하고, 2318에서 IoT 디바이스 세션 공개 키를 포함하는 IoT 디바이스 패킷이 생성된다. 2319에서, IoT 디바이스는 IoT 디바이스 비공개 키로 IoT 디바이스 패킷에 서명한다. 2320에서, IoT 디바이스는 패킷을 암호화되지 않은 채널을 통해 IoT 허브로 전송하고, 2321에서 IoT 허브는 패킷을 암호화된 채널을 통해 IoT 서비스로 전송한다.

2322에서, IoT 서비스는 (예컨대, IoT 디바이스 공개 키를 사용하여) 패킷의 서명을 검증하고, 2323에서 IoT 서비스는 (위에서 상세히 설명된 바와 같이) IoT 서비스 비공개 키 및 IoT 디바이스 공개 키를 사용하여 세션 비밀을 생성한다. 2324에서, IoT 디바이스는 (역시, 전술한 바와 같이) IoT 디바이스 비공개 키 및 IoT 서비스 공개 키를 사용하여 세션 비밀을 생성하고, 2325에서 IoT 디바이스는 난수를 생성하고 그것을 세션 비밀을 사용하여 암호화한다. 2326에서, IoT 서비스는 암호화된 패킷을 암호화된 채널을 통해 IoT 허브로 전송한다. 2327에서, IoT 허브는 암호화된 패킷을 암호화되지 않은 채널을 통해 IoT 디바이스로 전송한다. 2328에서, IoT 디바이스는 세션 비밀을 사용하여 패킷을 해독한다.

도 23c를 참조하면, IoT 디바이스는 2329에서 세션 비밀을 사용하여 패킷을 재암호화하고, 2330에서 IoT 디바이스는 암호화된 패킷을 암호화되지 않은 채널을 통해 IoT 허브로 전송한다. 2331에서, IoT 허브는 암호화된 패킷을 암호화된 채널을 통해 IoT 서비스로 전송한다. IoT 서비스는 2332에서 세션 비밀을 사용하여 패킷을 해독한다. 2333에서, IoT 서비스는 난수가 그가 전송한 난수와 일치하는지를 검증한다. 이어서, IoT 서비스는 2334에서 페어링이 완료되었음을 지시하는 패킷을 전송하고, 2335에서 모든 후속 메시지들이 세션 비밀을 사용하여 암호화된다.

데이터 전송 조건을 식별하기 위해 패킷 간격 타이밍을 수정하는 장치 및 방법

블루투스 저에너지(BTLE) 디바이스는 디바이스들 간에 접속을 설정하기 위해 "광고 간격"으로 분리된 광고 패킷을 전송한다. BTLE 주변 디바이스는 광고 간격을 사용하여 주변의 모든 디바이스로 광고 패킷을 브로드캐스팅한다. 이어서, 수신 BTLE 디바이스는 이 정보에 따라 동작하거나 더 많은 정보를 수신하도록 접속할 수 있다.

BTLE에 대한 2.4 ㎓ 스펙트럼은 2402 ㎒에서 2480 ㎒까지 걸치며 0에서 39까지 번호가 매겨진 40개의 1 ㎒ 와이드 채널을 사용한다. 각각의 채널은 2 ㎒만큼 분리된다. 채널들(37, 38, 39)은 광고 패킷을 전송하는 데에만 사용된다. 나머지는 접속 중 데이터 교환에 사용된다. BTLE 광고 동안, BTLE 주변 디바이스는 패킷들을 3개의 광고 채널에서 차례로 송신한다. 디바이스 또는 비콘을 스캐닝하는 중앙 디바이스는 광고 패킷에 대한 그러한 채널들을 청취할 것이며, 이는 그것이 인근 디바이스를 발견하도록 돕는다. 채널들(37, 38, 39)은 의도적으로 2.4 ㎓ 스펙트럼에 걸쳐 확산된다(즉, 채널들(37, 39)은 대역의 첫 번째 및 마지막 채널이며 채널(38)은 중간에 있다). 임의의 단일 광고 채널이 차단되는 경우, 다른 채널들은 수 ㎒의 대역폭만큼 분리되어 있기 때문에 자유로울 가능성이 있다.

IoT 디바이스가 송신될 데이터를 가질 때, 그것은 통상적으로 데이터가 전송될 준비가 되었음을 지시하기 위해 그것의 광고 패킷의 일부로서 플래그를 포함할 것이다. 본 발명의 일 실시예에서, 이 플래그를 사용하기보다는, IoT 디바이스는 그것이 보류 중인 데이터를 가짐을 지시하기 위해 광고 간격을 조정한다. 예를 들어, T가 데이터가 보류 중이 아닌 때의 광고 패킷들 간의 시간인 경우, 0.75T, 0.5T 또는 1.25T와 같은 상이한 광고 간격을 선택하여 데이터가 보류 중임을 지시할 수 있다. 일 실시예에서, 2개의 상이한 간격은 애플리케이션의 특정 요구에 기초하여 프로그래밍 가능하고 어떤 간격이 어떤 상태를 의미하는지를 결정하는 것을 더 어렵게 만든다.

도 24는 BTLE 통신 인터페이스(2410)가 데이터가 송신될 준비가 되었을 때 광고 간격을 조정하는 광고 간격 선택 로직(2411)을 포함하는 IoT 디바이스(101)의 일 실시예를 예시한다. 또한, IoT 허브(110) 상의 BTLE 통신 인터페이스(2420)는 광고 간격의 변화를 검출하고 확인 응답을 제공하며 데이터를 수신하는 광고 간격 검출 로직(2421)을 포함한다.

특히, 예시된 실시예에서, IoT 디바이스(101) 상의 애플리케이션(2401)은 그것이 전송될 데이터를 가지고 있음을 지시한다. 이에 응답하여, 광고 간격 선택 로직(2411)은 광고 간격을 수정하여 IoT 허브(110)에 데이터가 송신될 것임을 통지한다(예를 들어, 간격을.75T 또는 어떤 다른 값으로 변경). 광고 간격 검출 로직(2421)이 변경을 검출하면, BTLE 통신 인터페이스(2420)는 IoT 디바이스(101)의 BTLE 통신 인터페이스(2410)에 접속하여 데이터를 수신할 준비가 되었음을 지시한다. 이어서, IoT 디바이스(101)의 BTLE 통신 인터페이스(2410)는 IoT 허브의 BTLE 통신 인터페이스(2420)에 데이터를 송신한다. 이어서, IoT 허브는 데이터를 IoT 서비스(120) 및/또는 사용자의 클라이언트 디바이스(도시되지 않음)로 통과시킬 수 있다. 데이터가 송신된 후에, 이어서 광고 간격 선택 로직(2411)은 통상의 광고 간격(예를 들어, AI=T)으로 되돌아갈 수 있다.

본 발명의 일 실시예에서, 보안 통신 채널이 전술한 하나 이상의 보안/암호화 기술을 사용하여 IoT 디바이스(101)와 IoT 서비스(120) 간에 설정된다(예를 들어, 도 16a 내지 도 23c 및 관련 텍스트 참조). 예를 들어, 일 실시예에서, IoT 서비스(120)는 IoT 디바이스(101)와 IoT 서비스(120) 사이의 모든 통신을 암호화하기 위해 전술한 바와 같이 IoT 디바이스(101)와의 키 교환을 수행한다.

본 발명의 일 실시예에 따른 방법이 도 25에 예시된다. 방법은 상기에 기술된 시스템 아키텍처의 맥락 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

2500에서, IoT 디바이스는 광고 패킷을 생성할 때 표준 광고 간격을 사용한다(예를 들어, 시간(T)으로 분리됨). IoT 디바이스는, 2501에서 결정된, 전송할 데이터가 있을 때까지 2502에서 표준 광고 간격을 유지한다. 이어서, 2503에서, IoT 디바이스는 광고 간격을 스위칭하여 송신할 데이터가 있음을 지시한다. 2504에서, IoT 허브 또는 다른 네트워크 디바이스는 IoT 디바이스와의 접속을 설정함으로써, IoT 디바이스가 자신의 데이터를 송신할 수 있게 한다. 마지막으로, 2505에서, IoT 디바이스는 자신의 보류 중인 데이터를 IoT 허브로 송신한다.

본 명세서에서 광고 간격 기술이 BTLE 프로토콜의 맥락 내에서 설명되지만, 본 발명의 기본 원리는 BTLE에 제한되지 않는다는 점에 주의해야 한다. 실제로, 본 발명의 기본 원리는 디바이스들 사이의 무선 통신을 설정하기 위한 광고 간격을 선택하는 임의의 시스템 상에서 구현될 수 있다.

또한, 전용 IoT 허브(110)가 상기의 많은 실시예에서 예시되지만, 전용 IoT 허브 하드웨어 플랫폼은 본 발명의 기본 원리를 준수하기 위해 요구되지 않는다. 예를 들어, 상술한 다양한 IoT 허브는 아이폰(iPhone)® 및 안드로이드(Android)® 디바이스와 같은 다양한 다른 네트워킹 디바이스 내에서 실행되는 소프트웨어로서 구현될 수 있다. 실제로, 위에서 논의한 IoT 허브는 IoT 디바이스와 통신하고(예를 들어, BTLE 또는 다른 로컬 무선 프로토콜을 사용) 인터넷을 통해 접속을 설정(예를 들어, WiFi 또는 셀룰러 데이터 접속을 사용하여 IoT 서비스로의)할 수 있는 임의의 디바이스 상에서 구현될 수 있다.

IoT 허브를 IoT 디바이스에 접속시킬 때 무선 트래픽을 감소시키는 시스템 및 방법

다수의 IoT 허브가 특정 위치에서 구성될 때, 단일 IoT 디바이스는 범위 내의 각각의 IoT 허브와 접속할 능력을 가질 수 있다. 언급한 바와 같이, IoT 디바이스는 IoT 허브가 커맨드 및/또는 데이터를 송신하기 위해 그에 접속될 수 있도록 "접속 가능한" 범위 내의 임의의 IoT 허브들에 통지하기 위해 광고 채널을 사용할 수 있다. 다수의 IoT 허브가 IoT 디바이스의 범위 내에 있을 때, IoT 서비스는 이들 IoT 허브 각각을 통해 IoT 디바이스로 어드레싱되는 커맨드/데이터를 송신하려고 시도할 수 있고, 이에 의해 무선 대역폭을 낭비하고 성능을 감소시킨다(예를 들어, 다중 전송들로 인한 간섭으로 인해).

이 문제를 해결하기 위해, 본 발명의 일 실시예는 특정 IoT 허브가 IoT 디바이스에 성공적으로 접속되면 다른 IoT 허브가 커맨드/데이터를 송신하려고 시도하는 것을 중단하도록 통지받을 것을 보장하는 기술을 구현한다. 이 실시예는 모두 IoT 디바이스(101)의 범위 내에 있는 IoT 허브들(110 내지 112)의 예시적인 세트를 도시하는 도 26a 내지 도 26c와 관련하여 설명될 것이다. 그 결과, IoT 디바이스(101)의 보안 무선 통신 모듈(2610)은 IoT 허브들(110 내지 112) 각각의 보안 무선 통신 모듈들(2650 내지 2652)을 보고 그에 접속할 수 있다. 일 실시예에서, 보안 무선 통신 모듈은 전술한 보안 BTLE 모듈을 포함한다. 그러나, 본 발명의 기본 원리들은 임의의 특정 무선 표준으로 제한되지 않는다.

도 26a에 예시된 바와 같이, 일 실시예에서, IoT 디바이스(101)의 보안 무선 통신 모듈(2610)은, 그것이 "접속 가능"하다(즉, 범위 내의 임의의 디바이스에 의해 그에 접속될 수 있음)는 것을 지시하는 광고 비콘을 인근 무선 통신 디바이스들에 주기적으로 송신하는 광고 제어 로직(2610)을 포함한다. 이어서, 광고 비콘을 수신하는 임의의 IoT 허브들(110 내지 112)은 IoT 디바이스(101)를 인식하고, 보안 무선 통신 모듈들(2650 내지 2652)은 커맨드/데이터가 IoT 서비스에 의해 IoT 디바이스(101)로 어드레싱되었을 때 IoT 디바이스(101)의 보안 무선 통신 모듈(2610)에 접속할 수 있다.

도 26b에 예시된 바와 같이, 일 실시예에서, IoT 서비스가 IoT 디바이스(101)에 대한 데이터/커맨드를 가질 때, IoT 서비스는 데이터/커맨드를 특정 위치 내의 IoT 허브들(110 내지 112) 모두(예를 들어, 사용자의 계정과 관련된 및/또는 IoT 디바이스(101)의 범위 내의 모든 IoT 허브)로 송신할 수 있다. 예시된 바와 같이, 이어서, IoT 허브들(110 내지 112) 각각은 커맨드/데이터를 제공하기 위해 IoT 디바이스(101)와 접속하려고 시도할 수 있다.

도 26c에 예시된 바와 같이, 일 실시예에서, 단일의 IoT 허브(111)만이 IoT 디바이스(101)에 성공적으로 접속하고 IoT 디바이스(101)에 의한 처리를 위한 커맨드/데이터를 제공할 것이다. BTLE와 같은 소정 무선 통신 프로토콜에서, 일단 접속이 이루어지면, 보안 무선 통신 모듈(2610)은 광고 비콘을 송신하는 것을 중단할 것이다. 그렇기 때문에, 다른 IoT 허브들(110, 112)은 IoT 디바이스(101)가 IoT 허브(111)로부터 데이터를 성공적으로 수신했다는 것을 알 수 있는 어떠한 방법도 갖지 않을 것이며, 커맨드/데이터를 송신하려고 계속 시도할 것이고, 그에 따라 무선 대역폭을 소비하고 간섭을 생성한다.

이러한 제한을 해결하기 위해, 보안 무선 통신 모듈(2610)의 일 실시예는, IoT 허브(111)의 보안 무선 통신 모듈(2651)과의 성공적인 접속을 검출할 때, 광고 제어 모듈(2612)이 광고 비콘을 계속 송신하게 하는 접속 관리자(2611)를 포함한다. 그러나, IoT 디바이스(101)가 "접속 가능하다"는 것을 지시하는 대신에, 새로운 광고 비콘은 IoT 디바이스(101)가 "접속 가능하지 않음"을 지시한다. 일 실시예에서, "접속 가능하지 않음" 지시에 응답하여, IoT 허브들(110, 112)의 보안 무선 통신 모듈들(2650, 2652)은 IoT 디바이스에 커맨드/데이터를 송신하려고 시도하는 것을 중단함으로써 불필요한 무선 트래픽을 감소시킬 것이다.

상기 기술들은 기존의 무선 프로토콜들 외에 쉽게 구현될 수 있는 기술들을 사용하여 바람직하지 않은 무선 트래픽에 대한 훌륭한 해결책을 제공한다. 예를 들어, 일 실시예에서, "접속 가능" 및 "접속 가능하지 않음" 지시는 BTLE 표준의 맥락 내에서 구현된다. 그러나, 언급한 바와 같이, 본 발명의 기본 원리는 다양한 상이한 무선 네트워크 프로토콜을 사용하여 구현될 수 있다.

본 발명의 일 실시예에 따른 방법이 도 27에 예시된다. 방법은 상기에 기술된 시스템 아키텍처의 맥락 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

2701에서, 커맨드 및/또는 데이터는 2개 이상의 IoT 허브를 통해 IoT 서비스로부터 송신된다. 예를 들어, 사용자는 IoT 서비스에 접속된 사용자의 모바일 디바이스 상의 앱을 통해 IoT 디바이스를 제어하려고 시도하고 있을 수 있다. 2702에서, IoT 허브는 IoT 디바이스에 접속하려고 시도하고 IoT 허브들 중 하나가 성공적으로 접속하고 IoT 디바이스에 커맨드/데이터를 제공한다. 언급한 바와 같이, IoT 허브는 IoT 디바이스가 광고 비콘에서 "접속 가능" 지시를 송신하는 결과로서 IoT 디바이스를 인식할 수 있다.

2703에서, 성공적인 접속에 응답하여, IoT 디바이스는 "접속 가능하지 않음" 광고 비콘을 송신하기 시작하고, 이에 의해 IoT 디바이스가 더 이상 접속 가능하지 않음을 범위 내의 임의의 IoT 허브에 알린다. 2704에서, "접속 가능하지 않음" 비콘을 수신하면, 다른 IoT 허브는 커맨드/데이터를 IoT 디바이스로 송신하려고 시도하는 것을 중단한다.

보안 사물 인터넷(IoT) 디바이스 프로비저닝을 위한 시스템 및 방법

전술한 바와 같이, 일 실시예에서, 디바이스가 IoT 허브에 광고할 때, 그것은 IoT 디바이스를 고유하게 식별하기 위해 허브 및 IoT 서비스가 사용하는 8 바이트의 "디바이스 ID"를 사용한다. 디바이스 ID는, 판독되고 시스템에 IoT 디바이스를 프로비저닝/등록하기 위해 IoT 서비스로 송신되는, IoT 디바이스 상에 인쇄된 고유 바코드 또는 QR 코드 내에 포함될 수 있다. 프로비저닝/등록되면, 디바이스 ID는 시스템의 IoT 디바이스를 어드레싱하는 데 사용된다.

이 구현에 관한 한 가지 보안 문제는, 바코드/QR 코드 데이터가 암호화 없이 송신될 수 있기 때문에, 디바이스 ID의 무선 전송을 스니핑(sniffing)하여 시스템을 손상시킬 수 있어서, 다른 사용자가 디바이스 ID를 자신의 계정과 관련시킬 수 있게 한다는 점이다.

일 실시예에서, 이러한 문제를 해결하기 위해, "관련 ID"는 각각의 디바이스 ID와 관련되고, 프로비저닝 프로세스 중에 사용되어 디바이스 Id가 명확하게 결코 송신되지 않음을 보장한다. 도 28에 예시된 바와 같이, 이 실시예에서, 관련 ID(2812)는 IoT 디바이스(101) 상에 인쇄된 바코드/QR 코드에 포함되는 반면 디바이스 ID(2811)는 보안 무선 통신 모듈(2810) 내에 안전하게 유지되며, 이는 IoT 서비스(120)와의 보안 통신을 보장하기 위해 전술한 기술을 구현한다. 일 실시예에서, 관련 ID(2812)는 디바이스 ID와 같이 8 바이트 ID이고 IoT 디바이스마다 고유하다. 새로운 IoT 디바이스(101)가 시스템에 프로비저닝될 때, 사용자는 IoT 앱 또는 애플리케이션이 설치된 사용자 디바이스(135)를 이용하여 관련 ID(2812)를 포함하는 바코드/QR 코드를 스캔한다. 대안적으로, 또는 부가적으로, IoT 허브(110)는 관련 ID를 포함하는 바코드/QR 코드를 캡처하는 데 사용될 수 있다.

어느 경우이든, 관련 ID는 각각의 관련 ID와 각각의 디바이스 ID 사이의 관련을 포함하는 디바이스 데이터베이스(2851)에서 탐색을 수행하는 IoT 서비스(120) 상의 디바이스 프로비저닝 모듈(2850)로 송신된다. 디바이스 프로비저닝 모듈(2850)은 관련 ID(2812)를 사용하여 디바이스 ID(2811)를 식별하고, 이어서 디바이스 ID를 사용하여 시스템에 새로운 IoT 디바이스(101)를 프로비저닝한다. 특히, 디바이스 ID가 디바이스 데이터베이스(2851)로부터 결정되면, 디바이스 프로비저닝 모듈(2850)은 디바이스 ID(2811)를 사용하여 IoT 허브(110)가 IoT 디바이스(101)와 통신하도록 인가하는 커맨드를 IoT 허브(110)(사용자 디바이스(135)를 포함할 수 있음)로 송신한다.

일 실시예에서, 관련 ID(2812)는 IoT 디바이스(101)가 제조될 때(즉, 보안 무선 통신 모듈(2810)이 프로비저닝될 때) 공장에서 생성된다. 이어서, 디바이스 ID(2811) 및 관련 ID(2812) 둘 모두가 IoT 서비스에 제공될 수 있고 디바이스 데이터베이스(2851) 내에 저장될 수 있다. 예시된 바와 같이, 디바이스 데이터베이스(2851)는 각각의 디바이스가 프로비저닝되었는지 여부를 지정하는 지시를 포함할 수 있다. 예로서, 이는 IoT 디바이스(101)가 프로비저닝됨을 지시하는 제1 값(예컨대, 1) 및 IoT 디바이스가 프로비저닝되지 않음을 지시하는 제2 값(예컨대, 0)을 갖는 2진 값일 수 있다. 시스템이 IoT 디바이스(101)를 프로비저닝/등록하면, IoT 서비스(120)와 IoT 디바이스(101) 사이의 통신이 전술한 보안 기술을 사용하여 보호되기 때문에 디바이스 ID가 사용될 수 있다.

일 실시예에서, 사용자가 IoT 디바이스를 판매할 때, 사용자는 IoT 서비스(120)에 로그인하고 사용자의 계정으로부터 IoT 디바이스를 해제함으로써 디바이스 ID를 해제할 수 있다. 이어서, 새로운 사용자는 본 명세서에 설명된 디바이스 프로비저닝 기술을 사용하여 IoT 디바이스를 프로비저닝하고 IoT 디바이스를 자신의 계정과 관련시킬 수 있다.

본 발명의 일 실시예에 따른 방법이 도 29에 예시된다. 방법은 상기에 기술된 시스템 아키텍처의 맥락 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

2901에서, 디바이스 ID와 IoT 디바이스의 관련 ID 사이에 관련이 생성된다(예를 들어, IoT 디바이스가 제조되는 공장에서). 관련 ID는 IoT 디바이스 상에 스탬핑된 바코드/QR 코드 내에 임베딩될 수 있다. 2902에서, 디바이스 ID와 관련 ID 사이의 관련이 IoT 서비스 상에 저장된다. 2903에서, 사용자는 새로운 IoT 디바이스를 구입하고 (예를 들어, 앱 또는 애플리케이션이 설치된 사용자의 모바일 디바이스를 통해 또는 바코드 판독기를 갖는 IoT 허브를 통해) 관련 ID를 포함하는 바코드/QR 코드를 스캔한다.

2904에서, 관련 ID는 IoT 서비스로 송신되고, 2905에서, 관련 ID는 디바이스 ID를 식별하는 데 사용된다. 2906에서, IoT 디바이스는 디바이스 ID를 사용하여 프로비저닝된다. 예를 들어, IoT 디바이스 데이터베이스는 이 특정 디바이스 ID가 프로비저닝되었음을 지시하도록 업데이트될 수 있고 IoT 서비스는 디바이스 ID를 IoT 허브에 통신하여, IoT 허브에게 새로운 IoT 디바이스와 통신하도록 명령할 수 있다.

사물 인터넷(IoT) 시스템에서 흐름 제어를 수행하는 시스템 및 방법

로컬 무선 네트워크 트래픽은 주어진 위치 내의 IoT 디바이스들의 수에 기초하여 증가할 것이다. 또한, 일부의 경우에, IoT 디바이스는 IoT 디바이스에 의해 수행되고 있는 기능을 고려할 때 합당한 것보다 더 많은 데이터를 송신하고 있을 수 있다. 예를 들어, IoT 디바이스 상의 소프트웨어/하드웨어가 오작동할 수 있거나, IoT 디바이스가 해킹되어, IoT 디바이스가 불필요한 데이터를 IoT 서비스에 계속해서 송신하게 할 수 있다.

본 발명의 일 실시예는 지정된 데이터 임계치가 특정 IoT 디바이스에 의해 도달되었을 때 IoT 허브에서 흐름 제어를 수행하여, 데이터 트래픽을 효과적으로 무시함으로써 이러한 문제를 해결한다. 일 실시예에서, 각각의 IoT 디바이스는 IoT 디바이스가 송신하도록 허용된 기간에 걸친 데이터 양을 지시하는 흐름 제어 파라미터들의 지정된 세트로 구성된다. 흐름 제어 파라미터들은 IoT 디바이스의 타입에 기초할 수 있다. 예를 들어, 도어 록 및 온도 조절기와 같은 소정 IoT 디바이스는 전형적으로 짧은 데이터 패킷만을 주기적으로 송신해야 하는 반면, 비디오 카메라와 같은 다른 IoT 디바이스는 잠재적으로 비-주기적 방식으로 상당히 더 많은 양의 데이터를 송신할 수 있다. 따라서, 흐름 제어 파라미터들은 문제의 IoT 디바이스의 예상 동작에 기초하여 충분한 양의 대역폭을 제공하도록 설정될 수 있다. 일 실시예에서, 각각의 IoT 디바이스는 그 IoT 디바이스의 데이터 요구에 기초하여 특정 흐름 제어 "클래스"에 할당된다.

그러한 실시예가 도 30에 예시되면, 이는 상이한 세트의 흐름 제어 파라미터들(3015, 3031, 3041)로 각각 구성된 보안 무선 통신 모듈(2810, 3030, 3040)을 갖는 복수의 IoT 디바이스(101 내지 103)를 도시한다. 일 실시예에서, 흐름 제어 파라미터들은 각각의 IoT 디바이스가 지정된 기간에 걸쳐 송신할 것으로 예상되는 데이터의 양 및/또는 빈도를 지정한다(예를 들어,.25 Mbyte/시간, 50 Mbyte/시간, 100 Mbyte/일, 10회의 통신 시도/일 등). 일 실시예에서, 흐름 제어 파라미터들(3015, 3031, 3041)은, 예시된 바와 같이, IoT 디바이스 데이터베이스(2851) 내의 디바이스별 흐름 제어 파라미터들(3020)의 세트를 관리하는 디바이스 관리 모듈(3021)을 포함하는 IoT 서비스(120)에 의해 지정될 수 있다. 예를 들어, 각각의 IoT 디바이스에 대한 데이터 전송 요구가 결정되면, 디바이스별 흐름 제어 파라미터들(3020)은 이러한 요구를 반영하도록 업데이트될 수 있다.

언급된 바와 같이, 일 실시예에서, 디바이스 데이터베이스(2851)는 복수의 상이한 흐름 제어 "클래스"(예를 들어, 시청각 디바이스, 온도 디바이스, 제어 디바이스, 보안 디바이스 등)에 대한 데이터 전송 요구를 포함한다. 새로운 IoT 디바이스가 시스템에 도입될 때, 그것은 IoT 디바이스의 요구 및/또는 IoT 디바이스의 타입에 기초하여 특정 흐름 제어 클래스와 관련된다.

디바이스별 흐름 제어 파라미터들(3020)은 로컬 데이터베이스 내에 디바이스별 흐름 제어 파라미터들(3010)의 사본을 저장하는 흐름 제어 관리 로직(2811)을 포함하는 IoT 허브(110)에 분배될 수 있다. 일 실시예에서, 흐름 제어 관리(2811)는 각각의 IoT 디바이스(101 내지 103)로부터 수신되고/되거나 그로 송신되는 데이터 트래픽의 양을 모니터링할 수 있다. 데이터 트래픽의 양이 (디바이스별 흐름 제어 파라미터들(3010)에 의해 표시된 바와 같은) 지정된 임계치에 도달하면, IoT 허브(110)는 일정 기간 동안 송신하는 것을 중단하도록 IoT 디바이스에게 명령할 수 있고/있거나 단순히 IoT 디바이스로부터 트래픽을 차단할 수 있다.

특정 IoT 디바이스가 지정된 임계치보다 높은 레벨에서 송신/수신하고 있으면, 이는 IoT 디바이스가 오작동 중임을 지시할 수 있다. 그렇기 때문에, 일 실시예에서, IoT 서비스(120)는 IoT 디바이스를 리셋하라는 커맨드를 송신할 수 있다. 디바이스가 여전히 임계치보다 높은 레벨에서 통신하고 있는 경우, IoT 서비스(120)는 IoT 디바이스에 패치와 같은 소프트웨어 업데이트를 송신할 수 있다. 업데이트된 소프트웨어가 설치되면, IoT 디바이스가 리셋되고 새로운 소프트웨어로 초기화된다. 또한, IoT 디바이스가 오작동하는 것을 사용자에게 알리기 위해 IoT 서비스로부터 사용자 디바이스로 통지가 전송될 수 있다.

일 실시예에서, IoT 허브(110)는 데이터 통신 임계치에 도달했다는 사실에도 불구하고 소정 타입의 데이터 트래픽을 허용할 수 있다. 예를 들어, 일 실시예에서, IoT 허브(110)는 IoT 디바이스가 자신의 임계치에 도달했더라도 소정 타입의 "높은 우선 순위" 통지를 허용할 것이다. 예로서, IoT 디바이스가 도어 록 또는 도어 엔트리 검출기인 경우, 소정 조건하에서(예를 들어, 집이 모니터링되고 있을 때), IoT 허브(110)는 IoT 디바이스가 사용되고 있는 도어를 누군가가 열었음을 지시하는 데이터를 통과시킬 수 있다. 유사하게, IoT 디바이스가 열 및/또는 연기 검출기인 경우, IoT 허브(110)는 (예를 들어, 온도가 임계 값에 도달했기 때문에) 알람 조건을 지시하는 데이터를 통과시킬 수 있다. (예를 들어, 잠재적으로 위험한 조건을 표현하는 것과 같은) 다양한 다른 타입의 "높은 우선 순위" 통지가 현재의 흐름 제어 상태에 무관하게 IoT 허브(110)에 의해 통과될 수 있다. 일 실시예에서, 이들 "높은 우선 순위" 통지는 후술되는 바와 같이 상이한 속성들을 사용하여 식별된다.

본 발명의 일 실시예에 따른 방법이 도 31에 예시된다. 방법은 상기에 기술된 시스템 아키텍처의 맥락 내에서 구현될 수 있지만, 임의의 특정 시스템 아키텍처로 제한되지 않는다.

3101에서, 각각의 IoT 디바이스에 대해 흐름 제어 파라미터들이 지정된다. 일 실시예에서, IoT 디바이스는 그와 관련된 흐름 제어 파라미터들의 지정된 세트를 갖는 특정 IoT 디바이스 "클래스"에 할당될 수 있다. 3102에서, 흐름 제어 파라미터들은 IoT 시스템 내의 IoT 허브 상에 저장된다. 일 실시예에서, 각각의 허브는 IoT 디바이스 파라미터들(예를 들어, 로컬식으로 프로비저닝된 IoT 디바이스들에 대한 그 파라미터들만) 모두의 서브 세트를 저장할 수 있다.

IoT 허브가 특정 IoT 디바이스가 3103에서 결정된 지정된 흐름 제어 파라미터들 밖에서 동작하고 있음을 검출하면, 3104에서, IoT 허브는 IoT 디바이스와의 추가적인 통신을 일시적으로 억제할 것이다(예를 들어, IoT 디바이스와 IoT 서비스 사이의 통신을 차단). 또한, 언급한 바와 같이, IoT 서비스 및/또는 IoT 허브는 IoT 디바이스를 재부팅하고/하거나 IoT 디바이스 상에 소프트웨어 업데이트를 설치함으로써 문제를 해결하기 위한 조치를 취할 수 있다.

속성 클래스를 사용하여 사물 인터넷(IOT) 디바이스 및 트래픽을 관리하기 위한 시스템 및 방법

상이한 IoT 디바이스들이 주어진 위치에서 상이한 기능들을 수행하는 데 사용될 수 있다. 예를 들어, 소정 IoT 디바이스가 온도 및 상태(예컨대, 온/오프 상태)와 같은 데이터를 수집하고, 이 데이터가 최종 사용자에 의해 액세스되고/되거나 다양한 타입의 경고 조건들을 생성하는 데 사용될 수 있는 IoT 서비스에 이 데이터를 다시 보고하는 데 사용될 수 있다. 이 구현을 가능하게 하기 위해, 본 발명의 일 실시예는 수집된 데이터, 시스템 데이터, 및 다른 형태의 데이터를 상이한 타입의 속성 클래스들을 사용하여 관리한다.

도 32는 직렬 주변 인터페이스(SPI) 버스와 같은 직렬 인터페이스(3216)를 통해 마이크로제어기 유닛(MCU)(3215)과 통신하는 보안 무선 통신 모듈(3218)을 포함하는 IoT 디바이스의 일 실시예를 예시한다. 보안 무선 통신 모듈(3218)은 전술한 기술들을 사용하여 IoT 서비스(120)와의 보안 통신을 관리하고, MCU(3215)는 IoT 디바이스(101)의 애플리케이션-특정 기능을 수행하기 위한 프로그램 코드를 실행한다.

일 실시예에서, IoT 디바이스에 의해 수집된 데이터 및 IoT 디바이스에 관련된 시스템 구성을 관리하기 위해 다양한 상이한 속성 클래스들이 사용된다. 특히, 도 32에 도시된 예에서, 속성들은 애플리케이션 속성들(3210), 시스템 속성들(3211), 및 우선 순위 통지 속성들(3212)을 포함한다. 일 실시예에서, 애플리케이션 속성들(3210)은 IoT 디바이스(101)에 의해 수행되는 애플리케이션-특정 기능과 관련된 속성들을 포함한다. 예를 들어, IoT 디바이스가 보안 센서를 포함하면, 애플리케이션 속성들(3210)은 도어 또는 윈도우가 개방되었는지 여부를 지시하는 2진 값을 포함할 수 있다. IoT 디바이스가 온도 센서를 포함하면, 애플리케이션 속성들(3210)은 현재 온도를 지시하는 값을 포함할 수 있다. 사실상 무제한 수의 다른 애플리케이션-특정 속성들이 정의될 수 있다. 일 실시예에서, MCU(3215)는 애플리케이션-특정 프로그램 코드를 실행하고, 애플리케이션-특정 속성들(3210)에 대한 액세스만 제공받는다. 예를 들어, 애플리케이션 개발자는 보안 무선 통신 모듈(3218)을 갖는 IoT 디바이스(101)를 구입하고 MCU(3215)에 의해 실행될 애플리케이션 프로그램 코드를 설계할 수 있다. 결과적으로, 애플리케이션 개발자는 애플리케이션 속성들에 액세스할 필요가 있을 것이지만, 아래에 설명되는 다른 타입의 속성들에 액세스할 필요는 없을 것이다.

일 실시예에서, 시스템 속성들(3211)은 IoT 디바이스(101) 및 IoT 시스템에 대한 동작 및 구성 속성들을 정의하는 데 사용된다. 예를 들어, 시스템 속성들은 네트워크 구성 설정(예컨대, 상기 논의한 흐름 제어 파라미터들과 같은), 디바이스 ID, 소프트웨어 버전, 광고 간격 선택, 보안 구현 특징부(상기 설명한) 및 IoT 디바이스(101)가 IoT 서비스와 안전하게 통신할 수 있게 하는 데 필요한 다양한 다른 낮은 레벨 변수를 포함할 수 있다.

일 실시예에서, 우선 순위 통지 속성들(3212)의 세트가 이들 속성들과 관련된 중요성 또는 심각성의 레벨에 기초하여 정의된다. 예를 들어, 특정 속성이 임계치에 도달하는 온도 값과 같은 위험한 조건(예컨대, 사용자가 실수로 스토브를 켜진 채로 나둔 경우 또는 사용자의 집 안의 열 센서가 트리거될 때)과 관련된 경우, 이 속성은 우선 순위 통지 속성 클래스에 할당될 수 있다. 전술한 바와 같이, 우선 순위 통지 속성들은 다른 속성들과는 상이하게 처리될 수 있다. 예를 들어, 특정 우선 순위 통지 속성이 임계치에 도달할 때, IoT 허브는 IoT 허브에 의해 구현되고 있는 현재의 흐름 제어 메커니즘에 관계없이, IoT 서비스에 속성의 값을 전달할 수 있다. 일 실시예에서, 우선 순위 통지 속성들은 또한 IoT 서비스를 트리거하여 (예를 들어, 사용자에게 잠재적으로 위험한 조건을 경고하기 위해) 사용자의 집 또는 사업장 내의 알람 조건들 및/또는 사용자에 대한 통지를 생성할 수 있다.

도 32에 예시된 바와 같이, 일 실시예에서, 애플리케이션 속성들(3210), 시스템 속성들(3211) 및 우선 순위 통지 속성들(3212)의 현재 상태는 IoT 서비스(120) 상의 디바이스 데이터베이스(2851) 내에 복제/미러링된다. 예를 들어, 속성들 중 하나의 변경이 IoT 디바이스(101) 상에서 업데이트될 때, 보안 무선 통신 모듈(3218)은 이 변경을 IoT 서비스(120) 상의 디바이스 관리 로직(3021)에 통신하고, 그것은 디바이스 데이터베이스(2851) 내의 속성의 값을 응답적으로 업데이트한다. 또한, 사용자가 IoT 서비스 상에서 속성들 중 하나를 업데이트하는 경우(예를 들어, 원하는 온도와 같은 현재 상태 또는 조건을 조정함), 속성 변경은 디바이스 관리 로직(3021)으로부터 보안 무선 통신 모듈(3218)로 송신될 것이고, 그것은 이어서 자신의 속성의 로컬 사본을 업데이트할 것이다. 이러한 방식으로, 속성들은 IoT 디바이스(101)와 IoT 서비스(120) 간에 일관된 방식으로 유지된다. 속성들은 또한 IoT 앱 또는 애플리케이션이 설치된 사용자 디바이스를 통해 그리고/또는 하나 이상의 외부 서비스(3270)에 의해 IoT 서비스(120)로부터 액세스될 수 있다. 언급한 바와 같이, IoT 서비스(120)는 다양한 상이한 속성 클래스들에 대한 액세스를 제공하기 위해 애플리케이션 프로그래밍 인터페이스(API)를 노출시킬 수 있다.

또한, 일 실시예에서, 우선 순위 통지 처리 로직(3022)은 우선 순위 통지 속성(3212)에 관련된 통지의 수신에 응답하여 규칙 기반 동작을 수행할 수 있다. 예를 들어, 우선 순위 통지 속성이 위험한 조건(예를 들어, 다리미 또는 스토브가 사용자에 의해 온 상태로 있는 것과 같은)을 지시하면, 우선 순위 통지 처리 로직(3022)은 위험한 디바이스를 턴오프하려고 시도하는 규칙들의 세트를 구현할 수 있다(예를 들어, 가능한 경우 디바이스에 "오프" 커맨드를 전송). 일 실시예에서, 우선 순위 통지 처리 로직(3022)은 (예를 들어, 위험한 디바이스가 "온" 상태에 있을 때 사용자가 집을 떠난 것으로 검출되는 경우) 위험한 디바이스를 턴오프할지 여부를 결정하기 위해 사용자의 현재 위치와 같은 다른 관련 데이터를 이용할 수 있다. 또한, 우선 순위 통지 처리 로직(3022)은 사용자의 클라이언트 디바이스에 경고 조건을 송신하여 사용자에게 조건을 통지할 수 있다. 잠재적으로 위험한 또는 달리 바람직하지 않은 조건을 해결하려고 시도하기 위해 우선 순위 통지 처리 로직(3022)에 의해 다양한 다른 타입의 규칙 세트들이 구현될 수 있다.

BTLE 속성들(3205)의 세트 및 속성 어드레스 디코더(3207)가 또한 도 32에 도시되어 있다. 일 실시예에서, BTLE 속성들(3205)은 도 19 및 도 20에 대해 전술한 바와 같이 판독 및 기입 포트를 설정하는 데 사용될 수 있다. 속성 어드레스 디코더(3207)는 각각의 속성과 관련된 고유 ID 코드를 판독하여 어느 속성이 수신/송신되고 있는지를 결정하고 그에 맞춰 속성을 처리한다(예를 들어, 속성이 보안 무선 통신 모듈(3218) 내에 저장된 곳을 식별한다).

A. 가짜 광고

소정 예들에서, 공격자가 가짜 IoT 디바이스를 사용하여 정상 상태(즉, 전송할 데이터 없음)에 있는 실제 IoT 디바이스와 동일한 광고 데이터를 광고하는 것이 가능할 수 있다. 이 광고 패킷이 실제 신호보다 더 강한 신호를 사용하여 전송되는 경우, 허브는 실제 IoT 디바이스에 접속하려고 전혀 시도하지 못하도록 제어될 수 있다. 예를 들어, 도어 센서의 경우, 공격자는 그렇다면 검출됨이 없이 도어를 열 수 있다.

본 발명의 일 실시예에서, 각각의 IoT 디바이스는 모든 IoT 허브들에 대해 이용 가능해지는 그의 광고 데이터에 암호 비밀을 추가하며, 따라서 그들은 실제 IoT 디바이스들을 가짜 IoT 디바이스들과 구별할 수 있다. 일 실시예에서, 암호 비밀은 시스템 속성으로서 설정되며, 따라서 IoT 서비스에 대해 먼저 이용 가능해질 것이고, 그로부터 SSL 또는 다른 보안 통신 프로토콜을 사용하여 IoT 허브들 각각으로 배포될 수 있다.

도 33은 본 발명의 일 실시예에 따른 IoT 디바이스(101), IoT 서비스(120) 및 IoT 허브(110)에 의해 수행되는 동작들을 예시한다. IoT 디바이스 부팅시, IoT 디바이스(101)가 링크되기 전에, IoT 디바이스(101)는 설정된 링크 요청 플래그들 및 접속 요청 플래그들 및 (링크/접속이 요청되고 있음을 나타내는) 0으로 설정된 비밀 바이트들을 이용하여 IoT 허브(110)에 광고할 수 있다. 이어서, IoT 허브 또는 클라이언트 디바이스와의 링크가 형성된다. 링크 형성 후, 보안 무선 통신 모듈(3218)의 비밀-카운터 처리 로직(3310)은 32 바이트 마스터 비밀(3322)을 생성하고, (예를 들어, 전술한 속성 동기화 기술들을 사용하여) 이를 시스템 속성(3211) 상에 설정하여 IoT 서비스(120)에 대해 이용 가능해지게 한다.

그 다음, IoT 서비스(120)는 그 비밀이 SSL 또는 다른 보안 프로토콜을 통해 IoT 허브들(110)에 대해 이용 가능해지게 할 수 있다. 비밀/카운터 처리 로직(3310)은 32 바이트 카운터 COUNTER_1(3331)을 생성하고 이를 0으로 초기화한다. 비밀/카운터 처리 로직(3310)은 32 바이트 COUNTER_1(3331)과 결합하여 32 바이트 마스터 비밀(3322)을 사용하여 32 바이트 공유 비밀(3340)을 생성한다. 일 실시예에서, 키잉-해시 메시지 인증 코드(keyed-hash message authentication code, HMAC)-SHA256이 HMAC에 대한 키로서 마스터 비밀을 그리고 데이터로서 COUNTER_1을 사용하여 공유 비밀(3340)을 생성하는 데 사용된다.

비밀/카운터 처리 로직(3310)은 1 바이트 카운터 COUNTER_2(3332)를 생성하고 이를 0으로 초기화한다. 일 실시예에서, HMAC 생성 로직(3345)은 공유 비밀을 사용하여, (예로서, SHA256을 사용하여) 광고 플래그들 및 COUNTER_2(3332)의 HMAC(3312)를 생성한다. 키는 32 바이트 공유 비밀(3340)이며, 데이터는 광고 패킷(3314)으로부터의 제조자 데이터에 이어서 COUNTER_2(3332)에 이어서 32 바이트에 패딩할 0들의 시퀀스로 구성되는 32 바이트이다. 일 실시예에서, 32 바이트 버퍼(3317)가 생성되고, 0으로 종료된다. 버퍼 안으로, 버퍼는 2 바이트 제조자 ID, 플래그들을 포함하는 제조자 데이터, 디바이스 ID, 프로토콜 버전을 포함하는 광고 패킷(3314)으로부터 데이터를 복사한다. 버퍼는 또한 현재의 COUNTER_2 값(3332)을 복사한다. HMAC 생성 로직(3345)은 키로서 공유 비밀(3340)을 그리고 데이터로서 32 바이트 버퍼(3317)의 내용들을 사용하여 HMAC(3312)를 생성한다.

일 실시예에서, HMAC(3312)의 바이트들(26, 27)은 COUNTER_2 값(3332)에 바로 이어서 광고 패킷(3314) 내에 배치된다. 그 다음, 비밀/카운터 처리 로직(3310)은 다른 시스템 속성(예컨대, 타이머 속성)에서 지정된 빈도에 기초하여 작동하도록 타이머(3311)를 설정한다. 일 실시예에서, 이 기간은 5분이다.

일 실시예에서, 타이머가 작동할 때, 비밀/카운터 처리 로직(3310)은 32 바이트 COUNTER_1을 증가시키고, 32 바이트 COUNTER_1과 결합하여 32 바이트 마스터 비밀을 사용하여 새로운 32 바이트 공유 비밀을 생성한다. 비밀/카운터 처리 로직(3310)은 1 바이트 COUNTER_2를 증가시키고, 32 바이트 버퍼(3317)를 생성하고, 이를 0으로 종료한다. 버퍼 안으로, 버퍼는 2 바이트 제조자 ID, 플래그들을 포함하는 제조자 데이터, 디바이스 id, 프로토콜 버전 및 COUNTER_2의 값을 복사한다. HMAC 생성 로직(3345)은 키로서 공유 비밀(3340)을 그리고 데이터로서 32 바이트 버퍼(3317)를 사용하여 HMAC(3312)를 생성한다. HMAC의 바이트들(26, 27)은 COUNTER_2(3332)에 바로 이어서 광고 패킷(3314) 내에 배치된다.

일 실시예에서, 광고 플래그들이 변할 때, 비밀/카운터 처리 로직(3310)은 1 바이트 COUNTER_2를 증가시키고, 32 바이트 버퍼(3317)를 생성하고, 이를 0으로 종료한다. 버퍼(3317) 안으로, 버퍼는 2 바이트 제조자 ID, 플래그들을 포함하는 제조자 데이터, 디바이스 ID, 프로토콜 버전 및 COUNTER_2(3332)를 복사한다. HMAC 생성(3345) HMAC(3312)는 키로서 공유 비밀을 그리고 데이터로서 32 바이트 버퍼를 사용하여 생성된다. HMAC(3312)의 바이트들(26, 27)은 COUNTER_2(3332)에 바로 이어서 광고 패킷(3314) 내에 배치된다.

본 발명의 일 실시예에서는, 다음의 보안 처리 동작들이 IoT 허브(110) 상에서 수행된다. IoT 허브(110)가 IoT 디바이스(101)에 대한 마스터 비밀(3322) 및 counter 1(3331)을 수신할 때, 공유 비밀 생성 로직(3350)은 마스터 비밀 및 counter 1(+ 또는 - 1)을 사용하여 IoT 디바이스(101)에 대한 3개의 공유 비밀(3355)을 생성 및 저장한다. 허브(110)는 다른 시스템 속성에서 지정된 빈도(예컨대, 일 실시예에서 5분)에 기초하여 작동하도록 타이머(3351)를 설정한다. 타이머가 작동할 때, IoT 허브(110)는 counter 1을 증가시키고, 이것(+ 또는 - 1)을 마스터 비밀(3322)과 함께 사용하여 IoT 디바이스(101)에 대한 3개의 새로운 공유 비밀(3355)을 생성 및 저장한다.

일 실시예에서, 허브가 처음으로 새로운 디바이스를 볼 때, 링크 및 접속 요청 비트들이 광고 패킷(3314)에 설정된 경우, 비밀 바이트들은 무시되고 허브는 접속한다. 비밀 바이트들이 정확하지 않고 링크 요청 플래그가 명확한 경우, 허브는 보안 이벤트 보고 모듈(3375)을 통해 서비스에 대한 사악한 활동을 플래깅한다. IoT 허브(110)가 주변 기기에 대한 공유 비밀을 갖지 않으면, 그것은 마스터 비밀(3322) 및 counter 1(3331) 값들이 수신될 때까지 주변 기기를 무시할 것이다. IoT 허브가 IoT 디바이스에 대한 공유 비밀들을 갖는다면, HMAC 생성 로직(3360)은 (광고 패킷(3314)으로부터의) 공유 비밀들(3355) 및 플래그들 및 counter 2(3332)에 기초하여 3개의 HMAC(3365)를 계산한다.

일 실시예에서, 생성된 각각의 HMAC에 대해, HMAC 분석 로직(3370)은 처음 2개의 바이트를 광고 패킷(3314) 내의 비밀 바이트들과 비교한다. 일치가 발견되지 않으면, 보안 이벤트 보고 모듈(3375)은 사악한 활동을 IoT 서비스(120)에 보고하며, 이어서 이 IoT 서비스는 통지를 최종 사용자의 클라이언트에 전송할 수 있다.

일 실시예에서, IoT 허브가 (플래그들 또는 counter 2가 아니라) 비밀 바이트 변경만을 볼 때, 그것은 counter 1(3331)을 증가시키고, 공유 비밀들(3355)을 재생성하고, 타이머(3351)를 재시작한다. HMAC 생성 로직(3360)은 새로운 HMAC들(3365)을 생성하고, HMAC 분석 로직(3370)은 현재 광고 패킷들(3314)에 대한 새로운 결과들을 체크한다. 일치가 없다면, 보안 이벤트 보고 로직(3375)은 사악한 활동을 IoT 서비스(120)에 보고한다.

IoT 허브(110)가 플래그들 및/또는 counter 2(3332)에 대한 변경들을 검출할 때, IoT 허브는 현재 공유 비밀들(3355)을 현재 광고 데이터(3314)와 비교한다(예를 들어, HMAC 분석 모듈(3370)에 의해 분석될 새로운 HMAC들(3365)을 생성한다). 현재 공유 비밀들이 실패하면, IoT 허브는 counter 1을 증가시키고, 공유 비밀들(3355)을 재생성하고, 타이머(3351)를 재시작한다. 그 다음, IoT 허브는 새로운 공유 비밀들(3355)을 현재 광고 데이터(3314)에 대해 체크한다. 일치가 없다면, 보안 이벤트 보고 모듈(3375)은 사악한 활동을 IoT 서비스(120)에 보고한다.

B. 가짜 IoT 허브

누군가가 가짜 IoT 허브를 사용하여 IoT 디바이스에 접속하는 것이 가능할 수 있다. 접속은 결국 타임아웃될 것이지만, 공격자가 IoT 디바이스에 대한 접속을 유지하는 경우, 그들은 실제 IoT 허브들로부터 그것을 효과적으로 숨길 수 있다.

도 26a 내지 도 26c와 관련하여 전술한 바와 같이, 일 실시예에서, IoT 디바이스(101)가 IoT 허브(111)에 접속할 때, 그것을 볼 수 있는 다른 IoT 허브들(110, 112)에 "접속 가능하지 않음"으로서 광고한다. 도 35에 예시된 바와 같이, 일 실시예에서, 진짜 IoT 허브(110, 112)가 "접속 가능하지 않음"으로서 광고하는 IoT 디바이스를 본다면, 그것은 IoT 서비스(120)에 (IoT 허브들(110, 112)에 의해 수행되는 IoT 서비스(120)에 대한 보고에 의해 지시되는 바와 같은) 상태를 보고한다. 일 실시예에서, IoT 서비스(120)가 이 정보를 수신할 때, 그것은 디바이스 데이터베이스(2851), 또는 IoT 디바이스(101)가 어느 IoT 허브(111)에 접속되는지를 결정하기 위한 디바이스/허브 접속 상태(3400)를 유지하는 임의의 다른 데이터베이스를 검색한다. 도 34에서, IoT 디바이스(101)는 예시된 바와 같이 IoT 서비스(120)에 그의 접속 상태를 제공하는 IoT 허브(111)에 접속된다. 접속 보안 모듈(3405)은 IoT 디바이스(101)가 적법한 IoT 허브(111)에 접속되는지를 결정하기 위해 디바이스/허브 접속 상태 데이터(3400)를 평가한다.

대조적으로, IoT 디바이스(101)가 어떠한 IoT 허브에도 접속되지 않으면, 도 35에 예시된 바와 같이, 접속 보안 모듈(3405)은 (예를 들어, 클라이언트 디바이스(611)에 대한 경고 통지의 형태로) 사악한 활동을 보고한다. 특히, 이 실시예에서, 어떠한 적법한 IoT 허브(110 내지 112)도 IoT 디바이스(101)와의 접속을 보고하고 있지 않다. 그 결과, IoT 허브들(110 내지 112) 중 하나 이상이 그가 IoT 디바이스(101)로부터 "접속 가능하지 않음" 지시를 수신하고 있다는 것을 IoT 서비스(120)에 통신하는 것에 응답하여, 적법한 IoT 허브와의 접속의 결여와 결합하여, 접속 보안 모듈(3405)은 거짓 IoT 허브(3500)가 IoT 디바이스(101)에 접속하고 있을 수 있다고 결론지을 것이다.

C. 이벤트 숨기기

공격자가 도어 개방 이벤트와 같은 이벤트가 도어를 다시 닫기에 충분한 시간 동안 서비스에 보고되는 것을 방지할 수 있는 경우, 사용자는 이벤트가 발생했다는 것을 경고받지 못할 수 있다.

본 발명의 일 실시예는 적어도 2개의 특징을 이용하여 이 문제를 해결한다. 첫째, 도어 센서가 접속된다는 속성은, 그들이 그들의 속성 값들을 서비스에 전송할 때 현재 상태뿐만 아니라 상태 변화도 항상 보고할 "래치된" 속성인 것으로 정의된다. 이것은 도어가 다시 닫히더라도 사용자가 도어가 열렸다는 통지를 수신할 것을 보장한다. 도 36은 래치된 속성(3610)이 MCU(3215) 및/또는 보안 무선 통신 모듈(3218)에 의해 유지되고 궁극적으로 (예를 들어, 접속이 재설정된 후에) IoT 서비스(120)와 동기화되는 일 실시예를 예시한다. 래치된 속성은 그의 기능을 수행하는 센서의 현재 상태를 나타내는 현재 값(3600)을 포함한다. 예를 들어, 도어 센서의 경우, 현재 상태는 "개방" 또는 "폐쇄"일 수 있다. 또한, 각각의 래치된 속성은 IoT 서비스(120)와의 마지막 동기화 및/또는 IoT 디바이스(101)가 재설정된 마지막 시간 이후에 발생한 상태 변화들(3601)의 지시를 포함한다. 예를 들어, IoT 디바이스(101)가 IoT 서비스(120)와 접속할 수 없었던 동안 도어가 열렸다가 이어서 닫히면, 이 상태 변화(3601)는 IoT 디바이스에 저장되고, 이어서 현재 값(3600)에도 불구하고, 접속이 이루어지면 IoT 서비스(120)에 제공될 것이다. 일 실시예에서, 래치된 속성은 그가 IoT 서비스(120) 상의 대응하는 래치된 속성(3610)과 동기화되지 않음을 지시하는 더티 플래그를 포함한다.

둘째, 본 발명의 일 실시예에서, 래치된 속성들에 대해 IoT 서비스(120)로부터의 수신 확인이 요구된다. 따라서, IoT 디바이스(101)가 접속 문제 또는 공격자에 의한 간섭 때문에 IoT 서비스(120)에 정보를 제공할 수 없는 경우, IoT 디바이스(101)는 IoT 서비스(120)로부터 수신 확인을 성공적으로 수신할 때까지 계속 시도할 것이다. 일 실시예에서, 수신 확인은 특수 시스템 속성 상의 설정된 동작의 형태로 수행된다. IoT 디바이스(101)가 설정된 요청을 수신할 때만, 그것은 래치된 속성(3610) 상의 더티 플래그를 소거하여 값을 보고하려고 시도하는 것을 중단한다.

다양한 기능 컴포넌트들이 본 명세서에서 "로직" 또는 "모듈"로서 설명된다. 이러한 기능 컴포넌트들은 집적 회로(예를 들면, 주문형 집적 회로, 범용 프로세서, 마이크로제어기 등)와 같은 하드웨어일 수 있다. 대안적으로, 이러한 기능 컴포넌트들은 처리 디바이스에 의해 실행되는 소프트웨어로 또는 하드웨어와 소프트웨어의 조합을 사용하여 구현될 수 있다.

본 발명의 실시예는 위에서 설명된 다양한 단계를 포함할 수 있다. 단계는 범용 또는 특수-목적 프로세서로 하여금 그 단계를 수행하게 하기 위해 사용될 수 있는 기계-실행 가능 명령어들로 구현될 수 있다. 대안적으로, 이들 단계는 단계를 수행하기 위한 하드와이어드 로직(hardwired logic)을 포함하는 특정 하드웨어 컴포넌트들에 의해, 또는 프로그래밍된 컴퓨터 컴포넌트와 맞춤형 하드웨어 컴포넌트의 임의의 조합에 의해 수행될 수 있다.

본 명세서에 설명된 바와 같이, 명령어는, 소정의 동작을 수행하도록 구성되거나, 비일시적인 컴퓨터 판독 가능 매체에 구현되는 메모리에 저장된 소프트웨어 명령어 또는 미리 결정된 기능을 갖는 주문형 집적 회로(ASIC)와 같은 하드웨어의 특정 구성을 지칭할 수 있다. 따라서, 도면에 도시된 기술은 하나 이상의 전자 디바이스(예를 들어, 최종 스테이션, 네트워크 요소 등) 상에 저장되고 그것 상에서 실행되는 코드 및 데이터를 사용하여 구현될 수 있다. 그러한 전자 디바이스는 비일시적 컴퓨터 기계 판독 가능 저장 매체(예를 들어, 자기 디스크, 광 디스크, 랜덤 액세스 메모리, 판독 전용 메모리, 플래시 메모리 디바이스, 상변화 메모리) 및 일시적 컴퓨터 기계 판독 가능 통신 매체(예를 들어, 전기, 광학, 음향 또는 다른 형태의 전파 신호 - 예를 들어, 반송파, 적외선 신호, 디지털 신호 등)와 같은 컴퓨터 기계 판독 가능 매체를 사용하여 코드 및 데이터를 저장하고 (내부적으로 그리고/또는 네트워크를 통해 다른 전자 디바이스와) 통신한다. 부가적으로, 그러한 전자 디바이스는 전형적으로 하나 이상의 저장 디바이스(비일시적 기계 판독 가능 저장 매체), 사용자 입력/출력 디바이스(예를 들어, 키보드, 터치스크린, 및/또는 디스플레이), 및 네트워크 접속부와 같은 하나 이상의 다른 컴포넌트에 결합된 하나 이상의 프로세서의 세트를 포함한다. 프로세서의 세트와 다른 컴포넌트의 결합은 전형적으로 하나 이상의 버스 및 브리지(또한 버스 제어기로 지칭됨)를 통해 이루어진다. 저장 디바이스 및 네트워크 트래픽을 반송하는 신호는 각각 하나 이상의 기계 판독 가능 저장 매체 및 기계 판독 가능 통신 매체를 대표한다. 따라서, 주어진 전자 디바이스의 저장 디바이스는 전형적으로 그 전자 디바이스의 하나 이상의 프로세서의 세트 상에서의 실행을 위한 코드 및/또는 데이터를 저장한다. 물론, 본 발명의 실시예의 하나 이상의 부분이 소프트웨어, 펌웨어, 및/또는 하드웨어의 상이한 조합을 사용하여 구현될 수 있다.

이러한 상세한 설명 전반에 걸쳐, 설명의 목적으로, 본 발명의 완전한 이해를 제공하기 위해 다수의 특정 상세가 기술되었다. 그러나, 본 발명은 이러한 특정 상세들 중 일부 없이도 실시될 수 있다는 것이 당업자에게 명백할 것이다. 소정의 경우에, 잘 알려진 구조 및 기능은 본 발명의 주제를 불명확하게 하는 것을 피하기 위해 정성 들여 상세히 설명되지 않았다. 따라서, 본 발명의 범주 및 사상은 후속하는 청구범위의 관점에서 판단되어야 한다.

Claims

시스템으로서,
IoT 서비스로 송신될 마스터 비밀을 생성하는 비밀/카운터 처리 로직/회로를 포함하는 IoT 디바이스;
상기 IoT 서비스로부터 제1 보안 통신 채널을 통해 상기 마스터 비밀을 수신하는 하나 이상의 IoT 허브들 - 상기 IoT 허브들 중 적어도 하나는 상기 마스터 비밀을 사용하여 상기 IoT 디바이스와 제2 보안 통신 채널을 설정함 - 을 포함하는, 시스템.
제1항에 있어서, 상기 마스터 비밀은 상기 마스터 비밀을 상기 IoT 디바이스 상에 시스템 속성으로서 설정함으로써 상기 IoT 서비스로 송신되며, 상기 IoT 디바이스는 상기 IoT 디바이스의 시스템 속성들을 상기 IoT 서비스와 자동으로 동기화하는 회로/로직을 포함하는, 시스템.
제1항에 있어서, 상기 비밀/카운터 처리 로직/회로는 제1 카운터를 생성하고, 상기 마스터 비밀과 결합하여 상기 제1 카운터의 값을 사용하여 공유 비밀을 생성하는, 시스템.
제3항에 있어서, 키잉-해시 메시지 인증 코드(keyed-hash message authentication code, HMAC)가 상기 마스터 비밀을 상기 HMAC에 대한 키로서 그리고 상기 제1 카운터를 데이터로서 사용하여 상기 공유 비밀을 생성하는 데 사용되는, 시스템.
제3항에 있어서, 상기 비밀/카운터 처리 로직/회로는 제2 카운터를 생성하며, 상기 시스템은,
상기 공유 비밀을 키로서 사용하여 상기 제2 카운터 값 및 광고 패킷으로부터의 데이터를 갖는 키잉-해시 메시지 인증 코드(HMAC)를 생성하는 HMAC 생성 로직/회로를 추가로 포함하는, 시스템.
제5항에 있어서, 상기 광고 패킷으로부터의 상기 데이터는 제조자 ID, 제조자 플래그들, 디바이스 ID 및/또는 프로토콜 버전을 포함하며, 상기 광고 패킷으로부터의 상기 데이터에는 상기 제2 카운터 값이 이어지는, 시스템.
제6항에 있어서,
상기 광고 패킷으로부터의 상기 데이터 및 상기 제2 카운터 값을 저장하는 N 바이트 버퍼를 추가로 포함하며, 상기 제2 카운터 값에는 N 바이트에 패딩할 0들의 시퀀스가 이어지는, 시스템.
제5항에 있어서, 상기 IoT 디바이스는 상기 HMAC로부터의 바이트들의 지정된 세트 및 상기 제2 카운터 값을 포함하는 광고 패킷을 생성하고, 상기 시스템은,
시스템 속성에서 지정된 빈도에 기초하여 작동하도록 구성된 타이머를 추가로 포함하며, 상기 타이머가 작동할 때, 상기 비밀/카운터 처리 로직/회로는 상기 제1 카운터 값을 증가시키고, 상기 마스터 비밀과 결합하여 상기 증가된 제1 카운터 값을 사용하여 새로운 공유 비밀을 생성하는, 시스템.
제8항에 있어서, 상기 비밀/카운터 처리 로직/회로는 상기 타이머 작동에 응답하여 상기 제2 카운터 값을 또한 증가시키는, 시스템.
제8항에 있어서, 상기 비밀/카운터 처리 로직/회로는 하나 이상의 광고 플래그들에 대한 검출된 변화에 응답하여 상기 제2 카운터 값을 또한 증가시키는, 시스템.
제8항에 있어서, 상기 IoT 허브는,
상기 마스터 비밀 및 상기 제1 카운터 값을 사용하여 상기 IoT 디바이스와 관련된 복수의 공유 비밀들을 생성 및 저장하는 공유 비밀 생성 로직을 포함하는, 시스템.
제11항에 있어서, 상기 IoT 허브는,
상기 복수의 공유 비밀들 및 상기 IoT 디바이스로부터 수신된 광고 패킷으로부터의 데이터를 사용하여 복수의 HMAC들을 생성하는 HMAC 생성 로직을 포함하는, 시스템.
제12항에 있어서, 상기 광고 패킷으로부터의 상기 데이터는 상기 제2 카운터 값 및 광고 데이터를 포함하는, 시스템.
제13항에 있어서, 상기 IoT 허브는,
HMAC의 지정된 바이트들을 상기 IoT 디바이스로부터 수신된 광고 패킷 내의 비밀 바이트들과 비교하는 HMAC 분석 로직을 추가로 포함하며, 일치가 발견되지 않는 경우, 경고 조건이 상기 IoT 서비스에 보고되는, 시스템.
방법으로서,
IoT 서비스로 송신될 마스터 비밀을 IoT 디바이스 상에서 생성하는 단계;
제1 보안 통신 채널을 통해 하나 이상의 IoT 허브들에서 상기 IoT 서비스로부터 상기 마스터 비밀을 수신하는 단계;
상기 마스터 비밀을 사용하여 상기 IoT 디바이스와 제2 보안 통신 채널을 설정하는 단계를 포함하는, 방법.
제15항에 있어서, 상기 마스터 비밀은 상기 마스터 비밀을 상기 IoT 디바이스 상에 시스템 속성으로서 설정함으로써 상기 IoT 서비스로 송신되며, 상기 IoT 디바이스는 상기 IoT 디바이스의 시스템 속성들을 상기 IoT 서비스와 자동으로 동기화하는 회로/로직을 포함하는, 방법.
제15항에 있어서,
제1 카운터를 생성하는 단계; 및
상기 마스터 비밀과 결합하여 상기 제1 카운터의 값을 사용하여 공유 비밀을 생성하는 단계를 추가로 포함하는, 방법.
제17항에 있어서, 키잉-해시 메시지 인증 코드(HMAC)가 상기 마스터 비밀을 상기 HMAC에 대한 키로서 그리고 상기 제1 카운터를 데이터로서 사용하여 상기 공유 비밀을 생성하는 데 사용되는, 방법.
제17항에 있어서,
제2 카운터를 생성하는 단계를 추가로 포함하며, 상기 방법은,
상기 공유 비밀을 키로서 사용하여 상기 제2 카운터 값 및 광고 패킷으로부터의 데이터를 갖는 HMAC를 생성하는 단계를 추가로 포함하는, 방법.
제19항에 있어서, 상기 광고 패킷으로부터의 상기 데이터는 제조자 ID, 제조자 플래그들, 디바이스 ID 및/또는 프로토콜 버전을 포함하며, 상기 광고 패킷으로부터의 상기 데이터에는 상기 제2 카운터 값이 이어지는, 방법.
제20항에 있어서,
상기 광고 패킷으로부터의 상기 데이터 및 상기 제2 카운터 값을 N 바이트 버퍼에 저장하는 단계를 추가로 포함하며, 상기 제2 카운터 값에는 N 바이트에 패딩할 0들의 시퀀스가 이어지는, 방법.
제19항에 있어서, 상기 IoT 디바이스는 상기 HMAC로부터의 바이트들의 지정된 세트 및 상기 제2 카운터 값을 포함하는 광고 패킷을 생성하고, 상기 방법은,
시스템 속성에서 지정된 빈도에 기초하여 작동하도록 타이머를 구성하는 단계를 추가로 포함하며, 상기 타이머가 작동할 때, 상기 제1 카운터 값이 증가되고, 상기 마스터 비밀과 결합하여 상기 증가된 제1 카운터 값을 사용하여 새로운 공유 비밀이 생성되는, 방법.
제22항에 있어서,
상기 타이머 작동에 응답하여 상기 제2 카운터 값을 증가시키는 단계를 추가로 포함하는, 방법.
제22항에 있어서,
하나 이상의 광고 플래그들에 대한 검출된 변화에 응답하여 상기 제2 카운터 값을 증가시키는 단계를 추가로 포함하는, 방법.
제22항에 있어서,
상기 마스터 비밀 및 상기 제1 카운터 값을 사용하여 상기 IoT 허브 상에서 상기 IoT 디바이스와 관련된 복수의 공유 비밀들을 생성 및 저장하는 단계를 추가로 포함하는, 방법.
제25항에 있어서,
상기 복수의 공유 비밀들 및 상기 IoT 디바이스로부터 수신된 광고 패킷으로부터의 데이터를 사용하여 상기 IoT 허브 상에서 복수의 HMAC들을 생성하는 단계를 추가로 포함하는, 방법.
제26항에 있어서, 상기 광고 패킷으로부터의 상기 데이터는 상기 제2 카운터 값 및 광고 데이터를 포함하는, 방법.
제27항에 있어서,
HMAC의 지정된 바이트들을 상기 IoT 디바이스로부터 수신된 광고 패킷 내의 비밀 바이트들과 비교하는 단계를 추가로 포함하며, 일치가 발견되지 않는 경우, 경고 조건이 상기 IoT 서비스에 보고되는, 방법.
시스템으로서,
로컬 무선 통신 채널들을 통해 복수의 IoT 허브들과 통신을 설정하는 무선 통신 모듈을 포함하는 사물 인터넷(IoT) 디바이스;
상기 IoT 디바이스가 접속 가능함을 지시하는 제1 광고 비컨들을 사용자의 상기 복수의 IoT 허브들로 송신하는 광고 제어 로직
- 상기 광고 제어 로직은 상기 IoT 디바이스가 제1 IoT 허브와 접속을 설정하는 경우 상기 IoT 디바이스가 접속 가능하지 않음을 지시하는 제2 광고 비컨을 IoT 허브들로 송신하기 시작하고, 상기 제1 IoT 허브 이외의 상기 IoT 허브들은 상기 IoT 디바이스의 상기 접속 가능하지 않음 상태를 IoT 서비스에 보고함 -; 및
상기 IoT 허브들 중 하나 이상으로부터 상기 접속 가능하지 않음 상태를 수신할 때 상기 IoT 디바이스가 임의의 알려진 IoT 허브에 접속되는지를 결정하는 상기 IoT 서비스의 접속 보안 모듈을 포함하며,
상기 접속 보안 모듈이 상기 IoT 디바이스가 접속되는 알려진 IoT 허브를 식별할 수 없는 경우, 경고 조건이 생성되는, 시스템.
제29항에 있어서,
IoT 디바이스들과 IoT 허브들 사이의 접속들에 대한 접속 상태들을 저장하기 위해 상기 IoT 서비스 상에 유지되는 데이터베이스를 추가로 포함하며, 상기 접속 보안 모듈은 하나 이상의 IoT 허브들로부터 접속 가능하지 않음 지시를 수신할 때 상기 데이터베이스에 질의하는, 시스템.
제29항에 있어서,
커맨드들 및/또는 데이터를 상기 복수의 IoT 허브들 각각으로 송신하는 IoT 서비스를 추가로 포함하며, 상기 복수의 IoT 허브들 각각은 상기 커맨드들 및/또는 데이터를 상기 IoT 디바이스에 제공하기 위해 상기 IoT 디바이스와 접속하려고 시도하고, 상기 제1 IoT 허브만이 상기 IoT 디바이스와 접속을 설정하는, 시스템.
제29항에 있어서,
상기 제1 IoT 허브가 상기 IoT 디바이스와 상기 접속을 설정한 때를 설정 및/또는 검출하고, 상기 광고 제어 로직을 응답적으로 제어하여 상기 제2 광고 비컨을 송신하기 시작하는 접속 관리자를 추가로 포함하는, 시스템.
제29항에 있어서, 상기 IoT 디바이스의 상기 무선 통신 모듈은 상기 제1 IoT 허브 상의 무선 통신 모듈과 상기 접속을 설정하는, 시스템.
제32항에 있어서, 상기 IoT 디바이스의 상기 무선 통신 모듈 및 상기 제1 IoT 허브의 상기 무선 통신 모듈은 블루투스 저에너지(BTLE) 무선 통신 모듈들을 포함하는, 시스템.
제32항에 있어서,
상기 IoT 서비스와 접속을 설정하기 위해 사용자 디바이스 상에서 실행되는 앱을 추가로 포함하며, 상기 사용자는 상기 앱을 통해 입력을 제공하여 상기 IoT 서비스로 하여금 상기 IoT 디바이스로 송신될 커맨드들 및/또는 데이터를 생성하게 하는, 시스템.
제35항에 있어서, 상기 커맨드들은 상기 IoT 디바이스로부터 센서 판독에 관련된 데이터를 검색하는 적어도 하나의 커맨드 또는 상기 IoT 디바이스 상에서 파라미터를 설정하는 적어도 하나의 커맨드를 포함하는, 시스템.
방법으로서,
IoT 디바이스로부터 복수의 IoT 허브들로, 상기 IoT 디바이스가 접속 가능함을 지시하는 제1 광고 비컨들을 송신하는 단계;
상기 IoT 디바이스가 제1 IoT 허브와 접속을 설정하는 경우 상기 IoT 디바이스가 접속 가능하지 않음을 지시하는 제2 광고 비컨을 IoT 허브들로 송신하는 단계 - 상기 제1 IoT 허브 이외의 상기 IoT 허브들은 상기 IoT 디바이스의 상기 접속 가능하지 않음 상태를 IoT 서비스에 보고함 -; 및
상기 IoT 허브들 중 하나 이상으로부터 상기 접속 가능하지 않음 상태를 수신할 때 상기 IoT 디바이스가 임의의 알려진 IoT 허브에 접속되는지를 결정하는 단계를 포함하며,
상기 IoT 디바이스가 접속되는 알려진 IoT 허브가 식별될 수 없는 경우, 경고 조건을 생성하는, 방법.
제37항에 있어서,
IoT 디바이스들과 IoT 허브들 사이의 접속들에 대한 접속 상태들을 저장하기 위해 상기 IoT 서비스 상에 데이터베이스를 유지하는 단계를 추가로 포함하며, 접속 보안 모듈은 하나 이상의 IoT 허브들로부터 접속 가능하지 않음 지시를 수신할 때 상기 데이터베이스에 질의하는, 방법.
제37항에 있어서,
커맨드들 및/또는 데이터를 IoT 서비스로부터 상기 복수의 IoT 허브들 각각으로 송신하는 단계를 추가로 포함하며, 상기 복수의 IoT 허브들 각각은 상기 커맨드들 및/또는 데이터를 상기 IoT 디바이스에 제공하기 위해 상기 IoT 디바이스와 접속하려고 시도하고, 상기 제1 IoT 허브만이 상기 IoT 디바이스와 상기 접속을 설정하는, 방법.
제38항에 있어서, 상기 IoT 디바이스의 무선 통신 모듈은 상기 제1 IoT 허브 상의 무선 통신 모듈과 상기 접속을 설정하는, 방법.
제40항에 있어서, 상기 IoT 디바이스의 상기 무선 통신 모듈 및 상기 제1 IoT 허브의 상기 무선 통신 모듈은 블루투스 저에너지(BTLE) 무선 통신 모듈들을 포함하는, 방법.
제38항에 있어서,
상기 IoT 서비스와 접속을 설정하기 위해 사용자 디바이스 상에서 앱을 실행하는 단계를 추가로 포함하며, 상기 사용자는 상기 앱을 통해 입력을 제공하여 상기 IoT 서비스로 하여금 상기 IoT 디바이스로 송신될 커맨드들 및/또는 데이터를 생성하게 하는, 방법.
제38항에 있어서, 커맨드들은 상기 IoT 디바이스로부터 센서 판독에 관련된 데이터를 검색하는 적어도 하나의 커맨드 또는 상기 IoT 디바이스 상에서 파라미터를 설정하는 적어도 하나의 커맨드를 포함하는, 방법.
프로그램 코드가 저장된 비일시적 기계 판독 가능 매체로서, 상기 프로그램 코드는, 사물 인터넷(IoT) 디바이스에 의해 실행될 때, 상기 IoT 디바이스로 하여금,
IoT 디바이스로부터 복수의 IoT 허브들로, 상기 IoT 디바이스가 접속 가능함을 지시하는 제1 광고 비컨들을 송신하는 동작;
상기 IoT 디바이스가 제1 IoT 허브와 접속을 설정하는 경우 상기 IoT 디바이스가 접속 가능하지 않음을 지시하는 제2 광고 비컨을 IoT 허브들로 송신하는 동작 - 상기 제1 IoT 허브 이외의 상기 IoT 허브들은 상기 IoT 디바이스의 상기 접속 가능하지 않음 상태를 IoT 서비스에 보고함 -; 및
상기 IoT 허브들 중 하나 이상으로부터 상기 접속 가능하지 않음 상태를 수신할 때 상기 IoT 디바이스가 임의의 알려진 IoT 허브에 접속되는지를 결정하는 동작을 수행하게 하며,
상기 IoT 디바이스가 접속되는 알려진 IoT 허브가 식별될 수 없는 경우, 경고 조건을 생성하는, 비일시적 기계 판독 가능 매체.
제37항에 있어서,
IoT 디바이스들과 IoT 허브들 사이의 접속들에 대한 접속 상태들을 저장하기 위해 상기 IoT 서비스 상에 데이터베이스를 유지하는 동작들을 유발하는 추가의 프로그램 코드를 포함하며, 접속 보안 모듈은 하나 이상의 IoT 허브들로부터 접속 가능하지 않음 지시를 수신할 때 상기 데이터베이스에 질의하는, 기계 판독 가능 매체.
제37항에 있어서,
커맨드들 및/또는 데이터를 IoT 서비스로부터 상기 복수의 IoT 허브들 각각으로 송신하는 동작들을 유발하는 추가의 프로그램 코드를 포함하며, 상기 복수의 IoT 허브들 각각은 상기 커맨드들 및/또는 데이터를 상기 IoT 디바이스에 제공하기 위해 상기 IoT 디바이스와 접속하려고 시도하고, 상기 제1 IoT 허브만이 상기 IoT 디바이스와 상기 접속을 설정하는, 기계 판독 가능 매체.
제45항에 있어서, 상기 IoT 디바이스의 무선 통신 모듈은 상기 제1 IoT 허브 상의 무선 통신 모듈과 상기 접속을 설정하는, 기계 판독 가능 매체.
제47항에 있어서, 상기 IoT 디바이스의 상기 무선 통신 모듈 및 상기 제1 IoT 허브의 상기 무선 통신 모듈은 블루투스 저에너지(BTLE) 무선 통신 모듈들을 포함하는, 기계 판독 가능 매체.
제45항에 있어서,
상기 IoT 서비스와 접속을 설정하기 위해 사용자 디바이스 상에서 앱을 실행하는 동작들을 유발하는 추가의 프로그램 코드를 포함하며, 상기 사용자는 상기 앱을 통해 입력을 제공하여 상기 IoT 서비스로 하여금 상기 IoT 디바이스로 송신될 커맨드들 및/또는 데이터를 생성하게 하는, 기계 판독 가능 매체.
제45항에 있어서, 커맨드들은 상기 IoT 디바이스로부터 센서 판독에 관련된 데이터를 검색하는 적어도 하나의 커맨드 또는 상기 IoT 디바이스 상에서 파라미터를 설정하는 적어도 하나의 커맨드를 포함하는, 기계 판독 가능 매체.
방법으로서,
사물 인터넷(IoT) 디바이스 및/또는 IoT 서비스에서 관리되는 복수의 데이터 아이템들 각각에 대한 속성을 지정하는 단계 - 상기 속성들 중 적어도 일부는 현재 값을 갖는 래치된 속성들 및 소정 기간에 걸친 상기 래치된 속성에 대한 상태 변화들의 지시를 포함함 -;
IoT 디바이스가 소정 기간 동안 상기 IoT 서비스와 접속할 수 없을 때, 상기 소정 기간에 걸쳐 상기 래치된 속성에 대해 발생하는 임의의 상태 변화들의 지시를 유지하는 단계;
상기 소정 기간 후에 상기 IoT 디바이스와 상기 IoT 서비스 사이에 성공적인 접속을 설정할 때, 상기 IoT 디바이스로부터 상기 IoT 서비스로 상기 래치된 속성의 상태 변화들의 상기 지시를 송신하는 단계; 및
상태 변화들의 상기 지시를 분석하여 상기 IoT 서비스 상에서 경고 조건을 생성할지를 결정하는 단계를 포함하는, 방법.
제51항에 있어서, 상기 래치된 속성은 도어 또는 윈도우 센서와 관련되고, 상기 상태 변화들은 상기 래치된 속성의 현재 값에도 불구하고 상기 도어 또는 윈도우가 상기 소정 기간 동안 개방되었음을 지시하는, 방법.
제52항에 있어서,
상기 경고 조건의 상기 생성에 응답하여 사용자의 클라이언트 디바이스로 통지를 송신하는 단계를 추가로 포함하는, 방법.
제51항에 있어서,
복수의 속성 클래스들을 정의하는 단계;
하나 이상의 래치된 속성들을 포함한 상기 속성들 각각을 상기 속성 클래스들 중 하나 이상과 관련시키는 단계 - 상기 속성 클래스들은 상기 데이터 아이템들이 상기 IoT 디바이스 및/또는 상기 IoT 서비스의 컴포넌트들에 의해 저장 및 처리되는 방식을 지정하고,
상기 속성 클래스들은 우선 순위 통지 속성 클래스를 포함하며, 하나 이상의 래치된 속성들을 포함한 속성들의 제1 세트가 상기 속성들의 제1 세트와 관련된 중요성 또는 심각성의 레벨에 기초하여 상기 우선 순위 통지 속성 클래스와 관련됨 -;
상기 우선 순위 통지 속성 클래스와 관련된 속성들에 대한 통지들을 상기 우선 순위 통지 속성 클래스와 관련되지 않은 속성들에 대한 다른 통지들에 앞서 상기 IoT 디바이스로부터 상기 IoT 서비스로 송신하는 단계; 및
상기 통지들의 수신 시, 상기 IoT 서비스 상에서 우선 순위 통지 속성 규칙들의 세트를 구현하여, 상기 통지들과 관련된 잠재적으로 위험하거나 달리 바람직하지 않은 조건을 해결하려고 시도하는 단계를 추가로 포함하는, 방법.
제54항에 있어서, 상기 IoT 디바이스는,
상기 IoT 디바이스의 애플리케이션 특정 기능들을 수행하기 위해 애플리케이션-특정 프로그램 코드를 실행하는 마이크로제어기 유닛; 및
상기 IoT 서비스와 보안 무선 통신 채널을 설정하는 보안 무선 통신 모듈을 포함하는, 방법.
제54항에 있어서, 상기 속성 클래스들은 상기 애플리케이션-특정 프로그램 코드를 실행할 때 상기 MCU에 의해 사용 가능한 애플리케이션 속성 클래스를 포함하는, 방법.
제56항에 있어서, 상기 속성 클래스들은 상기 보안 무선 통신 모듈, 상기 MCU, 및/또는 상기 IoT 서비스에 의해 사용 가능한 시스템 속성들에 대한 시스템 속성 클래스를 추가로 포함하는, 방법.
제57항에 있어서, 상기 시스템 속성들, 애플리케이션 속성들, 및 우선 순위 통지 속성들은 상기 IoT 디바이스와 상기 IoT 서비스 사이에서 동기화되는, 방법.
제58항에 있어서, 상기 시스템 속성들, 애플리케이션 속성들, 및 우선 순위 통지 속성들 중 하나 이상은 상기 IoT 서비스와 클라이언트 디바이스 및/또는 하나 이상의 외부 서비스들 사이에서 동기화되는, 방법.
제59항에 있어서, 특정 IoT 디바이스에 대한 흐름 제어 제한들로 인해 상기 우선 순위 통지 속성 클래스와 관련되지 않은 통지들을 차단하도록 구성된 IoT 허브가 상기 우선 순위 통지 속성 클래스와 관련된 상기 IoT 디바이스로부터의 통지들을 통과시키는, 방법.
시스템으로서,
네트워크를 통해 사물 인터넷(IoT) 서비스에 통신 가능하게 결합된 복수의 IoT 디바이스들을 포함하며,
상기 IoT 디바이스 및 상기 IoT 서비스는 복수의 데이터 아이템들을 관리하고, 속성이 지정되고 상기 데이터 아이템들 각각과 관련되며, 상기 속성들 중 적어도 일부는 현재 값을 갖는 래치된 속성들 및 소정 기간에 걸친 상기 래치된 속성에 대한 상태 변화들의 지시를 포함하고,
IoT 디바이스가 소정 기간 동안 상기 IoT 서비스와 접속할 수 없을 때, 상기 소정 기간에 걸쳐 상기 래치된 속성에 대해 발생하는 임의의 상태 변화들의 지시를 유지하고,
상기 소정 기간 후에 상기 IoT 디바이스와 상기 IoT 서비스 사이에 성공적인 접속을 설정할 때, 상기 IoT 디바이스로부터 상기 IoT 서비스로 상기 래치된 속성의 상태 변화들의 상기 지시를 송신하고,
상태 변화들의 상기 지시를 분석하여 상기 IoT 서비스 상에서 경고 조건을 생성할지를 결정하는, 시스템.
제61항에 있어서, 상기 래치된 속성은 도어 또는 윈도우 센서와 관련되고, 상기 상태 변화들은 상기 래치된 속성의 현재 값에도 불구하고 상기 도어 또는 윈도우가 상기 소정 기간 동안 개방되었음을 지시하는, 방법.
제61항에 있어서, 상기 IoT 디바이스는,
상기 IoT 디바이스의 애플리케이션 특정 기능들을 수행하기 위해 애플리케이션-특정 프로그램 코드를 실행하는 마이크로제어기 유닛; 및
상기 IoT 서비스와 보안 무선 통신 채널을 설정하는 보안 무선 통신 모듈을 포함하는, 시스템.
제63항에 있어서, 상기 속성 클래스들은 상기 애플리케이션-특정 프로그램 코드를 실행할 때 상기 MCU에 의해 사용 가능한 애플리케이션 속성 클래스를 포함하는, 시스템.
제64항에 있어서, 상기 속성 클래스들은 상기 보안 무선 통신 모듈, 상기 MCU, 및/또는 상기 IoT 서비스에 의해 사용 가능한 시스템 속성들에 대한 시스템 속성 클래스를 추가로 포함하는, 시스템.
제15항에 있어서, 상기 시스템 속성들, 애플리케이션 속성들, 및 우선 순위 속성들은 상기 IoT 디바이스와 상기 IoT 서비스 사이에서 동기화되는, 시스템.
제66항에 있어서, 상기 시스템 속성들, 애플리케이션 속성들, 및 우선 순위 통지 속성들 중 하나 이상은 상기 IoT 서비스와 클라이언트 디바이스 및/또는 하나 이상의 외부 서비스들 사이에서 동기화되는, 시스템.
제67항에 있어서, 특정 IoT 디바이스에 대한 흐름 제어 제한들로 인해 상기 우선 순위 통지 속성 클래스와 관련되지 않은 통지들을 차단하도록 구성된 IoT 허브가 상기 우선 순위 통지 속성 클래스와 관련된 상기 IoT 디바이스로부터의 통지들을 통과시키는, 시스템.
프로그램 코드가 저장된 기계 판독 가능 매체로서, 상기 프로그램 코드는, 하나 이상의 기계들에 의해 실행될 때, 상기 기계들로 하여금,
사물 인터넷(IoT) 디바이스 및/또는 IoT 서비스에서 관리되는 복수의 데이터 아이템들 각각에 대한 속성을 지정하는 동작 - 상기 속성들 중 적어도 일부는 현재 값을 갖는 래치된 속성들 및 소정 기간에 걸친 상기 래치된 속성에 대한 상태 변화들의 지시를 포함함 -;
IoT 디바이스가 소정 기간 동안 상기 IoT 서비스와 접속할 수 없을 때, 상기 소정 기간에 걸쳐 상기 래치된 속성에 대해 발생하는 임의의 상태 변화들의 지시를 유지하는 동작;
상기 소정 기간 후에 상기 IoT 디바이스와 상기 IoT 서비스 사이에 성공적인 접속을 설정할 때, 상기 IoT 디바이스로부터 상기 IoT 서비스로 상기 래치된 속성의 상태 변화들의 상기 지시를 송신하는 동작; 및
상태 변화들의 상기 지시를 분석하여 상기 IoT 서비스 상에서 경고 조건을 생성할지를 결정하는 동작을 수행하게 하는, 기계 판독 가능 매체.
제69항에 있어서, 상기 래치된 속성은 도어 또는 윈도우 센서와 관련되고, 상기 상태 변화들은 상기 래치된 속성의 현재 값에도 불구하고 상기 도어 또는 윈도우가 상기 소정 기간 동안 개방되었음을 지시하는, 방법.
제70항에 있어서,
상기 경고 조건의 상기 생성에 응답하여 사용자의 클라이언트 디바이스로 통지를 송신하는 동작을 유발하는 추가의 프로그램 코드를 포함하는, 방법.
제71항에 있어서,
복수의 속성 클래스들을 정의하는 단계;
하나 이상의 래치된 속성들을 포함한 상기 속성들 각각을 상기 속성 클래스들 중 하나 이상과 관련시키는 단계 - 상기 속성 클래스들은 상기 데이터 아이템들이 상기 IoT 디바이스 및/또는 상기 IoT 서비스의 컴포넌트들에 의해 저장 및 처리되는 방식을 지정하고,
상기 속성 클래스들은 우선 순위 통지 속성 클래스를 포함하며, 하나 이상의 래치된 속성들을 포함한 속성들의 제1 세트가 상기 속성들의 제1 세트와 관련된 중요성 또는 심각성의 레벨에 기초하여 상기 우선 순위 통지 속성 클래스와 관련됨 -;
상기 우선 순위 통지 속성 클래스와 관련된 속성들에 대한 통지들을 상기 우선 순위 통지 속성 클래스와 관련되지 않은 속성들에 대한 다른 통지들에 앞서 상기 IoT 디바이스로부터 상기 IoT 서비스로 송신하는 단계; 및
상기 통지들의 수신 시, 상기 IoT 서비스 상에서 우선 순위 통지 속성 규칙들의 세트를 구현하여, 상기 통지들과 관련된 잠재적으로 위험하거나 달리 바람직하지 않은 조건을 해결하려고 시도하는 단계를 추가로 포함하는, 방법.