KR20170053130A - 보안 개체에서 접근을 제어하는 방법 및 그 장치 - Google Patents

Abstract

본 발명은 M2M(Machine to Machine communication) 시스템에서 보안 접근을 제어하는 방법 및 장치에 관한 것이다. 보다 상세하게는 M2M 장치의 보안 개체에서 보안 데이터 및 어플리케이션 개체에 대한 접근을 제어하는 방법 및 장치에 관한 것이다. 일 실시예는 M2M(Machine to Machine communication) 장치의 보안 개체가 접근 제어 동작을 수행하는 방법에 있어서, 타 M2M 장치로부터 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 접근을 요청하는 요청 메시지를 수신하는 단계와 접근 요청에 대한 접근 권한을 확인하는 단계 및 타 M2M 장치의 어플리케이션 개체에 대한 접근 권한이 확인되는 경우, 요청 메시지에 기초하여 어플리케이션 개체 또는 프로파일 자원에 대한 조회, 생성, 삭제 및 업데이트 중 적어도 하나의 동작을 처리하는 단계를 포함하는 방법 및 장치를 제공한다.

Description

보안 개체에서 접근을 제어하는 방법 및 그 장치{Methods for controlling contact in Machine to Machine communication secure element and Apparatuses thereof}

본 발명은 M2M(Machine to Machine communication) 시스템에서 보안 접근을 제어하는 방법 및 장치에 관한 것이다. 보다 상세하게는 M2M 장치의 보안 개체에서 보안 데이터 및 어플리케이션 개체에 대한 접근을 제어하는 방법 및 장치에 관한 것이다.

사물 통신(M2M, "Machine to machine communication" 또는 MTC, "Machine type communication" 또는 스마트 디바이스 통신, "Smart Device communication" 또는 "Machine oriented communication" 또는 사물 인터넷, "Internet of Things")은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 방식의 모든 통신 방식을 지칭한다. 최근 oneM2M 회의에서 M2M과 관련된 논의가 이루어지고 있으나, oneM2M의 아키텍처(Architecture) 및 요구 사항(Requirement)을 충족시키는 기술적인 요소들이 제시되지 않은 상태이다.

사물 통신은 통상적으로 사람이 직접적으로 통신과 응용 제어를 수행하지 않기 때문에, 사물 간에 메시지를 교환하기 위해서 송수신 방법과 절차와 필요하다. 아울러, 사물 통신에서는 다양한 디바이스에서 생성된 데이터가 저장되고, 이를 활용하기 위해서 다수의 서비스(예를 들어, 어플리케이션 개체)에서 해당 데이터를 이용할 수 있다.

다만, 다수의 디바이스에서 생성된 데이터를 다수의 어플리케이션 개체에서 접근하여 활용하는 경우에 어플리케이션 개체의 접근을 이용한 해킹 등 보안 이슈가 발생될 수 있다.

이러한, 문제를 해결하기 위해서는 보안에 민감한 데이터에 대한 접근을 제어하는 절차가 필요하다. 그러나, 종래 기술과 같이 보안에 민감한 데이터를 별도의 장치에서 저장 및 관리하고, 보안에 민감한 데이터에 대한 접근 권한을 별도의 장치에서 미리 설정하는 경우에 디바이스의 잦은 변경 및 다양한 어플리케이션의 접근에 따른 다이나믹 제어가 어려운 문제점이 있다.

즉, USIM 등에 미리 보안에 민감한 데이터가 등록되는 경우, 해당 데이터나 어플리케이션을 추가, 변경 및 삭제하지 못한다. 따라서, 새로운 디바이스 또는 서비스가 추가되는 경우에 제조사나 서비스 사업자가 별도의 USIM을 장치에 해당 데이터나 어플리케이션을 추가하여 등록해야 하는 문제점이 있다. 즉, 종래에는 하나의 USIM에 하나의 서비스에 관한 보안 데이터만을 저장 및 관리할 수 있어서, 사용자 서비스 측면에서 불편함을 초래한다.

따라서, 보안 데이터에 대한 고 신뢰성 보안 정책을 제공하면서도 서비스 또는 M2M 장치 추가 및 변경에 대해서 유연함을 제공할 수 있는 M2M 시스템에서의 보안 데이터 관리 방안에 대한 연구가 필요한 실정이다.

전술한 배경에서 안출된 일 실시예는 높은 보안성을 제공하면서도 M2M 장치 및 M2M 서비스의 변경에 따라 보안 개체의 데이터나 어플리케이션을 변경, 삭제 및 수정할 수 있는 보안 개체 접근 제어 방법 및 장치를 제안하고자 한다.

또한, 일 실시예는 하나의 보안 개체 내에 다수의 어플리케이션 개체를 구성하여 M2M 장치의 변경 또는 어플리케이션의 추가, 삭제 및 변경에 대한 접근 제어를 유연하게 수행할 수 있는 보안 개체의 동작을 제안하고자 한다.

전술한 과제를 해결하기 위한 일 실시예는 M2M(Machine to Machine communication) 장치의 보안 개체가 접근 제어 동작을 수행하는 방법에 있어서, 타 M2M 장치로부터 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 접근을 요청하는 요청 메시지를 수신하는 단계와 접근 요청에 대한 접근 권한을 확인하는 단계 및 타 M2M 장치의 어플리케이션 개체에 대한 접근 권한이 확인되는 경우, 요청 메시지에 기초하여 어플리케이션 개체 또는 프로파일 자원에 대한 조회, 생성, 삭제 및 업데이트 중 적어도 하나의 동작을 처리하는 단계를 포함하는 방법을 제공한다.

또한, 일 실시예는 접근 제어 동작을 수행하는 M2M(Machine to Machine communication) 장치의 보안 개체에 있어서, 타 M2M 장치로부터 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 접근을 요청하는 요청 메시지를 수신하는 수신부와 접근 요청에 대한 접근 권한을 확인하는 접근 권한 확인부 및 타 M2M 장치의 어플리케이션 개체에 대한 접근 권한이 확인되는 경우, 요청 메시지에 기초하여 어플리케이션 개체 또는 프로파일 자원에 대한 조회, 생성, 삭제 및 업데이트 중 적어도 하나의 동작을 처리하는 제어부를 포함하는 M2M 장치의 보안 개체을 제공한다.

이상에서 설명한 일 실시예에 따르면, M2M 시스템에서 별도의 보안 개체를 등록하지 않고도 보안 개체 내의 어플리케이션을 추가, 사용, 변경 및 삭제할 수 있는 효과를 제공한다.

또한, 일 실시예에 따르면, 하나의 보안 개체 내에 다수의 어플리케이션을 구성하여 이에 대한 제어 동작을 M2M 장치의 신호 송수신에 따라 수행함으로써, 높은 보안성을 제공함과 동시에 M2M 시스템의 구성 환경 변화를 동적으로 반영할 수 있는 효과를 제공한다.

도 1은 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.
도 4는 일 실시예에 따른 공통 서비스 개체의 기능적 아키텍쳐를 도시한 도면이다.
도 5는 일 실시예에 따른 M2M 장치의 보안 개체 동작을 설명하기 위한 도면이다.
도 6은 일 실시예에 따른 M2M 장치의 보안 개체의 구성을 설명하기 위한 도면이다.
도 7은 일 실시예에 따른 M2M 장치의 보안 개체에 구성되는 어플리케이션 개체에 대한 리스트 조회 동작을 설명하기 위한 도면이다.
도 8은 일 실시예에 따른 어플리케이션 개체에 대한 기본적인 접근 권한을 확인하는 동작을 설명하기 위한 도면이다.
도 9는 일 실시예에 따른 어플리케이션 개체에 대한 추가적인 접근 권한을 확인하는 동작을 설명하기 위한 도면이다.
도 10은 일 실시예에 따른 M2M 장치의 보안 개체 내에 어플리케이션 개체를 추가 생성하는 동작을 설명하기 위한 도면이다.
도 11은 일 실시예에 따른 M2M 장치의 보안 개체 내에 구성되는 어플리케이션 개체를 변경 또는 삭제하는 동작을 설명하기 위한 도면이다.
도 12는 일 실시예에 따른 어플리케이션 개체의 추가, 변경 또는 삭제에 대한 권한을 확인하는 절차를 설명하기 위한 도면이다.
도 13은 일 실시예에 따른 M2M 장치의 보안 개체 내에 구성되는 어플리케이션 개체를 활성화 또는 비활성화하는 동작을 설명하기 위한 도면이다.
도 14는 일 실시예에 따른 M2M 장치의 보안 개체 내에 구성되는 어플리케이션 개체를 활성화 또는 비활성화 동작을 위한 권한을 확인하는 절차를 설명하기 위한 도면이다.
도 15는 일 실시예에 따른 프로파일 자원의 구조를 예시적으로 도시한 도면이다.
도 16은 일 실시예에 따른 M2M 장치의 보안 개체에 대한 구성을 도시한 도면이다.

이하, 본 발명의 일부 실시 예들을 예시적인 도면을 통해 상세하게 설명한다. 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.

또한, 본 발명의 구성 요소를 설명하는 데 있어서, 제 1, 제 2, A, B, (a), (b) 등의 용어를 사용할 수 있다. 이러한 용어는 그 구성 요소를 다른 구성 요소와 구별하기 위한 것일 뿐, 그 용어에 의해 해당 구성 요소의 본질이나 차례 또는 순서 등이 한정되지 않는다. 어떤 구성 요소가 다른 구성요소에 "연결", "결합" 또는 "접속"된다고 기재된 경우, 그 구성 요소는 그 다른 구성요소에 직접적으로 연결되거나 접속될 수 있지만, 각 구성 요소 사이에 또 다른 구성 요소가 "연결", "결합" 또는 "접속"될 수도 있다고 이해되어야 할 것이다.

본 발명의 실시예들은 사물 통신을 중심으로 설명한다. 사물 통신은 M2M(Machine to Machine communication), MTC(Machine Type Communication), IoT(Internet of Things), 스마트 장치 통신(Smart Device Communication, SDC), 또는 사물 지향 통신(Machine Oriented Communication) 등으로 다양하게 불려질 수 있다. 최근 oneM2M에서 사물통신과 관련된 많은 기술적 사항을 제시하고 있다. 사물 통신은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 다양한 통신을 지칭한다. 사물 통신은 에너지(energy) 분야, 엔터프라이즈(enterprise) 분야, 헬스케어(Healthcare) 분야, 공공 서비스(Public Services) 분야, 주거(Residential) 분야, 리테일(Retail) 분야, 운송(Transportation)분야, 그리고 기타 분야 등으로 나뉘어진다. 본 발명은 상기 분야를 포함하며, 그 외의 분야에도 적용 가능하다.

도 1은 일 실시예에 따른 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.

