KR101560072B1

KR101560072B1 - 트랩 이벤트 등록 및 알림 방법 및 이를 채용하는 단말

Info

Publication number: KR101560072B1
Application number: KR1020137017507A
Authority: KR
Inventors: 박승규; 추연성
Original assignee: 엘지전자 주식회사
Priority date: 2011-01-27
Filing date: 2012-01-27
Publication date: 2015-10-13
Anticipated expiration: 2032-01-27
Also published as: WO2012102566A2; EP2651073A2; KR20140033318A; CN103493429A; US9426043B2; CN103493429B; EP2651073A4; EP2651073B1; WO2012102566A3; US20130297789A1

Abstract

TrapMO의 Inward 트랩 및 Outward 트랩과 관련된 보안상의 취약점을 보완할 수 있는 방법. 이를 위해 본 명세서에 개시된 제1 실시 예에 따른 단말상의 다른 기능적 컴포넌트에 트랩을 통지하는 단말의 트랩 동작 제어 방법은, 서버로부터 트랩 등록 요청을 수신하는 단계 여기에서 상기 트랩 등록 요청은, 트랩(trap) 식별자, 서버 식별자 및 타겟 식별자를 포함하고; 상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계; 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 서버 식별자를 상기 트랩 식별자와 연관되게 저장하면서 트랩을 등록하는 단계 여기에서, 상기 트랩은 트랩 이벤트를 포함하고 상기 트랩 식별자와 연관되고; 상기 트랩 이벤트를 감지하는 단계; 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계; 및 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 트랩 이벤트를 상기 실행 가능한 노드에 통지하는 단계를 포함하는 것을 특징으로 한다.

Description

트랩 이벤트 등록 및 알림 방법 및 이를 채용하는 단말{METHOD FOR REGISTERING AND PROVIDING NOTICE OF A TRAP EVENT, AND TERMINAL USING SAME}

본 명세서는 DM 클라이언트에서 트랩 이벤트를 등록하고 트랩 이벤트의 발생을 알리는 방법과 이를 채용하는 단말에 관한 것이다.

휴대용 단말 관리를 위한 대표적인 기술로 OMA(Open Mobile Alliance)의 장치 관리(DM; Device Management)기술을 들 수 있다. DM은 DM 서버와 DM 클라이언트 사이에 양방향 세션을 열고, 이 세션을 통해서 DM 명령들(Commands)을 주고 받음으로써 단말 관리를 하게 된다. 이러한 DM 세션을 열기 위해서 DM 클라이언트가 DM 서버에게 Package 1을 통해 세션을 시작할 수 있고, 반대로 DM 서버가 단말 관리가 필요하다고 판단할 경우, Package 0이라 불리는 DM 알림(Notification)을 보내서 DM 클라이언트에게 DM 세션을 요청할 수도 있다. DM 클라이언트는 DM 서버로부터 DM 알림(Notification)을 받은 경우, DM 서버에게 Package 1을 보내 DM 세션을 시작할 수 있다.

비록 DM 세션은 양방향 세션이지만, 이를 통해 주고 받게 되는 DM 명령들(Commands)은 비대칭적인 특성을 갖는다. 즉 DM 서버는 DM 클라이언트에게 모든 DM 명령을 보낼 수가 있지만, DM 클라이언트는 DM 서버의 장치 정보(DevInfo)/장치 상세 정보(DevDetail 정보)를 바꾸는 변경(Replace) 명령과 결과들(Results), 그리고 경고(Alert)만을 DM 서버에게 보낼 수가 있다.

DM은 Challenge-Credential에 기반한 사용자 인증 프레임워크를 제공한다. 이 프레임워크는 DM 서버와 DM 클라이언트가 서로를 인증할 수 있는 양방향 인증 서비스를 제공하며, MD5, HTTP-Digest, Basic Authentication 등 다양한 인증 메커니즘을 사용할 수 있도록 해준다. 이 인증 방법을 사용하면, 먼저 인증을 요청하는 쪽이 Challenge를 상대방에게 보내게 된다. DM은 앞서 말한 것처럼 양방향 인증이기 때문에 DM 클라이언트, DM 서버 모두가 Challenge를 보낼 수가 있다. Challenge를 받은 상대방은 자신의 Credential 정보를 보내주어야 하며, 이 Credential을 받아보고 상대방을 인증하게 된다.

DM은 단말을 관리하기 위한 일종의 프레임워크이며, 휴대용 단말 관리에서 대표적으로 논의되는 소프트웨어 관리, 이벤트 모니터링, 보안을 위한 잠금 기능 등은 별도의 관리 객체(MO; Management Object) 에서 다루어지게 된다. 대표적인 MO로는 단말에 설치되는 소프트웨어 관리 기능을 갖고 있는 SCOMO(Software Component Management Object; 소프트웨어 컴포넌트 관리 객체), 원격으로 단말의 기능을 잠그고 풀 수 있는 LAWMO(Lock And Wipe Management Object; 잠금 및 해제 객체), 단말에 원격으로 프로세스를 구성하여, 천이(transaction)를 수행할 수 있는 SACMO(Software and Application Control Management Object; 소프트웨어 및 애플리케이션 제어 관리 객체), 방화벽 및 NAT 등으로 인해 DM 서버와 DM 클라이언트가 직접적인 연결이 불가능할 때, 장치 관리를 할 수 있도록 해주는 GwMO(Gateway Management Object) 등이 있다.

위에서 언급되지 않는 대표적인 MO로 TrapMO(Trap Management Object)를 들 수가 있는데, TrapMO는 모바일 디바이스의 이벤트를 모니터링하고 관련 정보를 보고하기 위한 기능을 수행한다. 이러한 모니터링 이벤트의 종류로는 콜 셋업 실패(call setup failure), 배터리 레벨(battery level), RF 손실(RF loss), 메모리 사용 레벨(memory usage level), DM 계정 수정(DM Account modified), 외부 저장소 부착(external storage attached), S/W 또는 H/W 결함(S/W or H/W faults) 등을 들 수 있다. 이렇게 단말의 상태를 모니터링하고 보고하는 기능은 매우 유용한데, 예로 RF 손실(RF loss)을 모니터링하는 기능은 기지국의 커버리지(coverage)를 개선하는데 큰 도움을 줄 수 있다.

단말 안에서 각각의 트랩(Trap) 이벤트는 고유의 트랩 식별 정보(Trap ID)를 가지고 구분이 된다. 여기에서, 트랩은 실행중인 프로그램에서 발생하는 이벤트를 검출하기 위해 특별한 조건을 걸어 놓은 것을 의미할 수 있다. 예를 들어, DM 서버가 DM 클라이언트의 특정 트랩 이벤트(trap_event1)를 모니터링하기 위해서는 등록(registration)과 알림(notification)이라는 두 가지 단계를 거쳐야 한다. 등록(registration)은 DM 서버가 특정 이벤트(trap_event1)을 모니터링하기 위해 DM 클라이언트에게 모니터링 등록을 요청하는 단계이며, 알림(notification)은 DM 클라이언트가 해당 이벤트(trap_event1)가 발생하였을 경우, 관련 정보를 DM 서버에 보고하는 단계이다.

TrapMO는 단말의 이벤트를 모니터링하는 기능을 제공하는데, 해당 이벤트가 발생하였을 경우, 어디로 이벤트 관련 정보를 보고할 것인지에 따라 내부(Inward)와 외부(Outward) 타입으로 나눌 수가 있다. Outward 타입의 트랩은 단말에서 해당 이벤트가 발생하였을 경우, 발생한 이벤트에 관한 정보를 단말의 외부 서버로 전달하는 트랩이다. 이 때 외부 서버는 단말에 트랩 이벤트를 등록한 DM 서버 자신일 수도 있고, 제 3자의 DM 서버일 수도 있다. Inward 타입의 트랩은 발생한 트랩 이벤트에 관한 정보가 외부 서버로 전달되는 것이 아니고, 단말 내부의 다른 컴포넌트로 전달되는 트랩이다.

본 명세서에 개시된 실시 예들은 전술한 문제점을 해결하기 위한 것으로서, TrapMO의 Inward 트랩 및 Outward 트랩과 관련된 보안상의 취약점을 보완할 수 있는 방법을 제공하는 것을 목적으로 한다.

상기 기술적 과제를 해결하기 위한 본 명세서에 개시된 제1 실시 예에 따른 단말상의 다른 기능적 컴포넌트에 트랩을 통지하는 단말의 트랩 동작 제어 방법은, 서버로부터 트랩 등록 요청을 수신하는 단계 여기에서 상기 트랩 등록 요청은, 트랩(trap) 식별자, 서버 식별자 및 타겟 식별자를 포함하고; 상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계; 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 서버 식별자를 상기 트랩 식별자와 연관되게 저장하면서 트랩을 등록하는 단계 여기에서 상기 트랩은 트랩 이벤트를 포함하고 상기 트랩 식별자와 연관되고; 상기 트랩 이벤트를 감지하는 단계; 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계; 및 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 트랩 이벤트를 상기 실행 가능한 노드에 통지하는 단계를 포함하는 것을 특징으로 한다.

일 실시 예에 있어서, 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계는, 접근 제어 리스트(ACL; Access Control List)에 기초하여, 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계인 것을 특징으로 한다.

또한 일 실시 예에 있어서, 상기 트랩을 등록하는 단계는, 상기 트랩 식별자와 연관된 트랩의 서브-트리(sub-tree)를 추가하는 단계를 포함하고, 상기 서브-트리(sub-tree)는, 상기 실행 가능한 노드를 지시하는 타겟 식별자와 상기 서버 식별자를 포함하는 것을 특징으로 한다.

또한 일 실시 예에 있어서, 제3 항에 있어서, 상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계는, 상기 서버가 상기 실행 가능한 노드의 실행 권한과 함께 서브-트리를 생성할 수 있는 추가 권한이 있는지 확인하는 단계를 포함하는 것을 특징으로 한다.

또한 일 실시 예에 있어서, 상기 트랩 동작 제어 방법은, 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있찌 않으면, 상기 서버에 등록 실패를 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 한다.

또한 일 실시 예에 있어서, 상기 트랩 동작 제어 방법은, 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있지 않으면, 상기 트랩의 등록을 해제하는 단계를 더 포함하는 것을 특징으로 한다.

또한 일 실시 예에 있어서, 상기 트랩 동작 제어 방법은, 상기 저장된 서버 식별자에 의해 식별되는 서버에 상기 트랩의 등록이 해제되었음을 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 한다.

한편, 상기 기술적 과제를 해결하기 위한 본 명세서에 개시된 제1 실시 예에 따른 단말은, 서버로부터 트랩 등록 요청을 수신하는 송수신부 여기에서 상기 트랩 등록 요청은, 트랩(trap) 식별자, 서버 식별자 및 타겟 식별자를 포함하고; 및 상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하고, 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 서버 식별자를 상기 트랩 식별자와 연관되게 저장하면서 트랩을 등록하고, 여기에서 상기 트랩은 트랩 이벤트를 포함하고 상기 트랩 식별자와 연관되고, 상기 트랩 이벤트를 감지하고, 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 컨트롤러를 포함하고, 상기 송수신부는, 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 트랩 이벤트를 상기 실행 가능한 노드에 통지하는 것을 특징으로 한다.

다른 한편, 상기 기술적 과제를 해결하기 위한 본 명세서에 개시된 제2 실시 예에 따른 서버에 트랩을 통지하는 단말의 트랩 동작 제어 방법은, 서버로부터 트랩 등록 요청을 수신하는 단계 여기에서 상기 트랩 등록 요청은 트랩 식별자 및 상기 트랩이 통지되는 서버의 식별자를 포함하고; 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식별자와 동일한지 확인하는 단계; 및 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식별자와 동일하면, 상기 트랩 식별자와 연관된 트랩을 등록하는 단계를 포함하는 것을 특징으로 한다.

