Patent Application
20120036559
The present specification relates generally to telecommunications and more particularly relates to a system, method and apparatus for security management of an electronic device.
Complexity and features of electronic devices, particularly mobile electronic devices such as personal digital assistants incorporating wireless telephony, email and web-browsing functions, and the like, continue to advance. There is little sign of such advances plateauing. There is much activity relative to providing enhanced applications and services to these electronic devices. With provision of such enhanced applications comes the risk of malicious applications, including viruses and spyware.
Mobile devices also often store context information such as location information as well as other information that pertains to the identity of a given subscriber (for example, subscriber preferences such as preferred genres for content, identity information such as MSISDN or Uniform Resource Identifier addresses, billing and account information such as credit card information). This information may be explicitly input by the subscriber (for example, the subscriber may input his/her login information when accessing a given authorized application) or otherwise autonomously determined by applications resident within the device as the subscriber accesses a given authorized application (for example, the device may autonomously determine the location of the subscriber by using an embedded triangulation capability such as a the Global Positioning System). Problems can arise when malicious applications extract and forward subscriber or device information to an unauthorized server without the consent or knowledge of the subscriber.
A system, method and apparatus for security management of an electronic device are provided. In one aspect, the system includes a profile server and a inspection point server that are both connectable to a mobile electronic device. The mobile electronic device is configured to send contextual data such as location data (such as address, country, region/area, city, building, floor, altitude, geotags, latitude/longitude) or information pertaining to the identity of the subscriber from the device and into a network attached to the mobile electronic device. The profile server is configured to authorize (or deny authorization) of location requests. The inspection point server is configured to intercept the location data being sent from the device and query the profile server to determine if the request was authorized.
Those skilled in the art will now recognize that other contextual data (for example, the subscribers call or session state (e.g. busy, available, on-line, current web-site visited) or information that pertains to the identity of a given subscriber (for example, subscriber preferences, identity information, billing and financial information) may be sent from the device and applicable to the foregoing system, method and apparatus. Those skilled in that art will now recognize that the teachings herein can be extended to intermediate and regulate other contextual information or information that pertains to the identity of a given subscriber in addition to location data.
An aspect of the specification provides a security management system comprising a first computing module connectable to an electronic device. The first computing module is configured to receive an authorization request. The authorization request comprises a request for approval to send contextual data (such as location data or information pertaining to the identity of the subscriber) from the electronic device to a destination server. The first computing module is configured to access security management data. The first computing module is also configured to determine whether to generate authorization data that represents authorization of the request based on a comparison of the authorization request and the security management data. The system also comprises a second computing module connectable to the electronic device. The second computing module is configured to receive a delivery request from the electronic device to send contextual data such as location data or information pertaining to the identity of the subscriber to the destination server. The second computing module is configured to access the first computing module. The second computing module is configured to determine whether to send the location information based on a comparison of the delivery request and authorization data.
The first computing module can be implemented as a policy server.
The second computing module can be implemented as a inspection point server.
The first computing module and the second computing module can be implemented on a single server.
The security management data can comprise an identification of the electronic device or subscriber and destination server identification such that the authorization data is generated provided the destination server identification matches an identity of the destination server.
The security management data can further comprise additional settings such that the first computing module is configured to consider the additional settings when determining whether to generate the authorization data.
The additional settings can comprise privacy settings respective to the electronic device or subscriber.
The additional settings can comprise settings established by a carrier or service provider that provides network access to the electronic device.
The additional settings can comprise profile preferences pertaining to subscribers such as filters to allow/block information to/from subscribers under particular states (such as “busy”, “work”) and various granularities of location information (such as address, country, region/area, city, building, floor, altitude, geotags, latitude/longitude).
The additional settings can comprise settings established by the destination server.
Another aspect of the specification provides a method for security management comprising:
receiving a request to deliver contextual data (such as location data or information pertaining to the identity of the subscriber);
receiving authorization data representing whether the request is authorized; the authorization data generated in response to a request to generate the authorization data by the electronic device;
determining if the request to deliver the contextual data is acceptable based on a comparison of the request to deliver and the authorization data;
sending the contextual data for delivery based on results of the determining.
The response to the request to generate the authorization data can be based on an examination of security management data that comprises an identification of the electronic device and destination server identification such that the authorization data is generated provided the destination server identification matches an identity of a destination for the contextual data such as location data or information pertaining to the identity of the subscriber from specified in the request to deliver.
Various embodiments will now be discussed, by way of example only, in relation to the attached Figures in which:
Referring now to
While the present embodiment contemplates a core mobile network 62 (for example, network technologies based on Global System for Mobile (GSM) communications, Code Division Multiple Access (CDMA), and the like), it is to be understood that in other embodiments other types of networks other than core mobile network technologies are contemplated, such as, for example, (e.g. the Internet or an Intranet connected to electronic device 54 via an Institute of Electrical and Electronic Engineers (IEEE) 802.11 connection or IEEE 802.16).
Referring briefly to
Electronic device 54 also comprises a locating unit 232, which is implemented in a present embodiment in the form of a global positioning system (GPS) hardware chipset that communicates with the known network of GPS satellites and provides latitude and longitude coordinates of device 54 to processor 220. Locating unit 232 can be implemented in other ways. For example, in other embodiments, locating unit 232 can be implemented as software executable on processor 220, which communicates with network elements that are attached to the core mobile network 62 including a Gateway Mobile Location Centre (GMLC) (not shown) or Secure User Plane Location (SUPL) servers such as a SUPL Positioning Center (SPC) (not shown) or SUPL Location Center (SLC) (not shown). Such a GMLC and potentially other network elements are configured to determine the location of device 54 based on triangulation of device 54 in relation to a plurality of base stations, in addition to base station 66 that are in communication with radio network interface 226.
Electronic device 54, in the present exemplary embodiment, also comprises an authorized application 236 and an unauthorized application 240, which are maintained in non-volatile storage 228 and are executable on processor 220. Applications 236 and 240 will be discussed further below.
It should be understood that system 50 can be scaled to include a plurality of electronic devices 54.
Referring again to
Profile server 78 can be based on any suitable server computing environment. While not shown herein, it will be understood by those skilled in the art the server 62 includes a hardware configuration that may comprise one or more input devices in the form of a keyboard, a mouse and the like; one more output devices in the form of a display, and the like; a network interface for conducting network communications; all of which are interconnected by a microcomputer comprised of one or more central processing units that itself is connected to volatile memory and non-volatile memory. As will become apparent from the following discussions, the computing environment of profile server 78 will also comprise software processes that can be read from and maintained in non-volatile memory (or other computer readable media) that can be executed on the one or more central processing units.
Profile server 78 can also be configured to provide for a direct communication with an Inspection Point Server 102 to provide control and supplementary information for the purposes of the Inspection Point Server's function of traffic analysis. An example of this relationship may be found in the 3GPP standards for a Policy and Charging Rules Function (PCRF) in communication with a Policy and Charging Enforcement Function (PCEF), where the PCRF is Profile Server 78 and the PCEF is, encompassed by Inspection Point Server 102.
Profile server 78 also maintains a database 82 that can be maintained within the aforementioned computing environment or on a separate computing environment. Database 82 maintains security management data 86 respective to subscriber S or device 54, the details of which will be discussed in greater detail below.
Profile server 78 also maintains one or more interfaces, including, in a present embodiment, an authorized server interface 90, a subscriber interface 92, a device interface 94 and a provider interface 98, which are software applications that can be used to make certain changes to security management data 86 according various privileges associated with each interface 90, a subscriber interface 92, a device interface 94 and a provider interface 98. Each interface 90, 92, 94 and 98 and the privileges associated with each will be discussed further below.
System 50 also comprises an inspection point server 102 which is also connected to core mobile network 62. In turn, inspection point server 102 connects to a wide area network which in the present embodiment is the Internet 106. Internet 106 in turn is connected to at least one authorized server 110 and at least one unauthorized server 114. (Note that in other embodiments authorized server 110 and/or unauthorized server 114 can be directly connected to core mobile network 62 or Inspection point Server 102 instead of connected via Internet 106).
Both authorized server 110 and unauthorized server 114 represent computing devices that are capable of receiving and/or utilizing location data about device 54 as provided by locating unit 232. (In variations, authorized server 110 and unauthorized server 114 are capable of receiving other contextual data and/or information pertaining to the identity of the subscriber S that is stored in device 54). The identity of authorized server(s) 110 are maintained as part of security management data 86, and, as will be discussed in greater detail below, inspection point server 102 is configured to cooperate with device 54 and profile server 78 so that location data about device 54 (or other contextual data and/or information pertaining to the identity of the subscriber S that is stored in device 54) is permitted to be sent to authorized server 110, while location data about device 54 (or other contextual data and/or information pertaining to the identity of the subscriber S that is stored in device 54) is not permitted to be sent to unauthorized server 114.
It is to be understood that the features of profile server 78 can be incorporated into a policy decision point (PDP) server or Policy Charging Rules Function (PCRF) as contemplated in Request for Comments 3198 promulgated by the Internet Engineering Task Force (IETF) and found at http://www.ietf.orq/rfc/rfc3198.txt (IETF 3198). The features of inspection point server 102 can also be incorporated into a General Packet Radio Service (GPRS) Gateway Support Node (GGSN), a Packet Data Serving Node (PDSN), and/or can be an independent deep packet inspection (DPI) node directly in the path of traffic, and/or can be incorporated into a Policy Enforcement Point (PEP) as discussed in IETF 3198 and 3GPP TS 23.203 Policy and charging control architecture, and/or indirectly managing traffic through communications with such a Policy Enforcement Point (PEP).
It is also to be understood that where inspection point server 102 is incorporated into a GGSN, PDSN, DPI node, PCEF, and/or a PEP, and where that inspection point server 102 requests the decision from profile server 78 as incorporated into a PDP, then profile server 78 can be configured with the same privacy rules that are also used for the call flow that are used when a GMLC (as incorporated into core mobile network 62) requests a privacy decision. An alternative design is that the inspection point server 102 (again as incorporated into a PEP) can be configured to request a policy decision from a Policy Charging Control Architecture (PCC) defined in the 3GPP standard TS23.203 and as incorporated into core mobile network 62. Of note, however, is that the TS23.203 standard does not provide any privacy capability today, so one, non-limiting, inventive aspect of the present specification is that a suitably modified PCC can proxy that policy request to a suitably modified policy server 78; that suitably modified policy server 78 can then continue with the same privacy decision processing in just the same way as if the GMLC requested a privacy decision. Alternatively, the inspection point server 102, as incorporated into a GGSN, PDSN, DPI node, and/or PEP, can be requested to provide a privacy decision or any other application/content server requested a privacy decision. Thus, another, non-limiting, inventive aspect of the present specification is that, where the GMLC is not in path of a location request then inspection point server 102 can still manage privacy through integration between the inspection point server 102 as incorporated into a GGSN, PDSN, DPI node, PCEF and/or PEP, and profile server 78.
Those skilled in the art will recognize that other subscribers (depicted as subscriber S′ in
Referring now to
Block 305 comprises receiving provider provisioning data. Block 305 can be implemented by way of a desktop computer or the like that connects to provider interface 98 via Internet 106 or in other suitable fashion. Such a desktop computer would typically be operated by a customer service representative of the carrier or service provider that hosts and otherwise administers the access of device 54 on core mobile network 62 (even if device 54 happens to be “roaming” and connected to core mobile network 62 via a base station 66 that is not controlled by that carrier or service provider). The provider provisioning data can typically comprises identifying information about subscriber S or device 54, such as one or more of the Mobile Systems International Subscriber Identity Number (MSISDN), International Mobile Equipment Identity (IMEI), and an indication of whether or not subscriber S or device 54 is permitted to access Internet 106 or servers attached to Internet 106. The provider provisioning data can also comprise the identity of authorized server 110 or the identity of unauthorized server 114.
Block 308 comprises receiving subscriber provisioning data. Block 308 can be implemented by way of a desktop computer or the like that connects to subscriber interface 92 via Internet 106 or in other suitable fashion. Block 308 can also be implemented by way of the device 54 where the device is connected to subscriber interface 92 via a number of messaging protocols (e.g. Short Message Service, Unstructured Supplementary Service Data) and IP protocols (e.g. Wireless Application Protocol, Session Initiation Protocol, Hypertext Transfer Protocol, and Extensible Markup Language). The subscriber S administers the access of device 54 on core mobile network 62 (even if device 54 happens to be “roaming” and connected to core mobile network 62 via a base station 66 that is not controlled by that carrier or service provider). The subscriber provisioning data can typically comprises identifying information about the subscriber S or device 54, such as one or more of the Mobile Systems International Subscriber Identity Number (MSISDN), International Mobile Equipment Identity (IMEI), and an indication of whether or not the subscriber S or device 54 authorizes the explicit or autonomous access or delivery of contextual data such as location data or information pertaining to the identity of the subscriber to the Internet 106 or servers attached to Internet 106. The subscriber provisioning data can also comprise the identity of authorized server 110 or the identity of unauthorized server 114. An authorized agent (not shown) may administer the access of device 54 on core mobile network 62 on behalf of a subscriber S. For example, a parent may administer the security access data on behalf of a child or a corporate administrator may administer the security access data on behalf of an employee.
Block 310 comprises receiving device provisioning data. Block 310 can also be implemented by way of a desktop computer or the like that connects to device interface 94 via Internet 106 or in other suitable fashion. Alternatively, or in addition, block 310 can be effected by a connection from device 54 to device interface 94, either via Internet 106 or via a direct connection (not shown) from device 54 via core mobile network 62 to device interface 94. However device interface 94 is accessed, such access would typically be effected by a subscriber that owns, operates or controls device 54. The device provisioning data can typically comprise the identity of authorized server 110 or the identity of unauthorized server 114, potentially overriding such identities if they have been provided as part of provider provisioning data at block 305. The device provisioning data can also comprise any specific privacy restrictions. Such privacy restrictions can include, for example, restricting time periods during which a server is identified as an authorized server, and then other time periods during which a serve is identified an unauthorized server.
Block 315 comprises receiving authorized server provisioning data. Block 315 can be implemented by way of a desktop computer or the like that connects to authorized server interface 90 via Internet 106 or in other suitable fashion. Such a desktop computer would typically be operated by a customer service representative or the like that hosts and otherwise administers authorized server 110. Block 315 can also be implemented via direct connection from authorized server 110 connecting to authorized server interface 90. Authorized server provisioning data can include, for example, digital certificates or other security tokens that can be used to verify the identity or authenticity of requests from authorized server 100.
The foregoing teachings relative to privacy restrictions can be supplemented by the teachings of Applicant's copending application PCT/CA2007/001570, “METHOD AND SYSTEM FOR ACTIVE PROFILE SERVER” the contents of which are incorporated herein by reference.
Block 320 comprises storing, managing, and distributing the security management data. Block 320 can be implemented by profile server 78 generating security management data 86 so as to contain the results of blocks 305, 308, 310 and 315, and to store security management data 86 on database 82. In turn, the security management data can be used to configure to affect the operation of the device 54, network elements in the core mobile network 62 (e.g. GMLC, SPC, or SLC), or Inspection Point Server 102. For example, the collective security management data can be used to update the settings of an anti-spyware application on the device 54, the settings of triangulation infrastructure attached to the core mobile network 62, or settings of the Inspection Point Server so that only traffic of interest results in a query to the Profile Server 78. Those skilled in the art will recognize that the dissemination of configuration data can be used to collectively reduce signalling and message traffic in the core mobile network 62 and between the inspection point server 102 and profile server 78. The dissemination of configuration data associated with security management data can be realized with a configuration mediation platform as described by the teachings of Applicant's copending application PCT/CA2008/000491, “CONFIGURATOR” the contents of which are incorporated herein by reference. Those skilled in the art will recognize that a number of protocols and interfaces can be used to disseminate configuration data into the device 54, network elements in the core mobile network 62 (e.g. GMLC, SPC, or SLC), or Inspection Point Server 102 including Application Programming Interfaces (API) based on CORBA (Common Object Request Broker Architecture) or SOAP/XML (Simple Object Access Protocol/Extensible Markup Language).
It should be understood that all or part of method 300 can be re-performed in order to provide updates or modifications to security management data 86. It should also be understood that security management data 86 can be generated and stored using other methodologies other than method 300. Of note is that not all blocks of method 300 need be performed in order to generate security management data 86.
As a general, simplified example, Table I shows exemplary contents of security management data 86, which can be generated by method 300 or other means.
Table I contains two fields; Device Identification and Authorized Server Identification. The contents of device identification field provide at least one unique identifier (e.g. IMEI, IMSI, MSISDN, Uniform Resource Identifier (URI) (e.g. John.Doe@network_operator.com)) for device 54 or subscriber S. The contents of the authorized server identification field provide at least one unique identifier (e.g. Internet Protocol address, Media Access Control (MAC) Identifier, digital certificate, Uniform Resource Identifier (URI) (e.g. Social_nework_application@generic_network.com)) for authorized server 110. Additional fields can be added to Table Ito provide further security management data as desired.
Referring now to
Block 405 comprises receiving a location request authorization. In system 50, the location request is received by profile server 78. The location request itself can be generated by authorized application 236 or unauthorized application 240 executing on device 54, introduced earlier in reference to
Those skilled in the art will now recognize that a number of protocols and interfaces can be used to query the profile server 78 including RADIUS (Remote Authentication Dial In User Service), DIAMETER, Session Initiation Protocol (SIP) as well as Application Programming Interfaces (API) based on CORBA (Common Object Request Broker Architecture) or SOAP/XML (Simple Object Access Protocol/Extensible Markup Language).
Both applications 236 and 240 include the functionality of obtaining location data corresponding to the location of device 54 via locating unit 232 and placing that location data in volatile storage 224 for usage by processor 220. Those skilled in the art will now recognize that applications 236 and 240 can also access other contextual data as well as information pertaining to the identity of the subscriber S that is stored in device 54. Likewise, both applications 236 and 240 also include the functionality of sending that location data or other contextual data as well as information pertaining to the identity of the subscriber S that is stored in device 54 over link 70 via network interface 216. More specifically, authorized application 236 is configured to attempt to deliver the location data to authorized server 110 or unauthorized server 114, while unauthorized application 240 is configured to attempt to deliver the location data to unauthorized server 114.
It should now be understood that authorized application 236 is defined, for purposes of explaining these embodiments, as “authorized” because security management data 86 as defined in Table I indicates that server 110 is “authorized”. By the same token, it should now be understood that unauthorized application 240 is defined, for purposes of explaining these embodiments, as “unauthorized” because security management data 86 as defined in Table I includes no express indication that server 114 is “authorized”, and therefore server 114 is deemed to be “unauthorized”. Table I could be structured so as to include an express list of “unauthorized” application as well.
Block 410 comprises receiving security management data. Block 410 is performed by profile server 78 accessing database 82 to read security management data 86 therefrom.
Block 415 comprises determining if the request at block 405 is acceptable. Block 415 can be implemented by profile server 78 utilizing programming logic to compare the contents of the request from block 405 with the contents of security management data 86. Thus, if the request at block 405 was generated by unauthorized application 240, then the determination at block 415 will be “no”, the request at block 405 is not acceptable and the request will be refused. In an embodiment where the contextual data is embedded in the data traffic, the profile server 78 will send a response to the inspection point server 102 indicating that the location request was not authorized. In turn, the inspection point server 102 will not allow the data traffic containing the contextual data to be forwarded to the authorized server 110. A notification (not shown) may be communicated to the device, subscriber, or authorized agent describing details pertaining to the unauthorized access attempt (for example, the address and service information associated with the unauthorized server). The notification may be sent via a variety of well known messaging systems including but not limited to Short Message Service (SMS), Multi-Media Message Service (MMS), or e-mail.
If, however, the request at block 405 was generated by authorized application 236, then the determination at block 415 will be “yes”, the request at block 405 is acceptable and the request will be authorized. In an embodiment where the contextual data is embedded in the data traffic, the profile server 78 will send a response to the inspection point server 102 indicating that the location request was authorized. In turn, the inspection point server 102 will allow the data traffic containing the contextual data to be forwarded to the authorized server 110.
As part of the performance of block 420 or block 425, a log-file can be created for subsequent usage. For example, logs of refused requests can be generated at block 420 and sent to device 54, or other locations, to indicate that unauthorized requests have been made. In the event that unauthorized application 240 is mal-ware, a virus, or spyware, then the reports generated as part of block 420 can be used to trigger or suggest the removal of application 240 from device 54. It should be understood, however, that in many circumstances unauthorized application 240 would not likely send the request received at block 405 and would in fact simply attempt to send the location data of device 54 directly to unauthorized server 114. However, as will become apparent from the discussion below, regardless of whether unauthorized application 240 invokes method 400, the attempt to send location data from device 54 to unauthorized server 114 can be blocked using the teachings herein. Indeed, as another example of potential uses for log files, logs of accepted requests generated at block 425 can be used by inspection point server 102.
Referring now to
Block 505 comprises receiving a request to deliver location data. In system 50, the request to deliver location data is received by inspection point server 102. The request itself can be generated by authorized application 236 or unauthorized location application 240 executing on device 54, introduced earlier in reference to
As discussed above, in specific configurations both applications 236 and 240 include the functionality of obtaining location data corresponding to the location of device 54 via locating unit 232 and placing that location data in volatile storage 224 for usage by processor 220. Likewise, both applications 236 and 240 also include the functionality of sending that location data over link 70 via network interface 216. Recall again that, authorized application 236 is configured to attempt to deliver the location data to authorized server 110 or unauthorized server 114, while unauthorized application 240 is configured to attempt to deliver the location data to unauthorized server 114.
Block 510 comprises receiving authorized request record and/or retrieving security management data. Block 510 is implemented by inspection point server 102 querying profile server 78 to obtain security management data and/or to ascertain whether a previous performance of method 500 resulted in an authorization to provide location information. Block 510 can be effected by accessing a log generated by block 420 or block 425 of method 400, for examination as to whether previous location requests were authorized. Those skilled in the art will recognize that a number of protocols and interfaces can be used to query the profile server 78 including RADIUS, DIAMETER, SIP as well as API based on CORBA or SOAP/XML.
Block 515 comprises determining if the request at block 505 is acceptable. Block 515 can be implemented by inspection point server 102 utilizing programming logic to compare the contents of the request from block 505 with the contents of the log and/or other security management data obtained at block 510. In one embodiment, if the request at block 505 was generated by unauthorized location application 240, whereby location data is requested to be delivered to unauthorized server 114, then the determination at block 415 will be “no”, delivery is not authorized, as there will have been no authorizations for such delivery generated during previous performances of block 425. As a result, at block 520, the delivery of the location data will be dropped. In another embodiment, the security management data retrieved by querying profile server 78 indicates that that the location request at block 505 is associated with an unauthorized server 114. As a result, at block 520, the delivery of the location data will be dropped. In a given embodiment, a notification (not shown) may be communicated to the device, subscriber, or authorized agent describing details pertaining to the unauthorized access attempt (for example, the address and service information associated with the unauthorized server). The notification may be sent via a variety of well known messaging systems including but not limited to Short Message Service (SMS), Multi-Media Message Service (MMS), or e-mail.
If, however, the request at block 505 was generated by authorized application 236, (for example, if a previous performance of block 425 indicated that such a location request is authorized or if the security management data retrieved by querying profile server 78 indicates that the location request at block 505 is associated with an authorized server110), then the determination at block 515 will be “yes”, the request at block 505 is acceptable. Method 500 will then advance to block 525 at which point the location data received at block 505 will be forwarded to authorized server 110.
It should now be understood that authorized application 236, working in conjunction with authorized server 114, can be directed to a wide variety of applications. For example, in the location context, assume that authorized server 114 hosts an airline reservation system that is accessible to a web-browser executing on device 54. In this example, location application 236 can be configured to send location data about subscriber S or device 54 so that the airline reservation system can default to propose flight departure information relative to the location of subscriber S or device 54. As another example, assume that authorized server 114 hosts a weather information service that is accessible to a web-browser executing on device 54, then application 236 can be configured to send location data about subscriber S or device 54 so that the weather information service can default to provide weather information relative to the location of subscriber S or device 54. Many other types of applications that can be hosted by authorized server 114 will now occur to those skilled in the art, and indeed future applications will no doubt be conceived, However, since the location data of device 54 (or other types of data as discussed above) can be used for malicious purposes, or purposes that are unauthorized or beyond the privacy preferences of the operator of device 54, then the teachings herein can be used so that authorized location requests are permitted while unauthorized location requests are blocked.
While the foregoing discusses certain embodiments, it is to be understood that such embodiments are by way of example only, and that variations, combinations, and subsets thereof are contemplated.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/CA2008/001197 | 6/26/2008 | WO | 00 | 9/1/2011 |