어플리케이션 개체(Application Entity, AE)(110)는 종단간(end-to-end) M2M 솔루션을 위한 어플리케이션 로직을 제공한다. 일 예로 차량 등의 집단적인 추적 어플리케이션(fleet tracking application), 원격 혈당 감시 어플리케이션(remote blood sugar monitoring application), 또는 원격 전력 검침과 제어 어플리케이션(remote power metering and controlling application) 등이 될 수 있다(Application Entity (AE): Application Entity provides Application logic for the end-to-end M2M solutions. Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring application, or remote power metering and controlling application.). 공통 서비스 개체(Common Services Entity, CSE)(120)는 서비스 기능의 집합으로써, 이러한 서비스 기능은 M2M 환경에 공통적으로 사용하는 기능이다. 이러한 서비스 기능은 참조점(Reference Points) Mca, Mcc를 통해 다른 기능으로 드러나며, 참조점 Mcn를 이용하여 기반 네트워크 서비스를 이용한다. 일 예로는 데이터 관리(Data Management), 디바이스 관리(Device Management), M2M 구독 관리(M2M Subscription Management), 위치 서비스(Location Service) 등이 될 수 있다. CSE에 의해 제공되는 서브기능(subfunction)은 논리적으로 CSF(Common service function)으로 이해될 수 있다. oneM2M 노드의 CSE내에 CSF 중 일부는 필수적(mandatory)이 되며 일부는 선택적(optional)이 될 수 있다. 마찬가지로 CSF 내의 서브기능들 역시 필수적 또는 선택적이 될 수 있다.

기반 네트워크 서비스 기능(Underlying Network Services Function, NSF)(130)은 공통 서비스 개체에게 서비스를 제공한다. 서비스의 예로는 디바이스 관리, 위치 서비스(location services)와 디바이스 트리거링(device triggering)을 포함한다.

참조점(Reference Points)은 공통 서비스 개체(CSE)에서 지원되는 것으로 Mca 참조점은 어플리케이션 개체와 공통 서비스 개체 간의 통신 플로우를 지시하는 참조점이다. Mcc 참조점은 두 공통 서비스 개체 간의 통신 플로우를 지시하는 참조점이다. Mcn 참조점은 공통 서비스 개체와 하나의 네트워크 서비스 개체간의 통신 플로우를 지시하는 참조점이다.

보다 상세히, Mca 참조점은 하나의 어플리케이션 개체(AE)가 공통 서비스 개체에 의해 지원되는 서비스를 사용할 수 있도록 한다. Mca 참조점을 통해 제공되는 서비스들은 공통 서비스 개체가 제공하는 기능에 의존적이며, 어플리케이션 개체와 공통 서비스 개체는 동일한 물리적 개체에 존재하거나 다른 물리적 개체에 따로 존재할 수 있다. Mcc 참조점은 필요한 기능을 제공하는 다른 공통 서비스 개체의 서비스를 사용하고자 하는 공통 서비스 개체에게 그러한 사용을 가능하게 한다. Mcc 참조점을 통해 제공되는 서비스들은 공통 서비스 개체가 제공하는 기능에 의존적이다. Mcc 참조점은 서로 다른 M2M 노드 간에 지원될 수 있다. Mcn 참조점은 필요한 기능을 제공하는 기반 네트워크의 서비스 개체를 사용하고자 하는 공통 서비스 개체에게 그러한 사용을 가능하게 하며, 이는 전송과 연결 이외의 서비스를 제공한다. Mcn 참조점의 인스턴스(instance)는 기반 네트워크에서 제공되는 서비스에 의존적으로 구현된다. 두 개의 물리적 M2M 노드 간의 정보 교환은 기본 서비스를 제공하는 기반 네트워크의 전송(transport) 및 연결(connectivity) 서비스를 사용할 수 있다.

본 명세서에서는 공통 서비스 개체를 CSE로 기재할 수 있으며, 네트워크 서비스 개체를 NSE로 기재할 수 있다. 또한, 본 명세서에서의 M2M 장치는 CSE 또는 AE를 의미하거나, CSE 또는 AE를 포함하는 장치를 의미하며, M2M 시스템을 구성하는 디바이스 또는 단말을 의미한다.

도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.

도 2를 참조하면, 기반노드(Infrastructure Node, 250)는 M2M 통신을 제공하는데 필수적인 서버 기능을 수행한다. 기반노드(250)는 기반노드 응용개체(AE, 252)와 기반노드 공통서비스개체(CSE, 254)로 구성된다. 기반노드 공통서비스 개체(254)는 다양한 자원을 이용하여 구성된다. 252와 254는 Mca 참조점을 통하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.

