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

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

Info

Publication number
WO2012102566A2
WO2012102566A2 PCT/KR2012/000625 KR2012000625W WO2012102566A2 WO 2012102566 A2 WO2012102566 A2 WO 2012102566A2 KR 2012000625 W KR2012000625 W KR 2012000625W WO 2012102566 A2 WO2012102566 A2 WO 2012102566A2
Authority
WO
WIPO (PCT)
Prior art keywords
trap
server
identifier
event
client
Prior art date
Application number
PCT/KR2012/000625
Other languages
English (en)
French (fr)
Other versions
WO2012102566A3 (ko
Inventor
추연성
Original Assignee
엘지전자 주식회사
박승규
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사, 박승규 filed Critical 엘지전자 주식회사
Priority to US13/979,804 priority Critical patent/US9426043B2/en
Priority to CN201280006886.XA priority patent/CN103493429B/zh
Priority to EP12740034.9A priority patent/EP2651073B1/en
Priority to KR1020137017507A priority patent/KR101560072B1/ko
Publication of WO2012102566A2 publication Critical patent/WO2012102566A2/ko
Publication of WO2012102566A3 publication Critical patent/WO2012102566A3/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0681—Configuration of triggering conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1491—Countermeasures against malicious traffic using deception as countermeasure, e.g. honeypots, honeynets, decoys or entrapment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/125—Protection against power exhaustion attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings

Definitions

  • This specification registers a trap event in a DM client and stores the trap event.
  • the present invention relates to a method for notifying occurrence and a terminal employing the same.
  • a representative technology for portable terminal management is the device management (DM) technology of the Open Mobile Alliance (OMA).
  • OMA Open Mobile Alliance
  • the DM opens a two-way session between the DM server and the DM client, through which the DM
  • Terminal management is performed by sending and receiving commands.
  • the DM client can start a session through Package 1 to the DM server, and if the DM server determines that the terminal needs to be managed, it sends a DM notification called Package 0 to the DM. You can also request a DM session from the client.
  • DM clients can use the DM server
  • Package 1 can be sent to DM server to start DM session.
  • the DM session is a two-way session
  • the DM sends and receives
  • All DM commands can be sent to the client, but the DM client changes the DM server's device information (Devlnfo) / device details (DevDetail information).
  • DM provides a user authentication framework based on Challenge-Credential.
  • This framework provides a two-way authentication service that allows the DM server and the DM client to authenticate each other, and enables the use of various authentication mechanisms such as MD5, HTTP-Digest, and Basic Authentication.
  • MD5 Secure Digital
  • HTTP-Digest HyperText Transfer Protocol
  • Basic Authentication the first person requesting authentication sends a challenge to the other party.
  • DM is a two-way authentication, so both the DM client and the DM server can challenge.
  • the challenged party must send his / her credential information to receive the credential and authenticate the other party.
  • the DM is a kind of framework for managing terminals.
  • Software management, event monitoring, and locking functions for security are discussed in a separate Management Object (MO). do.
  • Representative MOs include a SCOMO (Software Component Management Object) having a software management function installed in the terminal, and a Lock And Wipe Management Object (LAWMO) that can remotely lock and unlock the functions of the terminal. Lock and unlock objects), software and application control management objects (SACMOs), firewalls, and NATs that allow processes to be remotely configured on the terminal and perform transactions.
  • SCOMO Software Component Management Object
  • LAWMO Lock And Wipe Management Object
  • SACMOs software and application control management objects
  • firewalls firewalls
  • NATs Network Address Translation
  • a representative MO may be a trap management object (TrapMO), which performs a function for monitoring an event of a mobile device and reporting related information.
  • TrapMO trap management object
  • These types of monitoring events include call setup failure, battery level, RF loss, memory usage level, DM Account modified, and external. External storage attached, SAV or H / W faults, and the like.
  • Such a function of monitoring and reporting the state of the terminal is very useful, for example, the function of monitoring the RF loss (RF loss) can be a great help to improve the coverage of the base station (coverage).
  • Each trap event in the terminal is distinguished with a unique trap identification information (Trap ID).
  • a trap may mean that special conditions are put in place to detect an event occurring in a running program.
  • a DM server can send a specific trap event (trap_eventl) to a DM client.
  • Registration is the stage where the DM server requests the DM client to monitor the registration in order to monitor a specific event (trap_eventl), and notification is sent by the DM client to the event (trap— event 1). If this occurs, the step of reporting the relevant information to the DM server.
  • TrapMO provides the function to monitor the event of the terminal. When the event occurs, it depends on where to report event related information.
  • An outward type trap is a trap that transmits information about an event to an external server of the terminal when the corresponding event occurs in the terminal.
  • the external server may be a DM server that has registered a trap event in the terminal. It could be your own DM server.
  • Inward type tram is a trap that does not send information about the tram event that occurred to external server, but to other components inside the terminal.
  • a method for controlling a tram operation of a terminal for notifying a tram to another functional component on a terminal includes receiving a tram registration request from a server.
  • the trap registration request includes a trap identifier, a server identifier and a target identifier; Confirming that the server has execution authority of an executable node associated with the trap identifier and indicated by the target identifier; If the server has permission to execute the executable node, rounding the trap while storing the server identifier associated with the trap identifier, wherein the trap includes a trap event and is associated with the trap identifier.
  • the checking of whether the server identified by the stored server identifier has execution authority of the executable node may be performed based on an access control list (ACL). And checking whether the server identified by the stored server identifier has the execution authority of the executable node.
  • ACL access control list
  • registering the trap may include adding a sub-tree of a trap associated with the trap identifier, wherein the sub-tree Is characterized in that it comprises a target identifier indicating the executable node and the server identifier.
  • the method of claim 3 wherein the step of checking whether the server has the execution authority of the executable node associated with the trap identifier and indicated by the target identifier, And checking whether there is an additional authority for generating a sub-tree together with the execution authority of the executable node.
  • the method may further include transmitting a message indicating registration failure to the server if the server does not have an execution authority of the executable node. It is done.
  • the trap operation control method The stored server
  • the server identified by the identifier does not have the execution authority of the executable node, further comprising the step of deregistering the tram.
  • the trap operation control method the stored server
  • the terminal for receiving a trap registration request from a server, wherein the trap registration request, trap (trap) identifier, A server identifier and a target identifier; And verifying that the server has execution authority of an executable node associated with the trap identifier and indicated by the target identifier, and if the server has execution authority of the executable node, the server identifier to the trap.
  • the trap While storing in association with the identifier, wherein the trap includes a trap event and is associated with the tram identifier, detects the tram event, and is executed by a server identified by the stored server identifier. And a controller for checking whether a node has execution authority of the possible node, wherein the transceiver unit executes the trap event if the server identified by the stored server identifier has execution authority of the executable node. And notifying the node.
  • the tram operation control method of the terminal for notifying the tram to the server for solving the technical problem, the step of receiving a trap registration request from the server, wherein the trap The registration request includes a trap identifier and an identifier of a server to which the trap is notified; Checking whether an identifier of a server included in the trap registration request is the same as an identifier of a server that has sent a trap registration request to the terminal; And registering the tram associated with the trap identifier if the identifier of the server included in the trap registration request is the same as the identifier of the server that sent the trap registration request to the terminal.
  • the trap operation control method the trap registration request
  • the identifier of the included server is not the same as the identifier of the server that sent the trap registration request to the terminal, further comprising the step of transmitting a message indicating registration failure to the server that sent the trap round request to the terminal; It is done.
  • the terminal for notifying a trap to the server for solving the technical problem, the transceiver for receiving a trap registration request from the server where the trap registration request is A trap identifier and an identifier of a server to which the trap is notified; And checking whether the identifier of the server included in the trap registration request is the same as the identifier of the server that has sent the trap registration request to the terminal, and the identifier of the server included in the tram registration request transmits the trap registration request to the terminal. If the same as the identifier of one server, it characterized in that it comprises a controller for rounding the trap associated with the trap identifier.
  • the DM server when the DM server monitors a specific event of the terminal using Inward trapping, it can be ensured that the DM server has appropriate authority with respect to a command performed as a result of the event occurrence. [22] Also, according to the present invention, even if the ACL, which is the runtime attribute of the DM tree, is changed, it is possible to ensure that the command executed by the DM server using the inward trap reflects the ACL of the changed DM tree.
  • the DM server monitors a specific event of a terminal by using an outward trap, it is possible to prevent the information of the occurrence event from being transmitted to an undesired DM server.
  • FIG. 1 shows a device management architecture according to the embodiments disclosed in this specification.
  • 2A is a flowchart illustrating an event monitoring process of an outward trap according to the prior art.
  • 2B is a flowchart illustrating an event monitoring process of an inward trap according to the prior art.
  • FIG. 3 is a diagram showing the structure of a trap management object tree according to the prior art.
  • Figure 4A illustrates the registration process for Inward notifications according to the prior art.
  • 4B is a flowchart illustrating a notification procedure after registration for inward notification according to the prior art.
  • FIG. 5A is a flowchart illustrating a problem of a method of processing inward trams according to the prior art.
  • 5B is a flowchart illustrating a problem of a method of processing an outward trap according to the prior art.
  • FIG. 6 is a flowchart showing a method for enhancing the security of a TrapMO according to the prior art.
  • FIG. 7 illustrates a trap management object tree according to the embodiments disclosed in the specification.
  • This figure shows the Management Object Tree.
  • 8A shows security at the time of registration of an inward trap according to the first embodiment of the present invention.
  • 8B is a diagram illustrating security at the time of notification of an inward trap according to the first embodiment of the present invention.
  • FIG. 9 shows a notification failure processing process according to the first embodiment of the present invention.
  • 11A and l ib are flowcharts illustrating a process of strengthening security when registering an outward trap according to a third embodiment of the present invention.
  • FIG. 13 is a diagram illustrating a DM account according to a second embodiment of the present disclosure.
  • 15 is a block diagram of a terminal 400 and a server 500 disclosed herein.
  • FIG. 1 is a diagram illustrating a device management architecture according to embodiments disclosed herein.
  • the device management (DM) is a DM including a DM client 110 and a DM server 120.
  • the DM client 110 is abstract software that complies with the requirements of the DM client specified in the Open Mobile Alliance (OMA) Device Management Enabler.
  • OMA Open Mobile Alliance
  • DM server 120 is an abstract software component that follows the requirements of the DM server specified in the OMA Device Manager.
  • the client-server notification (DM-1) provides an interface through which the servers 120 can send device management notifications to the clients 110.
  • Client-server notification (DM-1) is an intermediate carrier and an interface that can operate over many protocols, such as WAP push and SIP push.
  • the Device Management Client-Server Protocol (DM-2) allows the server 120 to
  • Device Management Client-Server Protocol is an intermediary carrier and an interface that provides many standardized bindings, including HTTP and HTTPS. This interface is exposed via a radio-based data transfer protocol (eg GPRS) to provide over-the-air device management capabilities.
  • DM-2 Device Management Client-Server Protocol
  • GPRS radio-based data transfer protocol
  • the DM client 110 may initially be supplied via a file on the smart card 210. This file contains a series of DM commands for setting or changing settings at the DM client 110.
  • Profile DM-3 is a unidirectional interface in which no feedback from DM client 110 is provided. In the next practical opportunity to be connected to the DM server 120
  • DM client 110 is the only expected result.
  • DM client 110 may initially be supplied via a file sent by some push protocol. This file contains the DM commands for setting or changing the configuration on the DM client.
  • the bootstrap profile OTA (DM-4) is a one-way interface from the OTA server 220 to the DM client 110 where no feedback from the DM client 110 is provided. In the next practical opportunity, the DM client 110 connecting to the DM server 120 is the only expected result.
  • the DM client 110 may initially be supplied through the enabler 230.
  • the CP bootstrap profile (CP-1) is a one-way direction from the CP enabler 230 to the DM client 110, where no feedback from the DM client 110 is provided.
  • 2A is a flowchart illustrating an event monitoring process of an outward trap according to the prior art.
  • the DM server 120 receives the first trap event (trap_eventl) of the DM client 110.
  • the DM server 120 transmits the trap event of the Outward type to the DM server 120 itself that has registered the event.
  • the DM server 120 also registers with the DM client 110 to monitor the second trap event trap_event2 of the DM client 110 (S102).
  • the DM server 120 may register the trap event of the Outward type to the DM client 110 to send information about the event generated in the terminal to the second DM server 120, which registered the event.
  • the DM client 110 may monitor whether rounded trap events are detected and detect that a first trap event (trap_eventl) occurs (S103).
  • the DM client 110 detects the occurrence of the first trap event (trap_eventl).
  • the DM server 120 registered in the event is notified (S 104).
  • the DM client 110 transmits related information to the DM server 120 as a generic alert, and a meta type (meta ype) and meta for a generic alert.
  • Meta.Type is set to urn: oma: mo: diagmon: 1.0: TrapNotification to indicate that this Generic Alert message is a trap event notification, Meta oraiat is indicated as "chr"
  • the location URI (Source.LocURI) indicates the address of TargetServer / ⁇ x> / ServerID associated with the trap event that occurred.
  • the data contains a trap identifier, which trap event It tells you if it happened.
  • the DM client 110 continues to check whether registered trap events are detected.
  • the DM client 110 detects the occurrence of the second trap event (trap_event2).
  • the second 1) server 120 'registered in the event is notified (S 106). At this time, the DM client 110 traps the second trap as a generic alert.
  • trap_event2 Information related to the occurrence of the event (trap_event2) is transmitted to the second DM server 120 ', and other necessary information (meta type (Meta.Type), meta format (Meta.Format), and source location described above)
  • URIs Source.LocURI
  • Data Data, etc.
  • the DM server 120 may monitor the event generated by the DM client 110 and send the result to itself or to another server.
  • 2B is a flowchart illustrating an event monitoring process of an inward trap according to the prior art.
  • the inward trap is a tram that transmits the result of the event, as in the outward trap, not to the external DM server 120 but to other internal functional components.
  • the DM server 120 is a software component of the DM client 110.
  • the DM command is used to specify a specific node (for example,
  • the SCOMO 304 of the DM client 110 starts downloading the package PKG1 according to the Exec command received in step 111 from the DM server 120 (S112).
  • the DM server 120 automatically cancels the download process of the package PKG1 when the DM client 110 enters a low battery state.
  • the Inward trap is registered with the TrapMO (TrapMO) 30 2 of the client 110 (SI 13). As this inward trap is registered, the DM client 110 sends the event information to a specific node (eg, 'SCOMO / Download / PKGl / Operations / Stop') when a trap event (trap_eventl; Low_Battery) occurs. Will be sent.
  • a specific node eg, 'SCOMO / Download / PKGl / Operations / Stop'
  • trap_eventl Low_Battery
  • the DM client 110 monitors the occurrence of the registered trap event and detects the occurrence of the trap event (trap_eventl; Low_Battery) (S 114).
  • the TrapMO 302 When the trap event (trap_eventl; Low—Battery) occurs, the TrapMO 302 generates a trap event.
  • the inward notification registered in the event is searched for, and an Exec command is sent to the corresponding node (S115).
  • the node is delivered to the DM client 110 when the DM server 120 rounds the inward trap, and in this embodiment, refers to 'SCOMO Download / PKGl / Operations / Stop'.
  • the SCOMO 304 receives an Exec command from the TrapMO 302, The download of the package PKG1 is canceled (S116).
  • the DM server 120 uses such an inward trap to transmit information about the event occurrence to other components in the terminal. It can be delivered to ensure proper processing according to event occurrence.
  • the DM server 120 commands the download of the software package PKG1 to the DM client 110, and the terminal enters a low power state (Low_Powered), the package ( The command to cancel the download of PKG1) can be easily handled using TrapMO.
  • FIG. 3 is a diagram illustrating a structure of a trap management object tree according to the prior art.
  • TrapMO delivers information about the event that occurred to a specific URI (URIl).
  • URIl URIl
  • an instance of TrapMO having a TrapID of trap_eventl is searched.
  • the DM server 120 traverses the TrapMO subtree of the DM client 110 and can retrieve that instance, or retrieve the trap instance through its relative address as shown in Table 1 below. Can point.
  • TrapID retrieve an instance of TrapMO, trap_eventl.
  • DM client 110 may reuse the relative addressing described above.
  • the DM client 110 sends an Exec command to the node indicated by the URI node value for all URIs listed under the TargetURI. As a result, the inward notification process is completed.
  • This section describes the process of registering an event (trap_eventl) as an outward type.
  • the DM server 120 receives a trap event (trap_eventl) of the DM client 110.
  • VI Server 120 For monitoring purposes, assume a situation where events that have occurred are forwarded to another DM server ('DMS1'). VI Server 120 first registers for outward trap event registration.
  • the TmpID is 'trap_eventl'
  • the DM server 120 adds identification information ('DMS1') of another DM server as a child node under the 'ToRef / TargetServer' node, and the registration process is completed accordingly.
  • a notification that informs another DM server 'DMS1' may be performed.
  • the DM client 110 monitors a trap event, detects the occurrence of a trap event (trap_eventl), and detects a TrapMO instance in which TrapID is trap_eventl among the TrapMO.
  • the DM client 110 transmits information on a trap event (trap_eventl) for all 'ServerlD's registered under' ToRef / TargetServer 'in the found TrapMO instance subtree. This delivery is delivered using a generic alert.
  • Another DM server ('DMS1')
  • the DM client 110 receives information about a trap event (trap_eventl).
  • TrapMO's Inward trap can execute unspecified DM commands to the terminal, there is a potential security risk.
  • only the DM server 120 having proper authority in the registration and notification of inward traps should perform the process. That is, only the VI server 120 having the registration authority can register the inward trap, and when the inward trap performs a specific operation through a notification process, the inward trap is stored. The DM server 120 must have execute permission.
  • FIG. 4A illustrates a registration procedure for Inward notification according to the prior art.
  • the DM client 110 For successful registration, when the DM client 110 receives a registration request for inward notification from the DM server 120 (S121), the DM server 120 performing the registration corresponds to a TrapMO instance. It is checked whether the 'ToRef TargetURT' has permission to perform the Add command (S122). That is, the DM client 110 performs a process of checking whether there is an appropriate authority to perform registration for inward notification.
  • step 122 if the DM server 120 has an additional authority to the corresponding node, registration is successfully completed by adding a node for inward notification (S123). However, in step 122, if the DM server 120 does not have additional authority to the corresponding node, registration fails (S 125).
  • 4B is a flowchart illustrating a notification procedure after registration for inward notification according to the prior art.
  • the client 110 does not perform a separate authority check on the generated inward trap by transmitting the corresponding trap event to the designated node and executing it.
  • this problem is not caused by TrapMO itself, but rather by a problem with the DM's security model on which TrapMO depends.
  • the DM client 110 is a DM.
  • the subject that executes the DM command is identified, and the subject is checked to see if it has the necessary authority to execute the DM command.
  • This security check is applied to the registration process of the inward trap, which ensures that the DM server 120 performing the round has the right to add to the TrapMO instance associated with the trap event to be monitored. It is ensured that 120 has the necessary authority for registration.
  • the subject that delivers the event information to the designated node is Enabler, and the subject that actually executes the command is the functional component that receives the event information. Becomes Therefore, the subject that executes the commands registered in the inward trap is not the DM server 120.
  • the nature of this inward trap notification process means that relying on the conventional DM security model does not solve the inward trap security problem.
  • 5A is a flowchart illustrating a problem of a method of processing an inward tram according to the related art.
  • the DM server 120 may restart the device. It is assumed that there is no privilege present (in this example, there is no execute privilege for 'DiagMonMO / Restart / Operations / Start,'), and that the TrapMO instance that you want to monitor has the privilege to add.
  • the DM server 120 may generate a trap event (trap_eventl) of the DM client 110;
  • WiFi.Connected sends an M command requesting registration to monitor the event (S141).
  • the DM server 120 sends an M command requesting registration to monitor the event (S141).
  • the DM server 120 sends an M command requesting registration to monitor the event (S141).
  • the DM client 120 generates a trap event (trap_eventl; WiFi_Connected).
  • the DM client 120 detects that a trap event (trap_eventl; WiFi_Connected) has occurred (S143).
  • DiagMonMO Diagnostic and Monitoring Management objects
  • the DM client 110 may be restarted.
  • the unauthorized DM server 120 may restart the terminal despite having only the right to add to the subtree of TrapMO. And this can be a serious security risk.
  • an outward trap may designate any server that reports an event occurrence when the DM server 120 registers a trap event monitoring with the DM client 110.
  • This feature has the advantage of increasing the scalability and flexibility in configuring the DM server 120 for OMA DM service. That is, the V server 120 that registers the trap event and the DM server 120 that monitors the trap event may be separated, thereby increasing scalability and flexibility.
  • these outward traps there is one drawback to the function of these outward traps: they can be configured to receive trap events from other DM servers that do not intend to monitor trap events.
  • 5B is a flowchart illustrating a problem of a method of processing an outward trap according to the prior art.
  • the first DM server O forwards to 'trap_eventl' of the first DM client 110.
  • the first DM server 120 is the second DM Outward traps are also registered in 'trap_eventl' of the client 110 (110), and information about the generated event is transmitted to the second DM server 120 (S 152).
  • the event trap_eventl is detected (S153 and S155).
  • the client (110 ,) sends information about each tram event that has occurred.
  • the data is transmitted to the server 120 '(S154, S156).
  • the DM server 120 generates an outward trap.
  • FIG. 6 illustrates a method for enhancing the security of a TrapMO according to the prior art.
  • the proposed method has a problem due to the runtime characteristics of the OMA DM Access Control List (AC ACL) on which TrapMO depends.
  • AC ACL OMA DM Access Control List
  • the VI specifies that each node has an ACL attribute, which indicates what command authority the DM server 120 has on that node.
  • ACL attribute indicates what command authority the DM server 120 has on that node.
  • the problem is that these nodes' ACLs can be changed because they have runtime characteristics. Therefore, even if you have execution permission at the same time during the registration process and allow registration, you will lose execution permission due to the ACL changed later.
  • the DM server 120 will first register a command that has permission to execute as an Inward trap, and later change it to another command that is not authorized for that command.
  • Another problem with the proposed method is that it does not include a method for improving the security weaknesses of the outward traps. Therefore, an outbound trap is used to transmit an unauthorized trap event to expose information of a sensitive terminal to the outside. , There is a possibility to forward the event to the DM server 120 that does not want to receive the trap event, or further exploit the DoS attack.
  • embodiments of the present invention are based on the Iinward trap and the Outward trap of TrapMO.
  • embodiments of the present invention provide a method for enhancing security for each of an inward trap and an outward trap. to provide.
  • the DM server 120 For inward traps, the DM server 120 performs the inward trap list for the DM client 110, and when an event is generated and a registered command is executed, an authorized DM server ( Only 120 suggests ways to carry out the command. At this time, even if the ACL, which is a runtime attribute of the DM tree, is changed, a method that can determine whether to execute the command is suggested.
  • the DM client 110 uses the DM account information of the DM client 110.
  • Bootstrap is a method that allows receiving events only for trusted DM servers 120.
  • the second method is Optimistic Notification Control, which can be used efficiently when low outbound trap attempts are in violation of security.
  • a method for enhancing TrapMO security is divided into an inward trap and an outward trap.
  • Trap trap management object tree
  • the trap management object tree according to the embodiments disclosed herein further includes a 'ToRei7TargetURI / ⁇ x> / RegisteredServerID' node.
  • server identification information of the DM server 120 that registered the trap event is stored. If a trap event occurs after registration, the DM client 110 refers to the server identification information stored in the trap event to determine whether the DM server 120 that registered the trap event has an execute right in the ACL. Can solve security problems that reflect runtimes.
  • a transition from one state to another refers to the transition from one state to another.
  • the process can be immediately, almost immediately, incrementally or at any other appropriate rate.
  • the progress of the process can be controlled automatically by a device such as a terminal once the process is activated, or can be controlled by the user.
  • a device such as a terminal once the process is activated, or can be controlled by the user.
  • the process flow described below includes a number of actions that appear to occur in a particular order, these processes may be performed in series or in parallel (e.g., parallelizing or multiplying).
  • 8A is a flowchart illustrating a process of strengthening security when registering an inward trap according to a first embodiment of the present invention.
  • This method allows the DM server 120 to send specific traps to the DM client 110.
  • the process includes storing an identifier (ServerlD) of the DM server 120 that performs registration.
  • the identifier of the DM server 120 uniquely refers to the DM server 120 and may include the domain name of the DM server 120.
  • the DM client 110 needs to check whether the 'ServerlD' to be stored is correct before storing the 'ServerlD' (identifier) of the DM server 120 performing registration in the inward trap.
  • the DM account information of 110) can be used.
  • the DM account stores the information of this I server 120 bootstraped by the DM client 110, and since the certificate also includes authentication information, the DM client 110 stores the DM server 120 ), Verify that 'ServerlD' is correct (valid), save only 'ServerlD' that is valid (valid), and complete the registration successfully. If 'ServerlD is not valid (invalid), registration will fail.
  • the DM client 110 may send a trap event (trap_eventl;
  • Inward trap registration request for monitoring the ID of the trap event to be monitored is received (S201). Inward trap registration request is sent by DM server 120 to DM
  • an Add command By sending an Add command to the client 110, it searches for an instance with TrapID of 'tmp_eventl' among the instances of TrapMO and requests an Add command under 'ToRef / TargetURI'.
  • the added node must include the address ('URI1') of the node to be executed when a trap event occurs.
  • the DM client 110 checks whether the DM server 120 has a right to perform the command (S202). This is a process of checking the registration authority of the DM server 120.
  • the DM Client (110) is a DM that performs Inward Trace Registration.
  • the server ID (server identifier) of the server 120 is obtained to determine suitability of ServerlD (S203). Suitable ServerlD has DM Client 110
  • the account must contain the information of the DM server 120 including 'ServerlD', and must also be the ServerlD of the DM server that can be authenticated using the authentication information contained in the DM account.
  • the DM server currently registering Inward traps
  • This process is to check the notification authority of Inward trap.
  • the DM client 110 performs Inward trap registration when the VI server 120 has appropriate registration authority through steps 202 to 204 (S205). This process is to perform the Add DM command sent from the DM server 120 in step 202.
  • the DM client 110 stores the appropriate 'ServerlD' of the DM server 120,
  • the client 110 may import 'ServerlD' which has performed this registration.
  • step 206 Upon successful completion up to step 206, inward trap registration is completed and registration is successful (S207).
  • registration fails S208. If registration fails, DM client 110 additionally sends a Result Code (e.g., "Not Authorized") to inform DM server 120 of registration failure.
  • a Result Code e.g., "Not Authorized”
  • 8B is a diagram illustrating security at the time of notification of an inward trap according to the first embodiment of the present invention.
  • the present embodiment relates to a DM that changes dynamically in relation to the notification of an inward trap.
  • the DM client 110 executes a notification result execution command of the inward trap and enables the TrapMO enabler or the inward trap.
  • DM client (110) is also a command By checking the ACL information immediately before execution, it is determined whether to allow the command execution by reflecting the dynamically changing ACL.
  • the DM client 110 receives the identification information ('trap_eventl') of the trap event.
  • a TrapMO instance with a TrapID of 'trap_eventl' is searched (S213).
  • the DM client 110 sub-subscribes the TrapMO instance found in step 213.
  • the URI ('ToRefTargetURI / ⁇ x> / URr) is retrieved from the tree (S214).
  • the DM client 110 obtains' ServerlD 'of the DM server 120 that registers the URI (' ToRef / TargetURI / ⁇ x> / URr) (S215).
  • the DM client 110 executes the node indicated by the value of the URI ('ToRef TargetURI / ⁇ x> URT) (S217).
  • step 216 If it is determined in step 216 that there is no notification authority, a notification failure is handled.
  • the DM client 110 may process using the following method.
  • the first method is that when the notification fails, the DM client 110 does not do anything else (silent discard).
  • This generic alert is a type (e.g.,
  • the third method is that if the notification fails, the DM client 110 sends a corresponding Inward trap.
  • the client 110 notifies the VI server 120 of the failure before it terminates, allowing the DM server 120 to handle the notification failure if necessary. In other words, you can take the necessary steps to secure the execution rights.
  • FIG. 9 illustrates a notification failure processing process according to the first embodiment of the present invention. Drawing.
  • the DM client 110 notifies the DM server 120 through the generic alert before notifying the DM server 120 of two notification failures. Until the first two failed notifications, the DM server 120 is notified to the DM server 120 through a generic alert. The generic alert at this time is the same as the generic alert of the second method.
  • the DM client 110 sends a general alert to the DM server 120 to release the inward trap.
  • This general alert includes the type (eg 'urn: oma: at: trapmo: 1.0: InwardTrapUnregistered')- ⁇ : indicating that the inward trap has been revoked.
  • the generic alert contains the event trap.
  • a generic alert that informs the termination of this event trap may be sent by the DM client 110 to the DM server 120 before or after the termination is completed.
  • 9 illustrates a case in which the DM client 110 sends a generic alert that informs the termination of an event trap before the event trap is canceled.
  • the DM server to be notified of the cancellation is the VI server 120 which rounds up the canceled inward trap, and 'ServerlD' of the DM server 120 is stored in, for example, oRef7TargetURI / ⁇ x> / RegisteredServerID.
  • the DM client 110 may not send a generic alert when the notification fails, and the number of notification failures until the trap event is terminated is determined by the DM.
  • the client 110 and the DM server 120 may be determined through negotiation.
  • the terminal must authenticate that the DM server 120 has the appropriate rights for Inward registration and notification described below.
  • the DM server 120 creates a subtree under the 'ToRef / TargetURT node.
  • Inward traps can be registered by adding them.
  • DM server 120
  • Registration is not allowed unless you have permission to execute the executable node indicated by 'ToRef / TargetURI'.
  • the terminal must verify the execution permission along with basic ACL rules (eg, additional permission to add a sub-tree). If the DM server 120 does not have execution rights, the round should be rejected with a TrapMO Result Code '1400 (registration failed due to inadequate authority)'.
  • the DM server 120 identified by the 'RegisteredServerlD' node which is a sibling node of ToRef / TargetURI / ⁇ x> / URr, is identified by the 'ToRef / TargetURI / ⁇ x> / URr node.
  • the trap can be notified to the executable node indicated by the 'ToRef7TargetURI / ⁇ x> / URT node, as long as it has the Execution permission of the indicated executable node.
  • ACLs can change dynamically. For example, the terminal must confirm the execution permission (Exec permission right) before notifying the trap event, or the terminal must initiate a check process according to the ACL change.
  • the DM server 120 does not have the execution authority of the executable node, the related inward trap list should be released as soon as practical. After the inward trap has been terminated, the terminal should remove the sub-tree subtracting under the 'ToRef / TargetURI' node. Generic Alert to notify you of termination
  • It may be sent to the DM server 120 identified by the 'RegisteredServerlD' node.
  • a second embodiment of the present invention provides a DM server 120 to which a generated trap event is delivered.
  • the DM account of the DM client 110 stores information of the DM server 120 registered by the DM client 110 through bootstrapping.
  • the information of the DM server 120 stores the address, authentication means, authentication value, etc. of the DM server 120, including 'ServerlD'.
  • DM servers 120 registered in the account (Account) can be seen to have a trust relationship (trust relationship) with the DM client (110).
  • Privacy sensitive information may also be included. For example, a tram event occurs when a terminal moves to a specific region. Therefore, it is necessary to limit the DM server 120 to which the trap event is forwarded to the DM server 120 trusted by the DM client 110, and which DM server 120 can be trusted or not. This can be checked through the VI Account information in 110). If it is determined that there is no trust relationship because the DM server 120 to which the trap event is forwarded is not registered in the DM account, the DM server 120
  • the client 110 bootstraps the server and creates a DM account (Account), and then proceeds with the registration process.
  • Account DM account
  • the DM server 120 receiving the outward trap event may be limited to the DM server 120 itself performing the registration.
  • the DM client 110 receives an outward trap registration request from the DM server 120 for monitoring a trap event 'trap event' (TrapID) (S211).
  • the request may be a request to transmit the result of the generated trap to the DM server identified as 'DMS1'.
  • the DM client 110 checks whether the DM server 120 has a right to perform outward trap registration (S212). This process causes the DM client 110 to search for a TrapMO instance with a TrapID of 'trap_eventl',
  • the DM client 110 attempts to register the DM server 120 as a trap event recipient.
  • Another DM server ('DMS1') checks whether the current DM client 110 bootstrap DM server 120 (S213). This can be confirmed by finding the DMAcc instance that has 'ServerlD,' of server I ('DMS1') in the DM account owned by DM client 110. Further, by checking the authentication information and the like stored in the found DMAcc instance, it is possible to verify whether the DM server 'DMS1' is a bootstrap-DM server correctly.
  • the client 110 attempts to bootstrap to the DM server 'DMS1' (S215).
  • step 218 the process proceeds to step 218 and registration fails.
  • the server 120 can prevent the DM server 120 other than the DM server 120 from registering as a trap event receiver (S214).
  • DM client 110 checks whether DM server 120 and DM server ('DMS1') are correctly bootstrapped
  • ServerlD of the server 120 and ServerlD of the DM server ('DMS1') may be compared.
  • step 214 if the DM server 120 and the DM server ('DMS1') are bootstrap-strapped correctly, and ServerlD of the DM server 120 and ServerlD of the DM server ('DMS1') are the same. Perform the registration process. That is, the DM server ('DMS1') is added as a child node under the 'ToRef / TargetServer' node (S216), and thus the registration process is successfully completed (S217).
  • the DM server 120 If the DM server 120 wants to receive traps from the terminal, it will add a sub-tree under the 'ToRef / TargetServer' node. In order to succeed in registration , The terminal
  • 11A and 1 IB show registration of an outward trap according to a third embodiment of the present invention.
  • the second way to enhance the security of outward traps is Optimistic Notification Control.
  • the first method is to send a trap event, which is sensitive information of the DM client 110, only to the trusted DM server 110, while the second method does not want the trap event of the DM client 110 to receive the event.
  • This is a method of preventing transmission to the DM server 120.
  • an unspecified DM server 120 may be registered as a trap event recipient, which may cause the trap event to be forwarded to a DM server 120 that does not want to receive the trap event, or further exploited in a DoS attack. .
  • the second approach solves the security weaknesses of these outward traps and is very effective in situations where there are not many malicious outward traps.
  • the DM client 110 performs the outward trap registration process in the same manner as the conventional process. That is, when a DM server is registered as a trap event receiver, the DM server 120 proceeds with registration without checking whether it wants to receive the trap event. However, the DM client 110 stores a server identifier ('ServerlD') of the DM server 110 that has performed the outward trap registration. Of course, the stored 'ServerlD' must be a valid 'ServerlD' identified through a DM account. When the DM client 110 generates a trap event later and transmits the event information to the VI server registered as a receiver, the DM client 110 sends 'ServerlD' information that performed the round of the trap event.
  • 'ServerlD' server identifier
  • the DM server having received the trap event information, determines whether the tram event reception is secure through the 'ServerlD' attached to the event information and the trap event contents. If it is determined that the trap event reception is not secure, the DM server may send a response to the DM client 120 to request that the tram event registration be canceled.
  • the DM client 110 sends a DM from the DM server 120.
  • the request may be a request to transmit the result of the generated trap to the DM server 'DMS1'.
  • the VI client 110 checks whether the DM server 120 has the authority to perform the outward trap round (S222). This process causes the DM client 110 to find an instance of 'TrapMO' with a TrapID of 't p_eventl',
  • the DM client 110 performs the outward trap registration of the DM server 120.
  • a 'ServerlD' server identifier
  • determines the suitability of the 'ServerlD' S223.
  • DM client 110 has completed the bootstrapping (bootstrapping)
  • the DM client 110 of the DM account (Account) must include the information of the DM server 120 including' ServerlD ,, In addition, it must be 'ServerlD' of the IDM server 120 that can be authenticated using the authentication information contained in the DM account. Also It should be 'ServerlD' of the DM server 120 currently registering inward traps.
  • step 223 if there is no problem in registering an outward trap, DM
  • the client 110 performs the actual registration process. That is, the DM server ('DMS1') is added as a child node under the oRef / TargetServer 'node (S224), and the DM server 120
  • outward trap registration fails (S227). This completes the Outward Trap Round process.
  • the DM server 'DMS1' receives an Outward trap notification sent by the DM client 110 according to a trap event occurrence (S231).
  • the outward notification received contains the identification information (ID) of the server that registered this trap event.
  • the DM server 'DMS1' determines whether the received trap event is valid (S232). For this purpose, the DM server ('DMS1') determines the information of the 'ServerlD' and the Outward trap event that registered the outward trap included in the outward notification. That is, it may be determined that the trap is registered by the DM server 120 having no trust relationship with the trap or is not valid trap event information.
  • the server 'DMS1' processes the received trap event (S233).
  • step 232 when it is determined that the received trap event is not valid, the DM server (DMS1) sends a request to the DM client 110 to cancel the trap event registration ( S234).
  • the second embodiment of the present invention described above is a method of sending a trap event, which is sensitive information of the DM client 110, to the trusted DM server 120 only.
  • the second embodiment of the present invention provides a DM client 110.
  • Trap event is transmitted to the DM server 120 that does not want to receive the event.
  • These two methods may be applied separately, but the two methods may be used at the same time. That is, by applying both methods, it is possible to prevent the trap event from being transmitted to the DM server 120 that does not want to receive the trap event while simultaneously sending the trap event to a reliable DM server.
  • Fanout means that the DM server 120 sends a DM command to the DM gateway, and the DM gateway sends a DM command to all end devices. ) Is sent. That is, the DM server 120 transmits a DM command only once to the DM gateway, so that all the DM commands can be sent to the end devices targeted by the DM command. Terminal management can be performed. To use this fanout, the DM server 120 must
  • Fanout Registration is performed by adding related sub-trees such as DM commands under 'Fanout / ⁇ x>', in which case
  • the Image Inventory function allows the DM server 120 to store image data, such as a SW package, to the DM Gateway, and to the end device, which is stored to the DM Gateway. Refers to an image. Image Inventory function is to end the image in the DM gateway repeatedly than the remote DM server 120 sends each image to the end device. It is much more efficient because it can be delivered to a device. In order to perform this image inventory function, an image registration process is required. In this process, the DM server 120 performs registration by adding related images under ' ⁇ x> / Images / ⁇ x>' of 'ImagelnventoryMO', which is also guaranteed by ACL. Just checking the Add permission is enough.
  • the process of registering SW that can be downloaded to the terminal is similar, and the DM server 120 is located under ' ⁇ x> / Download / ⁇ x>' of the SCOMO.
  • Embodiments of the present invention assume that an ACL may dynamically change during terminal management.
  • ACL properties of nodes are described in detail in Section 7. Properties of Nodes of [OMA-DM-TND], which is incorporated herein by reference.
  • the DM commands allowed in the ACL are Get and Replace, which means that the DM server 120 can freely change the ACL value as needed.
  • the authority of the DM server 120 is removed (Enterprise domain (Enterprise domain) ), Or by granting a new permission to the DM server 120 by request
  • Enterprise domain Enterprise domain
  • Enterprise DM server 120 delegates administrative rights).
  • the ACL may change from time to time in the terminal management performance due to the above reasons, and the present invention includes a method of reinforcing and reflecting it in Inward trap security.
  • This VI client 110 receives a trap event registration request for monitoring a trap event 'trap_eventl' from a DM server (1 2 ⁇ 3) (S301). At this time, the DM server 120 rounds the Inward trap and, when the 'trap_eventl' event occurs, sends the command 'URir', which is the command of the terminal to be executed (in this embodiment, 'trap_eventl' is
  • URI1 DiagMonMO / Restart / Operations / Start
  • the DM client 110 receives the Inward trap registration request from the DM server 120, checks the right to register the DM server 120 with the trap event, and then performs Inward trap registration. The DM client 110 checks whether the 'ServerlD' of the DM server 120 is correct (bootstrapping or not).
  • the DM client 110 detects that WiFi is connected (S303).
  • the DM client 110 indicates that a 'trap_eventr' has occurred from the WiFi connection.
  • the DM client 110 searches for a URI registered as an inward trap and ServerlD mapped with the URI (S305). For example, DM client 110 starts from the root of TmpMO, and TrapMO with TrapID 'trap_eventl'.
  • the DM client 110 searches 'TargetURI / ⁇ x> / URT' registered as an Inward trap from the found TrapMO instance, and searches the ServerlD mapped with the URI.
  • the DM client 110 checks whether the ServerlD is a correct server identifier through a DM account of the DM client 110.
  • the DM client 110 checks whether the ServerlD found has the execute permission for the node indicated by the URI.
  • the DM client 110 determines that only ServerlD that satisfies these two conditions has the authority for Inward notification.
  • An ACL representing the execution rights of a DM tree can be changed at runtime
  • FIG. 13 is a flowchart illustrating an outward trap event registration and notification process using a DM account according to the second embodiment of the present disclosure.
  • the DM client 110 receives a trap event registration request for monitoring a trap event 'trap_eventl' from the DM server 120 (S311). At this time, the DM server 120 registers an outward trap and designates a DM server ('DMS1') as a server to report an event when a 'trap_eventl' event occurs.
  • 'trap_eventr' is a 'Low_Battery' event.
  • the DM client 110 authenticates the outward trap registration received from the DM server 120 (S312).
  • the DM client 110 checks whether the DM server 'DMS1' has registration authority for this registration. Also, check whether the ServerlD of the DM server ('DMS1') is correct (bootstrapping and additionally, the identifier of the DM server 120) through the DM Account. At this time, if the DM server 'DMS1' is not bootstrapping, bootstrapping may be additionally performed. If the DM server ('DMS1') does not have registration authority or bootstrapping fails, registration fails.
  • the registration is performed (S313).
  • the DM client 110 sends the DM outbound trap registration result.
  • the DM client 110 detects a 'Low_Battery' event (S315).
  • the DM client 110 transmits information related to the trap event 'trap_eventl' to the DM server 120 (S317).
  • the DM client 110 receives a trap event registration request for monitoring a trap event 'trap_eventl' from the DM server 120 (S321). At this time, the DM server 120 registers an outward trap, and designates a DM server ('DMS1') as a server to report an event when a 'trap_eventl' event occurs.
  • 'trap_eventl' is
  • the DM client 110 receives an Outward Trap Round Request from the DM server 120,
  • the DM client 110 After checking whether the DM server 'DMS1' has a right to perform registration, the corresponding round is performed (S322).
  • the DM client 110 checks whether the ServerlD of the DM server 120 is correct through a DM account, and stores the connection with this registration. The correct ServerlD is bootstrapping through the DM Account and must be the server identifier of the DM server 120 performing the registration. If the ServerlD is not correct, the round fails.
  • the DM client 110 is the battery (battery) is lowered below a certain level
  • the VI client 110 transmits the information related to the trap event 'trap_eventl' to the DM server 'DMS1' and the ServerlD stored in step 322 (S325).
  • the DM server ('DMS1') authenticates this outward trap registration from the information of 'trap_eventl' received from the DM client 110 and the ServerlD information that registered this outward trap (S326).
  • the DM server ('DMS1') can verify this outward notification through a trust relationship between itself and the server with ServerlD. If the outward notification was previously authenticated, step 326 can be omitted and there is no need to keep checking for duplicate identical outward notifications.
  • 'DMS1' is a DM for 'trap_eventl' to DMS client 110
  • the request for deregistration of the server 'DMS1' is transmitted (S327).
  • 15 is a block diagram of a terminal 400 and a server 500 disclosed herein.
  • the terminal 400 may include a storage unit 410 and a controller 420.
  • the storage means 410 stores the method according to the embodiment shown in Figs.
  • the controller 420 controls the storage means 410 and the transceiver 430. Specifically, the controller 420 executes the methods stored in the storage means 410, respectively.
  • the controller 420 transmits the above-described signals through the transceiver 430.
  • the server 500 includes a storage means 510, a controller 520, and a transceiver 530.
  • the storage means 510 stores a method according to the embodiment shown in Figs.
  • the controller 520 controls the storage means 510 and the transceiver 530. Specifically, the controller 520 executes the methods stored in the storage means 510, respectively.
  • the controller 520 transmits the aforementioned signals through the transceiver 530.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Catching Or Destruction (AREA)

Abstract

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

Description

명세서
발명의 명칭 : 트랩 이벤트 등록 및 알림 방법 및 이를 채용하는 단말 기술분야
[1] 본 명세서는 DM 클라이 언트에서 트랩 이벤트를 등록하고 트랩 이벤트의
발생을 알리는 방법과 이를 채용하는 단말에 관한 것이다.
배경기술
[2] 휴대용 단말 관리를 위한 대표적 인 기술로 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 세션을 시작할 수 있다.
[3] 비록 DM 세션은 양방향 세션이지만，이를 통해 주고 받게 되는 DM
명 령들 (Commands)은 비 대칭적 인 특성을 갖는다. 즉 DM 서버는 DM
클라이 언트에 게 모든 DM 명 령을 보낼 수가 있지만, DM 클라이 언트는 DM 서버 의 장치 정보 (Devlnfo)/장치 상세 정보 (DevDetail 정보)를 바꾸는
변경 (Replace) 명 령과 결과들 (Results), 그리고 경고 (Alert)만을 DM 서버에게 보낼 수가 있다.
[4] DM은 Challenge-Credential에 기반한 사용자 인증 프레임워크를 제공한다. 이 프레임워크는 DM 서버와 DM 클라이 언트가 서로를 인증할 수 있는 양방향 인증 서비스를 제공하며 , MD5, HTTP-Digest, Basic Authentication 등 다양한 인증 메커니즘을 사용할 수 있도록 해준다. 이 인증 방법을 사용하면，먼저 인증을 요청하는 쪽이 Challenge를 상대방에 게 보내게 된다. DM은 앞서 말한 것처 럼 양방향 인증이기 때문에 DM 클라이 언트, DM 서버 모두가 Challenge를 보낼 수가 있다. Challenge를 받은 상대방은 자신의 Credential 정보를 보내주어야 하며 , 이 Credential올 받아보고 상대방을 인증하게 된다.
[5] 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) 등이 있다.
[6] 위에서 언급되지 않는 대표^ 인 MO로 TrapMO(Trap Management Object) 를 들 수가 있는데， TrapMO는 모바일 디바이스의 이벤트를 모니터링하고 관련 정보를 보고하기 위한 기능을 수행한다. 이 러한 모니터링 이벤트의 종류로는 콜 셋업 실패 (call setup failure), 배터리 레벨 (battery level), RF 손실 (RF loss), 메모리 사용 레벨 (memory usage level), DM 계정 수정 (DM Account modified), 외부 저장소 부착 (external storage attached), SAV 또는 H/W 결함 (S/W or H/W faults) 등을 들 수 있다. 이 렇게 단말의 상태를 모니터 링하고 보고하는 기능은 매우 유용한데，예로 RF 손실 (RF loss)을 모니터 링하는 기능은 기지국의 커버 리지 (coverage)를 개선하는데 큰 도움올 줄 수 있다.
[7] 단말 안에서 각각의 트랩 (Trap) 이벤트는 고유의 트랩 식 별 정보 (Trap ID)를 가지고 구분이 된다. 여기에서 , 트랩은 실행중인 프로그램에서 발생하는 이벤트를 검출하기 위해 특별한 조건을 걸어 놓은 것을 의미할 수 있다. 예를 들어， DM 서버가 DM 클라이 언트의 특정 트랩 이벤트 (trap_eventl)를
모니터 링하기 위해서는 둥록 (registration)과 알림 (notification)이 라는 두 가지 단계를 거쳐야 한다. 등록 (registration)은 DM 서버가 특정 이벤트 (trap_eventl)을 모니터 링하기 위해 DM 클라이 언트에게 모니터 링 등록올 요청하는 단계이며 , 알림 (notification)은 DM 클라이 언트가 해당 이 벤트 (trap— event 1)가 발생하였을 경우, 관련 정보를 DM 서버에 보고하는 단계이다.
[8] . TrapMO는 단말의 이벤트를 모니터 링하는 기능을 제공하는데, 해당 이벤트가 발생하였을 경우, 어디로 이벤트 관련 정보를 보고할 것인지에 따라
내부 (Inward)와 외부 (Outward) 타입으로 나눌 수가 있다. Outward 타입의 트랩은 단말에서 해당 이벤트가 발생하였을 경우, 발생한 이벤트에 관한 정보를 단말의 외부 서버로 전달하는 트랩이다ᅳ 이 때 외부 서버는 단말에 트랩 이벤트를 등록한 DM 서버 자신일 수도 있고, 제 3자의 DM 서버 일 수도 있다. Inward 타입의 트램은 발생한 트램 이벤트에 관한 정보가 외부 서버로 전달되는 것이 아니고，단말 내부의 다른 컴포넌트로 전달되는 트랩이다.
발명의 상세한 설명
기술적 과제
[9] 본 명세서에 개시된 실시 예들은 전술한 문제점올 해결하기 위한 것으로서，
TrapMO의 Inward 트랩 및 Outward 트랩과 관련된 보안상의 취 약점을 보완할 수 있는 방법을 제공하는 것을 목적으로 한다.
과제 해결 수단 [1이 상기 기술적 과제를 해결하기 위한 본 명세서에 개시된 제 1 실시 예에 따른 단말상의 다른 기능적 컴포넌트에 트램을 통지하는 단말의 트램 동작 제어 방법은, 서버로부터 트램 등록 요청올 수신하는 단계 여기에서 상기 트랩 등록 요청은, 트랩 (trap) 식 별자，서버 식별자 및 타겟 식별자를 포함하고; 상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식 별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계 ; 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 서 버 식 별자를 상기 트랩 식 별자와 연관되게 저장하면서 트랩을 둥록하는 단계 여 기에서 상기 트랩은 트랩 이벤트를 포함하고 상기 트랩 식별자와 연관되고; 상기 트랩 이벤트를 감지하는 단계；상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계 ; 및 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 트램 이벤트를 상기 실행 가능한 노드에 통지하는 단계를 포함하는 것을 특징으로 한다.
[11] 일 실시 예에 있어서，상기 저장된 서버 식 별자에 의해 식 별되는 서버가 상기 실행 가능한 노드의 실행 권한올 가지고 있는지 확인하는 단계는，접근 제어 리스트 (ACL; Access Control List)에 기초하여，상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계인 것을 특징으로 한다.
[12] 또한 일 실시 예에 있어서 , 상기 트랩을 등록하는 단계는, 상기 트랩 식별자와 연관된 트랩의 서브 -트리 (sub-tree)를 추가하는 단계를 포함하고，상기 서브 -트리 (sub-tree)는, 상기 실행 가능한 노드를 지시하는 타겟 식별자와 상기 서버 식 별자를 포함하는 것을 특징으로 한다.
[13] 또한 일 실시 예에 있어서，제 3 항에 있어서 , 상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식 별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계는, 상기 서버가 상기 실행 가능한 노드의 실행 권한과 함께 서브 -트리를 생성 할 수 있는 추가 권한이 있는지 확인하는 단계를 포함하는 것을 특징으로 한다.
[14] 또한 일 실시 예에 있어서 , 상기 트랩 동작 제어 방법은，상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있찌 않으면, 상기 서버에 등록 실패를 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 한다.
[15] 또한 일 실시 예에 있어서，상기 트랩 동작 제어 방법은，상기 저장된 서버
식별자에 의해 식 별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있지 않으면，상기 트램의 등록을 해제하는 단계를 더 포함하는 것을 특징으로 한다.
[16] 또한 일 실시 예에 있어서 , 상기 트랩 동작 제어 방법은, 상기 저장된 서버
식별자에 의해 식별되는 서버에 상기 트랩의 둥록이 해제되 었음을 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 한다. [17] 한편, 상기 기술적 과제를 해결하기 위 한 본 명세서에 개시된 제 1 실시 예에 따른 단말은, 서버로부터 트랩 등록 요청을 수신하는 송수신부 여기에서 상기 트랩 등록 요청은，트랩 (trap) 식별자，서버 식별자 및 타겟 식 별자를 포함하고; 및 상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식 별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하고, 상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 서버 식별자를 상기 트랩 식 별자와 연관되 게 저장하면서 트랩을 등록하고，여기 에서 상기 트랩은 트랩 이벤트를 포함하고 상기 트램 식 별자와 연관되고, 상기 트램 이벤트를 감지하고， 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 컨트를러를 포함하고, 상기 송수신부는，상기 저장된 서버 식 별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면, 상기 트랩 이벤트를 상기 실행 가능한 노드에 통지하는 것을 특징으로 한다.
[18] 다른 한편，상기 기술적 과제를 해결하기 위한 본 명세서에 개시된 제 2 실시 예에 따른 서버에 트램을 통지하는 단말의 트램 동작 제어 방법은，서버로부터 트랩 등록 요청을 수신하는 단계 여기 에서 상기 트랩 등록 요청은 트랩 식 별자 및 상기 트랩이 통지되는 서버의 식별자를 포함하고; 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식 별자와 동일한지 확인하는 단계 ; 및 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식 별자와 동일하면，상기 트랩 식별자와 연관된 트램을 등록하는 단계를 포함하는 것을 특징으로 한다.
[19] 일 실시 예에 있어서，상기 트랩 동작 제어 방법은, 상기 트랩 등록 요청에
포함된 서버의 식 별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식별자와 동일하지 않으면，상기 단말에 트랩 둥록 요청을 송신한 서버에 등록 실패를 나타내는 메시지를 송신하는 단계를 더 포함하는 것을 특징으로 한다.
[2이 또 다른 한편，상기 기술적 과제를 해결하기 위한 본 명세서에 개시된 제 2 실시 예에 따른 서버에 트랩을 통지하는 단말은, 서버로부터 트랩 등록 요청을 수신하는 송수신부 여기에서 상기 트랩 등록 요청은 트랩 식 별자 및 상기 트랩이 통지되는 서버의 식 별자를 포함하고; 및 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청올 송신한 서버의 식별자와 동일한지 확인하고, 상기 트램 등록 요청에 포함된 서버 의 식 별자가 상기 단말에 트랩 등록 요청을 송신한 서 버의 식별자와 동일하면，상기 트랩 식별자와 연관된 트랩을 둥록하는 컨트롤러를 포함하는 것을 특징으로 한다.
발명의 효과
[21] 본 발명에 따르면, DM 서버가 Inward 트랩올 이용하여 단말의 특정 이벤트를 모니터 링 시，이벤트 발생의 결과로 수행되는 명 령에 대해 DM 서버가 적절한 권한을 가지고 있다는 것을 보장할 수 있다. [22] 또한，본발명에따르면, DM트리의런타임속성인 ACL이변하더라도, DM 서버가 Inward트랩을이용해단말에수행하는명령이변경된 DM트리의 ACL을 반영하여적합함을보장할수가있다.
[23] 또한，본발명에따르면, DM서버가 Outward트랩을이용하여단말의특정 이벤트를모니터링시，발생이벤트의정보가 DoS공격등에악용될수있는 가능성을크게줄일수있다.
[24] 또한，본발명에따르면， DM서버가 outward트랩을이용하여단말의특정 이벤트를모니터링시,발생이벤트의정보가이를원하지않는 DM서버에게 전달되는것을막을수있다.
도면의간단한설명
[25] 도 1은본명세서에개시된실시예들에따른장치관리아키텍쳐를나타내는 도면이다.
[26] 도 2a는종래기술에따른 Outward트랩의이벤트모니터링과정을예시적으로 나타내는흐름도이다.
[27] 도 2b는종래기술에따른 Inward트랩의이벤트모니터링과정을예시적으로 나타내는흐름도이다.
[28] 도 3은종래기술에따른트랩관리객체트리 (Trap Management Object Tree)의 구조를나타내는도면이다ᅳ
[29] 도 4a는종래기술에따른 Inward통지를위한등록절차를도시하는
흐름도이다.
[30] 도 4b는종래기술에따른 Inward통지를위한등록이후,통지절차를도시하는 흐름도이다.
[31] 도 5a는종래기술에따른 Inward트램을처리하는방식의문제점을나타내는 흐름도이다.
[32] 도 5b는종래기술에따른 Outward트랩을처리하는방식의문제점을나타내는 흐름도이다.
[33] 도 6은종래기술에따른 TrapMO의보안을강화하기위한방법을나타내는 흐름도이다.
[34] 도 7은본명세서에개시된실시예들에따른트랩관리객체트리 (Trap
Management Object Tree)를나타내는도면이다.
[35] 도 8a는본발명의제 1실시예에따른 Inward트랩의등록시에보안을
강화하는과정을나타내는흐름도이다.
[36] 도 8b는본발명의계 1실시예에따른 Inward트랩의알림시에보안을
강화하는과정을나타내는흐름도이다.
[37] 도 9는본발명의제 1실시예에따른알림실패처리과정을나타내는
도면이다.
[38] 도 10은본발명의제 2실시예에따른 Outward트랩의등록시에보안을 강화하는 과정을 나타내는 흐름도이다.
[39] 도 11a 및 도 l ib는 본 발명의 제 3 실시 예에 따른 Outward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.
[40] 도 12는 본 명세서에 개시된 제 1 실시 예에 따른 Inward 트랩 이벤트 등록
과정을 나타내는 흐름도이다.
[41] 도 13은 본 명세서에 개시된 제 2 실시 예에 따른 DM 계정 (Account)을 이용하여
Outward 트랩 이밴트 등록 및 알림 과정을 나타내는 흐름도이다.
[42] 도 14는 본 명세서에 개시된 제 3 실시 예에 따른 낙관적 알림 제어 (Optimistic
Notification Control)를 이용한 Outward 트랩 이벤트 둥록 및 알림 과정을 나타내는 흐름도이다.
[43] 도 15는 본 명세서에 개시된 단말 (400) 및 서버 (500)의 블록도이다.
발명의 실시를 위한 형태
[44] 이하, 첨부된 도면을 참조하여 본 발명의 특징과 바람직 한 실시 예를
구체적으로 설명 한다.
[45] 도 1은 본 명세서에 개시된 실시 예들에 따른 장치 관리 아키텍쳐를 나타내는 도면이다.
[46] 장치관리 (DM)는 DM 클라이언트 (110) 및 DM 서버 (120)를 포함하는 DM
인에 이블러 (100)에 의해 수행된다.
[47] DM 클라이 언트 (110)는 OMA(Open Mobile Alliance) 장치 관리 인에이불러에 명시된 DM 클라이언트의 요구사항을 따르는 추상적 인 소프트웨어
컴포넌트이다.
[48] DM 서버 ( 120)는 OMA 장치 관리 인에 이블러에 명시된 DM 서버의 요구사항을 따르는 추상적 인 소프트웨어 컴포넌트이다.
[49] 클라이언트 -서 버 알림 (DM-1)은 서버 (120)들이 클라이언트 (110)들에 장치 관리 알림을 보낼 수 있는 인터페이스를 제공한다. 클라이 언트 -서버 알림 (DM-1)은 중간 운반자이고, WAP 푸쉬 및 SIP 푸쉬와 같은 많은 프로토콜을 통해 동작할 수 있는 인터페이스이다.
[50] 장치 관리 클라이 언트-서버 프로토콜 (DM-2)은 서버 (120)들이
클라이 언트 (110)들에 장치 관리 명 령들을 송신하고, 클라이언트 (110)들이 서버 (120)들에 상태 및 알람을 송신할 수 있는 인터페이스를 제공한다. 장치 관리 클라이 언트-서버 프로토콜 (DM-2)은 증간 운반자이고， HTTP 및 HTTPS를 포함하는 많은 표준화된 바인딩을 제공하는 인터페이스이다. 이 인터페이스는 무선통신 (over-the-air) 장치 관리 성능을 제공하기 위해 무선연결 -기반 데이터 전달 프로토콜 (예를 들어， GPRS)을 통해 노출된다.
[51] DM 클라이 언트 (110)는 초기에 스마트 카드 (210) 상의 파일을 통해 공급될 수 있다. 이 파일은 DM 클라이 언트 (110)에서 설정을 셋팅하거나 변경하기 위한 일련의 DM 명 령들을 포함한다. 스마트 카드 (210)를 통한 DM 부트스트랩 프로파일 (DM-3)은 DM 클라이 언트 (110)로부터의 피드백이 제공되지 않는 단방향의 인터페이스이다. 다음의 실질적 인 기회에서 DM 서버 (120)에 연결되는
DM 클라이 언트 (110)가 유일한 기 대 결과이다.
[52] DM 클라이 언트 (110)는 초기에 몇몇 푸쉬 프로토콜에 의해 전송된 파일을 통해 공급될 수 있다. 이 파일은 DM 클라이 언트에서 설정올 셋팅하거나 변경하기 위한 DM 명 령들을 포함한다. 부트스트랩 프로파일 OTA(DM-4)는 DM 클라이언트 (110)로부터의 피드백이 제공되지 않는， OTA 서버 (220)에서 DM 클라이언트 (110)로의 단방향의 인터페이스이다. 다음의 실질적 인 기회에서 DM 서버 (120)에 연결되는 DM 클라이 언트 (110)가 유일한 기 대 결과이다.
[53] DM 클라이언트 (110)는 초기에 CP 인에 이블러 (230)를 통해 공급될 수 있다 . CP 부트스트랩 프로파일 (CP-1)은 DM 클라이 언트 (110)로부터의 피드백이 제공되지 않는, CP 인에 이블러 (230)에서 DM 클라이언트 (110)로의 단방향의
인터페이스이다. 다음의 실질적 인 기회에서 DM 서버 (120)에 연결되는 DM 클라이언트 (110)가 유일한 기 대 결과이다.
[54] 도 2a는 종래 기술에 따른 Outward 트랩의 이 벤트 모니터 링 과정을 예시적으로 나타내는 흐름도이다.
[55] DM 서버 (120)는 DM 클라이언트 (110)의 제 1 트랩 이벤트 (trap_eventl)를
모니터 링하기 위해 DM 클라이 언트 (110)에 등록한다 (S101). 여기에서， DM 서버 (120)는 단말에서 발생한 이벤트에 관한 정보를 이벤트를 등록한 DM 서버 (120) 자신에게 보내는 Outward 타입의 트랩 이벤트를 DM
클라이 언트 (110)에 등록할 수 있다.
[56] DM 서버 (120)는 또한 DM 클라이 언트 (110)의 계 2 트랩 이벤트 (trap_event2)를 모니터 링하기 위해 DM 클라이 언트 (110)에 등록한다 (S102). 여기 에서， DM 서버 (120)는 단말에서 발생한 이 벤트에 관한 정보를 이벤트를 등록한 제 2 DM 서버 (120，)에 게 보내는 Outward 타입의 트랩 이벤트를 DM 클라이 언트 (110)에 등록할 수 있다.
[57] DM 클라이언트 (110)는 둥록된 트랩 이벤트들이 검출되는지 모니터 링하고, 계 1 트랩 이벤트 (trap_eventl)가 발생함을 감지 할 수 있다 (S103).
[58] DM 클라이언트 (110)는 제 1 트랩 이벤트 (trap_eventl)의 발생을 이 트랩
이벤트에 등록되어 있는 DM 서버 (120)에 통지 (notification)한다 (S 104). 이때 DM 클라이 언트 (110)는 일반적 경고 (Generic Alert)로 관련 정보를 DM 서버 (120)에 게 전달하며 , 일반적 경고 (Generic Alert)에는 메타 타입 (Meta ype), 메타
포맷 (Meta.Format), 소스 위치 URI(Source.LocURI), 데이터 (Data) 등이 설정될 수 있다. Meta.Type은 urn:oma:mo: diagmon: 1.0:TrapNotification으로 설정되어 본 일반적 경고 (Generic Alert) 메시지가 트랩 이벤트 통지라는 것을 표시하고, 메타 포맷 (Meta oraiat)은 "chr"로 표시되며, 소스 위치 URI(Source.LocURI)는 발생한 트랩 이벤트와 연결되어 있는 TargetServer/<x>/ServerID의 주소를 표시 한다. 또한，데이터 (Data)는 트랩 식별자 (trap identifier)를 포함하여 , 어 떤 트랩 이벤트가 발생하였는지를 알려준다.
[59] DM 클라이언트 (110)는 계속하여 등록된 트랩 이벤트들이 검출되는지
모니터 링하고, 제 2 트랩 이벤트 (trap— event2)가 발생함을 감지할 수 있다 (S105).
[60] DM 클라이언트 (110)는 제 2 트랩 이벤트 (trap_event2)의 발생을 이 트랩
이벤트에 등록되어 있는 제 2 1) 서버 (120')에게 통지 (notification)한다 (S 106). 이 때 DM 클라이 언트 (110)는 일반적 경고 (Generic Alert)로 제 2 트랩
이벤트 (trap_event2)의 발생 관련 정보를 제 2 DM 서버 (120')에게 전달하며，기타 필요한 정보 (전술한 메타 타입 (Meta.Type), 메타 포맷 (Meta.Format), 소스 위치
URI(Source.LocURI), 데이터 (Data) 등)도 이때 같이 전달한다.
[61] 이와 같은 Outward 트랩을 통해 DM 서버 (120)는 DM 클라이 언트 (110)에서 발생하는 이 벤트를 모니터링하여 결과를 자신에게 보내게 하거나 다른 서버에게 보내게 할 수가 있다.
[62] 도 2b는 종래 기술에 따른 Inward 트랩의 이벤트 모니터 링 과정을 예시적으로 나타내는 흐름도이다.
[63] 전술한 바와 같이， Inward 트랩은 Outward 트랩에서와 같이 발생한 이벤트의 결과를 외부 DM 서버 (120)에 게 전달하는 것이 아니라，내부의 다른 기능적 컴포넌트에게 전달하는 트램이다.
[64] DM 서버 (120)는 DM 클라이 언트 (110)의 SCOMO(Software Component
Management Object)(304)에 게 패키지 (PKG1)를 다운로드 하도록 DM
명 령 (Command)을 보낸다 (SU 1). 여기에서， DM 명 령은 특정 노드 (예를 들어,
'SCOMO/Download/PKGl/Operations/Download')에 실행 (Exec) 명 령을 전달하는 것을 의미한다ᅳ
[65] DM 클라이언트 (110)의 SCOMO(304)는 DM 서버 (120)로부터 계 111 단계에서 수신한 실행 (Exec) 명 령에 따라 패키지 (PKG1)의 다운로드를 시작한다 (S112).
[66] DM 서버 (120)는 DM 클라이 언트 (110)가 로우 배터 리 (Low Battery) 상태가 되 면 패키지 (PKG1)의 다운로드 프로세스를 자동으로 취소하기 위해， DM
클라이 언트 (110)의 TrapMO(Trap Mobile Object)(302)에 Inward 트랩을 등록한다 (SI 13). 이 Inward 트랩이 등록됨에 따라， DM 클라이 언트 (110)는 트랩 이벤트 (trap_eventl; Low_Battery)가 발생하면，해당 이벤트 정보를 특정 노드 (예를 들어 , 'SCOMO/Download/PKGl/Operations/Stop')에 보내게 된다.
[67] DM 클라이언트 (110)는 등록된 트랩 이벤트의 발생을 모니터링하고，트랩 이벤트 (trap_eventl; Low_Battery)의 발생올 감지한다 (S 114).
[68] TrapMO(302)는 트랩 이벤트 (trap_eventl； Low— Battery)가 발생하면，이
이벤트에 등록되어 있는 Inward 통지 (notification)를 검 색하고, 해당 노드에 실행 (Exec) 명 령을 보낸다 (S115). 여기에서 , 해당 노드는 DM 서버 (120)가 Inward 트랩을 둥록할 때 DM 클라이언트 (110)에 전달한 것으로서 , 본 실시 예에서는 'SCOMO Download/PKGl/Operations/Stop'를 말한다.
[69] SCOMO(304)는 TrapMO(302)로부터 실행 (Exec) 명 령을 수신하여， 패키지 (PKG1)의 다운로드를 취소한다 (S116).
[70] 이와 같은 Inward 트랩을 이용하여， DM 서버 (120)는 별도의 메시지 없이 , 해당 단말의 DM 클라이 언트 (110)에서 이벤트가 발생했을 때，이벤트 발생에 관한 정보를 단말 내부의 다른 컴포넌트에 전달하여 이벤트 발생에 따른 적절한 처리가 이루어지 게 할 수 있다. 본 실시 예에서는, DM 서버 (120)가 DM 클라이 언트 (110)에 소프트웨어 패키지 (PKG1)의 다운로드를 명 령하고，단말이 저전력 (Low_Powered) 상태로 진입할 경우, 배터 리 소모를 줄이기 위해 패키지 (PKG1)의 다운로드를 취소하는 명 령을 TrapMO를 사용해 용이하게 처리할 수 있다.
[71] 전술한 바와 같이，트랩의 두 가지 종류인 Inward 트랩과 Outward 트랩은 모두 등록 (Registration)과 알림 (Notification)의 두 과정으로 구분할 수 있다. 이 등록과 알림은 모두 트랩 관리 객체 트리 (Trap Management Object Tree)를 통해서 처리되는데，이 TrapMO Tree를 통해 어떻게 Inward 트랩 이벤트와 Outward 트랩 이벤트가 처리되는지 구체적으로 설명한다.
[72] 도 3은 종래 기술에 따른 트랩 관리 객체 트리 (Trap Management Object Tree)의 구조를 나타내는 도면이다.
[73] 예를 들어， DM 서버 (120)가 DM 클라이언트 (110)에 트랩 이벤트 (trap_eventl)를 Inward 타입으로 둥록하는 상황을 가정한다. 트램 이벤트 (trap_eventl)가 발생하면， TrapMO는 발생한 이벤트에 관한 정보를 특정 URI(URIl)에 전달한다. 이 러한 Inward 트랩 이 벤트를 등록하기 위해서， DM 서버 (120)는 DM
클라이 언트 (110)의 TrapMO 인스턴스 증에서 TrapID가 trap_eventl인 TrapMO의 인스턴스를 검 색한다. DM 서버 (120)는 DM 클라이 언트 (110)의 TrapMO 서브 트리를 순희 (traverse)하며 , 해당 인스턴스를 검 색할 수 있고, 또는 아래의 표 1과 같은 상대 주소 (relative address)를 통해 해당 트랩 인스턴스를 가리킬 수 있다.
[74] 표 1
[Table 1]
<Item> <TargetParent>
<LocURI>.？ MOID=urn： oma: mo： oma-diagmontrap： 1.0&TrapID=trap_event 1 < LocU RI> </TargetParent> <Target> <LocURI>찾은 TrapMO 인스턴스의 경로 아래로 더 세부적 인 경로 지정 </LocURI> </Target> </Item>
[75] 전술한 방식으로 DM 서버 (120)가 TrapMO의 인스턴스를 발견하면，그
인스턴스의 자식 노드 중에서 TargetURI를 찾아 그 아래에 새로운 Inward 트랩인 URI(URIl)를 추가한다.
[76] 이와 같은 방식으로 Inward 트랩의 등록이 완료되면, TrapMO는 해당 트랩
이벤트 (trap— event 1)가 발생하였을 때 해당 컴포넌트에 알림 (notification)을 수행한다. DM 클라이 언트 (110)는 트랩 이벤트 (trap_eventl)의 발생을
모니터 링하고 있다가, 트랩 이벤트 (trap_eventl)의 발생이 감지되면, TrapID가 trap_eventl인 TrapMO의 인스턴스를 검색한다. 대안적으로, DM 클라이 언트 (110)는 전술한 상대 주소 (relative addressing)를 재사용할 수도 있다.
DM 클라이언트 (110)는 TrapMO의 인스턴스가 발견되면, TargetURI 밑에 둥록되어 있는 모든 URI에 대해서 URI 노드의 값이 가리키는 노드에 실행 (Exec) 명 령올 보낸다. 이에 따라， Inward 통지 과정 이 완료된다.
[77] 이제 반대로， DM 서버 (120)가 DM 클라이 언트 (110)에 트랩
이벤트 (trap_eventl)를 Outward 타입으로 등록하는 과정을 설명 한다. 이하에서는， DM 서버 (120)가 DM 클라이 언트 (110)의 트랩 이벤트 (trap_eventl)를
모니터 링하기 위해, 발생한 이벤트를 다른 DM 서버 ('DMS1')에 전달하는 상황을 가정한다. 먼저 Outward 트랩 이벤트 등록을 위해 VI 서버 (120)는 DM
클라이 언트 (110)의 TrapMO 인스턴스 중에서 TmpID가 'trap_eventl'인
인스턴스를 검 색한다. 이 과정에서 위에서 기술한 상대 주소 (relative
addressing)가 사용될 수도 있다. DM 서버 (120)는 이 TrapMO 인스턴스가 발견되면, 'ToRef/TargetServer' 노드 밑에 자식 노드로 다른 DM 서버의 식별 정보 ('DMS1')를 추가하고 이에 따라 등록 과정 이 완료된다.
[78] Outward 트랩 등록이 완료되고， DM 클라이언트 (110)는 해당 Trap
이벤트 (trap_eventl)가 발생하였을 경우, 다른 DM 서버 ('DMS1')에게 알려주는 알림 (notification)을 수행하면 된다. 이 과정올 위해 DM 클라이언트 (110)는 트랩 이벤트를 모니터링하고 있다가, 트랩 이벤트 (trap_eventl)의 발생을 감지하게 되고，감지 후 TrapMO 중에서 TrapID가 trap_eventl인 TrapMO 인스턴스를 검 색한다. DM 클라이 언트 (110)는 발견된 TrapMO 인스턴스 서브 트리에서 ToRef/TargetServer' 밑에 등록되어 있는 모든 'ServerlD'에 대해서 트랩 이벤트 (trap_eventl)에 대한 정보를 전달해 준다. 본 전달은 일반적 경고 (Generic Alert)를 사용하여 전달된다. 이 과정에서 다른 DM 서버 ('DMS1')는
'ToRef/TargetServer' 밑에 'ServerlD，로 등록 과정에서 추가되었기 때문에， DM 클라이 언트로 (110)로부터 트랩 이벤트 (trap_eventl)에 대한 정보를 전달 받게 된다.
[79] TrapMO의 Inward 트랩은 단말에 불특정 DM 명령 (Command)을 수행할 수 있기 때문에，잠재적 인 보안 위험 이 존재한다. 이 러한 보안 문제에 따른 위험을 막기 위해서는, Inward 트랩의 등록 (registration)과 알림 (notification) 과정에서 적절한 권한을 가지고 있는 DM 서버 (120)만이 해당 과정올 수행해야만 한다. 즉, Inward 트랩에 대한 등록은 등록 권한을 갖고 있는 VI 서버 (120)만이 할 수 있고, Inward 트랩이 추후 알림 과정 (notification process)을 통해 특정 동작 (operation)을 수행할 때는 그 Inward 트랩을 둥록한 DM 서버 (120)가 실행 권한을 가지고 있어야만 한다.
[80] 하지만 종래의 트랩 프레임워크에서는 이 러한 Inward 트랩의 보안 문제를
다루고 있지 않다. 이는 Inward 트랩의 등록과 알림 과정에서 , 종래의 트랩 프레임워크는 등록 과정 에 대한 DM 서버 (120)의 권한 확인만을 수행하기 때문이다. 이 러 한 트랩 프레임워크의 보안상의 결함은 TrapMO 자체의 문제에 기 인하기 보다는, TrapMO가 의존하고 있는 DM 보안 모델 (security model) 문제점 이 내제되어 있기 때문이다.
[81] 도 4a는 종래 기술에 따른 Inward 통지를 위한 등록 절차를 도시하는
흐름도이다.
[82] 성공적 인 등록을 위해， DM 클라이 언트 (110)는 DM 서버 (120)로부터 Inward 통지를 위한 등록 요청을 수신했을 때 (S121), 등록을 수행하는 DM 서버 (120)가 해당하는 TrapMO 인스턴스의 'ToRef TargetURT에 추가 (Add) 명 령을 수행할 수 있는 권한이 있는지 확인하게 된다 (S122). 즉， DM 클라이 언트 (110)는 Inward 통지를 위한 등록을 수행하는 데에 적합한 권한이 있는지 확인하는 과정을 수행한다.
[83] 제 122 단계에서 , DM 서버 (120)가 해당하는 노드에 추가 권한이 있으면， Inward 통지를 위한 노드를 추가함으로써 (S123) 등록이 성공적으로 완료된다 (S124). 그러나，제 122 단계에서， DM 서버 (120)가 해당하는 노드에 추가 권한이 없으면, 등록이 실패한다 (S 125).
[84] 도 4b는 종래 기술에 따른 Inward 통지를 위한 등록 이후, 통지 절차를 도시하는 흐름도이다.
[85] 제 131 단계 내지 제 135 단계를 참조하여 알 수 있는 바와 같이 , DM
클라이언트 (110)는 발생한 Inward 트랩에 대해, 해당하는 트랩 이벤트를 지정된 노드에 전달하고 실행하면서 , 별도의 권한 검사를 하지 않고 있다. 전술한 바와 같이 , 이 러한 문제점은 TrapMO 자체의 문제라기 보다는, TrapMO가 의존하고 있는 DM의 보안 모델 (security model)이 가지고 있는 문제점에 기 인한다.
[86] 즉, 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 트랩의 보안 문제가 해결되지 않는다는 것을 뜻한다.
[87] 도 5a는 종래기술에 따른 Inward 트램을 처리하는 방식의 문제점을 나타내는 흐름도이다.
[88] 이 예시적 인 실시 예에서， DM 서버 (120)는 디바이스를 재시작 (restart)할 수 있는 권한은 없고 (이 예제에서는 'DiagMonMO/Restart/Operations/Start，에 대한 실행 (Exec) 권한이 없음), 모니터 링하고자 하는 해당 TrapMO 인스턴스에는 추가 (Add)할 수 있는 권한을 가지고 있다고 가정한다.
[89] DM 서버 (120)는 DM 클라이 언트 (110)의 트랩 이벤트 (trap_eventl;
WiFi.Connected) 이벤트를 모니터 링하기 위해 등록을 요청하는 M 명 령을 보낸다 (S141). 이 때， DM 서버 (120)는 트랩 이벤트가
'DiagMonMO/Restart/Operations/Start'에 알림 (notification)이 보내지도록 Inward 트랩을 등록한다.
[90] DM 클라이언트 (120)는 트랩 이 벤트 (trap_eventl; WiFi_Connected)를
모니터 링한다. Wifi가 연결되면 (WiFi_Connected)(S142), DM 클라이 언트 (120)는 트랩 이벤트 (trap_eventl; WiFi_Connected)가 발생했음을 감지 한다 (S 143).
[91] TrapMO(302)는 Inward 트랩이 발생함에 따라，
'DiagMonMO/Restart/Operations/Start'로 발생한 트랩 이 벤트에 관한 정보를 전달한다 (S 144).
[92] DiagMonMO(Diagnostic and Monitoring Management objects)(306)는 받은 명 령에 따라서，단말을 재시작 (restart)한다 (S 145).
[93] 상기 실시 예에서 알 수 있듯이 , DM 클라이언트 (110)를 재시작 (restart)할
권한이 없는 DM 서버 (120)는 단지 TrapMO의 하위 트리에 추가 (Add)할 수 있는 권한만을 가지고 있음에도 불구하고 단말을 재시작 (restart)할 수 있다. 그리고 이는 심각한 보안 위험 이 될 수 있다.
[94] 반면에， Outward 트랩은 DM 서버 (120)가 DM 클라이 언트 (110)에 트랩 이벤트 모니터 링을 등록할 때，이벤트 발생을 보고하는 서버를 어떤 서 버 이든지 지정할 수 있다. 이 러한 특징은 OMA DM 서 비스를 하기 위해 DM 서버 (120)를 구성하는데 있어 확장성과 유연성을 높여주는 장점 이 있다. 즉，트랩 이벤트에 등록을 수행하는 이 V 서버 (120)와 트랩 이벤트를 모니터 링하는 DM 서버 (120)를 따로 분리하여 확장성과 유연성을 높일 수 있다. 하지만 이 러한 Outward 트랩의 기능에는 한가지 단점 이 있는데, 트랩 이벤트를 모니터 링 할 의도가 없는 다른 DM 서버가 트랩 이벤트를 받도록 설정 이 가능하다는 것이다.
[95] 이 러 한 Outward 트랩의 단점은 보안상의 취 약점으로 이어지는데，단순하게는 트랩 이 벤트를 받기 원하지 않는 DM 서버 (120)에 트랩 이벤트를 보낼 수 있다는 것이고，크게는 다수의 단말에 Outward 트랩을 등록하여，특정 VI 서버 (120)가 받도록 설정하면, 해당 DM 서버 (120)는 매우 많은 트랩 이벤트를 받게 되어， DoS(Denial of Service) 공격에 악용될 가능성 이 있다.
[96] 도 5b는 종래기술에 따른 Outward 트랩을 처리하는 방식의 문제점을 나타내는 흐름도이다.
[97] 제 1 DM 서버 ( O)는 제 1 DM 클라이 언트 (110)의 'trap_eventl'에 Outward
트랩을 등록하며, 발생한 이벤트에 관한 정보를 계 2 0\1 서버 (120')에
전달하도록 설정한다 (S151). 마찬가지로，제 1 DM 서버 (120)는 제 2 DM 클라이 언트 (110，)의 'trap_eventl'에도 Outward 트랩을 등록하며，발생한 이벤트에 관한 정보를 제 2 DM 서버 (120，)에 전달하도록 설정한다 (S 152).
[98] 제 1 DM 클라이언트 (110) 및 제 2 DM 클라이 언트 (110')는 각각 트랩
이벤트 (trap_eventl)를 감지한다 (S 153， S155).
[99] 트랩 이벤트 (trap_eventl)를 감지한 제 1 DM 클라이 언트 (110) 및 제 2 DM
클라이 언트 (110，)는 각각 발생한 트램 이 벤트에 관한 정보를 계 2 DM
서버 (120')에 전달한다 (S154, S156).
[100] 이 예시적 인 실시 예에서 알 수 있듯이， DM 서버 (120)는 Outward 트랩을
이용하여 트랩 이 벤트를 원하지 않는 DM 서버 (120)에 이벤트를 전달할 수 있으며，나아가 DoS 공격에 이용할 수가 있다.
[101] 도 6은 종래기술에 따른 TrapMO의 보안을 강화하기 위한 방법을 나타내는
흐름도이다.
[102] 이와 같은 문제를 해결하기 위 한 하나의 시도로서，발명의 명칭 이 "System and method for device management security of trap management object "인 미국 특허 공개 번호 US2010/0121967는 TrapMO의 보안을 강화하기 위해 새로운 방법을 제안하였다. 제안된 방법은 Inward 트랩 등록 시, 기존에 수행하던 DM
서버 (120)가 해당 Inward 트랩을 등록할 권한이 있는지 확인 (S162)함과 동시에, Inward 트랩으로 인해 수행하게 될 명 령을 실행할 권한이 있는지 추가로 확인 (S164)하고, 등록과 실행 권한을 모두 가지고 있는 DMS에 대해서만 등록을 허용 (S 165, S 167)하는 방법 이다.
[103] 그러나, 제안된 방법은 TrapMO가 의존하고 있는 OMA DM ACL(Access Control List)의 런타임 (runtime) 특징으로 인해 문제점을 갖게 된다. VI에서는 각각의 노드가 ACL 속성을 갖도록 규정하고 있는데， ACL 속성은 해당 노드에 DM 서버 (120)가 어떤 명 령 권한을 가지고 있는지 나타낸다. 문제는 이 러 한 노드의 ACL이 런타임 특성을 갖기 때문에，바뀔 수 있다는 점이다. 따라서 등록 과정에서 실행권한을 동시에 가지고 있어 등록을 허가한다고 해도，추후에 바뀐 ACL로 인해 실행 권한을 잃어버리 게 된다. 또 이 러한 취 약점을 이용하면， 처음에는 실행 권한을 가지고 있는 명 령을 Inward 트랩으로 등록하고, 나중에 해당 명 령올 권한이 없는 다른 명 령으로 바꾸게 되면， DM 서버 (120)가
실행권한이 없는 명 령을 실행할 수 있게 된다.
[104] 제안된 방법의 또 다른 문제점은 Outward 트랩이 가지고 있는 보안 약점에 대한 개선 방법을 포함하고 있지 않기 때문에 , Outward 트랩을 이용해 허가되지 않는 트랩 이벤트를 전달하여 민감한 단말의 정보를 외부에 노출하거나，트랩 이벤트를 받기 원치 않는 DM 서버 (120)에게 이벤트를 전달하거나, 나아가서 DoS 공격에 악용할 소지가 있는 점 이다.
[105] 따라서 , 본 발명의 실시 예들은 TrapMO의 Iinward 트랩 및 Outward 트랩과
관련된 보안상의 취약점을 보완할 수 있는 방법을 제공한다. 이를 위해, 본 발명의 실시 예들은 Inward 트랩과 Outward 트랩 각각에 대한 보안 강화 방법을 제공한다.
[106] Inward 트랩에 대해서는 DM 서버 (120)가 DM 클라이 언트 (110)에 대해 Inward 트랩 둥록을 수행하고, 이벤트가 실제 발생하여 등록되어 있는 명 령 이 수행될 때, 권한을 가지고 있는 DM 서버 (120)만이 명 령을 수행할 수 있는 방법을 제시한다. 이때, DM 트리의 런타임 속성 인 ACL이 변하더라도, 이를 반영하여 명 령 수행 여부를 결정할 수 있는 방법올 제시한다.
[107] Outward 트랩과 관련하여 Outward 트랩의 보안을 강화하는 2가지 방법을 제시한다. 첫 번째 방법은， Outward 트랩 등록 시 DM 클라이 언트 (110)의 DM 계정 (Account) 정보를 이용하여 DM 클라이언트 (110)가
부트스트랩 (bootstrap)되어 있어 신뢰할 수 있는 DM 서버 (120)들에 대해서만 이벤트를 수신할 수 있도록 허용하는 방법 이다. 두 번째 방법은 낙관적 통지 제어 (Optimistic Notification Control)로써，보안에 위배되는 Outward 트랩의 시도가 낮을 때 효율적으로 사용될 수 있는 방법 이다.
[108] 이하에서는，본 명세서에 개시된 실시 예들에 따른 TrapMO 보안을 강화하기 위한 방법을 Inward 트랩과 Outward 트랩으로 나누어서 설명한다.
[109] 도 7은 본 명세서 에 개시된 실시 예들에 따른 트랩 관리 객체 트리 (Trap
Management Object Tree)를 나타내는 도면이다.
[110] 종래 기술에 따른 트랩 관리 객체 트리와 비교하여 , 본 명세서에 개시된 실시 예들에 따른 트랩 관리 객체 트리는 'ToRei7TargetURI/<x>/RegisteredServerID' 노드를 더 포함한다. 이 노드에는 해당 트랩 이 벤트를 등록한 DM 서버 (120)의 서버 식별 정보가 저장된다. 등록 이후에 트랩 이벤트가 발생하면, DM 클라이 언트 (110)는 트랩 이벤트에 저장된 서버 식별 정보를 참조하여，트랩 이벤트를 등록한 DM 서버 (120)가 ACL에서 실행 (Exec) 권한을 보유하고 있는지 판단함으로써，런타임을 반영한 보안 문제를 해결할 수 있다.
[111] 먼저， Inward 트랩의 보안을 강화하기 위한 방법을 설명한다. 이 방법은 DM 클라이 언트 (110)가 트랩 이벤트 발생 시 , 해당 트랩 이벤트에 등록되어 있는 명 령에 Inward 통지 (notification)를 전달하고, 명 령을 수행하기 전에 동적으로 변하는 ACL 정보를 참고하여 DM 서버 (120)가 명 령 수행에 필요한 권한을 가지고 있는지 판단하는 것이다.
[112] 여기에서 사용되는 것처 럼, 한 상태에서 다른 상태로의 천이는 한 상태에서 다른 상태로 이 행하는 것을 말한다. 사용자가 인식하는 것과 같이 과정은 즉시 , 거의 즉시 , 점진적 또는 기타 적절한 속도일 수 있다. 과정의 진행은 과정 이 일단 활성화되면 사용자와는 무관하게 단말과 같은 장치에 의하여 자동으로 제어될 수 있거나，또는 사용자에 의하여 제어될 수 있다. 이하에 설명하는 과정 흐름은 특정한 순서로 일어나는 것처 럼 보이는 수많은 동작을 포함하지만, 이 러한 과정은 직 렬로 또는 병 렬로 (예를 들어 , 병 렬처 리기 또는 멀티
쓰레딩 (multi-threading) 환경을 이용하여) 실행 가능한，더 많거나 적은 동작을 포함할 수 있음을 인식하여야 한다. [113] 도 8a는 본 발명의 제 1 실시 예에 따른 Inward 트랩의 등록 시에 보안을 강화하는 과정을 나타내는 흐름도이다.
[114] 이 방법은 DM 서버 (120)가 DM 클라이 언트 (110)에 게 특정 트랩
이벤트 ('trap_evenU')를 모니터 링하기 위해 등톡하는 과정에서 , 등록을 수행하는 DM 서버 (120)의 식 별자 (identifier; 'ServerlD')를 저장하는 과정올 포함한다. DM 서버 (120)의 식 별자 (identifier)는 DM 서버 (120)를 유일하게 지칭하는 것으로， DM 서버 (120)의 도메인 이름을 포함할 수 있다 . DM 클라이 언트 (110)는 Inward 트랩에 등록을 수행하는 DM 서버 (120)의 'ServerlD' (identifier)를 저장하기 전에 저장할 'ServerlD'가 올바른 것인지 확인하는 과정을 거쳐 야 하는데，이를 위해 DM 클라이언트 (110)가 가지고 있는 DM 계정 (Account) 정보를 활용할 수 있다. DM 계정 (Account)은 DM 클라이언트 (110)가 부트스트랩한 이 I 서버 (120)의 정보를 저장하고 있으며，이 증에는 인증 정보 역시 포함되어 있기 때문에， DM 클라이 언트 (110)는 DM 서버 (120)의 'ServerlD'가 올바른지 (유효한지) 확인하고, 올바르다고 (유효하다고)확인된 'ServerlD'만을 저장하고 등록을 성공적으로 마치 게 된다. 만약 'ServerlD，가 올바르지 (유효하지) 않다면，등록은 실패하게 된다.
[115] DM 클라이언트 (110)는 DM 서버 (200)로부터 트랩 이벤트 (trap_eventl;
모니터 링하는 트랩 이벤트의 ID)를 모니터 링하기 위한 Inward 트랩 등록 요청을 수신한다 (S201). Inward 트랩 등록 요청은 DM 서버 (120)가 DM
클라이 언트 (110)에 게 추가 (Add) 명 령을 보내는 것으로， TrapMO의 인스턴스 중에서 TrapID가 'tmp_eventl'인 인스턴스를 검 색해서 'ToRef/TargetURI' 밑에 추가 (Add) 명 령을 요청한다. 추가 (Add)되는 노드에는 트랩 이벤트가 발생하였을 경우，실행될 노드의 주소 ('URI1')가 반드시 포함되어야 한다.
[116] DM 클라이 언트 (110)는 DM 서버 (120)로부터 추가 (Add) 명 령을 수신하면， DM 서버 (120)가 해당 명 령을 수행할 권한이 있는지 확인한다 (S202). 이는 DM 서버 (120)의 등록 권한을 확인하는 과정으로 제 201 단계에서 VI 서버 (120)가 보낸 추가 (Add) 명 령 이 대상 (target)으로 하는 노드에 대해 VI 서버 (120)가 추가 (Add) 권한을 가지고 있는지 확인한다. 추가 (Add) 권한 확인은 대상 (target) 노드의 ACL을 획득하여， ACL의 추가 (Add) 권한에 DM 서버 (120)가 포함되어 있는지 (예를 들어 , Add=DMS인지) 확인함으로써 가능하다.
[117] DM 클라이 언트 (110)는 Inward 트¾ 등록을 수행하는 DM
서버 (120)의 ServerID(server identifier)를 획득하여， ServerlD의 적합성을 판단한다 (S203). 적합한 ServerlD는 DM 클라이언트 (110)가
부트스트랩 (bootstrapping)을 완료하여 DM 클라이언트 (110)의 DM
계정 (Account)에 'ServerlD'를 포함한 DM 서버 (120)의 정보가 들어 있어 야 하며 , 또한 DM 계정 (Account)에 들어 있는 인증 정보를 이용해 인증 가능한 DM 서버의 ServerlD여 야만 한다. 또한 현재 Inward 트랩을 등록하고 있는 DM 서버의
ServerlD, 즉 'DMS'이 여 야 한다. [118] DM 서버 (120)가 'ToRef TargetURI/<x>/URI'의 값이 가리키는 노드를 실행할 권한이 있는지，즉 해당 노드에 실행 (Exec) ACL을 가지고 있는지
확인한다 (S204). 이 과정은 Inward 트랩의 알림 권한을 확인하는 과정으로，권한 확인은 그 노드의 ACL값에 예를 들어 , 'Exec=ServerID'가 포함되어 있는지 확인함으로써 가능하다. ACL 권한을 확인하는 방법은 예를 들어，
[OMA-DM-TND]에 상세히 기술되어 있으며，이에 대한 상세한 설명은 생략한다.
[119] DM 클라이언트 (110)는 제 202 단계 내지 제 204 단계를 통해 이 VI 서버 (120)가 적합한 등록 권한을 가지고 있을 경우， Inward 트랩 등록을 수행한다 (S205). 이 과정은 제 202 단계에서 DM 서버 (120)가 보내온 추가 (Add) DM 명 령을 수행하는 것이다.
[120] DM 클라이언트 (110)는 DM 서버 (120)의 적합한 'ServerlD'를 저장하고，본
Inward 트랩 등록과 매핑해 놓는다 (S206). 이 렇게 함으로써 추후에 DM
클라이언트 (110)는 본 등록을 수행한 'ServerlD'를 가져올 수 있다.
[121] 제 206 단계까지 성공적으로 완료되면, Inward 트랩 등록이 완료되고，등록은 성공한다 (S207).
[122] 그러나, 제 202 단계 내지 제 204 단계 중 어느 하나의 단계에서 실패하면, 등록은 실패한다 (S208). 등록이 실패하면, DM 클라이언트 (110)는 부가적으로 DM 서버 (120)에 등록 실패를 알리는 결과 코드 (Result Code) (예를 들어, "인증되지 않음 (Not Authorized)를 송신한다.
[123] 도 8b는 본 발명의 제 1 실시 예에 따른 Inward 트랩의 알림 시에 보안을
강화하는 과정을 나타내는 흐름도이다.
[124] 본 실시 예는, Inward 트랩의 알림과 관련해서，동적으로 변하는 DM
트리 (Tree)의 ACL을 반영하여 DM 클라이 언트 (110)가 권한이 있다고 판단한 명 령만을 안전하게 수행하는 방법을 제시한다. DM 클라이언트 (110)가 Inward 트랩의 알림 (notification)을 통해 수행되는 명 령 이 승인될 수 있는지 판단하기 위해서는, 해당 알림 (notification)을 발생시 킨 Inward 트랩 둥록을 어떤 DM 서 버 (120)가 수행했는지에 관한 정보가 필요하다. 이 정보는 도 8a에 도시된 Inward 트랩 등록 과정을 이용해 DM 클라이 언트 (110)가 Inward 트랩 등록 과정에서 적합한 DM 서버 (120)의 'ServerlD'만을 저장해 놓았기 때문에，본 알림 과정에서 이용이 가능할 수 있다 . DM 클라이 언트 (110)는 Inward 트랩 알림의 결과로 명 령올 수행하기 전에，본 등록을 수행한 'ServerlD'가 수행 권한을 가지고 있는지 판단함으로써 안전한 명 령만을 수행할 수가 있다.
[125] 이 러한 과정 이 없다면， DM 클라이언트 (110)는 Inward 트랩의 알림 결과 수행 명 령을 실행하는 주체가 TrapMO 인에 이블러 (Enabler)나， Inward 트랩
알림 (notification)을 전달받은 기능 컴포넌트 (functional component)라고 판단하기 때문에，해당 명 령 이 허용되어야 하는지 알 수가 없게 된다. 하지만 본 실시 예에 따르면，명 령 실행의 주체를 정확히 알 수가 있고 이를 통해 명 령 실행에 보안상의 문제가 없는지 명확하게 알게 된다. 또한 DM 클라이언트 (110)는 명 령 실행 직전에 ACL 정보를 확인함으로써 , 동적으로 변하는 ACL을 반영하여，명 령 실행 허용 여부를 판단하게 된다.
[126] DM 클라이언트 (110)는 트랩 이벤트의 식별 정보 ('trap_eventl')를
모니터 링하고 있다가 (S211), 트랩 이벤트 발생을 감지 한다 (S212).
[127] DM 클라이언트 (110)는 트랩 이벤트 발생이 감지되면, TrapMO 증에서
TrapID가 'trap_eventl'인 TrapMO 인스턴스를 검 색한다 (S213).
[128] DM 클라이 언트 (110)는 제 213 단계에서 발견한 TrapMO 인스턴스의 서브
트리에서 해당 URI('ToRefTargetURI/<x>/URr)를 가져온다 (S214).
[129] DM 클라이 언트 (110)는 해당 URI('ToRef/TargetURI/<x>/URr)를 등록한 DM 서버 (120)의 'ServerlD'를 가져은다 (S215).
[130] DM 클라이 언트 (110)는 가져온 'ServerlD，가 해당
URI('ToRef/TargetURI/<x> URr)의 값이 가리키는 노드를 실행할 권한이 있는지 , 즉 해당 노드에 실행 (Exec) ACL을 가지고 있는지 확인한다 (S216). 이 과정은 Inward 트랩의 알림 권한을 확인하는 과정으로, 권한 확인은 그 노드의 ACL값 중에서 'Exec=ServerID'가 포함되어 있는지 확인함으로써 가능하다.
[131] 제 216 단계에서 알림 권한이 있다고 판단되면, DM 클라이 언트 (110)는 해당 URI('ToRef TargetURI/<x> URT)의 값이 가리키는 노드를 실행한다 (S217).
[132] 아직 Inward 트랩 알림 이 수행되지 못한 URI('ToRef TargetURI/<x>/UR )가
존재하는지 확인하고 (S218), 존재한다면 제 214 단계로 회귀한다. 존재하지 않는다면， Inward 트랩 알림 과정 이 종료한다.
[133] 계 216 단계에서 알림 권한이 없다고 판단되면，알림 실패 (Notification Failure)를 처리한다. 알림 실패의 경우, DM 클라이 언트 (110)는 다음과 같은 방법을 이용하여 처리할 수 있다.
[134] 제 1 방법은 알림 이 실패할 경우， DM 클라이언트 (110)가 별다른 작업을 하지 않는 것이다 (silent discard).
[135] 제 2 방법은 알림 이 실패할 경우， DM 클라이언트 (110)가 DM 서버 (120)에
일반적 경고 (Generic Alert)를 보내는 것이다 (Generic Alert to DMS). 이 일반적 경고 (Generic Alert)는 알림 실패를 알리는 타입 (type) (예를 들어 ,
'urn:oma:at:trapnio:1.0:InwardNotificationFailecr)을 포함하고 있어야 하며，일반적 경고 (Generic Alert)의 '<Data>'에는 알림 실패에 대한 세부적 인 정보가 포함될 수 있다 (예를 들어，알림 실패의 이유: 인증되지 않음 (Not Authorized)).
[136] 제 3 방법은 알림 이 실패할 경우， DM 클라이언트 (110)가 해당 Inward 트랩
등록을 해지하는 것이다. 이는 알림 (Notification)이 실패한 Inward 트랩을 해지하여，알림 실패가 계속 발생하는 것을 방지할 수 있다 . DM
클라이 언트 (110)는 해지하기 전에 이 VI 서 버 (120)에게 알림 실패를 알려주어 , 필요하다면 DM 서버 (120)가 알림 (Notification) 실패를 처 리할 수 있도록 한다. 즉, 실행 (Exec) 권한을 확보하기 위해 필요한 조치를 할 수가 있다.
[137] 도 9는 본 발명의 제 1 실시 예에 따른 알림 실패 처리 과정을 나타내는 도면이다.
[138] 도 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 트랩을 둥록한 VI 서버 (120)이며 , 그 DM 서버 (120)의 'ServerlD'는 예를 들어 , oRef7TargetURI/<x>/RegisteredServerID'에 저장되어 있다.
[139] DM 클라이 언트 (110)는 알림 실패 시，일반적 경고 (Generic Alert)를 보내지 않을 수도 있으며，트랩 이벤트가 해지되기까지의 알림 실패 회수는 DM
클라이언트 (110)와 DM 서버 (120)가 협상을 통해 정할 수도 있다.
[140] 이상에서 설명한 보안 Inward 트랩의 메커니즘을 등록과 알림으로 나누어서 다시 정 리하면 아래와 같다.
[141] 보안 트랩 동작들을 위해，단말은 DM 서버 (120)가 이하에서 설명되는 Inward 등록 및 알림을 위한 적절한 권한들을 가지고 있음을 인증해야 한다.
[142] 둥록 과정에서 , DM 서버 (120)는 'ToRef/TargetURT 노드 밑에 서브 트리를
추가함으로써 Inward 트랩을 등록할 수 있다. DM 서버 (120)가 이
'ToRef/TargetURI'에 의해 지시되는 실행가능한 노드의 실행 권한을 가지고 있지 않다면, 등록은 허용되지 않는다. 단말은 기본적 인 ACL 규칙들 (예를 들어， 서브-트리를 추가하기 위한 추가 권한)과 함께 실행 권한을 검증해야 한다. DM 서버 (120)가 실행 권한을 가지고 있지 않다면, TrapMO 결과 코드 (Result Code) '1400(불층분한 권한 때문에 등록이 실패됨)'과 함께 둥록은 거절되어야 한다. 등록이 성공한 후에 , oRef/TargetURI/<x>/RegisteredServerID' 노드는 단말에 의해 본 Inward 트랩을 등록한 서버 식별자 (server identifier)와 함께 설정되어야 한다.
[143] 알림 과정에서 , ToRef/TargetURI/<x>/URr의 형제 노드인 'RegisteredServerlD' 노드에；의해 식 별되는 DM 서 버 (120)가 'ToRef/TargetURI/<x>/URr 노드에 의해 지시되는 실행 가능한 노드의 실행 (Exec) 권한 (permission)을 가지기만 하면， 트랩은 'ToRef7TargetURI/<x>/URT 노드에 의해 지시되는 실행가능한 노드에 통지될 수 있다. 실행 권한올 검증하는 방법은 구현 이슈이나, ACL이 동적으로 변할 수 있음이 고려되어야 한다. 예를 들어 , 단말은 트랩 이벤트를 알리기 전에 실행 허가 권한 (Exec permission right)을 확인해야 하고, 또는 단말은 ACL 변경에 따라 확인 절차 (check process)를 개시해야 한다.
[144] DM 서버 (120)가 실행가능한 노드의 실행 권한을 가지고 있지 않으면，관련된 Inward 트랩 둥록은 곧 (as soon as practical) 해지되어 야 한다. Inward 트랩이 해지된 후에，단말은 'ToRef/TargetURI' 노드 밑의 대웅하는 서브-트리를 제거해야 한다. 일반적 인 경고 (Generic Alert)가 해지를 알리기 위해
'RegisteredServerlD' 노드에 의해 식 별되는 DM 서버 (120)에 송신될 수 있다.
[ 145] 도 10은 본 발명의 제 2 실시 예에 따른 Outward 트랩의 등록 시에 보안을
강화하는 과정을 나타내는 흐름도이다.
[146] 본 발명의 제 2 실시 예는, 발생한 트랩 이벤트가 전달되는 DM 서버 (120)를
Outward 트랩으로 등록할 때， DM 클라이 언트 (110)에 있는 DM 계정 (Account) 정보를 이용하는 방법 이다. DM 클라이 언트 (110)의 DM 계정 (Account)에는 DM 클라이 언트 (110)가 부트스트랩 (bootstrapping)을 통해 등록한 DM 서버 (120)의 정보가 저장되어 있다. 이 DM 서버 (120)의 정보에는 'ServerlD，를 포함하여 , DM 서버 (120)의 주소，인증수단，인증 값 등이 저장되어 있다. 즉 DM
계정 (Account)에 등록되어 있는 DM 서버 (120)들은 DM 클라이 언트 (110)와 신뢰 적 인 관계 (trust relationship)를 가지고 있다고 볼 수가 있다.
[147] DM 클라이 언트 (110)의 트랩 이벤트 종류는 매우 광범위하며，그 중에서는
프라이버시 (Privacy)상 민감한 정보도 포함될 수 있다. 예로 특정 지 역으로 단말이 이동하였을 경우 발생하는 트램 이벤트가 그러하다. 따라서 트랩 이벤트가 전달되는 DM 서버 (120)를 DM 클라이언트 (110)가 신뢰 할 수 있는 DM 서버 (120)로 한정하는 것이 필요하며 , 어떤 DM 서버 (120)를 신뢰할 수 있는지 없는지는 DM 클라이 언트 (110)의 VI 계정 (Account) 정보를 통해 확인할 수 있다. 만일 트랩 이벤트가 전달될 DM 서버 (120)가 DM 계정 (Account)에 등록되지 않아서 신뢰 관계 (trust relationship)가 없다고 판단될 경우， DM
클라이 언트 (110)는 해당 서버와 부트스트랩 (bootstrapping)올 수행하여 DM 계정 (Account을 생성한 다음，등록 과정을 진행할 수도 있다. 또 DM
클라이 언트 (110)의 트랩 이 벤트 정보 보안올 더 강화하기 위해， Outward 트랩 이벤트를 수신하는 DM 서버 (120)를，등록을 수행하는 DM 서버 (120) 자신으로 제한할 수 있다.
[148] DM 클라이언트 (110)는 트랩 이벤트인 'trapᅳ eventl'(TrapID)에 모니터 링하기 위 한 Outward 트랩 등록 요청을 DM 서버 (120)로부터 수신한다 (S211). 상기 요청은 발생한 트랩의 결과를 'DMS1'으로 식별되는 DM 서버에 전송하도록 하는 요청 이 될 수 있다. [149] DM 클라이언트 (110)는 DM 서버 (120)가 Outward 트랩 등록을 수행할 수 있는 권한이 있는지 확인한다 (S212). 이 과정은 DM 클라이 언트 (110)가 TrapID가 'trap_eventl'인 TrapMO 인스턴스를 검 색하고, 그 하위 노드인
oRef TargetServer'에 추가 (Add)할 수 있는 권한이 있는지 확인함으로써 가능하다.
[150] DM 클라이언트 (110)는 DM 서버 (120)가 트랩 이 벤트 수신자로 등록하려는
다른 DM 서버 ('DMS1')가 현재 DM 클라이 언트 (110)가 부트스트랩한 DM 서버 (120)인지 확인한다 (S213). 이는 DM 클라이 언트 (110)가 가지고 있는 DM 계정에서 I 서버 ('DMS1')의 'ServerlD，를 가지고 있는 DMAcc 인스턴스를 발견함으로써 확인할 수 있다. 그리고, 추가로, 발견한 DMAcc 인스턴스에 저장되어 있는 인증 정보 등을 확인하여 , DM 서버 ('DMS1')가 올바르게 부트스트랩된 DM 서버 인지 검증할 수 있다.
[151] DM 서버 ('DMS1')가 부트스트랩 되지 않아서 , 신뢰 관계가 없다면, DM
클라이언트 (110)는 DM 서버 ('DMS1')에 게 부트스트랩올 시도한다 (S215).
도시되지 않았으나, 부트스트랩 과정 이 실패하면，제 218 단계로 진행하여 등록이 실패한다.
[152] DM 클라이언트 (110)는 트랩 이벤트와 관련된 보안성을 높이기 위해， DM
서버 (120)가 DM 서버 (120) 이외의 DM 서버 (120)를 트랩 이벤트 수신자로 등록하는 것을 방지할 수 있다 (S214). DM 클라이 언트 (110)는 DM 서버 (120)와 DM 서버 ('DMS1')가 올바르게 부트스트랩된 서버 인지 확인하고, DM
서버 (120)의 ServerlD와 DM 서버 ('DMS1')의 ServerlD를 비교할 수 있다.
[153] 제 214 단계에서， DM 서버 (120)와 DM 서버 ('DMS1')가 올바르게 부트스트랩된 서버 이고, DM 서버 (120)의 ServerlD와 DM 서버 ('DMS1')의 ServerlD가 동일한 경우에 등록 과정을 수행한다. 즉， 'ToRef/TargetServer' 노드 밑에 자식 노드로 DM 서버 ('DMS1')를 추가하고 (S216), 이에 따라 등록 과정 이 성공적으로 완료된다 (S217).
[154] 등록이 실패할 경우, 등록 실패에 해당하는 결과 코드 (Result Code)를
반환한다 (S218).
[155] 이상에서 설명한 보안 Outward 트랩에 대해서 다시 정리하면 아래와 같다.
[156] DM 서버 (120)는 단말로부터 트랩들을 수신하기를 원하면， 'ToRef/TargetServer' 노드 밑에 서브-트리를 추가할 것이다. 등록에 성공하기 위해，단말은
'ToRef/ argetServer/<x>/ServerID' 노드가 DM 서버 자신의 서버 식 별자 (예를 들어 , DM 서버는 다른 DM 서버들을 둥록할 수 없다)로 설정되어 있는지 검증해야 한다. 등록이 실패하면, 단말은 상태 코드 (status code) '403，숨김을 송신해야 한다. 일단 등록이 성공하면， 'ToRef/TargetServer/<x>/ServerI' 노드는 변경되지 않아야 한다.
[157] 도 11a 및 도 l ib는 본 발명의 제 3 실시 예에 따른 Outward 트랩의 등록 시에
보안올 강화하는 과정을 나타내는 흐름도이다. [158] Outward 트랩의 보안을 강화하는 두 번째 방법은 낙관적 알림 제어 (Optimistic Notification Control)이다. 첫 번째 방법이 DM 클라이 언트 (110)의 민감한 정보인 트랩 이벤트를 신뢰할 수 있는 DM 서버 (110)에게만 보내는 방법 인 반면，두 번째 방법은 DM 클라이 언트 (110)의 트랩 이벤트가 이벤트 수신을 원하지 않는 DM 서버 (120)에 게 전송되는 것을 막는 방법 이다. Outward 트랩 등록에서 불특정 DM 서버 (120)가 트랩 이벤트 수신자로 등록될 수 있고, 이는 트랩 이벤트 수신을 원하지 않는 DM 서버 (120)에 게 트랩 이 벤트가 전달되거나 더 나아가 DoS 공격에 악용될 소지가 있다. 두 번째 방법은 이 러한 Outward 트랩의 보안상 취 약점을 해결하며 , 동시에 악의적 인 Outward 트랩 둥록이 많지 않은 상황에서 매우 효과적 이다.
[159] 이를 위해， DM 클라이 언트 (110)는 Outward 트랩 등록 과정은 종래의 과정과 동일하게 수행한다. 즉 어 떤 DM Server가 트랩 이벤트 수신자로 등록될 때, 그 DM 서버 (120)가 트랩 이벤트 수신을 받기를 원하는지 별도의 확인 과정 없이 등록을 진행한다. 하지 만, DM 클라이 언트 (110)는 해당 Outward 트랩 등록을 수행한 DM 서 버 (110)의 서버 식 별자 (Server Identifier; 'ServerlD')를 저장한다. 물론, 저장된 'ServerlD'는 DM 계정을 통해 확인된 적합한 'ServerlD'여 야만 한다. DM 클라이 언트 (110)는 추후 트랩 이벤트가 발생하여 , 이벤트 정보를 수신자로 등록되어 있는 VI 서버에게 전송할 때，본 트랩 이벤트의 둥록을 수행했던 'ServerlD' 정보를 같이 보내주게 된다. 이 트랩 이벤트 정보를 수신한 DM 서버는 이벤트 정보에 같이 첨부되어 있는 그 'ServerlD，와 트랩 이벤트 내용을 통해 본 트램 이벤트 수신이 안전한 것인지 판단한다. 만약 트랩 이벤트 수신이 안전하지 않다고 판단되 면, DM 서버는 DM 클라이언트 (120)에게 웅답을 보내서 트램 이벤트 등록을 취소해달라고 요청할 수 있다.
[160] 도 11a를 참조하면, DM 클라이언트 (110)는 DM 서버 (120)로부터 DM
클라이 언트의 트랩 이벤트인 'trap_eventl'(TrapID)에 모니터 링하기 위 한 Outward 트랩 둥록 요청을 수신한다 (S221). 이 때，상기 요청은 발생한 트랩의 결과를 DM 서버 ('DMS1')에게 전송하게 하는 요청이 될 수 있다.
[161] 이 VI 클라이언트 (110)는 DM 서버 (120)가 Outward 트랩 둥록을 수행할 수 있는 권한이 있는지 확인한다 (S222). 이 과정은 DM 클라이 언트 (110)가 TrapID가 't p_eventl'인 'TrapMO' 인스턴스를 찾고, 그 하위 노드인
'ToRef/TargetServer，에 추가 (Add)할 수 있는 권한이 있는지 확인함으로써 가능하다.
[162] DM 클라이언트 (110)는 Outward 트랩 등록을 수행하는 DM 서버 (120)의
'ServerlD' (server identifier)를 획득하여， 'ServerlD'의 적합성을 판단한다 (S223). 적합한 'ServerlD，는 DM 클라이언트 (110)가 부트스트랩 (bootstrapping)을 완료하여 DM 클라이 언트 (110)의 DM 계정 (Account)에 'ServerlD，를 포함한 DM 서버 (120)의 정보가 포함되어 있어야 하며 , 또한 DM 계정 (Account)에 들어 있는 인증 정보를 이용해 인증 가능한 IDM 서버 (120)의 'ServerlD'여야만 한다. 또한 현재 Inward 트랩을 등록하고 있는 DM 서버 (120)의 'ServerlD'이여 야 한다.
[163] 제 223 단계에서 , Outward 트랩을 등록하는 데 문제가 없다면, DM
클라이 언트 (110)는 실제 등록 과정을 수행한다. 즉， oRef/TargetServer' 노드 밑에 자식 노드로 DM 서버 ('DMS1')를 추가하고 (S224), DM 서버 (120)의
'ServerlD，를 저장하고, 본 Outward 트랩 등록과 매핑해 놓는다 (S225). 이 렇게 함으로써 추후에 본 등록을 수행한 'ServerlD'를 가져올 수 있다. 이에 따라, Outward 트랩 등록이 성공한다 (S226).
[164] 제 223 단계에서, Outward 트랩을 둥록하는 데 문제가 발생한다면, Outward 트랩 등록이 실패한다 (S227). 이 렇게 Outward 트랩 둥록 과정 이 완료된다.
[165] 도 l ib를 참조하면， DM 서버 ('DMS1')는 DM 클라이언트 (110)가 트랩 이벤트 발생에 따라 보내온 Outward 트랩 알림을 수신한다 (S231). 수신한 Outward 알림에는 본 트랩 이 벤트를 등록한 서버의 식별 정보 (ID)가 포함되어 있다.
[166] DM 서버 ('DMS1')는 수신한 트랩 이벤트가 유효한지 판단한다 (S232). 이를 위해 DM 서버 ('DMS1')는 Outward 알림에 포함되어 있는 Outward 트랩을 등록한 'ServerlD' 및 Outward 트랩 이벤트의 정보를 통해 판단한다. 즉，자신과 신뢰 관계가 없는 DM 서버 (120)가 등록한 트랩이거나, 원하지 않는 트랩 이벤트 정보라면 유효하지 않다고 판단할 수 있다.
[167] 제 232 단계에서，수신한 트랩 이벤트가 유효하다고 판단된 경우에 , DM
서버 ('DMS1')는 수신한 트랩 이벤트를 처 리 한다 (S233).
[168] 제 232 단계에서，수신한 트랩 이 벤트가 유효하지 않다고 판단된 경우에 , DM 서버 ('DMS1')는 DM 클라이 언트 (110)에 게 해당 트랩 이벤트 등록올 취소해 달라는 요청을 보낸다 (S234).
[169] 전술한 본 발명의 제 2 실시 예는, DM 클라이언트 (110)의 민감한 정보인 트랩 이벤트를 신뢰할 수 있는 DM 서버 (120)에 게만 보내는 방법 이고, 제 2 실시 예는， DM 클라이언트 (110)의 트랩 이벤트가 이벤트 수신을 원하지 않는 DM 서버 (120)에게 전송되는 것을 막는 방법 이다. 이 두 가지 방법은 별개로 적용이 되어도 상관없지 만，두 가지 방법 이 동시에 사용되어도 무방하다. 즉, 두 가지 방법을 모두 적용하면，트랩 이 벤트를 신뢰할 수 있는 DM 서버 에게만 보내면서， 동시에 트랩 이벤트 수신을 원하지 않는 DM 서버 (120)에 게 트랩 이벤트가 전송되는 것을 막을 수 있다.
[170] . 전술한 실시 예들에서， Inward 트랩 이벤트 등록 과정에서 ACL
매커니즘 (Mechanism)으로 보장되는 추가 (Add) 권한 외에，실행 (Exec) 권한을 함께 검사하는 과정 이 추가되 었다. 이 러한 실행 (Exec) 권한 확인은 ACL 매커니즘 (Mechanism)으로는 보장되지 않는 부분이다. 이처 럼 트랩 이벤트 등록 과정 중에 Exec 권한을 검사하는 것은 다른 관리 객체 (MO)에서는 사용되지 않는
TrapMO의 독자적 인 부분이다. DM 프로토콜 (Protocol)에서
등록 (Registration)이 란 통상，관련 정보를 추가 (Add)함으로써 이루어진다. 이러한 등록 (Registration)이 필요한 관리 객체 (MO)로는 GwMO, SCOMO 등이 있다. [171] 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 Device)에 게 각각 이미지 (image)를 보내주는 것보다 DM 게이트웨이 (Gateway)에 있는 이미지 (image)를 반복적으로 단말 (End Device)에게 전달할 수가 있어 훨씬 효율적 이다. 이 러한 이미지 인벤토리 (Image Inventory) 기능을 수행하기 위해，이미지 둥록 (image Registration) 과정을 거쳐야 한다. 이 과정에서 DM 서버 (120)는 'ImagelnventoryMO'의 '<x>/Images/<x>' 밑에 관련 이미지 (image)를 추가 (Add)함으로써 등록을 수행하게 되는데，이 과정에서 역시 ACL로 보장되는 추가 (Add) 권한만 확인하면 층분하다.
[172] SCOMO에서도 단말에 다운로드 가능한 SW를 등록 (Registration)하는 과정 역시 비슷하며, DM 서버 (120)는 SCOMO의 '<x>/Download/<x>' 밑에
서브 -트리 (sub-tree)를 추가할 수 있는 권한만 확인하는 것으로 층분하다.
[173] 본 발명의 실시 예들은 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)에게 관리 권한 위 임)를 말한다.
[174] ACL은 위와 같은 사유로 인해，단말 관리 수행 증에 수시로 변할 수 있으며， 이를 Inward 트랩 보안에 반영하여 강화하는 방법을 본 발명은 담고 있다.
[175] 도 12는 본 명세서에 개시된 제 1 실시 예에 따른 Inward 트랩 이벤트 등록
과정을 나타내는 흐름도이다.
[176] 이 VI 클라이 언트 (110)는 DM 서버 (12<3)로부터 트랩 이 벤트인 'trap_eventl'을 모니터 링하기 위 한 트랩 이벤트 등록 요청을 수신한다 (S301). 이 때, DM 서버 (120)는 Inward 트랩을 둥록하며 , 'trap_eventl' 이 벤트 발생 시，실행할 단말의 명 령 인 'URir을 함께 보낸다 (본 실시 예에서 , 'trap_eventl'은
'WiFi— Connected' 이벤트이며 , 'URI1'은 'DiagMonMO/Restart/Operations/Start').
[177] DM 클라이언트 (110)는 DM 서버 (120)로부터 Inward 트랩 등록 요청을 받고, DM 서버 (120)가 해당 트랩 이벤트에 등록할 수 있는 권한을 확인한 후, Inward 트랩 등록을 수행한다 . DM 클라이언트 (110)는 DM 서버 (120)의 'ServerlD'가 올바른지 (부트스트랩 (bootstrapping)되 었는지 , DM 서버 (120)의
식 별자 (identifier)인지) DM 계정 (Account)을 통해 확인하고，본 등록과 연결시켜 저장한다 (S302).
[178] DM 클라이 언트 (110)는 WiFi가 연결되 었음을 감지한다 (S303).
[179] DM 클라이 언트 (110)는 WiFi 연결로부터 'trap_eventr이 발생하였음을
감지하고, 'trap_eventl'의 처리를 준비한다 (S304).
[180] DM 클라이 언트 (110)는 Inward 트랩으로 등록된 URI와 그 URI와 매핑되어 있는 ServerlD를 검 색한다 (S305). 예를 들어 , DM 클라이 언트 (110)는 TmpMO의 루트 (root)에서부터 시작하여 , TrapID가 'trap_eventl'인 TrapMO
인스턴스 (instance)를 검 색한다. 또한， DM 클라이 언트 (110)는 발견한 TrapMO 인스턴스 (instance)로부터， Inward 트랩으로 등록된 'TargetURI/<x>/URT를 검색하고， URI와 매핑되어 있는 ServerlD를 검 색한다. DM 클라이 언트 (110)는 ServerlD가 올바른 서버 식별자 (identifier)인지 DM 클라이 언트 (110)의 DM 계정 (Account)을 통해 확인한다. DM 클라이 언트 (110)는 상기 발견한 ServerlD가 URI가 가리키는 노드에 대한 실행 (Exec) 권한을 갖고 있는지 확인한다.
[181] DM 클라이언트 (110)는 이 두 가지 조건을 만족시키는 ServerlD만이 Inward 알림 에 대한 권한을 갖고 있다고 판단한다.
[182] DM 트리 (Tree)의 실행 권한을 나타내는 ACL은 실행시 바뀔 수 있는
런타임 (runtime) 속성 이기 때문에，본 발명의 실시 예들에 따른 권한 확인 방법에 의해 동적으로 바뀌는 ACL을 반영할 수 있다.
[183] 제 304 단계에서， ServerlD가 Inward 알림을 위한 권한이 있다고 확인되었을 경우에， DM 클라이 언트 (110)는 URI가 가리키는 노드에 Inward 알림을 보낸다 (S306). DiagMonMO(306)는 수행중인 작업을 재시작한다 (S307).
[184] 하나의 트랩 이벤트에 대해 다수의 Inward 트랩 등록이 이루어 질 수 있으므로, 이 러 한 경우 모든 등록에 대해 계 305 단계로 회귀한다.
[185] 도 13은 본 명세서에 개시된 제 2 실시 예에 따른 DM 계정 (Account)을 이용하여 Outward 트랩 이벤트 등록 및 알림 과정올 나타내는 흐름도이다.
[186] DM 클라이 언트 (110)는 DM 서버 (120)로부터 트랩 이벤트인 'trap_eventl'을 모니터 링하기 위 한 트랩 이벤트 등록 요청을 수신한다 (S311). 이때, DM 서버 (120)는 Outward 트랩을 등록하며, 'trap_eventl' 이 벤트 발생 시，이벤트를 보고할 서버로 DM 서버 ('DMS1')을 지정한다. 상기 예에서， 'trap_eventr은 'Low_Battery' 이벤트이다.
[187] DM 클라이 언트 (110)는 DM 서버 (120)로부터 수신한 Outward 트랩 등록을 인증한다 (S312). DM 클라이 언트 (110)는 DM 서버 ('DMS1')가 본 등록에 대한 등록 권한을 가지고 있는지 확인한다. 또한, DM 서버 ('DMS1')의 ServerlD가 을바른지 (부트스트랩 (bootstrapping) 되었는지，그리고 부가적으로 DM 서버 (120)의 식별자 (identifier인지 )) DM 계정 (Account)올 통해 확인한다. 이 때 DM 서버 ('DMS1')가 부트스트랩 (bootstrapping)이 되어 있지 않다면，부가적으로 부트스트랩 (Bootstrapping)을 수행할 수 있다. 만일 DM 서버 ('DMS1')가 등록 권한을 가지고 있지 않거나, 부트스트랩 (bootstrapping)이 실패한다면, 등록은 실패한다.
[188] DM 클라이 언트 (110)가 성공적으로 DM 서버 (120)의 Outward 트랩 등록을 인증하였다면，등록을 수행한다 (S313).
[189] 부가적으로, DM 클라이 언트 (110)는 Outward 트랩 등록 결과를 DM
서버 (120)에 전송한다 (S314).
[190] DM 클라이 언트 (110)는 'Low_Battery' 이벤트를 감지한다 (S315).
[191] 제 315 단계에서 감지 한 'Low— Battery' 이벤트로부터 DM 클라이 언트 (110)는
'trap_eventr이 발생하였음을 감지하고 'trap_eventl'의 처리를 준비한다 (S316).
[192] DM 클라이언트 (110)는 DM 서버 (120)에 트랩 이벤트 'trap_eventl'과 관련된 정보를 전달한다 (S317).
[193] 도 14는 본 명세서 에 개시된 제 3 실시 예에 따른 낙관적 알림 제어 (Optimistic
Notification Control)를 이용한 Outward 트랩 이 벤트 등록 및 알림 과정을 나타내는 흐름도이다.
[194] DM 클라이 언트 (110)는 DM 서버 (120)로부터 트랩 이벤트인 'trap_eventl'을 모니터 링하기 위한 트랩 이벤트 등록 요청을 수신한다 (S321). 이때， DM 서버 (120)는 Outward 트랩올 등록하며， 'trap_eventl' 이 벤트 발생 시 , 이벤트를 보고할 서버로 DM 서버 ('DMS1')를 지정한다. 상기 예에서， 'trap_eventl'은
'Low— Battery' 이벤트이다.
[195] DM 클라이언트 (110)는 DM 서버 (120)로부터 Outward 트랩 둥록 요청을 받고，
DM 서버 ('DMS1')가 등록을 수행할 권한이 있는지 확인 후, 해당 둥록을 수행한다 (S322). 또한 DM 클라이 언트 (110)는 DM 서버 (120)의 ServerlD가 올바른지 DM 계정 (Account)을 통해 확인하고, 본 등록과 연결시켜 저장한다. 올바른 ServerlD는 DM 계정 (Account)을 통해 부트스트랩 (bootstrapping)되어 있고, 등록을 수행하는 DM 서버 (120)의 서버 식별자 (server identifier)이어야 한다 올바르지 않는 ServerlD라면 둥록은 실패한다.
[196] DM 클라이언트 (110)는 배터 리 (battery)가 일정 수준 이하로 낮아지는
'Low_Battery' 상태임을 감지한다 (S323).
[197] DM 클라이 언트 (110)는 'Low_Battery' 상태로부터 'trapᅳ eventl'이
발생하였음을 감지하고 trap_eventl의 처리를 준비한다 (S324).
[198] 이 VI 클라이언트 (110)는 DM 서버 ('DMS1')에 게 트랩 이벤트 'trap_eventl'과 관련된 정보，그리고 제 322 단계에서 저장한 ServerlD를 전달한다 (S325).
[199] DM 서버 ('DMS1')는 DM 클라이언트 (110)로부터 받은 'trap_eventl'의 정보와 본 Outward 트랩을 등록한 ServerlD 정보로부터，본 Outward 트랩 등록을 인증한다 (S326). DM 서버 ('DMS1')는 자신과 ServerlD를 갖는 서버와의 신뢰 관계를 통해，본 Outward 알림을 검증할 수 있다. 만약， Outward 알림 이 이전에 인증되었다면, 제 326 단계는 생략 가능하며 , 중복해서 동일한 Outward 알림에 대해 계속 확인할 필요는 없다ᅳ
[200] DM 서버 ('DMS1')가 받은 Outward 알림 이 인증을 받지 못하면, DM
서버 ('DMS1')는 DMS 클라이언트 (110)에 게 'trap_eventl'에 대한 DM
서버 ('DMS1')의 등록을 해제해 달라는 요청올 전송한다 (S327).
[201] 도 15는 본 명세서 에 개시된 단말 (400) 및 서버 (500)의 블록도이다.
[202] 도 15에 도시된 바와 같이 단말 (400)은 저장 수단 (410)과 컨트를러 (420)와
송수신부 (430)를 포함한다. 상기 저장 수단 (410)은 도 1 내지 도 14에 도시된 실시 예에 따른 방법을 저장한다. 상기 컨트롤러 (420)는 상기 저장 수단 (410) 및 상기 송수신부 (430)를 제어한다. 구체적으로 상기 컨트를러 (420)는 상기 저장 수단 (410)에 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트를러 (420)는 상기 송수신부 (430)를 통해 상기 전술한 신호들을 전송한다.
[203] 또한，도 15에 도시된 바와 같이 서버 (500)는 저장 수단 (510)과 컨트를러 (520)와 송수신부 (530)를 포함한다. 상기 저장 수단 (510)은 도 1 내지 도 14에 도시된 실시 예에 따른 방법을 저장한다. 상기 컨트를러 (520)는 상기 저장 수단 (510) 및 상기 송수신부 (530)를 제어한다. 구체적으로 상기 컨트롤러 (520)는 상기 저장 수단 (510)에 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트를러 (520)는 상기 송수신부 (530)를 통해 상기 전술한 신호들을 전송한다.
[204] 이와 같이，이상에서 기술한 실시 예들은 모든 면에서 예시적 인 것이며
한정적 인 것이 아닌 것으로서 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허 청구범위에 의하여 나타내어지며，특허청구범위의 의미 및 범위 그리고 그 등가개념으로부터 도출되는 모든 변경 또는 변형된 형 태가 본 발명의 범위에 포함되는 것으로 해석되어 야 한다.

Claims

청구범위
[청구항 1] 단말상의 다른 기능적 컴포넌트에 트랩을 통지하는 단말의 트랩 동작 제어 방법에 있어서 ,
서버로부터 트랩 둥록 요청을 수신하는 단계 여기에서 상기 트랩 등록 요청은, 트랩 (trap) 식별자，서버 식 별자 및 타겟 식별자를 포함하고;
상기 서버가 상기 트랩 식 별자와 연관되고 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계 ;
상기 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면， 상기 서버 식별자를 상기 트랩 식별자와 연관되게 저장하면서 트랩을 등록하는 단계 여기에서 상기 트랩은 트랩 이벤트를 포함하고 상기 트랩 식별자와 연관되고;
상기 트램 이벤트를 감지하는 단계 ;
상기 저장된 서버 식별자에 의해 식 별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계; 및 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있으면，상기 트랩 이벤트를 상기 실행 가능한 노드에 통지하는 단계를 포함하는 것을 특징으로 하는 단말의 트랩 동작 제어 방법 .
[청구항 2] 제 1 항에 있어서 , 상기 저장된 서버 식 별자에 의해 식별되는
서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계는，
접근 제어 리스트 (ACL; Access Control List)에 기초하여 , 상기 저장된 서버 식별자에 의해 식별되는 서버가 상기 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계인 것을 특징으로 하는 단말의 트램 동작 제어 방법 .
[청구항 3] 제 1 항에 있어서 , 상기 트랩을 등록하는 단계는，
상기 트랩 식별자와 연관된 트랩의 서브 -트리 (sub-tree)를 추가하는 단계를 포함하고，
상기 서브 -트리 (sub-tree)는,
상기 실행 가능한 노드를 지시하는 타겟 식별자와 상기 서버 식별자를 포함하는 것을 특징으로 하는 단말의 트램 동작 제어 방법 .
[청구항 4] 제 3 항에 있어서，상기 서버가 상기 트랩 식별자와 연관되고 상기 타겟 식별자에 의해 지시되는 실행 가능한 노드의 실행 권한을 가지고 있는지 확인하는 단계는, 상기서버가상기실행가능한노드의실행권한과함께
서브-트리를생성할수있는추가권한이있는지확인하는단계를 포함하는것을특징으로하는단말의트램동작제어방법.
[청구항 5] 제 1항에있어서，상기서버가상기실행가능한노드의실행
권한을가지고있찌않으면,상기서버에둥록실패를나타내는 메시지를송신하는단계를더포함하는것을특징으로하는 단말의트랩동작제어방법.
[청구항 6] 제 1항에있어서 ,상기저장된서버식별자에의해식별되는
서버가상기실행가능한노드의실행권한을가지고있지않으면， 상기트랩의등록을해제하는단계를더포함하는것올특징으로 하는단말의트랩동작제어방법.
[청구항 7] 제 6항에있어서，상기저장된서버식별자에의해식별되는
서버에상기트랩의등록이해제되었음을나타내는메시지를 송신하는단계를더포함하는것을특징으로하는단말의트랩 동작제어방법.
[청구항 8] 단말상의다른기능적컴포넌트에트랩을통지하는단말에
있어서，
서버로부터트랩등록요청을수신하는송수신부여기에서상기 트랩둥록요청은，트랩 (tmp)식별자,서버식별자및타겟 식별자를포함하고;및
상기서버가상기트랩식별자와연관되고상기타겟식별자에 의해지시되는실행가능한노드의실행권한을가지고있는지 확인하고,상기서버가상기실행가능한노드의실행권한을 가지고있으면，상기서버식별자를상기트랩식별자와연관되게 저장하면서트랩을둥록하고，여기에서상기트랩은트랩 이벤트를포함하고상기트랩식별자와연관되고,상기트랩 이벤트를감지하고,상기저장된서버식별자에의해식별되는 서버가상기실행가능한노드의실행권한을가지고있는지 확인하는컨트롤러를포함하고,
상기송수신부는,
상기저장된서버식별자에의해식별되는서버가상기실행 가능한노드의실행권한을가지고있으면，상기트램이벤트를 상기실행가능한노드에통지하는것을특징으로하는단말.
[청구항 9] 서버에트랩올통지하는단말의트랩동작제어방법에있어서, 서버로부터트랩등록요청을수신하는단계여기에서상기트랩 둥록요청은트랩식별자및상기트랩이통지되는서버의 식별자를포함하고;
상기트랩등톡요청에포함된서버의식별자가상기단말에트랩 등록 요청을 송신한 서버의 식별자와 동일한지 확인하는 단계 ; 및 상기 트램 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식 별자와 동일하면, 상기 트랩 식별자와 연관된 트램올 둥록하는 단계를 포함하는 것올 특징으로 하는 단말의 트랩 등록 제어 방법 .
[청구항 10] 제 9 항에 있어서 , 상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 둥록 요청을 송신한 서버의 식별자와 동일하지 않으면，상기 단말에 트랩 등록 요청을 송신한 서버에 등록 실패를 나타내는 메시지를 송신하는 단계를 더 포함하는 것올 특징으로 하는 단말의 트램 등록 제어 방법 .
[청구항 11] 서버에 트랩을 통지하는 단말에 있어서,
서버로부터 트램 등록 요청올 수신하는 송수신부 여기에서 상기 트랩 둥록 요청은 트랩 식별자 및 상기 트랩이 통지되는 서버의 식 별자를 포함하고; 및
상기 트랩 둥록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식 별자와 동일한지 확인하고，상기 트랩 등록 요청에 포함된 서버의 식별자가 상기 단말에 트랩 등록 요청을 송신한 서버의 식별자와 동일하면，상기 트랩 식별자와 연관된 트램을 등록하는 컨트를러를 포함하는 것을 특징으로 하는 단말.
PCT/KR2012/000625 2011-01-27 2012-01-27 트랩 이벤트 등록 및 알림 방법 및 이를 채용하는 단말 WO2012102566A2 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/979,804 US9426043B2 (en) 2011-01-27 2012-01-27 Method for registering and providing notice of a trap event, and terminal using same
CN201280006886.XA CN103493429B (zh) 2011-01-27 2012-01-27 通知陷阱到设备的其它功能性组件的方法和通知陷阱到其它功能性组件的设备
EP12740034.9A EP2651073B1 (en) 2011-01-27 2012-01-27 Method for registering and providing notice of a trap event, and terminal using same
KR1020137017507A KR101560072B1 (ko) 2011-01-27 2012-01-27 트랩 이벤트 등록 및 알림 방법 및 이를 채용하는 단말

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201161436972P 2011-01-27 2011-01-27
US61/436,972 2011-01-27
US201161470491P 2011-04-01 2011-04-01
US61/470,491 2011-04-01
US201161527622P 2011-08-26 2011-08-26
US61/527,622 2011-08-26

Publications (2)

Publication Number Publication Date
WO2012102566A2 true WO2012102566A2 (ko) 2012-08-02
WO2012102566A3 WO2012102566A3 (ko) 2012-12-20

Family

ID=46581299

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/000625 WO2012102566A2 (ko) 2011-01-27 2012-01-27 트랩 이벤트 등록 및 알림 방법 및 이를 채용하는 단말

Country Status (5)

Country Link
US (1) US9426043B2 (ko)
EP (1) EP2651073B1 (ko)
KR (1) KR101560072B1 (ko)
CN (1) CN103493429B (ko)
WO (1) WO2012102566A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112566283A (zh) * 2020-11-30 2021-03-26 江苏极鼎网络科技有限公司 一种移动设备终端设备

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012221506A (ja) * 2011-04-07 2012-11-12 Kotatsu Kokusai Denshi Kofun Yugenkoshi ソフトウェアコンポーネント情報取得方法、ソフトウェアコンポーネント取得方法、サービスシステム
WO2013191515A1 (ko) * 2012-06-22 2013-12-27 엘지전자 주식회사 무선 통신 시스템에서 서버를 활성화 또는 비활성화하기 위한 방법 및 장치
EP2851833B1 (en) 2013-09-20 2017-07-12 Open Text S.A. Application Gateway Architecture with Multi-Level Security Policy and Rule Promulgations
US9979751B2 (en) 2013-09-20 2018-05-22 Open Text Sa Ulc Application gateway architecture with multi-level security policy and rule promulgations
US10824756B2 (en) 2013-09-20 2020-11-03 Open Text Sa Ulc Hosted application gateway architecture with multi-level security policy and rule promulgations
US11593075B2 (en) 2015-11-03 2023-02-28 Open Text Sa Ulc Streamlined fast and efficient application building and customization systems and methods
US11388037B2 (en) 2016-02-25 2022-07-12 Open Text Sa Ulc Systems and methods for providing managed services

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100121967A1 (en) 2007-04-06 2010-05-13 Ji-Eun Keum System and method for device management security of trap management object

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6536037B1 (en) * 1999-05-27 2003-03-18 Accenture Llp Identification of redundancies and omissions among components of a web based architecture
US7200651B1 (en) * 1999-07-02 2007-04-03 Cisco Technology, Inc. Dynamic configuration and up-dating of integrated distributed applications
US6990518B1 (en) * 2001-03-22 2006-01-24 Agilent Technologies, Inc. Object-driven network management system enabling dynamically definable management behavior
US7099947B1 (en) * 2001-06-08 2006-08-29 Cisco Technology, Inc. Method and apparatus providing controlled access of requests from virtual private network devices to managed information objects using simple network management protocol
US7082464B2 (en) * 2001-07-06 2006-07-25 Juniper Networks, Inc. Network management system
US7328260B1 (en) * 2002-06-04 2008-02-05 Symantec Operating Corporation Mapping discovered devices to SAN-manageable objects using configurable rules
US9077611B2 (en) * 2004-07-07 2015-07-07 Sciencelogic, Inc. Self configuring network management system
JP2006222929A (ja) * 2005-01-14 2006-08-24 Hitachi Communication Technologies Ltd ネットワークシステム
JP2008537858A (ja) * 2005-03-15 2008-09-25 エムフォーメイション テクノロジーズ インコーポレイテッド ワイヤレス端末においてトラップを管理及び監視するためのシステム及び方法
CN100479575C (zh) 2005-06-30 2009-04-15 华为技术有限公司 在设备管理中实现预定操作的方法及装置
US20070093243A1 (en) * 2005-10-25 2007-04-26 Vivek Kapadekar Device management system
US7966653B2 (en) * 2005-10-25 2011-06-21 International Business Machines Corporation Method and data processing system for determining user specific usage of a network
CN1859171A (zh) * 2005-12-02 2006-11-08 华为技术有限公司 一种网络设备数据管理方法
CN101009515A (zh) * 2006-01-24 2007-08-01 华为技术有限公司 通信终端设备管理方法及通信终端
US20070207800A1 (en) * 2006-02-17 2007-09-06 Daley Robert C Diagnostics And Monitoring Services In A Mobile Network For A Mobile Device
US20080065753A1 (en) * 2006-08-30 2008-03-13 Rao Bindu R Electronic Device Management
US8880578B2 (en) * 2006-12-01 2014-11-04 Lsi Corporation Hardware independent simple network management protocol based on a generic data collection scheme
JP5013838B2 (ja) * 2006-12-11 2012-08-29 キヤノン株式会社 ネットワーク管理システム、情報処理装置、および情報処理装置の制御方法
KR101401799B1 (ko) * 2007-07-19 2014-05-29 삼성전자주식회사 디바이스 관리 서비스를 브로드밴드 통신 모듈이 없는전자기기에 제공하는 시스템 및 방법
US8249848B2 (en) * 2007-09-05 2012-08-21 International Business Machines Corporation Verifying a processor design using a processor simulation model
US20110047253A1 (en) * 2009-08-19 2011-02-24 Samsung Electronics Co. Ltd. Techniques for controlling gateway functionality to support device management in a communication system
US20120233319A1 (en) * 2010-09-08 2012-09-13 Yang Ju-Ting Method of Diagnostics and Monitoring Management and Related Communication Device

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100121967A1 (en) 2007-04-06 2010-05-13 Ji-Eun Keum System and method for device management security of trap management object

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112566283A (zh) * 2020-11-30 2021-03-26 江苏极鼎网络科技有限公司 一种移动设备终端设备

Also Published As

Publication number Publication date
KR20140033318A (ko) 2014-03-18
EP2651073A2 (en) 2013-10-16
CN103493429B (zh) 2017-05-31
WO2012102566A3 (ko) 2012-12-20
CN103493429A (zh) 2014-01-01
KR101560072B1 (ko) 2015-10-13
US9426043B2 (en) 2016-08-23
EP2651073B1 (en) 2019-06-19
US20130297789A1 (en) 2013-11-07
EP2651073A4 (en) 2017-06-14

Similar Documents

Publication Publication Date Title
WO2012102566A2 (ko) 트랩 이벤트 등록 및 알림 방법 및 이를 채용하는 단말
JP6231054B2 (ja) 無線装置のプラットフォームの検証と管理
JP3995338B2 (ja) ネットワーク接続制御方法及びシステム
US8291093B2 (en) Peer-to-peer remediation
JP5987039B2 (ja) 複数のドメインのシステムおよびドメイン所有権
KR102104899B1 (ko) 무선 통신 시스템에서 접근 권한 인증을 위한 방법 및 장치
CN110476447A (zh) 在支持网络切片的移动系统中的增强的注册过程
US20160285628A1 (en) System and method for trusted provisioning and authentication for networked devices in cloud-based iot/m2m platforms
US9210035B2 (en) System, servers, methods and computer programs for machine-to-machine equipment management
US20060280127A1 (en) Domestic network setting method, home gateway device, home gateway program, and recording medium
WO2017004373A1 (en) Resource-driven dynamic authorization framework
US20180198786A1 (en) Associating layer 2 and layer 3 sessions for access control
US20060156388A1 (en) Method and apparatus for a security framework that enables identity and access control services
CN102859935A (zh) 利用虚拟机远程维护电子网络中的多个客户端的系统和方法
CN104054321A (zh) 针对云服务的安全管理
US8468585B2 (en) Management of credentials used by software applications
WO2014099690A1 (en) Hardware management interface
CA2523532A1 (en) Portable computing environment
Ahmad et al. Extending access control in AWS IoT through event-driven functions: an experimental evaluation using a smart lock system
WO2014038820A1 (ko) 무선 통신 시스템에서 서버의 단말의 리소스에 대한 접근 권한을 관리하기 위한 방법 및 이를 위한 장치
WO2008123682A1 (en) System and method for device management security of trap management object
CN113992420B (zh) 一种权限管理方法、系统，电子设备和存储介质
EP3235268A1 (en) Method, network node and terminal device in a communication network
CN118118906A (zh) 通信方法及通信装置
CN113660283A (zh) 一种合法性认证方法以及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12740034

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 20137017507

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2012740034

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13979804

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE