Patent Application
20060143179
The present invention relates generally to the field of apparatus and methods for managing security policies in mobile electronic devices and more particularly, to apparatus and methods that employ a device management tree.
Computing devices may have different capabilities and features based on the applications installed in their memory. The applications may be pre-installed to a computing device before purchase by a customer or installed after purchase by a customer or service technician via a storage media, such as a magnetic or optical disk. For computing devices that communicate with a computer network, applications may be installed after a customer or service technician downloads the applications to the computing device.
Installations of applications and updates on client devices present other issues that are not a concern for wired devices. Users of client devices frequently need access to a variety of information, but such information is not as readily available as wired connections due to the limited bandwidth of wireless connections. Also, the traffic experienced by a client device should be minimized in order to minimize power drain on the device's power source. Thus, communications are challenged to maximize the quality of information provided to client devices while minimizing the traffic imposed on the wireless connections to the devices.
A communication that utilizes a large number of applications must have the capability of managing the applications efficiently and proficiently. Two of the more important functions of these systems are client provisioning and device management. Generally, these functions operate independently (with the exception of the WAP profile used in SyncML device management bootstrapping). On the other hand, there are advantages for client provisioning and device management to converge. As application data protocols, both functions are typically generic and, thus, they are quite similar. The major difference between client provisioning and device management is at the level of transport protocols, where client provisioning is confined to a certain type. Thus, the amount and complexity of data that can be provisioned is limited.
Also, other nondevice management agents (e.g. software applications) in addition to client provisioning applications are also used on mobile client devices. For example, device configuration agents typically use different paths and mechanisms to access (e.g. read or write) device management data that is stored in varying locations and different databases leading to complexities and inconsistencies. The open mobile alliance (OMA) device management standard employs application level protocol (syncML DM), with transport protocol bindings (WAP, HTTP, OBEX) and a meta-data model called a device management tree (DMT) and also a small data model that maps some basic device configuration information on to the device management tree. However, the device management tree is designed to be used only with the device management user agent. At the same time other device management protocols and agents may exist on the same device and store and read data, such as client provisioning agents, device setting applications that may set for example the colors of a user interface, and other applications. Several problems can arise since data integrity may not be maintained since data access is not controlled by different applications. Also data consistency may be jeopardized since the values in a relationship checks to multiple applications agents and servers is not centralized.
For example,
As such, multiple agents may bypass the DMT 226 and store data in one more different databases and with different formatting. Hence, the data may not be synchronized and may be corrupted because there is no locking built in (e.g. multiple writes could potentially occur). In addition, the DMT controls the storage of data in a hierarchical fashion and is not typically used in the course of running an application. Also, device settings are typically stored in proprietary locations and other applications may not know where the device settings are located. In addition, other agents may store data in the DM data store 614 but not in an understood manner so that the data cannot be found by other agents. Conventional systems typically require that only the DM agent can utilize the DMT 226.
Also, the device management tree utilizes access control lists (ACL's) to access nodes and subtrees of the device management tree. ACL's are special attributes, optionally associated with device management tree nodes and are applied to the subtrees from the node down to the leafs or to the next node which has an ACL defined. The device management tree mechanism was designed for remote access by for example for an OMA DM server, and the subjects of the ACL's are server identifiers, as determined during the server authentication process. Unlike other data, ACL's in the DMT are controlled by a special variant of standard data manipulation commands. As attributes, they are also of a complex nature, with a syntax associating node operations with server identities for which they allowed. As such, the conventional device management tree of an OMA DM typically has only a single type of subject, mainly the management server identifier. As such, an external security policy subject, such as the management server is typically stored in the device management tree. They are introduced by explicit specification in for example an API as string parameters. However the DMT does not accommodate non-server policy subjects, such as applications or other entities.
As to security policy enforcement, it is known to use JAVA policy files for JAVA 2 security which may be suitable for runtime operations, but makes remote management of such policies difficult. Accordingly, a need exists for methods and apparatus with improved security policy enforcement and/or provisioning.
Briefly, a method and wireless client device, receives security policy information, such as that associated with a nonserver entity, such as an application on the device, for example, and updates the device management tree with the received security policy information. The device management tree is then accessed in response to a security policy access request, such as from an application or other non server entity during runtime of the wireless client device. As such, not only does the device management tree include external security policy subjects, such as server identities, but different internal security policy subjects are also used to configure a device management tree with suitable security policy enforcement information. Examples of internal subjects may include, but are not limited to, for example an OSGi bundle logical identifier, an OSGi bundle signer, a wireless carrier identifier as defined, for example, in a subscriber identification module (SIM), a subscription identifier from a subscriber identification module, or any other suitable information.
In one embodiment, an application interface (API) interfaces to a device management engine where the application interface (e.g. a security agent) is accessed by various local applications during runtime, to facilitate security policy enforcement. In one embodiment, the internal subjects are extracted by the device management tree engine. With respect to external subject types, although server identities are employed, it will be recognized that in cases where multiple users have access, for example, to the same mobile wireless device, the user identities may be determined in a process of authentication and can serve as external subject types as well.
One of the many advantages of the disclosed apparatus and methods is to make security policies themselves over the air provisionable. As such, security policies of nonservers, are placed in the device management tree from which they are read during the runtime.
Referring to
The wireless communication network 104 may include a variety of components for proper operation and communication with the client device 102. For example, for the cellular-based communication infrastructure shown in
The server 110 is capable of providing services requested by the client device 102. For example, a user of the device 102 may send a request for assistance, in the form of a data signal (such as text messaging), to the wireless communication network 104, which directs the data signal to the server 110. In response, the server 110 may interrogate the device and/or network state and identify one or more solutions. For those solutions that require change or correction of a programmable module of the device 102, the server 110 may send update data to the device via the wireless link 106 so that the programmable module may be updated to fulfill the request. If multiple solutions are available, then the server 110 may send these options to the device 102 and await a response from the device before proceeding.
The first embodiment 100 may also include an operator terminal 114, managed by a service person 116, which controls the server 110 and communicates with the device 102 through the server. When the server 110 receives the request for assistance, the service person may interrogate the device and/or network state to identify solution(s) and/or select the best solution if multiple solutions are available. The service person 116 may also correspond with the device 102 via data signals (such as text messaging) to explain any issues, solutions and/or other issues that may be of interest the user of the device.
The first embodiment 100 may further include a voice client device 118 connected to the rest of the wireless communication network 104 via a wired or wireless connection, such as wired line 118, and is available for use by the service person 116. The voice client device 118 may also connect to the network via the server 110 or the operator terminal 114. Thus, in reference to the above examples, a user of the device 102 may send a request for assistance, in the form of a voice signal, to the wireless communication network 106, which directs the data signal to the server 110. While the server 110 and or the service person 116 is interrogating the device and/or network state, identifying one or more solutions, and/or selecting an appropriate solution, the service person may correspond with the device 102 via voice signals to explain any issues, solutions and/or other issues that may be of interest the user of the device.
Referring to
The major difference comes at the level of transport protocols. For the example shown in
The client provisioning characteristics and parameters may be defined so that they may operate over the device management tree. A single new characteristic which is recursive may be utilized and is referenced herein as SYNCML-DM. The parameter names include, but are not limited to, a uniform resource identifier (URI) parameter, an operational (OP) parameter and a DATA parameter. The URI parameter is a sync node device management URI. An actual URI may be calculated as concatenation of URI's of nested characteristics and is the only parameter appearing in non-inner-most characteristics. The OP parameter is a node operation, with possible values such as ADD, REPLACE, DELETE and EXECUTE. The DATA parameter is data that may be applied by the operation, if any.
As shown in
The device management server 202 of the network 104 communicates with the device management agent 208 of the client device via communication link 212. For one embodiment, the signal protocol between the servers 202, 204 and the agents 208, 210 is a Hyper Text Transfer Protocol/Object Exchange (HTTP/OBEX). The provisioning and management framework 206 also receives sync signals, in the form of WAP Push, from the device management server 202 via connection link 214 and provides the incoming device management signals to the device management agent 208 via connection link 218. Likewise, the provisioning and management framework 206 further receives provisioning signals, in the form of WAP Push, from the client provisioning server 204 via connection link 216 and provide the incoming provisioning signals to the client provisioning agent 210 via connection link 220.
The client device further includes a device management engine 222 communicating with the device management agent 208 via connection link 224 and a device management tree 226 communicating with the device management engine via communication link 228.
Referring to
Referring to the client device 102 and the server 110 of
The input and output devices 308, 310 of the internal components 300 may include a variety of visual, audio and/or mechanical outputs. For example, the output device(s) 308 may include a visual output device 316 such as a liquid crystal display and light emitting diode indicator, an audio output device 318 such as a speaker, alarm and/or buzzer, and/or a mechanical output device 320 such as a vibrating mechanism. Likewise, by example, the input devices 310 may include a visual input device 322 such as an optical sensor (for example, a camera), an audio input device 324 such as a microphone, and a mechanical input device 326 such as a flip sensor, keyboard, keypad, selection button, touch pad, touch screen, capacitive sensor, motion sensor, and switch.
The internal components 300 may include a location circuit 328. Examples of the location circuit 328 include, but are not limited to, a Global Positioning System (GPS) receiver, a triangulation receiver, an accelerometer, a gyroscope, or any other information collecting device that may identify a current location of the device.
The memory portion 306 of the internal components 300 may be used by the processor 304 to store and retrieve data. The data that may be stored by the memory portion 306 include, but is not limited to, operating systems, applications, and data. Each operating system includes executable code that controls basic functions of the client device, such as interaction among the components of the internal components 300, communication with external devices via the transceiver 302 and/or the component interface 312, and storage and retrieval of applications and data to and from the memory portion 306. Each application includes executable code utilizes an operating system to provide more specific functionality for the client device, such as file system service and handling of protected and unprotected data stored in the memory portion 306. Data is non-executable code or information that may be referenced and/or manipulated by an operating system or application for performing functions of the client device.
The processor 304 may perform various operations to store, manipulate and retrieve information in the memory portion 306. Each component of the internal components 300 is not limited to a single component but represents functions that may be performed by a single component or multiple cooperative components, such as a central processing unit operating in conjunction with a digital signal processor and one or more input/output processors. Likewise, two or more components of the internal components 300 may be combined or integrated so long as the functions of these components may be performed by the client device.
Referring to
After identifying a characteristic at step 408, the client device determines whether the characteristic includes a URI parameter but does not include an OP parameter or a DATA parameter at step 410. If the characteristic only includes a URI parameter, then the client device appends the URI parameter at step 412, stores the URI parameter by pushing it down on a URI stack at step 414, and returns to step 408 where the client device identifies the next characteristic from the client provisioning document.
If the client device determines that the characteristic does not only include a URI parameter at step 410, then the client device determines whether the characteristic includes an OP parameter at step 416. If not, then the client device sets the OP parameter to “REPLACE” at step 418 and thereafter determines whether the characteristic includes a DATA parameter step 420. If the characteristic does include an OP parameter, then the client device proceeds directly to step 420 without updating the OP parameter.
The client device determines whether the characteristic includes a DATA parameter at step 420. If not, then the client device sets the DATA parameter to a NULL value at step 422 and sets device management tree (DMT) data at step 424. If the characteristic does include a DATA parameter, then the client device proceeds directly to step 424 to set the DMT data. To set the DMT data at step 424, the client device provides the data to the device management tree 226 (shown in
Referring to
The third line 506 of the exemplary data format 500 identifies a second node, nested within the first node, having a characteristic type of SYNCML-DM. The fourth line 508 sets the URI parameter of the second node to be “FileName”, the fifth line 510 sets the OP parameter of the second node to be “REPLACE”, and the sixth line 512 sets the DATA parameter of the second node to be “log.txt”. The seventh line 514 refers back to line 506 and indicates the end of all descriptions of the second node.
The eighth line 516 of the exemplary data format 500 identifies a third node, nested within the first node along with the second node, having a characteristic type of SYNCML-DM. The ninth line 518 sets the URI parameter of the third node to be “Level”, the tenth line 520 sets the OP parameter of the third node to be “REPLACE”, and the eleventh line 522 sets the DATA parameter of the second node to be “3”. The twelfth line 524 refers back to line 516 and indicates the end of all descriptions of the third node. Likewise, the thirteenth line 526 refers back to line 502 and indicates the end of all descriptions of the first node and its nested sub-nodes.
The device management tree interface 702 may be implemented in any suitable manner and in this example is a software application stored in memory that is executed by a processor. The DM data store 704 may, for example, be memory 306 or any other memory as desired.
Referring also to
As shown in
The device management agent 208 as noted above configures a client device 701 via over the air control information to store at least some data in the DM data store 704 according to the device management tree 226 structure. Also in this example, nondevice management agents include, the client provisioning agent 210 the client device setting agent 618 a configurable application agent 619 and any other suitable agent other than the DM agent 208.
The device management tree engine 222 handles multiple device management tree queries from the plurality of nondevice management agents 618, 619, 210 and 620 as well as the device management agent 208. The device management tree 226 as known in the art defines a searchable hierarchical tree structure for storing data in a data base such as a DM data storer 704. The DMT engine 222 enforces a common set of meta-data value constraints by using the same device management tree 226 for all accesses to the DM data store 704 and enforces a set for meta-data value constraints independently of which of the plurality of nondevice management agents initiated the updating of data in the DM data store. The DMT engine 222 in combination with the DM API 702 enforce the common set of meta-data value constraints independently of which the plurality of JAVA applications cause the updating of the data in the device management tree.
Among other advantages, a single access path represented by the DM API 702 allows the client device to guarantee device management data integrity efficient parallel access by multiple agents. Meta-data value constraints are universally enforced whether the data change is performed by the settings application by the user or by customer care agent via over the air control or other.
As shown in block 1002, the method includes updating under control of a security manager module 1003 (see e.g.,
The method of
In one example, the wireless client device 102 may receive security information via over the air provisioning and may evaluate, for example, the security information if it is in the form of a digital certificate signed by a trusted authority. The wireless client device then maps the security policy information from the digital certificate into the device management tree wherein the security policy information is associated within an application (e.g., software agent or any other suitable application). In one example, receiving of the security policy information is done by obtaining a security policy file and mapping the contents of the security policy file into the hierarchical device management tree structure. Once the hierarchical device management tree structure has been updated based on the received security policy information, accessing the device management tree may be done based on an access control list. The access control list has information about the identity of the accessor, e.g. signer information, user identity or identity information from SIM card. The accessing of the DMT is performed by one or more applications during runtime to utilize the security policy information in the device management tree. Since the device management tree, stores hierarchical data that represents a subject type other than a management server identifier, such as internal security policy subjects, the disclosed device management tree operation usage is different from known device management tree operations.
This is represented in the device management tree by the subtree shown in
The resource name node 1108 stores the various resources being protected by the specific permissions, like files or sockets or other entities. The action node 1110 is data that defines the action on the resource, such as a read/write, listen/accept, or other suitable action. The signer name node 1112 refers to an optional signer of the permission class code. The resource and signer nodes 1114 and 1116 respectively designate the resources and signers associated with a specific permission class implementation.
domain: O=“MIDlet Underwriters, Inc.”, C=US
allow: javax.microedition.io.connector.http
oneshot(oneshot): javax.microedition.io.Connector.comm
To map this policy, for example, to the device management tree, the domain field is stored in the principle node, the allow and one shot fields are stored in the permission level node and the permission names; javax.microaddition.io.connector.htttp and javax.microaddition.io.connector.com; will be stored in the permission name nodes 1210.
Accordingly, various security policies are stored in the hierarchical DMT and are over the air provisionable. Local ACL subjects of multiple types along with server identities and a more generic model for storing, accessing and provisioning various types of security policies in the system such as DMT ACL's, OSGi policies, MIDP policies or other application type of policies may be carried out through the use of the device management tree during run time. Other advantages would be recognized by those of ordinary skill in the art.
While the preferred embodiments of the invention have been illustrated and described, it is to be understood that the invention is not so limited. Numerous modifications, changes, variations, substitutions and equivalents will occur to those skilled in the art without departing from the spirit and scope of the present invention as defined by the appended claims.