중계노드(200)는 응용서비스노드(220)와 기반노드(100)의 M2M 통신 또는 Internet of Things, 사물통신 기능을 중계한다. 중계노드(200)는 중계노드 응용개체(202)와 중계노드 공통서비스개체(204)로 구성된다. 중계노드 공통서비스개체 (204)는 다양한 자원을 이용하여 구성된다. 202와 204는 Mca 참조점을 통하여 구분하며, 254와 204는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회(retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.

응용서비스노드(210)는 응용개체(212)와 중계노드 공통서비스개체(214)로 구성할 수 있다. 응용개체(212)는 기기의 목적상 요구되는 응용 기능을 처리한다. 응용서비스노드(210)의 공통서비스개체(214)는 다양한 자원을 이용하여 구성한다. 212와 214는 Mca 참조점을 통하여 구분하며, 214와 254는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성(create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답 메시지의 구성과 처리에 사용한다. 한편, 응용서비스노드(220)는 중계노드(200)를 통하여 기반노드(100)와 사물통신 기능을 수행할 수도 있다. 210과 220의 차이점은 노드를 구성하는 통신 인터페이스가 다른 것이 특징이다. 예를 들어, 220은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 100과 통신한다. 이에 반해, 210은 3G, LTE, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 100과 통신한다.

응용전용노드(230, 240)는 공통서비스개체를 가지지 않고, 응용개체(242)만을 가지고 사물통신을 하는 경우를 대상으로 한다. 230은 3G, LTE, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 100과 통신하는 경우이고, 240은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 100과 통신한다.

도 2에서 설명한 바와 같이, M2M 시스템은 기반노드, 중계노드, 응용 서비스 노드 및 응용전용 노드 중 적어도 하나 이상의 노드로 구성될 수 있으며, 각 노드는 CSE 또는 AE를 포함하여 구성될 수 있다. CSE와 AE는 각각의 참조점을 통해서 타 CSE 또는 AE와 통신을 수행할 수 있다.

도 3을 참조하면, 송신자(Originator, 300)는 요청 메시지를 수신자(Receiver, 310)로 전송한다(S320). 송신자(300)와 수신자(310)는 각각 M2M 장치일 수 있으며, 전술한 바와 같이 CSE 또는 AE일 수 있다. 또한, 송신자(300)와 수신자(310)는 CSE 또는 AE를 포함하는 노드 또는 서버 또는 장치일 수 있다.

요청 메시지는 하나 이상의 파라미터를 포함할 수 있다. 예를 들어, 요청 메시지에는 필수적인 파라미터와 선택적인 파라미터가 포함될 수 있다. 예를 들어, 송신측 파라미터, 수신측 파라미터, 요청 식별 파라미터 및 동작 파라미터는 필수적인 파라미터로 포함된다. 송신측 파라미터는 메시지를 전송하는 발원자에 대한 정보를 포함하고, 수신측 파라미터는 메시지를 수신하는 수신자에 대한 정보를 포함한다. 요청 식별 파라미터는 해당 요청 메시지를 식별하기 위한 유일한 ID 정보를 포함한다. 또한, 동작 파라미터는 요청 메시지에서 요청하는 동작을 구분하기 위한 정보를 포함한다. 동작 파라미터는 생성(Create), 조회(Retrieve), 갱신(Update), 삭제(Delete), 통지(Notify) 중 어느 하나로 설정될 수 있다. 또한, 동작 파라미터에 의해서 구분되는 동작 행동을 제한 또는 필터링하기 위해서 필터 파라미터(FilterCriteria)가 포함될 수도 있다.

수신자(310)는 요청 메시지가 수신되면, 해당 요청 메시지를 처리하기 위한 동작을 수행한다(S330). 예를 들어, 수신자(310)는 요청메시지(Request Message)를 송신한 송신자(300)가 해당 요청에 대한 권한을 가지고 있는지를 확인할 수 있다. 송신자(300)가 요청에 대한 권한을 가지고 있다고 판단되는 경우, 요청의 대상이 되는 리소스(requested resource)의 존재 여부를 확인한 후 요청 메시지를 처리한다. 또는, 수신자(310)는 요청 메시지의 동작 파라미터에 따라 해당하는 동작을 수행할 수 있다. 예를 들어, 동작 파라미터가 생성으로 설정되고, 특정 데이터의 변경, 추가, 삭제 등이 발생할 경우에 이를 송신자(300)측으로 알려주도록 지시하는 구독 기능이 설정되는 경우에 수신자(310)는 구독 정보를 생성하고, 해당 구독 정보에 해당하는 데이터에 변경, 추가, 삭제 등의 이벤트가 발생하는 경우에 이를 송신자(300) 측으로 통지할 수 있다.

수신자(310)는 요청 동작에 따른 처리 결과 정보를 생성하여 이를 응답메시지에 포함하여 송신자(300)로 전송한다(S340). S340 단계는 S330 단계 이전에 수행될 수도 있다. 즉, 수신자(310)는 요청 메시지를 수신하면, 이에 대한 단순 수신을 나타내는 ACK 응답 메시지를 생성하여 송신자(300)측으로 전송하고, 이후 S330 단계를 수행하여 요청 메시지를 처리할 수도 있다.

도 4는 본 발명의 일 실시예에 의한 공통 서비스 개체를 구성하는 도면이다. 도 4에서는 식별 정보의 처리 기능을 포함한다.

공통 서비스 개체가 제공하는 기능을 도 4와 같이 정리하면 식별(Addressing & Identification), 어플리케이션/서비스 계층 관리(Application and Service Layer Management), 데이터 관리 및 저장(Data Management & Repository), 위치(Location), 보안(Security), 통신 관리/전달 핸들링(Communication Management / Delivery Handling), 등록(Registration), 서비스 세션 관리(Service Session Management), 디바이스 관리(Device Management), 구독/알림(Subscription/Notification), 연결 관리(Connectivity Management), 디스커버리(Discovery), 서비스 과금/정산(Service Charging/Accounting), 네트워크 서비스 표출/서비스 실행 및 트리거링(Network Service Exposure / Service execution and triggering ), 그룹 관리(Group Management) 등이 있다.

물론, 상기 기능 이외에도 시맨틱스(Semantics), 데이터 분석(Data Analytics), 어플리케이션 인에이블먼트(Application Enablement), 네트워크 서비스 기능 관리(Network Service Function Management)등도 포함할 수 있다.

각각의 기능에 대해 살펴보면 다음과 같다.

ASM(Application and Service Layer Management)는 ADN, ASN, MN, IN의 AE와 CSE를 관리하는 것을 담당하며, 이는 CSE의 설정(configure), 트러블슈팅(troubleshoot), 업그레이드 기능과 AE의 업그레이드를 포함한다.

CMDH(Communication Management and Delivery Handling)는 다른 CSE, AE, NSE간의 통신을 책임진다. CMDH는 어느 시각에 어떤 통신 연결을 이용하여 통신을 전달할 것인지(CSE-CSE간 통신), 언제 필요하고 언제 허가되는지, 그리고 통신의 전달이 이후로 미루어질 때 통신 요청을 저장하는 것을 책임진다. CMDH는 통신에 대한 각 요청에 특화된 프로비전된 정책과 전달 핸들링 파라미터에 따라 수행된다. 기반 네트워크 데이터 전송 서비스를 이용한 통신에서 기반 네트워크는 동일한 전달 핸들링 기능을 지원할 수 있다. 이 경우 CMDH는 기반 네트워크를 사용할 수 있으며, 기반 네트워크에 동일한 전달 핸들링 기능을 액세스하는 프런트엔드로 동작할 수 있다.

DMR(Data Management and Repository)은 M2M 어플리케이션이 다른 개체와 데이터를 교환할 수 있도록 한다. DMR CSF는 데이터 저장 공간을 제공하고 이를 조정하는 기능을 제공한다. 또한 대량의 데이터를 수집하고 결합하거나, 데이터를 특정한 포맷으로 변환하거나, 또는 데이터를 분석 및 시맨틱 프로세싱을 위해 저장하는 기능을 포함한다. "데이터"라는 것은 M2M 디바이스로부터 투명하게 추출되는 로우 데이터(raw data)를 의미하거나 M2M 개체에 의해 계산 또는 결합되어 프로세싱된 데이터를 의미할 수 있다. 대량의 데이터를 수집하는 것은 빅데이터 저장 기능으로 알려진 것을 구성한다.

DMG(Device Management) CSF는 MN과 디바이스 노드 및 M2M 에어리어 네트워크에 있는 디바이스들의 디바이스 기능의 관리를 담당한다. 다음의 기능을 하나 이상 제공하는 디바이스 관리를 가능하게 한다. 어플리케이션 소프트웨어의 설치 및 세팅, 설정 세팅 및 프로비저닝, 펌웨어 업데이트, 로깅과 모니터링과 분석, 에어리어 네트워크의 토폴로지 관리, 그리고 에어리어 네트워크 관리 내의 디바이스를 포함한다.

DIS(디스커버리) CSF는 주어진 범위와 주제 내에서 허락된 권한(M2M 서비스 구독에서 허락된 것을 포함)과 주어진 범위 내에서 오리지네이터(Originator)로부터의 요청에 해당하는 정보와 리소스를 검색하는 것을 책임진다. 오리지네이터는 어플리케이션 또는 다른 CSE가 될 수 있다. 검색의 범위는 하나의 CSE가 되거나 다수의 CSE가 될 수 있다. 디스커버리 결과는 오리지네이터에게 리턴된다.

GMG(Group Management)는 요청과 관련된 그룹을 핸들링한다. 요청은 그룹과 그룹의 멤버십의 관리를 위해 전송되며 또한 그룹에 의해 지원되는 벌크 오퍼레이션도 담당한다. 그룹에 멤버를 추가 또는 삭제할 경우, 멤버가 그룹의 목적에 순응하는지를 확인할 필요가 있다. 벌크 오퍼레이션은 읽기, 쓰기, 구독하기, 알리기, 디바이스 관리 등을 포함한다. 요청 또는 구독은 그룹을 통하여 이루어지고, 그룹이 이러한 요청과 알림을 결합하는 것을 책임진다. 그룹의 멤버는 리소스에 대한 접근 권한에 대해 동일한 역할을 가진다. 이 경우, 접근 제어는 그룹에 의해 이루어진다. 기반 네트워크가 브로드캐스팅과 멀티캐스팅 기능을 제공할 경우, GMG CSF는 이러한 기능을 이용해야 한다.

LOC(Location) CSF는 위치 기반 서비스를 위해 M2M 노드(예를 들어 ASN, MN)의 지리적 위치 정보를 M2M AE가 습득할 수 있도록 한다. 동일한 또는 상이한 M2M 노드 내에 존재하는 M2M AE로부터 이러한 위치 정보가 요청될 수 있다.

NSE(Network Service Exposure) CSF는 M2M 어플리케이션을 대신하여 M2M 시스템으로부터의 서비스 요청에 대한 사용 가능하거나 지원 가능한 방식을 Mcn 참조점을 통하여 네트워크 서비스 기능을 액세스 하기 위해 기반 네트워크와의 통신을 관리한다. NSE CSF는 다른 CSF와 AF를 기반 네트워크에서 지원되는 특정한 기술과 메커니즘으로부터 은폐한다. 기반 네트워크로부터 제공되는 네트워크 서비스 기능은 디바이스 트리거링, 스몰 데이터 전송, 위치 알림, 폴리시 룰 셋팅, 위치 질의, IMS 서비스, 디바이스 관리 등을 포함하지만 이에 한정되지는 않는다. 이러한 기능들은 일반적인 전송 서비스를 포함하지 않는다

REG(Registration)는 어플리케이션 또는 다른 CSE가 CSE에 등록하도록 핸들링하는 것을 담당하는데, 이는 CSE에서 제공되는 서비스를 사용하려는 개체의 등록을 허락하기 위함이다. REG CSF는 CSE에 대한 디바이스의 등록 뿐만 아니라 디바이스의 특성/속성의 등록도 핸들링한다.

SEC(Security)는 주의를 요하는(센서티브) 데이터 핸들링 기능, 보안 운영 기능, 보안 결합 설정 기능, 권한 부여와 액세스 제어 기능, 식별 보호 기능을 제공한다. SEC CSF가 제공하는 센서티브 데이터 핸들링 기능은 저장과 조작 과정에서 보안이 필요한 로컬 크리덴셜을 보호하는 기능을 제공한다. 센서티브 데이터 핸들링 기능 역시 보안 알고리즘을 사용한다. 이 기능은 다양한 암호기법이 분리된 보안 환경을 지원한다. 보안 운영 기능은 다음의 기능을 제공하는데, 먼저 센서티브 데이터 핸들링 기능에 의해 지원되도록 전용된 보안 환경의 생성과 운영 기능을 제공한다. 또한 보안 환경에서 보호되는 루트 크리덴셜의 포스트 프로비저닝을 지원하며, M2M 서비스와 M2M 어플리케이션 서비스와 관련된 구독의 프로비저닝과 운영을 지원한다. 보안 결합 설정 기능은 M2M 노드들 간의 보안 결합을 설정하여 기밀성, 통합성, 인증, 권한 부여가 가능하도록 한다. 권한 부여와 액세스 제어 기능은 프로비전된 보안 정책과 할당된 롤에 따라 권한 부여된 개체로의 서비스와 데이터 접근을 제어한다. 개체의 유일한 식별자가 권한 부여에 사용되며, 식별 보호 기능은 개체 또는 사용자와 결합된 실제 식별 정보와 링크되지 않도록 임시의 식별자로 기능하는 익명을 제공할 수 있다.

SCA(Service Charging and Accounting)는 서비스 계층의 과금 기능을 제공한다. 온라인 과금과 오프라인 과금을 포함하는 상이한 과금 모델들을 지원한다. SCA CSF는 과금 가능한 이벤트를 확보하고, 정보를 저장하며, 과금 기록과 과금 정보를 생성한다. SCA CSF는 기반 네트워크의 과금 시스템과 상호작용 할 수 있다. 그러나 SCA CSF는 최종 서비스 레벨의 과금 정보를 생성하고 기록할 책임을 가진다. 기반 노드 또는 서비스 계층 과금 서버의 SCA CSF는 과금을 위한 과금 정보를 핸들링하는 것을 책임진다.

SSM(Service Session Management) CSF는 단대단 서비스 계층 연결인 M2M 서비스 세션을 관리한다. SSM CSF는 M2M 어플리케이션들 간의, 또는 M2M 어플리케이션과 CSE 간의, 또는 CSE들 간의 M2M 서비스 세션을 관리한다. M2M 서비스 세션의 관리는 세션 상태의 관리, 세션 인증과 설립, 세션과 관련된 기반 네트워크 연결 및 서비스의 관리, CSE의 멀티 홉인 cse의 세션 확장의 조정, 세션 종단간의 정보의 교환, 그리고 세션의 종료를 포함한다. 주어진 M2M 서비스 세션내에서 다음 홉의 CSE 또는 어플리케이션으로/부터의 메시지 송수신을 위해 SSM CSF는 로컬 CSE 내의 CMDH CSF를 이용한다. SSM CSF는 세션 참가자의 보안 크리덴셜과 인증과 관련된 세션 관리를 위해 SEC CSF를 이용한다. SSM CSF는 세션에 특화된 과금 이벤트를 생성하며 로컬 CSE 내의 SCA CSF와도 통신한다.

SUB(Subscription and Notification)는 구독을 유지하는 알림을 제공하며, 리소스의 변화(예를 들어 리소스의 삭제)를 트래킹한다. 리소스의 구독은 M2M AE 또는 CSE에 의해 시작되며, 호스팅 CSE에 의해 접근 권한이 그랜트된다. 활성화된 구독 중에 호스팅 CSE는 구독된 리소스의 변화가 발생하는 경우 리소스 구독자가 수신하길 원하는 주소로 알림을 전송한다.

도 4 및 그에 대한 설명은 공통 서비스 개체를 구현하는 실시예들이며 본 발명이 이에 한정되지는 않는다.

한편, 본 발명을 구현하기 위해 필요한 식별자(identifier)를 살펴보면 다음과 같다. M2M 식별자로는 M2M-SP-ID(M2M Service Provider Identifier), App-Inst-ID(Application Instance Identifier), App-ID(Application Identifier), CSE-ID(CSE Identifier), M2M-Node-ID(M2M Node Identifier/Device Identifier), M2M-Sub-ID(M2M Service Subscription Identifier), M2M-Request-ID(Request Identifier) 등이 있다.

oneM2M은 시스템을 구현하기 위해 충족시켜야 할 요구사항으로 전반적인 시스템 요구사항(Overall System Requirements), 관리 요구사항(Management Requirements), 데이터 모델과 의미 요구사항(Data Model & Semantics Requirements), 보안 요구사항(Security Requirements), 과금 요구사항(Charging Requirements), 운영 요구사항(Operational Requirements)을 제시하고 있다.

본 명세서에서는 M2M 시스템 기술, 특히 oneM2M 서비스 플랫폼 기술을 중심으로 설명한다. 그러나 이러한 설명이 M2M 서비스 플랫폼 기술에만 한정되는 것은 아니며, 기기간 통신, 즉 사물 통신을 제공하는 모든 시스템 및 구조와 이들 시스템에서 발생하는 통신 동작에 적용 가능하다.

아울러, 본 명세서에서 설명하는 M2M 장치의 보안 개체는 민감 데이터 및 민감 기능들을 조작, 권한이 없는 모니터링 또는 실행으로부터 보호하고, 권한이 부여된 oneM2M 개체의 민감한 데이터 및 민감한 기능들에 대한 액세스를 제공하는 개체를 의미하는 것이다(secure environment is a logical entity that protects Sensitive Data and Sensitive Functions from tampering, unauthorized monitoring or execution and that provides access to these Sensitive Data and Sensitive Functions to authorized oneM2M entities). 따라서, 보안 개체(secure environment)는 보안 엔티티(secure entity) 또는 보안 요소(secure element)와 동일한 의미로 사용되며 명칭에 제한은 없다.

이하에서는 도 4에서 도시된 바와 같이 M2M 장치의 보안 기능과 관련된 내용을 설명한다.

단말에서 보안상 민감한 정보를 해킹의 위험으로부터 안전하게 보관하거나 실행할 때 보안 개체를 사용한다. 보안 개체에는 보안상 민감한 데이터를 저장하는 기능과 외부의 요청에 의해 민감한 연산 처리를 수행하는 기능이 포함될 수 있다. 보안 개체에 따라서는 스마트폰 주소록, 멀티미디어 데이터 등 사전에 정의한 데이터에 한해서 보안 개체 사용 중에 데이터를 보안 개체 내부에 저장 및 관리할 수 있다.

사물 통신이 확산되면서, 사물 통신을 지원하는 M2M 장치에는 기존과 다른 특징이 요구된다. 예를 들어, 저사양, 소형, 저가 M2M 장치의 비중이 커지면서 사용자가 보안 개체(예를 들어, USIM)를 슬롯에 장착하는 기존의 형태보다는 M2M 장치에 내장하는 e-SIM 형태가 요구되고 있다. 그리고 센서/디스플레이 등 단위 기능과 중앙 처리 장치를 분리하여 중앙 처리 장치나 어플리케이션만 변경하면, 용도 변경을 하거나 저렴하게 기능 업그레이드를 수행할 수 있는 형태도 요구되고 있다.

그리고 IoT 국제 표준에서는 단말의 제조사나 사양, OS, 프로토콜에 무관하게 M2M 장치간에 서로 연동할 수 있는 규격을 정의하고 있다.

이처럼 사물통신은 다양한 종류의 M2M 장치들이 제 각기의 프로토콜로 다른 M2M 장치 혹은 다른 플랫폼과 연동을 하는 구조에서 여러 가지 서비스를 제공한다. 기존 스마트폰과 같은 스마트 단말의 경우에는 제조사와 플랫폼 사업자, 서비스 사업자 간 협의 하에 제품을 생산, 판매, 서비스 가입하는 형태가 일반적이었다면, 사물 통신에서는 대상 제품의 종류와 규격, 환경, 서비스가 워낙 다양하고, M2M 장치간 기능이 중복되는 경우도 많으며, 여러 가지 M2M 장치을 연동해서 서비스를 제공하려는 경향이 강해지고 있다.

따라서, M2M 장치의 경우에는 보안 개체 내에 구성되는 어플리케이션 개체나 데이터를 변경할 필요성이 생겼다. 예를 들어, 여러 서비스에서 동일한 기능의 센서를 사용하는 경우, 서비스 가입자는 각 서비스 마다 센서를 추가로 사서 달 것이 아니라 하나의 센서 값을 공유하는 것이 효율적이다. 마찬가지로 하나의 M2M 장치를 다른 서비스 용으로 변경해서 사용할 필요성도 있다.

이를 위해서는 M2M 장치의 보안 개체 내에 어플리케이션 개체를 추가, 사용, 변경 또는 삭제할 수 있어야 한다. 현재는 보안 개체 내에 보안 개체 제조사나 서비스 사업자가 어플리케이션 개체를 등록하고 있으며 추가, 변경 또는 삭제를 사용자가 수행할 수는 없다. 이는, 보안성을 높게 유지하기 위해서이다.

따라서, 사물 통신을 위해서 보안 안정성은 강하게 유지하면서도 어플리케이션 개체에 대한 관리를 자유롭게 할 수 있는 새로운 구조가 필요하다.

본 명세서에서의 어플리케이션 개체는 M2M 서비스를 제공하는 서비스를 제공하거나, M2M 장치가 생성한 데이터를 M2M 장치 별로 또는 M2M 서비스 별로 관리 또는 저장하기 위한 개체를 의미한다.

본 발명은 여러 M2M 장치가 생성한 데이터 또는 기능을 보안 개체 내에 구성되는 어플리케이션 개체를 이용하여 관리하는 방법 및 장치에 관한 것으로, 보안 개체는 보안 개체 내에 하나 이상의 어플리케이션 개체를 구성할 수 있다. 아울러, 일 실시예는 보안 개체 내에 구성되는 다수의 어플리케이션 개체를 생성, 사용, 변경 또는 삭제하기 위한 구체적인 접근 제어 방법 및 장치를 제공하고자 한다.

도 5는 일 실시예에 따른 M2M 장치의 보안 개체 동작을 설명하기 위한 도면이다.

도 5를 참조하면, M2M 장치의 보안 개체는 접근 제어 동작을 수행하는 방법에 있어서, 타 M2M 장치로부터 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 접근을 요청하는 요청 메시지를 수신하는 단계를 수행한다(S500). 보안 개체는 하나 또는 복수개의 어플리케이션 개체를 보안 개체 내에 구분하여 구성할 수 있다. 이 경우에 타 M2M 장치는 보안 개체 내에 구성되는 어플리케이션 개체에 접근하기 위해서는 보안 개체에서 요구하는 요구사항을 만족해야 한다. 예를 들어, 보안 개체에서 요구하는 권한 등을 인증 받아야 하며, 권한은 보안 개체 및 개별 어플리케이션 개체 중 적어도 하나의 개체에 대해서 동일 또는 상이하게 설정될 수도 있다.

한편, 요청 메시지는 타 M2M 장치가 필요로 하는 동작에 따라서 달라질 수 있다. 예를 들어, 요청 메시지는 보안 개체 내에 구성되는 어플리케이션 개체에 대한 리스트 조회, 어플리케이션 개체에 대한 선택, 어플리케이션 개체의 추가 또는 삭제, 어플리케이션 개체의 변경 등 다양한 요청 타입을 포함할 수 있다. 이 외에도, 요청 메시지는 보안 개체 또는 어플리케이션 개체에 구성되는 프로파일 자원에 대한 변경, 추가, 생성 또는 삭제를 요청하는 정보를 포함할 수도 있다.

일 예를 들어, 요청 메시지는 보안 개체에 대한 식별정보, 타 M2M 장치에 대한 식별정보 및 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 리스트를 요청하는 정보를 포함할 수 있다. 예를 들어, 요청 메시지는 요청 메시지를 처리할 보안 개체를 식별할 수 있는 정보와 요청 메시지를 전송하는 M2M 장치의 식별정보를 포함할 수 있다. 아울러, 요청 메시지는 보안 개체 내의 어플리케이션 개체에 대한 리스트를 요청하는 응답 유형에 대한 정보를 포함할 수 있다. 응답 유형은 어플리케이션 개체에 대한 리스트, 보안 개체의 미존재, 접근 조건 불만족 및 어플리케이션 개체의 미존재 등으로 구분될 수 있으며 이에 한정되지는 않는다.

다른 예로, 요청 메시지는 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 선택 정보를 포함하며, 선택 정보는 선택된 어플리케이션 개체에 대한 식별 정보 및 보안 레벨 정보를 포함할 수 있다. 타 M2M 장치는 보안 개체 내의 어플리케이션 개체를 선택할 필요가 있다. 이 경우, 요청 메시지에는 선택을 원하는 어플리케이션에 대한 식별정보 및 보안 레벨 정보가 포함될 수 있다.

또 다른 예로, 요청 메시지는 프로파일 자원에 대한 업데이트 동작을 지시하는 정보를 포함할 수 있다. 이 경우, 요청 메시지는 프로파일 자원에 대한 활성화 또는 비활성화를 지시하는 정보를 포함할 수 있다. 프로파일 자원은 도 15와 같이 구성될 수 있으며, 보안 개체 내에 저장 또는 구성될 수 있다. 또한, 프로파일 개체는 프로파일 유형 정보, 식별정보, 프로파일 생성자의 식별 정보, 프로파일 데이터 및 접근 권한 정보 중 적어도 하나의 정보를 속성 정보로 포함할 수 있다. 프로파일 유형 정보는 프로파일의 타입을 나타내는 정보를 포함하고, 식별정보는 다수의 프로파일을 구분하기 위한 식별정보를 포함한다. 또한, 프로파일 생성자의 식별정보는 해당 프로파일을 생성한 오퍼레이터, CSE, AE, M2M 장치 및 보안 개체 중 어느 하나의 식별 정보를 포함하고, 프로파일 데이터는 해당 프로파일에 저장되는 실제 데이터를 의미한다. 또한, 접근 권한 정보는 해당 프로파일에 접근하기 위한 권한에 대한 레벨 정보, 접근 권한이 있는 AE, 보안 개체, CSE 등의 정보 또는 설정된 권한에 대한 정보를 포함할 수 있다.

한편, M2M 장치의 보안 개체는 접근 요청에 대한 접근 권한을 확인하는 단계를 수행한다(S510). M2M 장치의 보안 개체는 요청 메시지를 확인하고, 요청 메시지를 전송한 타 M2M 장치의 접근 권한을 확인할 수 있다. 접근 권한은 요청 메시지의 종류에 따라 다를 수 있으며, 접근하고자 하는 AE 별로 다르게 설정될 수도 있다.

필요에 따라, 접근 요청에 대한 권한을 확인하는 단계는 보안 개체에 대한 접근 권한 여부를 확인하는 단계 및 하나 이상의 어플리케이션 개체 별로 설정되는 접근 권한 여부를 확인하는 단계를 더 포함할 수 있다. 예를 들어, 보안 개체에 구성되는 보안 개체를 선택하는 요청 메시지의 경우, 해당 보안 개체에 타 M2M 장치가 접근할 권한이 있는지를 1차적으로 확인하고, 보안 개체에 구성되는 어플리케이션 개체에 대한 접근 권한이 있는지를 2차적으로 확인할 수 있다. 보안 개체에 대한 접근 권한 또는 어플리케이션 개체 별로 설정되는 접근 권한은 요청 메시지에 포함되는 동작 파라미터 별로 구분되어 설정될 수 있다.

또한, M2M 장치의 보안 개체는 타 M2M 장치의 어플리케이션 개체에 대한 접근 권한이 확인되는 경우, 요청 메시지에 기초하여 어플리케이션 개체 또는 프로파일 자원에 대한 조회, 생성, 삭제 및 업데이트 중 적어도 하나의 동작을 처리하는 단계를 수행한다(S520). M2M 장치의 보안 개체는 요청 메시지와 접근 권한을 확인하고, 타 M2M 장치가 어플리케이션 개체 및 보안 개체에 접근할 권한이 있다면, 요청 메시지에서 지시되는 동작을 수행할 수 있다. 예를 들어, M2M 장치의 보안 개체는 어플리케이션 개체 또는 프로파일 자원에 대한 리스트 조회, 조회, 생성, 삭제 및 변경 중 적어도 하나의 동작을 요청 메시지의 요청 내용에 따라서 처리할 수 있다. 아울러, M2M 장치는 해당 처리 결과를 응답 메시지에 포함하여 타 M2M 장치로 전송할 수도 있다.

보안 개체가 접근 권한을 확인하고, 요청 메시지를 처리하는 과정은 보안 개체 내부의 각 관리 기능에 의해서 수행될 수도 있고, 보안 개체가 구성되는 M2M 장치의 다른 개체 또는 기능과 연동하여 수행될 수도 있다.

이하에서는, 전술한 본 발명을 보안 개체 동작을 요청 메시지 종류에 따라 구분하여 도면을 참조함으로써 보다 상세하게 설명하도록 한다. 필요에 따라, 이하에서는 보안 개체를 사용하는 타 M2M 장치를 어플리케이션이라 표기하고 보안 개체내부의 어플리케이션은 어플리케이션 개체(application entity, AE)로 기재하여 설명한다.

도 6은 일 실시예에 따른 M2M 장치의 보안 개체의 구성을 설명하기 위한 도면이다.

도 6을 참조하면 보안 개체(Secure Entity or Secure Environment, SE, 600)는 SE 접근 권한을 확인하고, 권한을 부여하기 위한 기능(630)과 하나 이상의 AE(610, 620)를 포함하여 구성할 수 있다. 예를 들어, SE(600)는 두 개의 AE(610, 620)를 포함하여 구성할 수 있다. 각각의 AE(610, 620)는 SE에 대한 접근 권한이 획득되었는지 확인할 수 있고, 해당 AE(610, 620)에 대한 접근 권한을 추가로 확인하거나 권한을 부여할 수 있다. 즉, SE(600) 내부에 구성되는 AE(610, 620)들은 SE의 권한과 AE에 대한 접근 권한을 모두 확인하는 경우 어플리케이션(예를 들어, 타 M2M 장치)이 접속할 수 있다. 이 경우, 어플리케이션은 AE에 대한 접근을 시도하는 요청 메시지를 보내고, SE(600)는 SE에 대한 접근 권한을 확인 또는 부여하고, 어플리케이션이 접근을 시도하는 AE(610 또는 620)는 SE에 대한 접근 권한의 획득을 확인하고, 추가적으로 해당 AE(610 또는 620)에 대한 접근 권한을 확인 또는 부여하여 높은 보안성을 제공할 수 있다.

구체적으로, 요청 메시지에 포함되는 정보에 따라서 보안 개체는 아래에서 설명하는 동작을 수행한다.

(1) 보안 개체에 대한 어플리케이션 개체에 대한 리스트 조회

타 M2M 장치는 AE 리스트를 요청하는 요청 메시지를 통해서 보안 개체 내부의 어플리케이션 리스트를 조회할 수 있다. 이 경우, 요청 메시지는 보안 개체에 대한 식별정보, 타 M2M 장치에 대한 식별정보 및 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 리스트를 요청하는 정보를 포함할 수 있다. 보안 개체 외부에서 어플리케이션 개체 리스트에 대한 조회를 요청해오면 조회 권한이 있는지를 확인한 다음 보안 개체의 어플리케이션 개체 리스트를 제공한다. 어플리케이션 개체에 접속할 때 어플리케이션 개체의 보안 요건에 따라 추가적인 인증과 권한 조회를 할 수 있다. 이를 위해 어플리케이션 개체 리스트에는 어플리케이션 개체마다 추가로 입력할 보안 파라미터가 명시될 수 있다.

도 7은 일 실시예에 따른 M2M 장치의 보안 개체에 구성되는 어플리케이션 개체에 대한 리스트 조회 동작을 설명하기 위한 도면이다.

도 7을 참조하면, 타 M2M 장치 (예를 들어, 외부 어플리케이션, 700)가 AE 리스트를 요청하는 요청 메시지를 보안 개체로 전송하면, 보안 개체 관리 기능(710)은 외부 어플리케이션(700)에 대한 AE 리스트 조회 권한을 확인하기 위해서 사용자 인증 결정 기능(740)으로 외부 어플리케이션(700)의 조회 권한 확인 및 리스트 요청을 전달한다. 사용자 인증 결정 기능(740)은 접근 제어 정책 관리 기능(750)으로 정책을 요청하고, 관련 정책 정보를 제공 받는다. 예를 들어, 관련 정책 정보는 권한 정보 및 해당 AE 또는 기능의 리스트 정보를 포함할 수 있다. 정책 정보 관리 기능(760)으로 권한 설정 데이터를 요청하여 권한 정보를 획득한다. 예를 들어, 권한 정보는 해당 어플리케이션의 권한 종류 및 해당 AE 요구 보안 수준에 대한 정보를 포함할 수 있다. 접근 제어 정책 관리 기능(750)은 권한 종류 별 사용 가능한 AE 리스트를 관리하고, 정책 정보 관리 기능(760)은 권한 종류 별 어플리케이션 식별정보 리스트를 관리하고 AE 별 보안 수준 정보를 저장/관리할 수 있다. 아울러, 사용자 인증 결정 기능(740)은 조회한 정책 정보와 권한 정보를 이용하여 리스트를 작성하고, AE를 위한 권한 부여 정보를 저장한다.

보안 개체 관리 기능(710)은 사용자 인증 결정 기능(740)으로부터 권한 정보를 수신하고, 보안 개체 자원 관리 기능(730)로 수신된 권한 범위 정보를 포함하는 AE 리스트 요청 정보를 전송한다. 이후, 보안 개체 관리 기능(710)은 보안 개체 자원 관리 기능(730)을 통해서 어플리케이션(700)의 권한 범위 내에서 AE 리스트를 제공 받아서 어플리케이션(700)으로 전달한다. 또한, 보안 개체 관리 기능(710)은 한시적 접근 권한 부여 리스트(720)에 타 M2M 장치(예를 들어, 도 7의 어플리케이션, 700)의 현재 연결에서의 SE 접근권한을 부여하는 요청을 제공한다. 이를 통해서, AE 리스트를 제공 받은 어플리케이션(700)은 현재 연결이 유지되는 상태에서는 SE에 대한 접근 권한을 추가적으로 확인하지 않을 수 있다.

이와 같이, 보안 개체는 AE 리스트를 요청하는 요청 메시지가 수신되면, AE 리스트 조회 권한 정책을 확인하고, 해당 외부 어플리케이션에 대한 정보를 조회해서 정책에 부합하는지를 판단한다. 보안 개체는 외부 어플리케이션이 정책에 부합하면 AE 리스트를 외부 어플리케이션에 제공한다. 그리고 외부 어플리케이션이 SE와 연동 채널이 유지되는 동안 해당 외부 어플리케이션에 부여한 권한을 보관하기 위해 '한시적 접근 권한 부여 리스트'에 등록할 수 있다.

이상에서는 710 내지 760를 이해의 편의를 돕기 위해서 기능 별로 나누어 설명하였으나, 710 내지 760은 보안 개체의 프로세서 또는 M2M 장치의 프로세서에 의해서 동작 될 수도 있다.

한편, 일 예로, AE 리스트를 조회하는 함수는 아래와 같이 구성될 수 있다.

○ availableAEList = getAE(applicationID, targetSeID)

위의 함수가 구성되어 수신되면, 보안 개체는 해당 함수의 외부 어플리케이션(application ID)의 조회 권한 여부 확인 후 해당 보안 개체에 구성되는 AE 리스트를 제공한다. applicationID는 AE 리스트를 요청하는 외부 어플리케이션의 식별정보이며, targetSeID는 해당 요청 메시지를 수신할 SE의 식별정보를 의미한다.

한편, AE 리스트 중 외부 어플리케이션이 사용할 AE를 선택하는 함수는 아래와 같이 구성될 수 있다.

○ securityLevel = selectAE(targetAeID, securityLevel)

targetAeID는 선택한 AE에 대한 식별정보를 의미하며, securityLevel은 보안 레벨을 의미한다. 선택 대상 AE는 외부 어플리케이션이 제시한 가능한 보안 레벨을 검토하여 적합한 보안레벨을 결정하여 리턴한다. 이때, 외부 어플리케이션 정보와 해당 AE의 정보를 함께 검토하여 보안 레벨이 결정될 수 있다.

(2) 보안 개체 내에 구성되는 AE에 대한 접근 권한 제어

하나의 보안 개체에는 여러 개의 어플리케이션 개체가 구성될 수 있다. 어플리케이션 개체마다 보안 수준이나 접근 권한이 다를 수 있다. 따라서, 기본적으로 어플리케이션 개체마다 인증을 수행하고, 권한 조회 및 부여 동작을 수행할 필요가 있다. 이를 위해서, 일 실시예는 보안 개체 접속시에 기본적인 인증과 권한 조회/권한 부여 동작을 수행한다. 즉, 보안 개체에 대한 접근 권한을 조회/부여하는 것이다. 이후, 보안 개체 내에 구성되는 어플리케이션 개체에 접근할 때는 전술한 동작을 통해서 이미 보안 개체에 대한 접근 권한은 갖고 있는 상태일 수 있다. 이 경우에 어플리케이션 개체에 따라서는 보안 개체에 접근할 권한으로 접근 가능한 어플리케이션 개체가 있을 수도 있고, 추가적인 인증 및 권한 부여가 필요한 어플리케이션 개체가 있을 수도 있다. 추가적인 인증이나 권한 부여가 필요한 어플리케이션 개체의 경우에는 보안 개체 접근을 위한 인증 및 권한 부여 이외에도 추가적인 인증 및 권한 부여가 필요하다.

도 8은 일 실시예에 따른 어플리케이션 개체에 대한 기본적인 접근 권한을 확인하는 동작을 설명하기 위한 도면이고, 도 9는 일 실시예에 따른 어플리케이션 개체에 대한 추가적인 접근 권한을 확인하는 동작을 설명하기 위한 도면이다.

도 8을 참조하면, 외부 어플리케이션(800)은 보안 개체 내에 구성되는 AE를 선택하는 요청 메시지를 전송한다. 예를 들어, 외부 어플리케이션(800)은 AE 리스트를 확보한 다음 원하는 AE가 존재하면 해당 AE에 연동을 요청할 수 있다. AE 관리 기능(810)은 외부 어플리케이션(800)의 AE 선택 요청에 대한 권한 부여 여부를 확인할 수 있다. 예를 들어, AE 관리 기능(810)은 SE 권한 부여 리스트(820)를 조회하여 외부 어플리케이션(800)이 선택한 AE에 대한 정당한 권한을 부여 받았는지를 확인할 수 있다. SE 권한 부여 리스트(820)는 도 7에서의 720과 동일할 수 있다. 즉, 외부 어플리케이션(800)이 도 7의 절차에 따라서 AE 리스트를 획득하는 과정에서 '한시적 접근 권한 부여 리스트'에 등록될 수 있고, 동일한 외부 어플리케이션(800)이 AE를 선택하는 경우에 '한시적 접근 권한 부여 리스트'를 확인하여 권한 인가 여부를 빠르게 확인할 수 있다.

한편, AE에 따라서 추가적인 권한 확인이 필요하면 도 7의 보안 개체 접근 권한 확인에 추가적으로 도 9의 보안 정책 확인과 외부 어플리케이션 정보를 조회해서 접근 권한 부여 여부를 확인하는 절차를 수행할 수 있다. 도 9를 참조하면, 외부 어플리케이션(900)이 보안 개체 내에 구성되는 특정 AE 또는 기능(Function)을 선택하면, AE 관리 기능(910)은 사용자 인증 결정 기능(920)을 통해서 권한 확인 및 리스트 요청을 수행할 수 있다. 사용자 인증 결정 기능(920)은 접속 제어 정책 관리 기능(930)으로 정책 정보를 요청하여 관련 정책 정보를 수집하고, 정책 정보 관리 기능(940)으로 권한 설정 정보를 요청하여 권한 정보를 제공 받아서 외부 어플리케이션이 선택한 AE 또는 기능에 대한 추가적인 권한 점검을 수행할 수 있다. 예를 들어, 접속 제어 정책 관리 기능(930)은 권한 종류 별 사용 가능한 기능에 대한 리스트를 관리할 수 있다. 또한, 정책 정보 관리 기능(940)은 권한 종류 별 어플리케이션 개체 식별정보 리스트를 관리하고, 기능 별 보안 수준 정보를 저장 및 관리할 수 있다. 아울러, 사용자 인증 결정 기능(920)은 조회한 정책 정보와 권한 정보로 리스트를 작성하거나, 기능을 위한 권한 부여 정보를 저장할 수 있다.

AE 관리 기능(910)은 권한 확인 및 인증이 완료되면 요청한 기능에 대한 리스트를 제공 받아서 외부 어플리케이션으로 전달할 수 있다. 리스트에는 요청한 기능 또는 AE에 대한 접속 권한 부여 또는 해당 기능 또는 AE의 데이터나 연동을 제공하는 내용이 포함될 수 있다. 또는 해당 리스트에는 외부 어플리케이션(900)이 접근할 수 있는 기능들에 대한 정보가 포함될 수도 있다.

이를 통해서, 외부 어플리케이션은 보안 개체에 대한 접속 권한을 부여 받고 추가적으로 요청한 AE에 대한 접속 권한을 부여 받음으로써 해당 AE의 정보에 접근할 수 있다.

이하에서는, 외부 어플리케이션이 보안 개체 내에 구성되는 어플리케이션 개체를 생성, 변경, 삭제하는 등의 동작을 수행하는 절차에 대해서 설명한다. 종래에는 보안 개체 내의 어플리케이션 개체를 변경, 생성, 삭제할 수 없었다. 이를 위해서는 최초 보안 개체를 등록하는 서비스 사업자 또는 제조사가 보안 개체를 새롭게 설정하여 등록함으로써 보안 개체 내의 내용을 변경, 삭제 및 생성하는 번거로움이 있었다.

(3) 어플리케이션 개체, 어플리케이션 개체 내의 함수 또는 데이터에 대한 생성, 변경, 삭제 동작

보안 개체 내에 구성되는 어플리케이션 개체를 생성하거나 변경 또는 삭제하기 위해서는 보안 개체에 접근하기 위한 접근 권한과는 다른 별도의 권한이 필요할 수 있다. 또한, 보안 개체에 구성되는 어플리케이션 개체 내의 함수 또는 데이터를 생성, 변경 또는 삭제하기 위해서는 해당 어플리케이션 개체에 대한 별도의 권한이 요구될 수 있다. 즉, 전술한 보안 개체 또는 어플리케이션 개체에 리스트를 요청하거나, 해당 개체에 접근하여 정보를 확인하기 위한 권한과는 별도로 생성, 변경 또는 삭제 권한이 요구될 수 있다. 이는 보안성을 한층 더 강화시킬 수 있다. 이를 위해서는 보안 개체와 각각의 어플리케이션 개체에서는 권한 정책과 권한 정보를 확인하여 권한 만족 여부를 판단할 수 있다.

한편, 외부 어플리케이션에서 AE 또는 AE 내부의 함수나 데이터를 생성, 변경 또는 삭제 등의 제어를 수행할 경우에 특별한 권한(예를 들어, 관리자 권한)으로 보안 채널(secure channel)을 생성하여 진행할 수 있다. 이 경우, 특별한 권한을 획득하지 못한 장치의 접근과 제어를 방지할 수 있다.

도 10은 일 실시예에 따른 M2M 장치의 보안 개체 내에 어플리케이션 개체를 추가 생성하는 동작을 설명하기 위한 도면이다.

도 10을 참조하면, 보안 개체는 외부 어플리케이션으로부터 보안 개체 내에 AE를 생성하도록 요청하는 AE 생성 요청을 수신할 수 있다(S1000). 보안 개체는 AE 생성을 요청한 외부 어플리케이션이 AE 생성 권한이 있는지를 확인한다(S1010). 만약, 외부 어플리케이션이 AE 생성 권한을 만족하지 못하는 경우에 외부 어플리케이션의 접근을 차단할 수 있다. 이와 달리 외부 어플리케이션이 AE를 생성할 특별한 권한이 있다면, 보안 개체 내에 새로운 AE를 구성하여 생성할 수 있다(S1020). 예를 들어, 보안 개체는 AE 생성에 대한 권한을 확인 한 후에 AE 템플릿(예를 들어, 생성되는 AE ID, resourceType, 저장 공간 확보)을 생성하고 새로 생성한 AE ID와 권한 정보를 리턴한다.

외부 어플리케이션은 리턴된 AE ID와 권한 정보(예를 들어, 토큰)을 이용하여 생성된 AE에 대한 보안 정책을 설정한다(S1030). 보안 정책은 해당 AE에 대한 접근 권한 및 보안 수준 등을 포함할 수 있다. 필요에 따라서 생성된 AE 또는 보안 정책 설정을 바이너리 등록하고(S1040), 생성된 AE에 데이터를 등록한다(S1050). 생성된 AE에 보안 설정과 데이터 설정을 완료하면 AE 생성이 완료된다(S1060).

도 10에서는 AE를 생성하는 절차를 중심으로 설명하였으나, AE 내부의 함수 또는 데이터를 생성하는 경우에 도 10의 절차가 전부 또는 일부 수행될 수 있다. 일 예로, AE 생성을 위한 요청 함수와 AE 내부의 함수 생성을 위한 요청 함수는 아래와 같이 구성될 수 있다.

○ (createAuth, aeID) = createAE(applicationID, targetSeID, newAeName, resourceType, authInfo)

○ createAuth = setAe(createAuth, applicationID, aeID, aeBinary)

○ createAuth = setSecurityPolicy(createAuth, applicationID, aeID, Privilege, selfPrivilege)

○ createAuth = setSecurityInformation(createAuth, applicationID, aeID, PrivilegeInformation)

○ createAuth = setAeData(createAuth, applicationID, dataInfomation)

○ (createAuth, functionID) = createFunction(createAuth, applicationID, newFunctionName, resourceType)

○ createAuth = setFunction(createAuth, applicationID, functionID, functionBinary)

○ createAuth = setSecurityPolicy(createAuth, applicationID, functionID, Privilege, selfPrivilege)

○ createAuth = setSecurityInformation(createAuth, applicationID, functionID, PrivilegeInformation)

○ createAuth = setFunctionData(createAuth, applicationID, dataInfomation)

도 11은 일 실시예에 따른 M2M 장치의 보안 개체 내에 구성되는 어플리케이션 개체를 변경 또는 삭제하는 동작을 설명하기 위한 도면이다.

도 11을 참조하면, 외부 어플리케이션은 보안 개체 내에 구성되어 있는 AE에 대한 변경 또는 삭제를 요청할 수 있다(S1100). 이 경우에 외부 어플리케이션은 AE에 대한 변경 또는 삭제를 위한 별도의 권한이 필요하다. 따라서, 보안 개체는 외부 어플리케이션의 AE 변경 또는 삭제 요청을 수신하면, 해당 외부 어플리케이션이 권한을 만족하는지 판단한다(S1110). 만약, 외부 어플리케이션이 권한을 만족하지 못하는 경우에 해당 요청에 대한 처리 동작을 수행하지 않고, 권한 조건을 만족하지 못함을 통지할 수 있다. 이와 달리, 외부 어플리케이션이 권한을 만족하는 경우에는 요청 메시지에 의해서 특정되는 AE 정보를 변경하거나, AE를 삭제할 수 있다(S1120). 필요한 경우, 변경 또는 삭제되는 AE에 대응되는 보안 정책을 변경 또는 삭제할 수 있다(S1130). 예를 들어, SE 또는 해당 AE에 대한 접근 권한을 변경하거나 삭제할 수 있고, 보안 수준을 변경 또는 삭제할 수도 있다.

필요에 따라, 변경 또는 삭제되는 AE에 대한 바이너리 파일도 변경 또는 삭제할 수 있다(S1140). 또한, AE에 대한 변경 요청에 해당 AE에 저장된 데이터에 대한 변경 요청을 포함하면, 해당 데이터를 변경할 수 있고, AE에 대한 삭제 요청이 있으면, 해당 AE에 저장 또는 관리되는 데이터도 모두 삭제할 수 있다(S1150). 이러한 과정이 종료되면 해당 AE에 대한 변경 또는 삭제 절차가 완료된다(S1160).

도 11에서는 AE를 변경 또는 삭제하는 절차를 중심으로 설명하였으나, AE 내부의 함수 또는 데이터를 변경 또는 삭제하는 경우에 도 11의 절차가 전부 또는 일부 수행될 수 있다.

한편, 일 예로, AE 변경(Update) 함수와 AE의 기능 변경(function Update) 함수는 아래와 같이 구성될 수있다.

○ updateAuth = updateAE(applicationID, targetSeID, aeID, authInfo)

○ updateAuth = setAe(updateAuth, applicationID, aeID, aeBinary)

○ updateAuth = setSecurityPolicy(updateAuth, applicationID, aeID, Privilege, selfPrivilege)

○ updateAuth = setSecurityInformation(updateAuth, applicationID, aeID, PrivilegeInformation)

○ updateAuth = setAeData(updateAuth, applicationID, dataInfomation)

○ updateAuth = updateFunction(updateAuth, applicationID, newFunctionName, resourceType)

○ updateAuth = setFunction(updateAuth, applicationID, functionID, functionBinary)

○ updateAuth = setSecurityPolicy(updateAuth, applicationID, functionID, Privilege, selfPrivilege)

○ updateAuth = setSecurityInformation(updateAuth, applicationID, functionID, PrivilegeInformation)

○ updateAuth = setFunctionData(updateAuth, applicationID, dataInfomation)

다른 예로, AE 삭제(Delete) 함수와 AE의 기능 삭제(function Delete) 함수는 아래와 같이 구성될 수 있다.

○ deleteAuth = deleteAE(applicationID, targetSeID, newAeName, resourceType, authInfo)

○ deleteAuth = setAe(deleteAuth, applicationID, aeID, aeBinary)

○ deleteAuth = deleteFunction(deleteAuth, applicationID, newFunctionName, resourceType)

○ deleteAuth = setFunction(deleteAuth, applicationID, functionID, aeBinary)

전술한 바와 같이, AE를 삭제하면 하위 기능(function)과 데이터 그리고 해당 AE에 대한 보안 정책, 외부 어플리케이션의 AE 관련 권한 정보도 모두 삭제된다.

도 12는 일 실시예에 따른 어플리케이션 개체의 추가, 변경 또는 삭제에 대한 권한을 확인하는 절차를 설명하기 위한 도면이다.

전술한 방법으로 보안 개체 내에 AE를 새롭게 생성하거나, 보안 개체 내에 생성되는 AE를 변경 또는 삭제하는 경우에 이를 위한 별도의 권한 확인이 필요하다. 이 경우에도 SE 또는 AE에 접근하기 위한 권한 확인과 유사하게 보안 정책과 외부 어플리케이션의 정보를 조회해서 외부 어플리케이션의 권한 오류 여부를 확인할 수 있다.

구체적으로, 도 12를 참조하면, 외부 어플리케이션(1200)이 AE에 대한 생성(설명의 편의를 위해서 생성을 중심으로 설명하나 변경 또는 삭제의 경우에도 동일하게 적용됨) 요청하는 경우에 SE 관리 기능(1210)은 외부 어플리케이션(1200)의 AE 생성 권한이 있는지 확인하기 위해서 CRUD 인증 결정 기능(1220)에 권한 확인 또는 리스트 요청을 전달한다. C.R.U.D는 생성(Create), 조회(Retrieve), 업데이트(Update) 및 삭제(Delete)를 의미한다. CRUD 인증 결정 기능(1220)은 CRUD 정책 관리 기능(1230)으로 CRUD 정책을 요청하여 관련 정책 정보를 수집하고, 정보 관리 인증 기능(1240)으로 권한 설정 데이터를 요청하여 권한 정보를 수집한다. 이후, CRUD 인증 결정 기능(1220)은 조회한 정책 정보와 권한 정보를 이용하여 외부 어플리케이션의 AE 생성 권한이 있는지 확인하거나, 권한을 부여하여 권한 부여 정보를 저장할 수 있다. 한편, CRUD 정책 관리 기능(1230)은 CRUD 종류별 정책을 저장 또는 관리하고, 리소스 타입 별 정책을 저장 또는 관리하며, 요청자 종류별 정책을 저장 또는 관리할 수 있다. 또한, 정보 관리 인증 기능(1240)은 요청자 종류 정보를 확인하고, 보안 정책 관련 정보를 확인할 수 있다.

SE 관리 기능(1210)은 CRUD 인증 결정 기능(1220)으로부터 리스트 정보를 제공 받을 수 있다. 해당 리스트 정보는 전술한 바와 같이 생성된 AE에 대한 AE 식별정보, AE 정책 정보 및 AE 권한 정보 중 적어도 하나의 정보를 포함할 수 있다. SE 관리 기능(1210)은 보안 개체 내에 AE 생성이 완료되면, 해당 AE에 대한 인증 정보및 AE 식별정보 중 적어도 하나의 정보를 외부 어플리케이션(1200)으로 제공할 수 있다.

예를 들면, AE 에 대한 생성, 조회, 변경, 삭제 권한에 대한 종류는 표 1과 같이 설정될 수 있다.

표 1에 예시적으로 구분한 것과 같이 권한 종류는 보안 레벨에 따라서 다양하게 구분되어 설정될 수 있다. 각 레벨에 따른 권한은 미리 설정된 권한 할당 정보에 따라서 다르게 구성될 수 있다.

(4) 보안 개체 내에 구성되는 AE의 활성화 또는 비활성화 동작 수행

보안 개체 내에 구성되는 AE에 대해서 생성, 변경 또는 삭제 뿐만 아니라 활성화 또는 비활성화 동작이 수행될 수도 있다. 예를 들어, 여름이 되면 난방기와 관련된 M2M 장치의 AE는 데이터 생성이 중지되고, 활용이 중지되어 전력 소모를 아낄 필요가 있다. 다만, 이 경우에 해당 AE를 삭제하면 겨울이 되었을 때, AE을 다시 생성하여 등록하는 불필요한 절차가 추가로 요구된다. 따라서, 특정 AE는 필요에 따라서 활성화되거나 비활성화 될 수 있다.

도 13은 일 실시예에 따른 M2M 장치의 보안 개체 내에 구성되는 어플리케이션 개체를 활성화 또는 비활성화하는 동작을 설명하기 위한 도면이다.

도 13을 참조하면, 보안 개체 내에 구성되는 AE에 대한 활성화 또는 비활성화 요청이 수신된다(S1300). 보안 개체는 이 경우에 해당 AE에 대한 활성화 또는 비활성화 요청을 수행하는 외부 어플리케이션의 권한이 있는지 권한 만족 여부를 판단한다(S1310). 만약, 외부 어플리케이션이 AE에 대한 활성화 또는 비활성화 권한이 없는 경우에는 권한을 만족하지 못한다는 내용을 외부 어플리케이션에 제공하고 절차를 종료한다. 이와 달리, 외부 어플리케이션이 권한을 만족하는 경우에는 해당 AE의 동작 프로세스를 활성화 또는 비활성화 할 수 있다(S1320). 예를 들어, 요청 메시지가 활성화 요청인 경우에 해당 AE 프로세스를 재기동하고, 요청 메시지가 비활성화 요청인 경우에 해당 AE 동작 중인 프로세스를 중지한다.

이후, 보안 개체의 정책 정보 관리 기능에서 해당 AE의 상태 항목을 활성화 또는 비활성화로 설정한다(S1330). 이는 해당 AE의 상태와 정책 정보를 일치시키기 위함이다. 이를 통해서, AE 활성화 또는 비활성화 동작이 완료된다(S1340).

도 13에서 설명한 바와 같이, 외부 어플리케이션은 보안 개체 내부의 AE의 활성화 동작을 제어할 수 있고, 이 경우에는 전술한 리스트 조회, 선택, 생성, 변경, 삭제 등과 같이 별도의 권한 인증을 수행할 필요가 있다. AE의 활성화 동작 제어 권한은 전술한 리스트 조회, 선택, 생성, 변경, 삭제 등의 권한과 연동되어 동일하게 설정될 수도 있고, 별도로 설정될 수도 있다. 아래에서는 AE 활성화 또는 비활성화 동작의 권한 확인 절차를 설명한다.

도 14는 일 실시예에 따른 M2M 장치의 보안 개체 내에 구성되는 어플리케이션 개체를 활성화 또는 비활성화 동작을 위한 권한을 확인하는 절차를 설명하기 위한 도면이다.

도 14를 참조하면, 외부 어플리케이션(1400)는 보안 개체 내에 구성되는 특정 AE에 대한 활성화 또는 비활성화를 요청할 수 있다. SE 관리 기능(1410)은 AE에 대한 활성화 또는 비활성화 요청이 수신되면, 외부 어플리케이션(1400)에 대한 권한확인 또는 리스트 요청을 사용자 인증 결정 기능(1420)으로 요청한다. 사용자 인증 결정 기능(1420)은 활성화/비활성화 정책 관리 기능(1430)으로 정책 정보를 요청하여 관련 정책 정보를 수집한다. 활성화/비활성화 정책 관리 기능(1430)은 활성화 또는 비활성화에 관련된 정책 정보를 저장 또는 관리한다. 또한, 사용자 인증 결정 기능(1420)은 정책 정보 관리 기능(1440)으로 권한 설정 데이터를 요청하여 권한 정보를 수집한다. 정책 정보 관리 기능(1440)은 활성화 또는 비활성화 정책 관련 정보를 조회하여 사용자 인증 결정 기능(1420)으로 제공한다. 예를 들어, 정책 정보 관리 기능(1440)은 대상 AE의 소유자 정보, AE의 상태정보 및 AE의 상태 변경 가능 여부에 대한 정보를 조회하여 사용자 인증 결정 기능(1420)으로 제공할 수 있다. 사용자 인증 결정 기능(1420)은 수집된 정책 정보와 권한 정보를 이용하여 외부 어플리케이션(1400)이 해당 AE를 활성화 또는 비활성화 하기 위한 적합한 권한이 있는지를 판단한다.

사용자 인증 결정 기능(1420)은 SE 관리 기능(1410)으로 판단된 권한 정보를 제공하고, SE 관리 기능(1410)은 권한 정보를 확인하여 해당 AE에 대한 활성화 또는 비활성화 동작을 수행한다. 이후, SE 관리 기능(1410)은 정책 정보 관리 기능(1440)으로 활성화 또는 비활성화 설정을 요청한다. 예를 들어, SE 관리 기능(1410)은 정책 정보 관리 기능(1440)이 관리하는 AE 상태정보를 변경된 정보로 변경하여 설정하도록 요청할 수 있다. 정책 정보 관리 기능(1440)은 해당 AE의 상태정보를 변경하고 SE 관리 기능(1410)으로 설정 변경 결과를 제공한다. SE 관리 기능(1410)은 처리 결과를 외부 어플리케이션(1400)으로 제공한다.

이와 같이, 보안 개체 내에 구성된 AE를 삭제하지 않고 활성화 또는 비활성화 설정을 통해서 해당 AE의 동작 또는 해당 AE로의 접근을 통제할 수 있다. 비활성화 시키는 경우에 해당 AE를 삭제하지 않고 동작만 정지시키므로, 이 기능을 활용하면 서로 상반되는 어플리케이션들을 설치해 놓고 상황에 맞는 어플리케이션이동작하도록 제어할 수 있다. 이를 통해서, 하나의 단말기를 다양한 용도로 활용할 수도 있다.

(5) 보안 개체 또는 어플리케이션 개체의 가입자 정보 또는 단말 정보를 생성, 활성화/비활성화, 삭제 또는 변경하는 동작

위에서 설명한 바와 같이, 외부 어플리케이션은 보안 개체 내부에 구성되는 어플리케이션 개체(AE)를 생성, 삭제, 변경, 조회할 수 있다. 이 외에도, 외부 어플리케이션은 보안 개체 또는 보안 개체 내에 구성되는 AE에 저장 또는 관리되는 가입자 정보 또는 단말 정보에 접근할 수도 있다. 예를 들어, 외부 어플리케이션은 보안 개체 내에 저장 또는 관리되는 가입자 정보(또는 단말 정보)의 추가, 활성화/비활성화, 삭제, 조회, 변경 등을 요청할 수도 있다. 이 경우에도 보안 개체는 해당 외부 어플리케이션의 권한을 확인할 필요가 있다. 특히, 가입자 정보와 단말 정보와 같은 프로파일 정보는 보안 중요성이 매우 높을 수 있으므로, 위에서 설명한 동작과는 별도의 권한 확인 과정이 추가적으로 요구될 수도 있다. 또는 보안 레벨 또는 권한 레벨이 높게 책정될 수도 있다.

예를 들면, 보안 개체에 저장 또는 관리되는 프로파일 정보를 생성, 업데이트(예를 들어, 활성화 또는 비활성화) 또는 삭제하기 위한 함수는 아래와 같이 각각 구성될 수 있다.

○ profileID = sendProfile(profileData)

○ enableReslut = enableProfile(profileID)

○ disableReslut = disableProfile(profileID)

○ deleteReslut = deleteProfile(profileID)

프로파일 정보는 보안 채널로 직접 연동 되어 있으므로, 보안 개체 또는 어플리케이션 개체에 대한 정보를 요청 메시지에 별도로 포함시키지 않을 수 있다. 즉, 프로파일 정보는 프로파일 식별정보로 바로 확인이 가능할 수 있다.

한편, 보안 개체 또는 어플리케이션 개체에서 저장 또는 관리되는 프로파일 자원(Profile resource)은 도 15와 같이 구성될 수 있다.

도 15는 일 실시예에 따른 프로파일 자원의 구조를 예시적으로 도시한 도면이다.

도 15를 참조하면, 프로파일 자원은 프로파일 타입정보, 프로파일 식별정보, 프로파일 생성자의 식별정보, 프로파일 접속 권한 정보 및 프로파일 데이터를 하위 속성정보로 포함할 수 있다. 각각의 속성정보는 아래 표 2에 설명되어 있는 정보를 포함한다.

한편, 보안 개체나 어플리케이션 개체의 보안 정책도 변경될 수 있다. 보안 정책을 변경하는 경우에는 보안 정책을 변경하기 위한 별도의 보안 채널이 연결될 수 있으므로, 보안 개체나 어플리케이션 개체에 대한 식별정보는 요청 메시지에 포함되지 않을 수 있다.

예를 들어, 보안 정책의 변경을 요청하는 함수는 아래와 같이 구성될 수 있다.

○ updateResult = updatePolicy(PolicyData)

이와 같이, 정책(Policy)의 경우 보안 개체나 어플리케이션 개체가 제조 또는 생성될 때 기본 정책이 등록될 수 있으며, 기본 정책이 등록되어 사용중인 경우에는 updatePolicy로 변경할 수도 있다.

이상에서 설명한 바와 같이, 본 발명에 따르면, 보안 개체에 구성되는 데이터를 추가, 변경, 조회, 삭제할 수 있으면서도 복수의 권한 인증 과정을 통해서 안전한 접근 제어가 가능하다. 사물 통신에서는 단말을 이용하는 환경이 다양하게 바뀔 수가 있다. 또한, 단말을 이용하는 서비스나 연동 플랫폼이 바뀔 수 있다. 이러한 상황에서 본 발명을 적용할 경우에 단말의 가입 정보를 추가, 변경, 삭제하고 새로운 서비스나 플랫폼과의 연동을 위한 어플리케이션 개체를 추가, 변경, 삭제할 수 있어서 단말을 계속해서 사용할 수 있는 장점이 있다. 뿐만 아니라, 하드웨어는 유지하면서 어플리케이션을 상황에 맞게 개선할 수 있기 때문에 단말의 활용도를 더욱 높일 수 있다. 특히 사물 통신에서 센서류와 같은 말단 디바이스(end device)는 대량으로 설치되는 경우가 많기 때문에 한 번 설치한 단말을 지속적으로 사용하는 것이 중요하다. 따라서, 본 발명은 단말을 상황 변화에 맞게 업그레이드를 할 수 있게 해주어 단말의 활용성을 증대시키는 효과를 제공한다.

이하에서는 도 1 내지 도 15를 참조하여 설명한 본 실시예들의 동작을 모두 또는 일부 수행할 수 있는 M2M 장치의 보안 개체에 대한 구성을 설명한다. 도 16에서의 구성은 기능적 측면으로 구분되는 것으로, 보안 개체의 프로세서 또는 저장장치와 연동되어 동작할 수도 있다.

도 16은 일 실시예에 따른 M2M 장치의 보안 개체에 대한 구성을 도시한 도면이다.

도 16을 참조하면, M2M(Machine to Machine communication) 장치의 보안 개체(1600)는, 타 M2M 장치로부터 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 접근을 요청하는 요청 메시지를 수신하는 수신부(1630)와 접근 요청에 대한 접근 권한을 확인하는 접근 권한 확인부(1620) 및 타 M2M 장치의 어플리케이션 개체에 대한 접근 권한이 확인되는 경우, 요청 메시지에 기초하여 어플리케이션 개체 또는 프로파일 자원에 대한 조회, 생성, 삭제 및 업데이트 중 적어도 하나의 동작을 처리하는 제어부(1610)를 포함할 수 있다.

또한, 접근 권한 확인부(1620)는 보안 개체에 대한 접근 권한 여부 및 하나 이상의 어플리케이션 개체 별로 설정되는 접근 권한 여부를 각각 확인할 수 있다. 접근 권한 확인부(1620)는 요청 메시지의 종류에 따라서 정책 정보와 타 M2M 장치의 정보를 조회하여 권한 여부를 확인할 수 있다. 접근 권한은 보안 개체에 대한 접근 권한과 어플리케이션 개체에 대한 접근 권한이 동일 또는 다르게 설정될 수 있다. 또는 접근 권한은 요청 메시지가 생성, 변경, 삭제, 활성화/비활성화 및 조회 중 어느 동작을 요구하는 지에 따라서 다르게 설정될 수도 있다. 또한, 접근 권한은 프로파일 정보 또는 정책 정보를 변경하는 경우에도 구분되어 설정될 수 있다.

제어부(1610)는 권한 정보를 확인하고, 요청 메시지에서 요청하는 정보를 확인하여 어플리케이션 개체에 대한 조회, 생성, 삭제 및 업데이트 동작을 필요에 따라 수행하고, 프로파일 정보 또는 정책 정보의 변경 동작을 수행할 수 있다.

이 외에도 제어부(1610)는 보안 개체의 접근 권한 확인 동작과 관련된 전반적인 보안 개체 동작을 제어할 수 있다.

한편, 수신부(1630)는 요청 메시지를 수신하고, 송신부(미도시)는 요청 결과에 대한 정보를 타 M2M 장치로 제공할 수 있다. 수신부(1630)와 송신부는 보안 개체(예를 들어, 프로세서)와 구분되어 M2M 장치에 구분될 수 있으며, 이 경우에는 보안 개체와 연동되어 동작할 수 있다.

전술한 실시예에서 언급한 표준내용 또는 표준문서들은 명세서의 설명을 간략하게 하기 위해 생략한 것으로 본 명세서의 일부를 구성한다. 따라서, 위 표준내용 및 표준문서들의 일부의 내용을 본 명세서에 추가하거나 청구범위에 기재하는 것은 본 발명의 범위에 해당하는 것으로 해석되어야 한다.

이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 발명의 기술사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (15)

1. M2M(Machine to Machine communication) 장치의 보안 개체가 접근 제어 동작을 수행하는 방법에 있어서,
   타 M2M 장치로부터 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 접근을 요청하는 요청 메시지를 수신하는 단계;
   상기 접근 요청에 대한 접근 권한을 확인하는 단계; 및
   상기 타 M2M 장치의 상기 어플리케이션 개체에 대한 접근 권한이 확인되는 경우, 상기 요청 메시지에 기초하여 상기 어플리케이션 개체 또는 프로파일 자원에 대한 조회, 생성, 삭제 및 업데이트 중 적어도 하나의 동작을 처리하는 단계를 포함하는 방법.
2. 제 1 항에 있어서,
   상기 요청 메시지는,
   상기 보안 개체에 대한 식별정보, 상기 타 M2M 장치에 대한 식별정보 및 상기 보안 개체 내에 구성되는 상기 하나 이상의 어플리케이션 개체에 대한 리스트를 요청하는 정보를 포함하는 방법.
3. 제 1 항에 있어서,
   상기 요청 메시지는,
   상기 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 선택 정보를 포함하며,
   상기 선택 정보는 선택된 어플리케이션 개체에 대한 식별 정보 및 보안 레벨 정보를 포함하는 방법.
4. 제 1 항에 있어서,
   상기 프로파일 자원은,
   상기 보안 개체 내에 저장되며,
   프로파일 유형 정보, 식별정보, 프로파일 생성자의 식별 정보, 프로파일 데이터 및 접근 권한 정보 중 적어도 하나의 정보를 속성 정보로 포함하는 방법.
5. 제 4 항에 있어서,
   상기 요청 메시지가 상기 프로파일 자원에 대한 업데이트 동작을 지시하는 정보를 포함하는 경우,
   상기 프로파일 자원에 대한 활성화 또는 비활성화를 지시하는 정보를 포함하는 방법.
6. 제 1 항에 있어서,
   상기 접근 요청에 대한 권한을 확인하는 단계는,
   상기 보안 개체에 대한 접근 권한 여부를 확인하는 단계; 및
   상기 하나 이상의 어플리케이션 개체 별로 설정되는 접근 권한 여부를 확인하는 단계를 더 포함하는 방법.
7. 제 6 항에 있어서,
   상기 보안 개체에 대한 접근 권한 또는 상기 어플리케이션 개체 별로 설정되는 접근 권한은,
   상기 요청 메시지에 포함되는 동작 파라미터 별로 구분되어 설정되는 방법.
8. 제 1 항에 있어서,
   상기 보안 개체는,
   상기 M2M 장치 내에 둘 이상으로 구분되어 구성되며, 둘 이상으로 구성되는 상기 보안 개체 각각은 둘 이상의 어플리케이션 개체를 포함하는 방법.
9. 접근 제어 동작을 수행하는 M2M(Machine to Machine communication) 장치의 보안 개체에 있어서,
   타 M2M 장치로부터 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 접근을 요청하는 요청 메시지를 수신하는 수신부;
   상기 접근 요청에 대한 접근 권한을 확인하는 접근 권한 확인부; 및
   상기 타 M2M 장치의 상기 어플리케이션 개체에 대한 접근 권한이 확인되는 경우, 상기 요청 메시지에 기초하여 상기 어플리케이션 개체 또는 프로파일 자원에 대한 조회, 생성, 삭제 및 업데이트 중 적어도 하나의 동작을 처리하는 제어부를 포함하는 M2M 장치의 보안 개체.
10. 제 9 항에 있어서,
    상기 요청 메시지는,
    상기 보안 개체에 대한 식별정보, 상기 타 M2M 장치에 대한 식별정보 및 상기 보안 개체 내에 구성되는 상기 하나 이상의 어플리케이션 개체에 대한 리스트를 요청하는 정보를 포함하는 M2M 장치의 보안 개체.
11. 제 9 항에 있어서,
    상기 요청 메시지는,
    상기 보안 개체 내에 구성되는 하나 이상의 어플리케이션 개체에 대한 선택 정보를 포함하며,
    상기 선택 정보는 선택된 어플리케이션 개체에 대한 식별 정보 및 보안 레벨 정보를 포함하는 M2M 장치의 보안 개체.
12. 제 9 항에 있어서,
    상기 프로파일 자원은,
    상기 보안 개체 내에 저장되며,
    프로파일 유형 정보, 식별정보, 프로파일 생성자의 식별 정보, 프로파일 데이터 및 접근 권한 정보 중 적어도 하나의 정보를 속성 정보로 포함하는 M2M 장치의 보안 개체.
13. 제 12 항에 있어서,
    상기 요청 메시지가 상기 프로파일 자원에 대한 업데이트 동작을 지시하는 정보를 포함하는 경우,
    상기 프로파일 자원에 대한 활성화 또는 비활성화를 지시하는 정보를 포함하는 M2M 장치의 보안 개체.
14. 제 9 항에 있어서,
    상기 보안 개체는,
    상기 M2M 장치 내에 둘 이상으로 구분되어 구성되며, 둘 이상으로 구성되는 상기 보안 개체 각각은 둘 이상의 어플리케이션 개체를 포함하는 M2M 장치의 보안 개체.
15. 제 9 항에 있어서,
    상기 접근 권한 확인부는,
    상기 보안 개체에 대한 접근 권한 여부 및 상기 하나 이상의 어플리케이션 개체 별로 설정되는 접근 권한 여부를 각각 확인하는 M2M 장치의 보안 개체.

Images