일 실시 예에 있어서, 상기 트랩 동작 제어 방법은, 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식별자와 동일하지 않으면, 상기 단말에 트랩 등록 요청을 송신한 서버에 등록 실패를 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 한다.

또 다른 한편, 상기 기술적 과제를 해결하기 위한 본 명세서에 개시된 제2 실시 예에 따른 서버에 트랩을 통지하는 단말은, 서버로부터 트랩 등록 요청을 수신하는 송수신부 여기에서 상기 트랩 등록 요청은 트랩 식별자 및 상기 트랩이 통지되는 서버의 식별자를 포함하고; 및 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식별자와 동일한지 확인하고, 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식별자와 동일하면, 상기 트랩 식별자와 연관된 트랩을 등록하는 컨트롤러를 포함하는 것을 특징으로 한다.

본 발명에 따르면, DM 서버가 Inward 트랩을 이용하여 단말의 특정 이벤트를 모니터링 시, 이벤트 발생의 결과로 수행되는 명령에 대해 DM 서버가 적절한 권한을 가지고 있다는 것을 보장할 수 있다.

또한, 본 발명에 따르면, DM 트리의 런타임 속성인 ACL이 변하더라도, DM 서버가 Inward 트랩을 이용해 단말에 수행하는 명령이 변경된 DM 트리의 ACL을 반영하여 적합함을 보장할 수가 있다.

또한, 본 발명에 따르면, DM 서버가 Outward 트랩을 이용하여 단말의 특정 이벤트를 모니터링 시, 발생 이벤트의 정보가 DoS 공격 등에 악용될 수 있는 가능성을 크게 줄일 수 있다.

또한, 본 발명에 따르면, DM 서버가 outward 트랩을 이용하여 단말의 특정 이벤트를 모니터링 시, 발생 이벤트의 정보가 이를 원하지 않는 DM 서버에게 전달되는 것을 막을 수 있다.

도 1은 본 명세서에 개시된 실시 예들에 따른 장치 관리 아키텍쳐를 나타내는 도면이다.
도 2a는 종래 기술에 따른 Outward 트랩의 이벤트 모니터링 과정을 예시적으로 나타내는 흐름도이다.
도 2b는 종래 기술에 따른 Inward 트랩의 이벤트 모니터링 과정을 예시적으로 나타내는 흐름도이다.
도 3은 종래 기술에 따른 트랩 관리 객체 트리(Trap Management Object Tree)의 구조를 나타내는 도면이다.
도 4a는 종래 기술에 따른 Inward 통지를 위한 등록 절차를 도시하는 흐름도이다.
도 4b는 종래 기술에 따른 Inward 통지를 위한 등록 이후, 통지 절차를 도시하는 흐름도이다.
도 5a는 종래기술에 따른 Inward 트랩을 처리하는 방식의 문제점을 나타내는 흐름도이다.
도 5b는 종래기술에 따른 Outward 트랩을 처리하는 방식의 문제점을 나타내는 흐름도이다.
도 6은 종래기술에 따른 TrapMO의 보안을 강화하기 위한 방법을 나타내는 흐름도이다.
도 7은 본 명세서에 개시된 실시 예들에 따른 트랩 관리 객체 트리(Trap Management Object Tree)를 나타내는 도면이다.
도 8a는 본 발명의 제1 실시 예에 따른 Inward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.
도 8b는 본 발명의 제1 실시 예에 따른 Inward 트랩의 알림 시에 보안을 강화하는 과정을 나타내는 흐름도이다.
도 9는 본 발명의 제1 실시 예에 따른 알림 실패 처리 과정을 나타내는 도면이다.
도 10은 본 발명의 제2 실시 예에 따른 Outward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.
도 11a 및 도 11b는 본 발명의 제3 실시 예에 따른 Outward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.
도 12는 본 명세서에 개시된 제1 실시 예에 따른 Inward 트랩 이벤트 등록 과정을 나타내는 흐름도이다.
도 13은 본 명세서에 개시된 제2 실시 예에 따른 DM 계정(Account)을 이용하여 Outward 트랩 이벤트 등록 및 알림 과정을 나타내는 흐름도이다.
도 14는 본 명세서에 개시된 제3 실시 예에 따른 낙관적 알림 제어(Optimistic Notification Control)를 이용한 Outward 트랩 이벤트 등록 및 알림 과정을 나타내는 흐름도이다.
도 15는 본 명세서에 개시된 단말(400) 및 서버(500)의 블록도이다.

이하, 첨부된 도면을 참조하여 본 발명의 특징과 바람직한 실시 예를 구체적으로 설명한다.

도 1은 본 명세서에 개시된 실시 예들에 따른 장치 관리 아키텍쳐를 나타내는 도면이다.

장치관리(DM)는 DM 클라이언트(110) 및 DM 서버(120)를 포함하는 DM 인에이블러(100)에 의해 수행된다.

DM 클라이언트(110)는 OMA(Open Mobile Alliance) 장치 관리 인에이블러에 명시된 DM 클라이언트의 요구사항을 따르는 추상적인 소프트웨어 컴포넌트이다.

DM 서버(120)는 OMA 장치 관리 인에이블러에 명시된 DM 서버의 요구사항을 따르는 추상적인 소프트웨어 컴포넌트이다.

클라이언트-서버 알림(DM-1)은 서버(120)들이 클라이언트(110)들에 장치 관리 알림을 보낼 수 있는 인터페이스를 제공한다. 클라이언트-서버 알림(DM-1)은 중간 운반자이고, WAP 푸쉬 및 SIP 푸쉬와 같은 많은 프로토콜을 통해 동작할 수 있는 인터페이스이다.

장치 관리 클라이언트-서버 프로토콜(DM-2)은 서버(120)들이 클라이언트(110)들에 장치 관리 명령들을 송신하고, 클라이언트(110)들이 서버(120)들에 상태 및 알람을 송신할 수 있는 인터페이스를 제공한다. 장치 관리 클라이언트-서버 프로토콜(DM-2)은 중간 운반자이고, HTTP 및 HTTPS를 포함하는 많은 표준화된 바인딩을 제공하는 인터페이스이다. 이 인터페이스는 무선통신(over-the-air) 장치 관리 성능을 제공하기 위해 무선연결-기반 데이터 전달 프로토콜(예를 들어, GPRS)을 통해 노출된다.

DM 클라이언트(110)는 초기에 스마트 카드(210) 상의 파일을 통해 공급될 수 있다. 이 파일은 DM 클라이언트(110)에서 설정을 셋팅하거나 변경하기 위한 일련의 DM 명령들을 포함한다. 스마트 카드(210)를 통한 DM 부트스트랩 프로파일(DM-3)은 DM 클라이언트(110)로부터의 피드백이 제공되지 않는 단방향의 인터페이스이다. 다음의 실질적인 기회에서 DM 서버(120)에 연결되는 DM 클라이언트(110)가 유일한 기대 결과이다.

DM 클라이언트(110)는 초기에 몇몇 푸쉬 프로토콜에 의해 전송된 파일을 통해 공급될 수 있다. 이 파일은 DM 클라이언트에서 설정을 셋팅하거나 변경하기 위한 DM 명령들을 포함한다. 부트스트랩 프로파일 OTA(DM-4)는 DM 클라이언트(110)로부터의 피드백이 제공되지 않는, OTA 서버(220)에서 DM 클라이언트(110)로의 단방향의 인터페이스이다. 다음의 실질적인 기회에서 DM 서버(120)에 연결되는 DM 클라이언트(110)가 유일한 기대 결과이다.

DM 클라이언트(110)는 초기에 CP 인에이블러(230)를 통해 공급될 수 있다. CP 부트스트랩 프로파일(CP-1)은 DM 클라이언트(110)로부터의 피드백이 제공되지 않는, CP 인에이블러(230)에서 DM 클라이언트(110)로의 단방향의 인터페이스이다. 다음의 실질적인 기회에서 DM 서버(120)에 연결되는 DM 클라이언트(110)가 유일한 기대 결과이다.

도 2a는 종래 기술에 따른 Outward 트랩의 이벤트 모니터링 과정을 예시적으로 나타내는 흐름도이다.

DM 서버(120)는 DM 클라이언트(110)의 제1 트랩 이벤트(trap_event1)를 모니터링하기 위해 DM 클라이언트(110)에 등록한다(S101). 여기에서, DM 서버(120)는 단말에서 발생한 이벤트에 관한 정보를 이벤트를 등록한 DM 서버(120) 자신에게 보내는 Outward 타입의 트랩 이벤트를 DM 클라이언트(110)에 등록할 수 있다.

DM 서버(120)는 또한 DM 클라이언트(110)의 제2 트랩 이벤트(trap_event2)를 모니터링하기 위해 DM 클라이언트(110)에 등록한다(S102). 여기에서, DM 서버(120)는 단말에서 발생한 이벤트에 관한 정보를 이벤트를 등록한 제2 DM 서버(120')에게 보내는 Outward 타입의 트랩 이벤트를 DM 클라이언트(110)에 등록할 수 있다.

DM 클라이언트(110)는 등록된 트랩 이벤트들이 검출되는지 모니터링하고, 제1 트랩 이벤트(trap_event1)가 발생함을 감지할 수 있다(S103).

DM 클라이언트(110)는 제1 트랩 이벤트(trap_event1)의 발생을 이 트랩 이벤트에 등록되어 있는 DM 서버(120)에 통지(notification)한다(S104). 이때 DM 클라이언트(110)는 일반적 경고(Generic Alert)로 관련 정보를 DM 서버(120)에게 전달하며, 일반적 경고(Generic Alert)에는 메타 타입(Meta.Type), 메타 포맷(Meta.Format), 소스 위치 URI(Source.LocURI), 데이터(Data) 등이 설정될 수 있다. Meta.Type은 urn:oma:mo:diagmon:1.0:TrapNotification으로 설정되어 본 일반적 경고(Generic Alert) 메시지가 트랩 이벤트 통지라는 것을 표시하고, 메타 포맷(Meta.Format)은 "chr"로 표시되며, 소스 위치 URI(Source.LocURI)는 발생한 트랩 이벤트와 연결되어 있는 TargetServer/＜x＞/ServerID의 주소를 표시한다. 또한, 데이터(Data)는 트랩 식별자(trap identifier)를 포함하여, 어떤 트랩 이벤트가 발생하였는지를 알려준다.

DM 클라이언트(110)는 계속하여 등록된 트랩 이벤트들이 검출되는지 모니터링하고, 제2 트랩 이벤트(trap_event2)가 발생함을 감지할 수 있다(S105).

DM 클라이언트(110)는 제2 트랩 이벤트(trap_event2)의 발생을 이 트랩 이벤트에 등록되어 있는 제2 DM 서버(120')에게 통지(notification)한다(S106). 이때 DM 클라이언트(110)는 일반적 경고(Generic Alert)로 제2 트랩 이벤트(trap_event2)의 발생 관련 정보를 제2 DM 서버(120')에게 전달하며, 기타 필요한 정보(전술한 메타 타입(Meta.Type), 메타 포맷(Meta.Format), 소스 위치 URI(Source.LocURI), 데이터(Data) 등)도 이때 같이 전달한다.

이와 같은 Outward 트랩을 통해 DM 서버(120)는 DM 클라이언트(110)에서 발생하는 이벤트를 모니터링하여 결과를 자신에게 보내게 하거나 다른 서버에게 보내게 할 수가 있다.

도 2b는 종래 기술에 따른 Inward 트랩의 이벤트 모니터링 과정을 예시적으로 나타내는 흐름도이다.

전술한 바와 같이, Inward 트랩은 Outward 트랩에서와 같이 발생한 이벤트의 결과를 외부 DM 서버(120)에게 전달하는 것이 아니라, 내부의 다른 기능적 컴포넌트에게 전달하는 트랩이다.

DM 서버(120)는 DM 클라이언트(110)의 SCOMO(Software Component Management Object)(304)에게 패키지(PKG1)를 다운로드 하도록 DM 명령(Command)을 보낸다(S111). 여기에서, DM 명령은 특정 노드(예를 들어, 'SCOMO/Download/PKG1/Operations/Download')에 실행(Exec) 명령을 전달하는 것을 의미한다.

DM 클라이언트(110)의 SCOMO(304)는 DM 서버(120)로부터 제111 단계에서 수신한 실행(Exec) 명령에 따라 패키지(PKG1)의 다운로드를 시작한다(S112).

DM 서버(120)는 DM 클라이언트(110)가 로우 배터리(Low Battery) 상태가 되면, 패키지(PKG1)의 다운로드 프로세스를 자동으로 취소하기 위해, DM 클라이언트(110)의 TrapMO(Trap Mobile Object)(302)에 Inward 트랩을 등록한다(S113). 이 Inward 트랩이 등록됨에 따라, DM 클라이언트(110)는 트랩 이벤트(trap_event1; Low_Battery)가 발생하면, 해당 이벤트 정보를 특정 노드(예를 들어, 'SCOMO/Download/PKG1/Operations/Stop')에 보내게 된다.

DM 클라이언트(110)는 등록된 트랩 이벤트의 발생을 모니터링하고, 트랩 이벤트(trap_event1; Low_Battery)의 발생을 감지한다(S114).

TrapMO(302)는 트랩 이벤트(trap_event1; Low_Battery)가 발생하면, 이 이벤트에 등록되어 있는 Inward 통지(notification)를 검색하고, 해당 노드에 실행(Exec) 명령을 보낸다(S115). 여기에서, 해당 노드는 DM 서버(120)가 Inward 트랩을 등록할 때 DM 클라이언트(110)에 전달한 것으로서, 본 실시 예에서는 'SCOMO/Download/PKG1/Operations/Stop'를 말한다.

SCOMO(304)는 TrapMO(302)로부터 실행(Exec) 명령을 수신하여, 패키지(PKG1)의 다운로드를 취소한다(S116).

이와 같은 Inward 트랩을 이용하여, DM 서버(120)는 별도의 메시지 없이, 해당 단말의 DM 클라이언트(110)에서 이벤트가 발생했을 때, 이벤트 발생에 관한 정보를 단말 내부의 다른 컴포넌트에 전달하여 이벤트 발생에 따른 적절한 처리가 이루어지게 할 수 있다. 본 실시 예에서는, DM 서버(120)가 DM 클라이언트(110)에 소프트웨어 패키지(PKG1)의 다운로드를 명령하고, 단말이 저전력(Low_Powered) 상태로 진입할 경우, 배터리 소모를 줄이기 위해 패키지(PKG1)의 다운로드를 취소하는 명령을 TrapMO를 사용해 용이하게 처리할 수 있다.

전술한 바와 같이, 트랩의 두 가지 종류인 Inward 트랩과 Outward 트랩은 모두 등록(Registration)과 알림(Notification)의 두 과정으로 구분할 수 있다. 이 등록과 알림은 모두 트랩 관리 객체 트리(Trap Management Object Tree)를 통해서 처리되는데, 이 TrapMO Tree를 통해 어떻게 Inward 트랩 이벤트와 Outward 트랩 이벤트가 처리되는지 구체적으로 설명한다.

도 3은 종래 기술에 따른 트랩 관리 객체 트리(Trap Management Object Tree)의 구조를 나타내는 도면이다.

예를 들어, DM 서버(120)가 DM 클라이언트(110)에 트랩 이벤트(trap_event1)를 Inward 타입으로 등록하는 상황을 가정한다. 트랩 이벤트(trap_event1)가 발생하면, TrapMO는 발생한 이벤트에 관한 정보를 특정 URI(URI1)에 전달한다. 이러한 Inward 트랩 이벤트를 등록하기 위해서, DM 서버(120)는 DM 클라이언트(110)의 TrapMO 인스턴스 중에서 TrapID가 trap_event1인 TrapMO의 인스턴스를 검색한다. DM 서버(120)는 DM 클라이언트(110)의 TrapMO 서브 트리를 순회(traverse)하며, 해당 인스턴스를 검색할 수 있고, 또는 아래의 표1과 같은 상대 주소(relative address)를 통해 해당 트랩 인스턴스를 가리킬 수 있다.

전술한 방식으로 DM 서버(120)가 TrapMO의 인스턴스를 발견하면, 그 인스턴스의 자식 노드 중에서 TargetURI를 찾아 그 아래에 새로운 Inward 트랩인 URI(URI1)를 추가한다.

이와 같은 방식으로 Inward 트랩의 등록이 완료되면, TrapMO는 해당 트랩 이벤트(trap_event1)가 발생하였을 때 해당 컴포넌트에 알림(notification)을 수행한다. DM 클라이언트(110)는 트랩 이벤트(trap_event1)의 발생을 모니터링하고 있다가, 트랩 이벤트(trap_event1)의 발생이 감지되면, TrapID가 trap_event1인 TrapMO의 인스턴스를 검색한다. 대안적으로, DM 클라이언트(110)는 전술한 상대 주소(relative addressing)를 재사용할 수도 있다. DM 클라이언트(110)는 TrapMO의 인스턴스가 발견되면, TargetURI 밑에 등록되어 있는 모든 URI에 대해서 URI 노드의 값이 가리키는 노드에 실행(Exec) 명령을 보낸다. 이에 따라, Inward 통지 과정이 완료된다.

이제 반대로, DM 서버(120)가 DM 클라이언트(110)에 트랩 이벤트(trap_event1)를 Outward 타입으로 등록하는 과정을 설명한다. 이하에서는, DM 서버(120)가 DM 클라이언트(110)의 트랩 이벤트(trap_event1)를 모니터링하기 위해, 발생한 이벤트를 다른 DM 서버('DMS1')에 전달하는 상황을 가정한다. 먼저 Outward 트랩 이벤트 등록을 위해 DM 서버(120)는 DM 클라이언트(110)의 TrapMO 인스턴스 중에서 TrapID가 'trap_event1'인 인스턴스를 검색한다. 이 과정에서 위에서 기술한 상대 주소(relative addressing)가 사용될 수도 있다. DM 서버(120)는 이 TrapMO 인스턴스가 발견되면, 'ToRef/TargetServer' 노드 밑에 자식 노드로 다른 DM 서버의 식별 정보('DMS1')를 추가하고 이에 따라 등록 과정이 완료된다.

Outward 트랩 등록이 완료되고, DM 클라이언트(110)는 해당 Trap 이벤트(trap_event1)가 발생하였을 경우, 다른 DM 서버('DMS1')에게 알려주는 알림(notification)을 수행하면 된다. 이 과정을 위해 DM 클라이언트(110)는 트랩 이벤트를 모니터링하고 있다가, 트랩 이벤트(trap_event1)의 발생을 감지하게 되고, 감지 후 TrapMO 중에서 TrapID가 trap_event1인 TrapMO 인스턴스를 검색한다. DM 클라이언트(110)는 발견된 TrapMO 인스턴스 서브 트리에서 'ToRef/TargetServer' 밑에 등록되어 있는 모든 'ServerID'에 대해서 트랩 이벤트(trap_event1)에 대한 정보를 전달해 준다. 본 전달은 일반적 경고(Generic Alert)를 사용하여 전달된다. 이 과정에서 다른 DM 서버('DMS1')는 'ToRef/TargetServer' 밑에 'ServerID'로 등록 과정에서 추가되었기 때문에, DM 클라이언트로(110)로부터 트랩 이벤트(trap_event1)에 대한 정보를 전달 받게 된다.

TrapMO의 Inward 트랩은 단말에 불특정 DM 명령(Command)을 수행할 수 있기 때문에, 잠재적인 보안 위험이 존재한다. 이러한 보안 문제에 따른 위험을 막기 위해서는, Inward 트랩의 등록(registration)과 알림(notification) 과정에서 적절한 권한을 가지고 있는 DM 서버(120)만이 해당 과정을 수행해야만 한다. 즉, Inward 트랩에 대한 등록은 등록 권한을 갖고 있는 DM 서버(120)만이 할 수 있고, Inward 트랩이 추후 알림 과정(notification process)을 통해 특정 동작(operation)을 수행할 때는 그 Inward 트랩을 등록한 DM 서버(120)가 실행 권한을 가지고 있어야만 한다.

하지만 종래의 트랩 프레임워크에서는 이러한 Inward 트랩의 보안 문제를 다루고 있지 않다. 이는 Inward 트랩의 등록과 알림 과정에서, 종래의 트랩 프레임워크는 등록 과정에 대한 DM 서버(120)의 권한 확인만을 수행하기 때문이다. 이러한 트랩 프레임워크의 보안상의 결함은 TrapMO 자체의 문제에 기인하기 보다는, TrapMO가 의존하고 있는 DM 보안 모델(security model) 문제점이 내제되어 있기 때문이다.

도 4a는 종래 기술에 따른 Inward 통지를 위한 등록 절차를 도시하는 흐름도이다.

성공적인 등록을 위해, DM 클라이언트(110)는 DM 서버(120)로부터 Inward 통지를 위한 등록 요청을 수신했을 때(S121), 등록을 수행하는 DM 서버(120)가 해당하는 TrapMO 인스턴스의 'ToRef/TargetURI'에 추가(Add) 명령을 수행할 수 있는 권한이 있는지 확인하게 된다(S122). 즉, DM 클라이언트(110)는 Inward 통지를 위한 등록을 수행하는 데에 적합한 권한이 있는지 확인하는 과정을 수행한다.

제122 단계에서, DM 서버(120)가 해당하는 노드에 추가 권한이 있으면, Inward 통지를 위한 노드를 추가함으로써(S123) 등록이 성공적으로 완료된다(S124). 그러나, 제122 단계에서, DM 서버(120)가 해당하는 노드에 추가 권한이 없으면, 등록이 실패한다(S125).

도 4b는 종래 기술에 따른 Inward 통지를 위한 등록 이후, 통지 절차를 도시하는 흐름도이다.

제131 단계 내지 제135 단계를 참조하여 알 수 있는 바와 같이, DM 클라이언트(110)는 발생한 Inward 트랩에 대해, 해당하는 트랩 이벤트를 지정된 노드에 전달하고 실행하면서, 별도의 권한 검사를 하지 않고 있다. 전술한 바와 같이, 이러한 문제점은 TrapMO 자체의 문제라기 보다는, TrapMO가 의존하고 있는 DM의 보안 모델(security model)이 가지고 있는 문제점에 기인한다.

즉, DM 보안 모델(security model)에 따르면, DM 클라이언트(110)는 DM 명령(Command)을 수행하기 전에 DM 명령(Command)을 수행하는 주체를 파악하고, 해당 주체가 DM 명령(Command) 수행에 필요한 권한을 가지고 있는지 검사하게 된다. 이러한 보안 검사는 Inward 트랩의 등록 과정에 적용되어, 등록을 수행하는 DM 서버(120)가 모니터링하려는 트랩 이벤트와 연관된 TrapMO 인스턴스에 추가(Add)할 수 있는 권한이 있는지 확인함으로써, DM 서버(120)가 등록에 필요한 권한을 가지고 있음을 보장하게 된다. 하지만 알림 (notification) 과정에서는 발생한 이벤트 정보를 지정되어 있는 노드에게 전달해주는 주체는 TrapMO 인에이블러(Enabler)이고, 실제로 그 명령을 수행하는 주체는 이벤트 정보를 받는 기능 컴포넌트(functional component)가 된다. 따라서 Inward 트랩에 등록되어 있는 명령을 수행하는 주체가 DM 서버(120)가 아닌 것이다. 이러한 Inward 트랩의 알림 과정의 특성은 종래의 DM 보안 모델(Security model)에 의존해서는 Inward 트랩의 보안 문제가 해결되지 않는다는 것을 뜻한다.

도 5a는 종래기술에 따른 Inward 트랩을 처리하는 방식의 문제점을 나타내는 흐름도이다.

이 예시적인 실시 예에서, DM 서버(120)는 디바이스를 재시작(restart)할 수 있는 권한은 없고(이 예제에서는 'DiagMonMO/Restart/Operations/Start'에 대한 실행(Exec) 권한이 없음), 모니터링하고자 하는 해당 TrapMO 인스턴스에는 추가(Add)할 수 있는 권한을 가지고 있다고 가정한다.

DM 서버(120)는 DM 클라이언트(110)의 트랩 이벤트(trap_event1; WiFi_Connected) 이벤트를 모니터링하기 위해 등록을 요청하는 DM 명령을 보낸다(S141). 이 때, DM 서버(120)는 트랩 이벤트가 'DiagMonMO/Restart/Operations/Start'에 알림(notification)이 보내지도록 Inward 트랩을 등록한다.

DM 클라이언트(120)는 트랩 이벤트(trap_event1; WiFi_Connected)를 모니터링한다. Wifi가 연결되면(WiFi_Connected)(S142), DM 클라이언트(120)는 트랩 이벤트(trap_event1; WiFi_Connected)가 발생했음을 감지한다(S143).

TrapMO(302)는 Inward 트랩이 발생함에 따라, 'DiagMonMO/Restart/Operations/Start'로 발생한 트랩 이벤트에 관한 정보를 전달한다(S144).

DiagMonMO(Diagnostic and Monitoring Management objects)(306)는 받은 명령에 따라서, 단말을 재시작(restart)한다(S145).

상기 실시 예에서 알 수 있듯이, DM 클라이언트(110)를 재시작(restart)할 권한이 없는 DM 서버(120)는 단지 TrapMO의 하위 트리에 추가(Add)할 수 있는 권한만을 가지고 있음에도 불구하고 단말을 재시작(restart)할 수 있다. 그리고 이는 심각한 보안 위험이 될 수 있다.

반면에, Outward 트랩은 DM 서버(120)가 DM 클라이언트(110)에 트랩 이벤트 모니터링을 등록할 때, 이벤트 발생을 보고하는 서버를 어떤 서버이든지 지정할 수 있다. 이러한 특징은 OMA DM 서비스를 하기 위해 DM 서버(120)를 구성하는데 있어 확장성과 유연성을 높여주는 장점이 있다. 즉, 트랩 이벤트에 등록을 수행하는 DM 서버(120)와 트랩 이벤트를 모니터링하는 DM 서버(120)를 따로 분리하여 확장성과 유연성을 높일 수 있다. 하지만 이러한 Outward 트랩의 기능에는 한가지 단점이 있는데, 트랩 이벤트를 모니터링할 의도가 없는 다른 DM 서버가 트랩 이벤트를 받도록 설정이 가능하다는 것이다.

이러한 Outward 트랩의 단점은 보안상의 취약점으로 이어지는데, 단순하게는 트랩 이벤트를 받기 원하지 않는 DM 서버(120)에 트랩 이벤트를 보낼 수 있다는 것이고, 크게는 다수의 단말에 Outward 트랩을 등록하여, 특정 DM 서버(120)가 받도록 설정하면, 해당 DM 서버(120)는 매우 많은 트랩 이벤트를 받게 되어, DoS(Denial of Service) 공격에 악용될 가능성이 있다.

도 5b는 종래기술에 따른 Outward 트랩을 처리하는 방식의 문제점을 나타내는 흐름도이다.

제1 DM 서버(120)는 제1 DM 클라이언트(110)의 'trap_event1'에 Outward 트랩을 등록하며, 발생한 이벤트에 관한 정보를 제2 DM 서버(120')에 전달하도록 설정한다(S151). 마찬가지로, 제1 DM 서버(120)는 제2 DM 클라이언트(110')의 'trap_event1'에도 Outward 트랩을 등록하며, 발생한 이벤트에 관한 정보를 제2 DM 서버(120')에 전달하도록 설정한다(S152).

제1 DM 클라이언트(110) 및 제2 DM 클라이언트(110')는 각각 트랩 이벤트(trap_event1)를 감지한다(S153, S155).

트랩 이벤트(trap_event1)를 감지한 제1 DM 클라이언트(110) 및 제2 DM 클라이언트(110')는 각각 발생한 트랩 이벤트에 관한 정보를 제2 DM 서버(120')에 전달한다(S154, S156).

이 예시적인 실시 예에서 알 수 있듯이, DM 서버(120)는 Outward 트랩을 이용하여 트랩 이벤트를 원하지 않는 DM 서버(120)에 이벤트를 전달할 수 있으며, 나아가 DoS 공격에 이용할 수가 있다.

도 6은 종래기술에 따른 TrapMO의 보안을 강화하기 위한 방법을 나타내는 흐름도이다.

이와 같은 문제를 해결하기 위한 하나의 시도로서, 발명의 명칭이 "System and method for device management security of trap management object"인 미국 특허 공개 번호 US2010/0121967는 TrapMO의 보안을 강화하기 위해 새로운 방법을 제안하였다. 제안된 방법은 Inward 트랩 등록 시, 기존에 수행하던 DM 서버(120)가 해당 Inward 트랩을 등록할 권한이 있는지 확인(S162)함과 동시에, Inward 트랩으로 인해 수행하게 될 명령을 실행할 권한이 있는지 추가로 확인(S164)하고, 등록과 실행 권한을 모두 가지고 있는 DMS에 대해서만 등록을 허용(S165, S167)하는 방법이다.

그러나, 제안된 방법은 TrapMO가 의존하고 있는 OMA DM ACL(Access Control List)의 런타임(runtime) 특징으로 인해 문제점을 갖게 된다. DM에서는 각각의 노드가 ACL 속성을 갖도록 규정하고 있는데, ACL 속성은 해당 노드에 DM 서버(120)가 어떤 명령 권한을 가지고 있는지 나타낸다. 문제는 이러한 노드의 ACL이 런타임 특성을 갖기 때문에, 바뀔 수 있다는 점이다. 따라서 등록 과정에서 실행권한을 동시에 가지고 있어 등록을 허가한다고 해도, 추후에 바뀐 ACL로 인해 실행 권한을 잃어버리게 된다. 또 이러한 취약점을 이용하면, 처음에는 실행 권한을 가지고 있는 명령을 Inward 트랩으로 등록하고, 나중에 해당 명령을 권한이 없는 다른 명령으로 바꾸게 되면, DM 서버(120)가 실행권한이 없는 명령을 실행할 수 있게 된다.

제안된 방법의 또 다른 문제점은 Outward 트랩이 가지고 있는 보안 약점에 대한 개선 방법을 포함하고 있지 않기 때문에, Outward 트랩을 이용해 허가되지 않는 트랩 이벤트를 전달하여 민감한 단말의 정보를 외부에 노출하거나, 트랩 이벤트를 받기 원치 않는 DM 서버(120)에게 이벤트를 전달하거나, 나아가서 DoS 공격에 악용할 소지가 있는 점이다.

따라서, 본 발명의 실시 예들은 TrapMO의 Iinward 트랩 및 Outward 트랩과 관련된 보안상의 취약점을 보완할 수 있는 방법을 제공한다. 이를 위해, 본 발명의 실시 예들은 Inward 트랩과 Outward 트랩 각각에 대한 보안 강화 방법을 제공한다.

Inward 트랩에 대해서는 DM 서버(120)가 DM 클라이언트(110)에 대해 Inward 트랩 등록을 수행하고, 이벤트가 실제 발생하여 등록되어 있는 명령이 수행될 때, 권한을 가지고 있는 DM 서버(120)만이 명령을 수행할 수 있는 방법을 제시한다. 이때, DM 트리의 런타임 속성인 ACL이 변하더라도, 이를 반영하여 명령 수행 여부를 결정할 수 있는 방법을 제시한다.

Outward 트랩과 관련하여 Outward 트랩의 보안을 강화하는 2가지 방법을 제시한다. 첫 번째 방법은, Outward 트랩 등록 시 DM 클라이언트(110)의 DM 계정(Account) 정보를 이용하여 DM 클라이언트(110)가 부트스트랩(bootstrap)되어 있어 신뢰할 수 있는 DM 서버(120)들에 대해서만 이벤트를 수신할 수 있도록 허용하는 방법이다. 두 번째 방법은 낙관적 통지 제어(Optimistic Notification Control)로써, 보안에 위배되는 Outward 트랩의 시도가 낮을 때 효율적으로 사용될 수 있는 방법이다.

이하에서는, 본 명세서에 개시된 실시 예들에 따른 TrapMO 보안을 강화하기 위한 방법을 Inward 트랩과 Outward 트랩으로 나누어서 설명한다.

도 7은 본 명세서에 개시된 실시 예들에 따른 트랩 관리 객체 트리(Trap Management Object Tree)를 나타내는 도면이다.

종래 기술에 따른 트랩 관리 객체 트리와 비교하여, 본 명세서에 개시된 실시 예들에 따른 트랩 관리 객체 트리는 'ToRef/TargetURI/＜x＞/RegisteredServerID' 노드를 더 포함한다. 이 노드에는 해당 트랩 이벤트를 등록한 DM 서버(120)의 서버 식별 정보가 저장된다. 등록 이후에 트랩 이벤트가 발생하면, DM 클라이언트(110)는 트랩 이벤트에 저장된 서버 식별 정보를 참조하여, 트랩 이벤트를 등록한 DM 서버(120)가 ACL에서 실행(Exec) 권한을 보유하고 있는지 판단함으로써, 런타임을 반영한 보안 문제를 해결할 수 있다.

먼저, Inward 트랩의 보안을 강화하기 위한 방법을 설명한다. 이 방법은 DM 클라이언트(110)가 트랩 이벤트 발생 시, 해당 트랩 이벤트에 등록되어 있는 명령에 Inward 통지(notification)를 전달하고, 명령을 수행하기 전에 동적으로 변하는 ACL 정보를 참고하여 DM 서버(120)가 명령 수행에 필요한 권한을 가지고 있는지 판단하는 것이다.

여기에서 사용되는 것처럼, 한 상태에서 다른 상태로의 천이는 한 상태에서 다른 상태로 이행하는 것을 말한다. 사용자가 인식하는 것과 같이 과정은 즉시, 거의 즉시, 점진적 또는 기타 적절한 속도일 수 있다. 과정의 진행은 과정이 일단 활성화되면 사용자와는 무관하게 단말과 같은 장치에 의하여 자동으로 제어될 수 있거나, 또는 사용자에 의하여 제어될 수 있다. 이하에 설명하는 과정 흐름은 특정한 순서로 일어나는 것처럼 보이는 수많은 동작을 포함하지만, 이러한 과정은 직렬로 또는 병렬로(예를 들어, 병렬처리기 또는 멀티 쓰레딩(multi-threading) 환경을 이용하여) 실행 가능한, 더 많거나 적은 동작을 포함할 수 있음을 인식하여야 한다.

도 8a는 본 발명의 제1 실시 예에 따른 Inward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.

이 방법은 DM 서버(120)가 DM 클라이언트(110)에게 특정 트랩 이벤트('trap_event1')를 모니터링하기 위해 등록하는 과정에서, 등록을 수행하는 DM 서버(120)의 식별자(identifier; 'ServerID')를 저장하는 과정을 포함한다. DM 서버(120)의 식별자(identifier)는 DM 서버(120)를 유일하게 지칭하는 것으로, DM 서버(120)의 도메인 이름을 포함할 수 있다. DM 클라이언트(110)는 Inward 트랩에 등록을 수행하는 DM 서버(120)의 'ServerID'(identifier)를 저장하기 전에 저장할 'ServerID'가 올바른 것인지 확인하는 과정을 거쳐야 하는데, 이를 위해 DM 클라이언트(110)가 가지고 있는 DM 계정(Account) 정보를 활용할 수 있다. DM 계정(Account)은 DM 클라이언트(110)가 부트스트랩한 DM 서버(120)의 정보를 저장하고 있으며, 이 중에는 인증 정보 역시 포함되어 있기 때문에, DM 클라이언트(110)는 DM 서버(120)의 'ServerID'가 올바른지(유효한지) 확인하고, 올바르다고(유효하다고)확인된 'ServerID'만을 저장하고 등록을 성공적으로 마치게 된다. 만약 'ServerID'가 올바르지(유효하지)않다면, 등록은 실패하게 된다.

DM 클라이언트(110)는 DM 서버(200)로부터 트랩 이벤트(trap_event1; 모니터링하는 트랩 이벤트의 ID)를 모니터링하기 위한 Inward 트랩 등록 요청을 수신한다(S201). Inward 트랩 등록 요청은 DM 서버(120)가 DM 클라이언트(110)에게 추가(Add) 명령을 보내는 것으로, TrapMO의 인스턴스 중에서 TrapID가 'trap_event1'인 인스턴스를 검색해서 'ToRef/TargetURI' 밑에 추가(Add) 명령을 요청한다. 추가(Add)되는 노드에는 트랩 이벤트가 발생하였을 경우, 실행될 노드의 주소('URI1')가 반드시 포함되어야 한다.

DM 클라이언트(110)는 DM 서버(120)로부터 추가(Add) 명령을 수신하면, DM 서버(120)가 해당 명령을 수행할 권한이 있는지 확인한다(S202). 이는 DM 서버(120)의 등록 권한을 확인하는 과정으로 제201 단계에서 DM 서버(120)가 보낸 추가(Add) 명령이 대상(target)으로 하는 노드에 대해 DM 서버(120)가 추가(Add) 권한을 가지고 있는지 확인한다. 추가(Add) 권한 확인은 대상(target) 노드의 ACL을 획득하여, ACL의 추가(Add) 권한에 DM 서버(120)가 포함되어 있는지(예를 들어, Add=DMS인지) 확인함으로써 가능하다.

DM 클라이언트(110)는 Inward 트랩 등록을 수행하는 DM 서버(120)의ServerID(server identifier)를 획득하여, ServerID의 적합성을 판단한다(S203). 적합한 ServerID는 DM 클라이언트(110)가 부트스트랩(bootstrapping)을 완료하여 DM 클라이언트(110)의 DM 계정(Account)에 'ServerID'를 포함한 DM 서버(120)의 정보가 들어있어야 하며, 또한 DM 계정(Account)에 들어 있는 인증 정보를 이용해 인증 가능한 DM 서버의 ServerID여야만 한다. 또한 현재 Inward 트랩을 등록하고 있는 DM 서버의 ServerID, 즉 'DMS'이여야 한다.

DM 서버(120)가 'ToRef/TargetURI/＜x＞/URI'의 값이 가리키는 노드를 실행할 권한이 있는지, 즉 해당 노드에 실행(Exec) ACL을 가지고 있는지 확인한다(S204). 이 과정은 Inward 트랩의 알림 권한을 확인하는 과정으로, 권한 확인은 그 노드의 ACL값에 예를 들어, 'Exec=ServerID'가 포함되어 있는지 확인함으로써 가능하다. ACL 권한을 확인하는 방법은 예를 들어, [OMA-DM-TND]에 상세히 기술되어 있으며, 이에 대한 상세한 설명은 생략한다.

DM 클라이언트(110)는 제202 단계 내지 제204 단계를 통해 DM 서버(120)가 적합한 등록 권한을 가지고 있을 경우, Inward 트랩 등록을 수행한다(S205). 이 과정은 제202 단계에서 DM 서버(120)가 보내온 추가(Add) DM 명령을 수행하는 것이다.

DM 클라이언트(110)는 DM 서버(120)의 적합한 'ServerID'를 저장하고, 본 Inward 트랩 등록과 매핑해 놓는다(S206). 이렇게 함으로써 추후에 DM 클라이언트(110)는 본 등록을 수행한 'ServerID'를 가져올 수 있다.

제206 단계까지 성공적으로 완료되면, Inward 트랩 등록이 완료되고, 등록은 성공한다(S207).

그러나, 제202 단계 내지 제204 단계 중 어느 하나의 단계에서 실패하면, 등록은 실패한다(S208). 등록이 실패하면, DM 클라이언트(110)는 부가적으로 DM 서버(120)에 등록 실패를 알리는 결과 코드(Result Code) (예를 들어, "인증되지 않음(Not Authorized)를 송신한다.

도 8b는 본 발명의 제1 실시 예에 따른 Inward 트랩의 알림 시에 보안을 강화하는 과정을 나타내는 흐름도이다.

본 실시 예는, Inward 트랩의 알림과 관련해서, 동적으로 변하는 DM 트리(Tree)의 ACL을 반영하여 DM 클라이언트(110)가 권한이 있다고 판단한 명령만을 안전하게 수행하는 방법을 제시한다. DM 클라이언트(110)가 Inward 트랩의 알림(notification)을 통해 수행되는 명령이 승인될 수 있는지 판단하기 위해서는, 해당 알림(notification)을 발생시킨 Inward 트랩 등록을 어떤 DM 서버(120)가 수행했는지에 관한 정보가 필요하다. 이 정보는 도 8a에 도시된 Inward 트랩 등록 과정을 이용해 DM 클라이언트(110)가 Inward 트랩 등록 과정에서 적합한 DM 서버(120)의 'ServerID'만을 저장해 놓았기 때문에, 본 알림 과정에서 이용이 가능할 수 있다. DM 클라이언트(110)는 Inward 트랩 알림의 결과로 명령을 수행하기 전에, 본 등록을 수행한 'ServerID'가 수행 권한을 가지고 있는지 판단함으로써 안전한 명령만을 수행할 수가 있다.

이러한 과정이 없다면, DM 클라이언트(110)는 Inward 트랩의 알림 결과 수행 명령을 실행하는 주체가 TrapMO 인에이블러(Enabler)나, Inward 트랩 알림(notification)을 전달받은 기능 컴포넌트(functional component)라고 판단하기 때문에, 해당 명령이 허용되어야 하는지 알 수가 없게 된다. 하지만 본 실시 예에 따르면, 명령 실행의 주체를 정확히 알 수가 있고 이를 통해 명령 실행에 보안상의 문제가 없는지 명확하게 알게 된다. 또한 DM 클라이언트(110)는 명령 실행 직전에 ACL 정보를 확인함으로써, 동적으로 변하는 ACL을 반영하여, 명령 실행 허용 여부를 판단하게 된다.

DM 클라이언트(110)는 트랩 이벤트의 식별 정보('trap_event1')를 모니터링하고 있다가(S211), 트랩 이벤트 발생을 감지한다(S212).

DM 클라이언트(110)는 트랩 이벤트 발생이 감지되면, TrapMO 중에서 TrapID가 'trap_event1'인 TrapMO 인스턴스를 검색한다(S213).

DM 클라이언트(110)는 제213 단계에서 발견한 TrapMO 인스턴스의 서브 트리에서 해당 URI('ToRef/TargetURI/＜x＞/URI')를 가져온다(S214).

DM 클라이언트(110)는 해당 URI('ToRef/TargetURI/＜x＞/URI')를 등록한 DM 서버(120)의 'ServerID'를 가져온다(S215).

DM 클라이언트(110)는 가져온 'ServerID'가 해당 URI('ToRef/TargetURI/＜x＞/URI')의 값이 가리키는 노드를 실행할 권한이 있는지, 즉 해당 노드에 실행(Exec) ACL을 가지고 있는지 확인한다(S216). 이 과정은 Inward 트랩의 알림 권한을 확인하는 과정으로, 권한 확인은 그 노드의 ACL값 중에서 'Exec=ServerID'가 포함되어 있는지 확인함으로써 가능하다.

제216 단계에서 알림 권한이 있다고 판단되면, DM 클라이언트(110)는 해당 URI('ToRef/TargetURI/＜x＞/URI')의 값이 가리키는 노드를 실행한다(S217).

아직 Inward 트랩 알림이 수행되지 못한 URI('ToRef/TargetURI/＜x＞/URI')가 존재하는지 확인하고(S218), 존재한다면 제214 단계로 회귀한다. 존재하지 않는다면, Inward 트랩 알림 과정이 종료한다.

제216 단계에서 알림 권한이 없다고 판단되면, 알림 실패(Notification Failure)를 처리한다. 알림 실패의 경우, DM 클라이언트(110)는 다음과 같은 방법을 이용하여 처리할 수 있다.

제1 방법은 알림이 실패할 경우, DM 클라이언트(110)가 별다른 작업을 하지 않는 것이다(silent discard).

제2 방법은 알림이 실패할 경우, DM 클라이언트(110)가 DM 서버(120)에 일반적 경고(Generic Alert)를 보내는 것이다(Generic Alert to DMS). 이 일반적 경고(Generic Alert)는 알림 실패를 알리는 타입(type)(예를 들어, 'urn:oma:at:trapmo:1.0:InwardNotificationFailed')을 포함하고 있어야 하며, 일반적 경고(Generic Alert)의 '＜Data＞'에는 알림 실패에 대한 세부적인 정보가 포함될 수 있다(예를 들어, 알림 실패의 이유: 인증되지 않음(Not Authorized)).

제3 방법은 알림이 실패할 경우, DM 클라이언트(110)가 해당 Inward 트랩 등록을 해지하는 것이다. 이는 알림(Notification)이 실패한 Inward 트랩을 해지하여, 알림 실패가 계속 발생하는 것을 방지할 수 있다. DM 클라이언트(110)는 해지하기 전에 DM 서버(120)에게 알림 실패를 알려주어, 필요하다면 DM 서버(120)가 알림(Notification) 실패를 처리할 수 있도록 한다. 즉, 실행(Exec) 권한을 확보하기 위해 필요한 조치를 할 수가 있다.

도 9는 본 발명의 제1 실시 예에 따른 알림 실패 처리 과정을 나타내는 도면이다.

도 9를 참조하면, DM 클라이언트(110)는 DM 서버(120)에게 트랩 이벤트를 해지하기 전에 2번의 알림 실패를 DM 서버(120)에게 일반적 경고(Generic Alert)를 통해 알려준다. 알림 실패가 처음 2번 발생할 때까지는, 일반적 경고(Generic Alert)를 통해 DM 서버(120)에게 알림 실패를 알려준다. 이때의 일반적 경고(Generic Alert)는 상기 제2 방법의 일반적 경고(Generic Alert)와 동일하다. 그리고 세 번째 알림 실패가 발생하면, DM 클라이언트(110)는 DM 서버(120)에게 해당 Inward 트랩을 해지하는 내용의 일반적 경고(Generic Alert)를 보낸다. 이 일반적 경고는 Inward 트랩의 해지를 알리는 타입(type)(예를 들면, 'urn:oma:at:trapmo:1.0:InwardTrapUnregistered')을 포함하며, 일반적 경고(Generic Alert)에는 이벤트 트랩의 해지에 대한 세부적인 정보(예를 들면, 이전에 발생한 알림 실패 횟수 및 이유)가 포함될 수 있다. 이 이벤트 트랩의 해지를 알리는 일반적 경고(Generic Alert)는 해지하기 전이나 해지가 완료된 후에 DM 클라이언트(110)가 DM 서버(120)에게 보낼 수다. 도 9에 도시된 실시 예는, DM 클라이언트(110)가 이벤트 트랩을 해지하기 전에 이벤트 트랩의 해지를 알리는 일반적 경고(Generic Alert)를 보내는 경우를 나타낸다. 해지를 통보할 DM 서버는 해지된 Inward 트랩을 등록한 DM 서버(120)이며, 그 DM 서버(120)의 'ServerID'는 예를 들어, 'ToRef/TargetURI/＜x＞/RegisteredServerID'에 저장되어 있다.

DM 클라이언트(110)는 알림 실패 시, 일반적 경고(Generic Alert)를 보내지 않을 수도 있으며, 트랩 이벤트가 해지되기까지의 알림 실패 회수는 DM 클라이언트(110)와 DM 서버(120)가 협상을 통해 정할 수도 있다.

이상에서 설명한 보안 Inward 트랩의 메커니즘을 등록과 알림으로 나누어서 다시 정리하면 아래와 같다.

보안 트랩 동작들을 위해, 단말은 DM 서버(120)가 이하에서 설명되는 Inward 등록 및 알림을 위한 적절한 권한들을 가지고 있음을 인증해야 한다.

등록 과정에서, DM 서버(120)는 'ToRef/TargetURI' 노드 밑에 서브 트리를 추가함으로써 Inward 트랩을 등록할 수 있다. DM 서버(120)가 이 'ToRef/TargetURI'에 의해 지시되는 실행가능한 노드의 실행 권한을 가지고 있지 않다면, 등록은 허용되지 않는다. 단말은 기본적인 ACL 규칙들(예를 들어, 서브-트리를 추가하기 위한 추가 권한)과 함께 실행 권한을 검증해야 한다. DM 서버(120)가 실행 권한을 가지고 있지 않다면, TrapMO 결과 코드(Result Code) '1400(불충분한 권한 때문에 등록이 실패됨)'과 함께 등록은 거절되어야 한다. 등록이 성공한 후에, 'ToRef/TargetURI/＜x＞/RegisteredServerID' 노드는 단말에 의해 본 Inward 트랩을 등록한 서버 식별자(server identifier)와 함께 설정되어야 한다.

알림 과정에서, 'ToRef/TargetURI/＜x＞/URI'의 형제 노드인 'RegisteredServerID' 노드에 의해 식별되는 DM 서버(120)가 'ToRef/TargetURI/＜x＞/URI' 노드에 의해 지시되는 실행 가능한 노드의 실행(Exec) 권한(permission)을 가지기만 하면, 트랩은 'ToRef/TargetURI/＜x＞/URI' 노드에 의해 지시되는 실행가능한 노드에 통지될 수 있다. 실행 권한을 검증하는 방법은 구현 이슈이나, ACL이 동적으로 변할 수 있음이 고려되어야 한다. 예를 들어, 단말은 트랩 이벤트를 알리기 전에 실행 허가 권한(Exec permission right)을 확인해야 하고, 또는 단말은 ACL 변경에 따라 확인 절차(check process)를 개시해야 한다.

DM 서버(120)가 실행가능한 노드의 실행 권한을 가지고 있지 않으면, 관련된 Inward 트랩 등록은 곧(as soon as practical) 해지되어야 한다. Inward 트랩이 해지된 후에, 단말은 'ToRef/TargetURI' 노드 밑의 대응하는 서브-트리를 제거해야 한다. 일반적인 경고(Generic Alert)가 해지를 알리기 위해 'RegisteredServerID' 노드에 의해 식별되는 DM 서버(120)에 송신될 수 있다.

도 10은 본 발명의 제2 실시 예에 따른 Outward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.

본 발명의 제2 실시 예는, 발생한 트랩 이벤트가 전달되는 DM 서버(120)를 Outward 트랩으로 등록할 때, DM 클라이언트(110)에 있는 DM 계정(Account) 정보를 이용하는 방법이다. DM 클라이언트(110)의 DM 계정(Account)에는 DM 클라이언트(110)가 부트스트랩(bootstrapping)을 통해 등록한 DM 서버(120)의 정보가 저장되어 있다. 이 DM 서버(120)의 정보에는 'ServerID'를 포함하여, DM 서버(120)의 주소, 인증수단, 인증 값 등이 저장되어 있다. 즉 DM 계정(Account)에 등록되어 있는 DM 서버(120)들은 DM 클라이언트(110)와 신뢰적인 관계(trust relationship)를 가지고 있다고 볼 수가 있다.

DM 클라이언트(110)의 트랩 이벤트 종류는 매우 광범위하며, 그 중에서는 프라이버시(Privacy)상 민감한 정보도 포함될 수 있다. 예로 특정 지역으로 단말이 이동하였을 경우 발생하는 트랩 이벤트가 그러하다. 따라서 트랩 이벤트가 전달되는 DM 서버(120)를 DM 클라이언트(110)가 신뢰할 수 있는 DM 서버(120)로 한정하는 것이 필요하며, 어떤 DM 서버(120)를 신뢰할 수 있는지 없는지는 DM 클라이언트(110)의 DM 계정(Account) 정보를 통해 확인할 수 있다. 만일 트랩 이벤트가 전달될 DM 서버(120)가 DM 계정(Account)에 등록되지 않아서 신뢰 관계(trust relationship)가 없다고 판단될 경우, DM 클라이언트(110)는 해당 서버와 부트스트랩(bootstrapping)을 수행하여 DM 계정(Account을 생성한 다음, 등록 과정을 진행할 수도 있다. 또 DM 클라이언트(110)의 트랩 이벤트 정보 보안을 더 강화하기 위해, Outward 트랩 이벤트를 수신하는 DM 서버(120)를, 등록을 수행하는 DM 서버(120) 자신으로 제한할 수 있다.

DM 클라이언트(110)는 트랩 이벤트인 'trap_event1'(TrapID)에 모니터링하기 위한 Outward 트랩 등록 요청을 DM 서버(120)로부터 수신한다(S211). 상기 요청은 발생한 트랩의 결과를 'DMS1'으로 식별되는 DM 서버에 전송하도록 하는 요청이 될 수 있다.

DM 클라이언트(110)는 DM 서버(120)가 Outward 트랩 등록을 수행할 수 있는 권한이 있는지 확인한다(S212). 이 과정은 DM 클라이언트(110)가 TrapID가 'trap_event1'인 TrapMO 인스턴스를 검색하고, 그 하위 노드인 'ToRef/TargetServer'에 추가(Add)할 수 있는 권한이 있는지 확인함으로써 가능하다.

DM 클라이언트(110)는 DM 서버(120)가 트랩 이벤트 수신자로 등록하려는 다른 DM 서버('DMS1')가 현재 DM 클라이언트(110)가 부트스트랩한 DM 서버(120)인지 확인한다(S213). 이는 DM 클라이언트(110)가 가지고 있는 DM 계정에서 DM 서버('DMS1')의 'ServerID'를 가지고 있는 DMAcc 인스턴스를 발견함으로써 확인할 수 있다. 그리고, 추가로, 발견한 DMAcc 인스턴스에 저장되어 있는 인증 정보 등을 확인하여, DM 서버('DMS1')가 올바르게 부트스트랩된 DM 서버인지 검증할 수 있다.

DM 서버('DMS1')가 부트스트랩 되지 않아서, 신뢰 관계가 없다면, DM 클라이언트(110)는 DM 서버('DMS1')에게 부트스트랩을 시도한다(S215). 도시되지 않았으나, 부트스트랩 과정이 실패하면, 제218 단계로 진행하여 등록이 실패한다.

DM 클라이언트(110)는 트랩 이벤트와 관련된 보안성을 높이기 위해, DM 서버(120)가 DM 서버(120) 이외의 DM 서버(120)를 트랩 이벤트 수신자로 등록하는 것을 방지할 수 있다(S214). DM 클라이언트(110)는 DM 서버(120)와 DM 서버('DMS1')가 올바르게 부트스트랩된 서버인지 확인하고, DM 서버(120)의 ServerID와 DM 서버('DMS1')의 ServerID를 비교할 수 있다.

제214 단계에서, DM 서버(120)와 DM 서버('DMS1')가 올바르게 부트스트랩된 서버이고, DM 서버(120)의 ServerID와 DM 서버('DMS1')의 ServerID가 동일한 경우에 등록 과정을 수행한다. 즉, 'ToRef/TargetServer' 노드 밑에 자식 노드로 DM 서버('DMS1')를 추가하고(S216), 이에 따라 등록 과정이 성공적으로 완료된다(S217).

등록이 실패할 경우, 등록 실패에 해당하는 결과 코드(Result Code)를 반환한다(S218).

이상에서 설명한 보안 Outward 트랩에 대해서 다시 정리하면 아래와 같다.

DM 서버(120)는 단말로부터 트랩들을 수신하기를 원하면, 'ToRef/TargetServer' 노드 밑에 서브-트리를 추가할 것이다. 등록에 성공하기 위해, 단말은 'ToRef/TargetServer/＜x＞/ServerID' 노드가 DM 서버 자신의 서버 식별자(예를 들어, DM 서버는 다른 DM 서버들을 등록할 수 없다)로 설정되어 있는지 검증해야 한다. 등록이 실패하면, 단말은 상태 코드(status code) '403' 숨김을 송신해야 한다. 일단 등록이 성공하면, 'ToRef/TargetServer/＜x＞/ServerI' 노드는 변경되지 않아야 한다.

도 11a 및 도 11b는 본 발명의 제3 실시 예에 따른 Outward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.

Outward 트랩의 보안을 강화하는 두 번째 방법은 낙관적 알림 제어(Optimistic Notification Control)이다. 첫 번째 방법이 DM 클라이언트(110)의 민감한 정보인 트랩 이벤트를 신뢰할 수 있는 DM 서버(110)에게만 보내는 방법인 반면, 두 번째 방법은 DM 클라이언트(110)의 트랩 이벤트가 이벤트 수신을 원하지 않는 DM 서버(120)에게 전송되는 것을 막는 방법이다. Outward 트랩 등록에서 불특정 DM 서버(120)가 트랩 이벤트 수신자로 등록될 수 있고, 이는 트랩 이벤트 수신을 원하지 않는 DM 서버(120)에게 트랩 이벤트가 전달되거나 더 나아가 DoS 공격에 악용될 소지가 있다. 두 번째 방법은 이러한 Outward 트랩의 보안상 취약점을 해결하며, 동시에 악의적인 Outward 트랩 등록이 많지 않은 상황에서 매우 효과적이다.

이를 위해, DM 클라이언트(110)는 Outward 트랩 등록 과정은 종래의 과정과 동일하게 수행한다. 즉 어떤 DM Server가 트랩 이벤트 수신자로 등록될 때, 그 DM 서버(120)가 트랩 이벤트 수신을 받기를 원하는지 별도의 확인 과정 없이 등록을 진행한다. 하지만, DM 클라이언트(110)는 해당 Outward 트랩 등록을 수행한 DM 서버(110)의 서버 식별자(Server Identifier; 'ServerID')를 저장한다. 물론, 저장된 'ServerID'는 DM 계정을 통해 확인된 적합한 'ServerID'여야만 한다. DM 클라이언트(110)는 추후 트랩 이벤트가 발생하여, 이벤트 정보를 수신자로 등록되어 있는 DM 서버에게 전송할 때, 본 트랩 이벤트의 등록을 수행했던 'ServerID' 정보를 같이 보내주게 된다. 이 트랩 이벤트 정보를 수신한 DM 서버는 이벤트 정보에 같이 첨부되어 있는 그 'ServerID'와 트랩 이벤트 내용을 통해 본 트랩 이벤트 수신이 안전한 것인지 판단한다. 만약 트랩 이벤트 수신이 안전하지 않다고 판단되면, DM 서버는 DM 클라이언트(120)에게 응답을 보내서 트랩 이벤트 등록을 취소해달라고 요청할 수 있다.

도 11a를 참조하면, DM 클라이언트(110)는 DM 서버(120)로부터 DM 클라이언트의 트랩 이벤트인 'trap_event1'(TrapID)에 모니터링하기 위한 Outward 트랩 등록 요청을 수신한다(S221). 이 때, 상기 요청은 발생한 트랩의 결과를 DM 서버('DMS1')에게 전송하게 하는 요청이 될 수 있다.

DM 클라이언트(110)는 DM 서버(120)가 Outward 트랩 등록을 수행할 수 있는 권한이 있는지 확인한다(S222). 이 과정은 DM 클라이언트(110)가 TrapID가 'trap_event1'인 'TrapMO' 인스턴스를 찾고, 그 하위 노드인 'ToRef/TargetServer'에 추가(Add)할 수 있는 권한이 있는지 확인함으로써 가능하다.

DM 클라이언트(110)는 Outward 트랩 등록을 수행하는 DM 서버(120)의 'ServerID'(server identifier)를 획득하여, 'ServerID'의 적합성을 판단한다(S223). 적합한 'ServerID'는 DM 클라이언트(110)가 부트스트랩(bootstrapping)을 완료하여 DM 클라이언트(110)의 DM 계정(Account)에 'ServerID'를 포함한 DM 서버(120)의 정보가 포함되어 있어야 하며, 또한 DM 계정(Account)에 들어 있는 인증 정보를 이용해 인증 가능한 DM 서버(120)의 'ServerID'여야만 한다. 또한 현재 Inward 트랩을 등록하고 있는 DM 서버(120)의 'ServerID'이여야 한다.

제223 단계에서, Outward 트랩을 등록하는 데 문제가 없다면, DM 클라이언트(110)는 실제 등록 과정을 수행한다. 즉, 'ToRef/TargetServer' 노드 밑에 자식 노드로 DM 서버('DMS1')를 추가하고(S224), DM 서버(120)의 'ServerID'를 저장하고, 본 Outward 트랩 등록과 매핑해 놓는다(S225). 이렇게 함으로써 추후에 본 등록을 수행한 'ServerID'를 가져올 수 있다. 이에 따라, Outward 트랩 등록이 성공한다(S226).

제223 단계에서, Outward 트랩을 등록하는 데 문제가 발생한다면, Outward 트랩 등록이 실패한다(S227). 이렇게 Outward 트랩 등록 과정이 완료된다.

도 11b를 참조하면, DM 서버('DMS1')는 DM 클라이언트(110)가 트랩 이벤트 발생에 따라 보내온 Outward 트랩 알림을 수신한다(S231). 수신한 Outward 알림에는 본 트랩 이벤트를 등록한 서버의 식별 정보(ID)가 포함되어 있다.

DM 서버('DMS1')는 수신한 트랩 이벤트가 유효한지 판단한다(S232). 이를 위해 DM 서버('DMS1')는 Outward 알림에 포함되어 있는 Outward 트랩을 등록한 'ServerID' 및 Outward 트랩 이벤트의 정보를 통해 판단한다. 즉, 자신과 신뢰 관계가 없는 DM 서버(120)가 등록한 트랩이거나, 원하지 않는 트랩 이벤트 정보라면 유효하지 않다고 판단할 수 있다.

제232 단계에서, 수신한 트랩 이벤트가 유효하다고 판단된 경우에, DM 서버('DMS1')는 수신한 트랩 이벤트를 처리한다(S233).

제232 단계에서, 수신한 트랩 이벤트가 유효하지 않다고 판단된 경우에, DM 서버('DMS1')는 DM 클라이언트(110)에게 해당 트랩 이벤트 등록을 취소해 달라는 요청을 보낸다(S234).

전술한 본 발명의 제2 실시 예는, DM 클라이언트(110)의 민감한 정보인 트랩 이벤트를 신뢰할 수 있는 DM 서버(120)에게만 보내는 방법이고, 제2 실시 예는, DM 클라이언트(110)의 트랩 이벤트가 이벤트 수신을 원하지 않는 DM 서버(120)에게 전송되는 것을 막는 방법이다. 이 두 가지 방법은 별개로 적용이 되어도 상관없지만, 두 가지 방법이 동시에 사용되어도 무방하다. 즉, 두 가지 방법을 모두 적용하면, 트랩 이벤트를 신뢰할 수 있는 DM 서버에게만 보내면서, 동시에 트랩 이벤트 수신을 원하지 않는 DM 서버(120)에게 트랩 이벤트가 전송되는 것을 막을 수 있다.

전술한 실시 예들에서, Inward 트랩 이벤트 등록 과정에서 ACL 매커니즘(Mechanism)으로 보장되는 추가(Add) 권한 외에, 실행(Exec) 권한을 함께 검사하는 과정이 추가되었다. 이러한 실행(Exec) 권한 확인은 ACL 매커니즘(Mechanism)으로는 보장되지 않는 부분이다. 이처럼 트랩 이벤트 등록 과정 중에 Exec 권한을 검사하는 것은 다른 관리 객체(MO)에서는 사용되지 않는 TrapMO의 독자적인 부분이다. DM 프로토콜(Protocol)에서 등록(Registration)이란 통상, 관련 정보를 추가(Add)함으로써 이루어진다. 이러한 등록(Registration)이 필요한 관리 객체(MO)로는 GwMO, SCOMO 등이 있다.

GwMO에서 등록(Registration)이 필요한 경우로 대표적인 경우가, 팬아웃 명령(Fanout Command) 등록과 이미지(Image) 등록이다. 팬아웃(Fanout)이란, DM 서버(120)가 DM 게이트웨이(Gateway)에 DM 명령(Command)을 보내주면, DM 게이트웨이(Gateway)가 모든 대상 단말(End Device)에게 DM 명령(Command)을 보내주는 방식이다. 즉, DM 서버(120)는 DM 명령(Command)을 단 한번만 DM 게이트웨이(Gateway)에게 전달함으로써, DM 명령(Command)이 대상으로 하는 단말(End Device)들에게 모두 보낼 수 있어, 효과적으로 단말 관리를 수행할 수가 있게 된다. 이러한 팬아웃(Fanout)을 사용하기 위해, DM 서버(120)는 팬아웃(Fanout)에 사용될 DM 명령(Command)을 DM 게이트웨이(Gateway)에게 등록해야 하는데, 이 과정이 팬아웃 등록(Fanout Registration)이다. 팬아웃 등록(Fanout Registration)은 'Fanout/＜x＞' 밑에 DM 명령(Command) 같은 관련 서브-트리(sub-tree)를 추가(Add)함으로써 수행이 되며, 이때는 등록(Registration)을 수행하는 DM 서버(120)가 'Fanout/＜x＞'에 추가(Add)할 수 있는 권한이 있는지만 확인하면 충분하다. 또한 GwMO의 이미지 인벤토리(Image Inventory) 기능은, DM 서버(120)가 SW 패키지 같은 이미지 데이터(image data)를 DM 게이트웨이(Gateway)에게 저장시켜 놓고, 단말(End Device)에게 DM 게이트웨이(Gateway)에게 저장되어 있는 이미지(image)를 참고하도록 하는 기능이다. 이미지 인벤토리(Image Inventory) 기능은 원격의 DM 서버(120)가 단말(End Devicc)에게 각각 이미지(image)를 보내주는 것보다 DM 게이트웨이(Gateway)에 있는 이미지(image)를 반복적으로 단말(End Device)에게 전달할 수가 있어 훨씬 효율적이다. 이러한 이미지 인벤토리(Image Inventory) 기능을 수행하기 위해, 이미지 등록(image Registration) 과정을 거쳐야 한다. 이 과정에서 DM 서버(120)는 'ImageInventoryMO'의 '＜x＞/Images/＜x＞' 밑에 관련 이미지(image)를 추가(Add)함으로써 등록을 수행하게 되는데, 이 과정에서 역시 ACL로 보장되는 추가(Add) 권한만 확인하면 충분하다.

SCOMO에서도 단말에 다운로드 가능한 SW를 등록(Registration)하는 과정 역시 비슷하며, DM 서버(120)는 SCOMO의 '＜x＞/Download/＜x＞' 밑에 서브-트리(sub-tree)를 추가할 수 있는 권한만 확인하는 것으로 충분하다.

본 발명의 실시 예들은 ACL이 단말 관리 중에 동적으로 변화할 수 있다는 것을 가정한다. 노드(Node)의 ACL 속성(Property)은 [OMA-DM-TND]의 Section 7. Properties of Nodes에 자세히 설명되어 있으며, 해당 문서는 참조로써 본 명세서에 편입된다. ACL에 허용되는 DM 명령들(Commands)은 획득(Get)과 변경(Replace)이며, 이는 DM 서버(120)가 필요에 따라, ACL 값을 자유롭게 바꿀 수 있음을 의미한다. DM 서버(120)가 ACL을 바꿀 수 있는 경우란, 예를 들어, 허락된 권한이 기한 도래 등을 이유로 소멸하여, 해당 DM 서버(120)의 권한을 제거하는 경우 (엔터프라이즈 도메인(Enterprise domain)에서 벗어나는 경우, 기존의 엔터프라이즈(Enterprise) DM 서버(120)의 관리 권한 철회) 또는 허락되지 않은 권한을 요청에 의해, 해당 DM 서버(120)에게 새로 부여하는 경우(엔터프라이즈 도메인(Enterprise domain)에 진입 시, 해당 엔터프라이즈(Enterprise) DM 서버(120)에게 관리 권한 위임)를 말한다.

ACL은 위와 같은 사유로 인해, 단말 관리 수행 중에 수시로 변할 수 있으며, 이를 Inward 트랩 보안에 반영하여 강화하는 방법을 본 발명은 담고 있다.

도 12는 본 명세서에 개시된 제1 실시 예에 따른 Inward 트랩 이벤트 등록 과정을 나타내는 흐름도이다.

DM 클라이언트(110)는 DM 서버(120)로부터 트랩 이벤트인 'trap_event1'을 모니터링하기 위한 트랩 이벤트 등록 요청을 수신한다(S301). 이때, DM 서버(120)는 Inward 트랩을 등록하며, 'trap_event1' 이벤트 발생 시, 실행할 단말의 명령인 'URI1'을 함께 보낸다(본 실시 예에서, 'trap_event1'은 'WiFi_Connected' 이벤트이며, 'URI1'은 'DiagMonMO/Restart/Operations/Start').

DM 클라이언트(110)는 DM 서버(120)로부터 Inward 트랩 등록 요청을 받고, DM 서버(120)가 해당 트랩 이벤트에 등록할 수 있는 권한을 확인한 후, Inward 트랩 등록을 수행한다. DM 클라이언트(110)는 DM 서버(120)의 'ServerID'가 올바른지(부트스트랩(bootstrapping)되었는지, DM 서버(120)의 식별자(identifier)인지) DM 계정(Account)을 통해 확인하고, 본 등록과 연결시켜 저장한다(S302).

DM 클라이언트(110)는 WiFi가 연결되었음을 감지한다(S303).

DM 클라이언트(110)는 WiFi 연결로부터 'trap_event1'이 발생하였음을 감지하고, 'trap_event1'의 처리를 준비한다(S304).

DM 클라이언트(110)는 Inward 트랩으로 등록된 URI와 그 URI와 매핑되어 있는 ServerID를 검색한다(S305). 예를 들어, DM 클라이언트(110)는 TrapMO의 루트(root)에서부터 시작하여, TrapID가 'trap_event1'인 TrapMO 인스턴스(instance)를 검색한다. 또한, DM 클라이언트(110)는 발견한 TrapMO 인스턴스(instance)로부터, Inward 트랩으로 등록된 'TargetURI/＜x＞/URI'를 검색하고, URI와 매핑되어 있는 ServerID를 검색한다. DM 클라이언트(110)는 ServerID가 올바른 서버 식별자(identifier)인지 DM 클라이언트(110)의 DM 계정(Account)을 통해 확인한다. DM 클라이언트(110)는 상기 발견한 ServerID가 URI가 가리키는 노드에 대한 실행(Exec) 권한을 갖고 있는지 확인한다.

DM 클라이언트(110)는 이 두 가지 조건을 만족시키는 ServerID만이 Inward 알림에 대한 권한을 갖고 있다고 판단한다.

DM 트리(Tree)의 실행 권한을 나타내는 ACL은 실행시 바뀔 수 있는 런타임(runtime) 속성이기 때문에, 본 발명의 실시 예들에 따른 권한 확인 방법에 의해 동적으로 바뀌는 ACL을 반영할 수 있다.

제304 단계에서, ServerID가 Inward 알림을 위한 권한이 있다고 확인되었을 경우에, DM 클라이언트(110)는 URI가 가리키는 노드에 Inward 알림을 보낸다(S306). DiagMonMO(306)는 수행중인 작업을 재시작한다(S307).

하나의 트랩 이벤트에 대해 다수의 Inward 트랩 등록이 이루어질 수 있으므로, 이러한 경우 모든 등록에 대해 제305 단계로 회귀한다.

도 13은 본 명세서에 개시된 제2 실시 예에 따른 DM 계정(Account)을 이용하여 Outward 트랩 이벤트 등록 및 알림 과정을 나타내는 흐름도이다.

DM 클라이언트(110)는 DM 서버(120)로부터 트랩 이벤트인 'trap_event1'을 모니터링하기 위한 트랩 이벤트 등록 요청을 수신한다(S311). 이때, DM 서버(120)는 Outward 트랩을 등록하며, 'trap_event1' 이벤트 발생 시, 이벤트를 보고할 서버로 DM 서버('DMS1')을 지정한다. 상기 예에서, 'trap_event1'은 'Low_Battery' 이벤트이다.

DM 클라이언트(110)는 DM 서버(120)로부터 수신한 Outward 트랩 등록을 인증한다(S312). DM 클라이언트(110)는 DM 서버('DMS1')가 본 등록에 대한 등록 권한을 가지고 있는지 확인한다. 또한, DM 서버('DMS1')의 ServerID가 올바른지(부트스트랩(bootstrapping) 되었는지, 그리고 부가적으로 DM 서버(120)의 식별자(identifier인지)) DM 계정(Account)을 통해 확인한다. 이때 DM 서버('DMS1')가 부트스트랩(bootstrapping)이 되어 있지 않다면, 부가적으로 부트스트랩(Bootstrapping)을 수행할 수 있다. 만일 DM 서버('DMS1')가 등록 권한을 가지고 있지 않거나, 부트스트랩(bootstrapping)이 실패한다면, 등록은 실패한다.

DM 클라이언트(110)가 성공적으로 DM 서버(120)의 Outward 트랩 등록을 인증하였다면, 등록을 수행한다(S313).

부가적으로, DM 클라이언트(110)는 Outward 트랩 등록 결과를 DM 서버(120)에 전송한다(S314).

DM 클라이언트(110)는 'Low_Battery' 이벤트를 감지한다(S315).

제315 단계에서 감지한 'Low_Battery' 이벤트로부터 DM 클라이언트(110)는 'trap_event1'이 발생하였음을 감지하고 'trap_event1'의 처리를 준비한다(S316).

DM 클라이언트(110)는 DM 서버(120)에 트랩 이벤트 'trap_event1'과 관련된 정보를 전달한다(S317).

도 14는 본 명세서에 개시된 제3 실시 예에 따른 낙관적 알림 제어(Optimistic Notification Control)를 이용한 Outward 트랩 이벤트 등록 및 알림 과정을 나타내는 흐름도이다.

DM 클라이언트(110)는 DM 서버(120)로부터 트랩 이벤트인 'trap_event1'을 모니터링하기 위한 트랩 이벤트 등록 요청을 수신한다(S321). 이때, DM 서버(120)는 Outward 트랩을 등록하며, 'trap_event1' 이벤트 발생 시, 이벤트를 보고할 서버로 DM 서버('DMS1')를 지정한다. 상기 예에서, 'trap_event1'은 'Low_Battery' 이벤트이다.

DM 클라이언트(110)는 DM 서버(120)로부터 Outward 트랩 등록 요청을 받고, DM 서버('DMS1')가 등록을 수행할 권한이 있는지 확인 후, 해당 등록을 수행한다(S322). 또한 DM 클라이언트(110)는 DM 서버(120)의 ServerID가 올바른지 DM 계정(Account)을 통해 확인하고, 본 등록과 연결시켜 저장한다. 올바른 ServerID는 DM 계정(Account)을 통해 부트스트랩(bootstrapping)되어 있고, 등록을 수행하는 DM 서버(120)의 서버 식별자(server identifier)이어야 한다. 올바르지 않는 ServerID라면 등록은 실패한다.

DM 클라이언트(110)는 배터리(battery)가 일정 수준 이하로 낮아지는 'Low_Battery' 상태임을 감지한다(S323).

DM 클라이언트(110)는 'Low_Battery' 상태로부터 'trap_event1'이 발생하였음을 감지하고 trap_event1의 처리를 준비한다(S324).

DM 클라이언트(110)는 DM 서버('DMS1')에게 트랩 이벤트 'trap_event1'과 관련된 정보, 그리고 제322 단계에서 저장한 ServerID를 전달한다(S325).

DM 서버('DMS1')는 DM 클라이언트(110)로부터 받은 'trap_event1'의 정보와 본 Outward 트랩을 등록한 ServerID 정보로부터, 본 Outward 트랩 등록을 인증한다(S326). DM 서버('DMS1')는 자신과 ServerID를 갖는 서버와의 신뢰 관계를 통해, 본 Outward 알림을 검증할 수 있다. 만약, Outward 알림이 이전에 인증되었다면, 제326 단계는 생략 가능하며, 중복해서 동일한 Outward 알림에 대해 계속 확인할 필요는 없다.

DM 서버('DMS1')가 받은 Outward 알림이 인증을 받지 못하면, DM 서버('DMS1')는 DMS 클라이언트(110)에게 'trap_event1'에 대한 DM 서버('DMS1')의 등록을 해제해 달라는 요청을 전송한다(S327).

도 15는 본 명세서에 개시된 단말(400) 및 서버(500)의 블록도이다.

도 15에 도시된 바와 같이 단말(400)은 저장 수단(410)과 컨트롤러(420)와 송수신부(430)를 포함한다. 상기 저장 수단(410)은 도 1 내지 도 14에 도시된 실시예에 따른 방법을 저장한다. 상기 컨트롤러(420)는 상기 저장 수단(410) 및 상기 송수신부(430)를 제어한다. 구체적으로 상기 컨트롤러(420)는 상기 저장 수단(410)에 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트롤러(420)는 상기 송수신부(430)를 통해 상기 전술한 신호들을 전송한다.

또한, 도 15에 도시된 바와 같이 서버(500)는 저장 수단(510)과 컨트롤러(520)와 송수신부(530)를 포함한다. 상기 저장 수단(510)은 도 1 내지 도 14에 도시된 실시예에 따른 방법을 저장한다. 상기 컨트롤러(520)는 상기 저장 수단(510) 및 상기 송수신부(530)를 제어한다. 구체적으로 상기 컨트롤러(520)는 상기 저장 수단(510)에 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트롤러(520)는 상기 송수신부(530)를 통해 상기 전술한 신호들을 전송한다.

이와 같이, 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로서 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 나타내어지며, 특허청구범위의 의미 및 범위 그리고 그 등가개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

Claims

단말상의 다른 기능적 컴포넌트에 트랩을 통지하는 단말의 트랩 동작 제어 방법에 있어서,
서버로부터 트랩 등록 요청을 수신하는 단계, 여기에서 상기 트랩 등록 요청은 타겟 식별자를 포함하고;
상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 상기 서버가 가지고 있는지 확인하는 단계;
상기 실행 가능한 노드의 실행 권한을 상기 서버가 가지고 있으면, 트랩을 등록하는 단계, 여기에서 상기 트랩은 모니터링될 이벤트를 포함하고 서버 식별자 및 트랩 식별자와 연관되어 있고;
상기 이벤트를 감지하는 단계;
상기 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계; 및
상기 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 트랩을 상기 실행 가능한 노드에 통지하는 단계를 포함하는 것을 특징으로 하는 단말의 트랩 동작 제어 방법.
제1 항에 있어서, 상기 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계는,
접근 제어 리스트(ACL; Access Control List)에 기초하여, 상기 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계인 것을 특징으로 하는 단말의 트랩 동작 제어 방법.
제1 항에 있어서, 상기 트랩을 등록하는 단계는,
상기 트랩 식별자와 연관된 트랩의 서브-트리(sub-tree)를 추가하는 단계를 포함하고,
상기 서브-트리(sub-tree)는,
상기 실행 가능한 노드를 지시하는 타겟 식별자와 상기 서버 식별자를 포함하는 것을 특징으로 하는 단말의 트랩 동작 제어 방법.
제3 항에 있어서, 상기 서버가 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계는,
상기 서버가 상기 실행 가능한 노드의 실행 권한과 함께 서브-트리를 생성할 수 있는 추가 권한이 있는지 확인하는 단계를 포함하는 것을 특징으로 하는 단말의 트랩 동작 제어 방법.
제1 항에 있어서, 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있지 않으면, 상기 서버에 등록 실패를 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 하는 단말의 트랩 동작 제어 방법.
제1 항에 있어서, 상기 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있지 않으면, 상기 트랩의 등록을 해제하는 단계를 더 포함하는 것을 특징으로 하는 단말의 트랩 동작 제어 방법.
제6 항에 있어서, 상기 서버 식별자에 의해 식별되는 서버에 상기 트랩의 등록이 해제되었음을 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 하는 단말의 트랩 동작 제어 방법.
단말상의 다른 기능적 컴포넌트에 트랩을 통지하는 단말에 있어서,
서버로부터 트랩 등록 요청을 수신하는 송수신부와, 여기에서 상기 트랩 등록 요청은 타겟 식별자를 포함하고; 및
상기 서버가 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하고, 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 트랩을 등록하고, 여기에서 상기 트랩은 모니터링될 이벤트를 포함하고, 서버 식별자 및 트랩 식별자와 연관되어 있고, 상기 이벤트를 감지하면 상기 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 컨트롤러를 포함하고,
상기 송수신부는,
상기 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 트랩을 상기 실행 가능한 노드에 통지하는 것을 특징으로 하는 단말.
삭제
삭제
삭제