Verification of mobile device integrity during activation

A mobile communication device. The mobile communication device comprises a verification application, when executed by a trusted security zone portion of the processor, examines an integrity of a preloaded open mobile alliance (OMA) device management (DM) payload, wherein a security key in the OMA DM payload is compared with a security key stored in the trusted security zone to determine the integrity of the OMA DM payload and to determine the state of a preloaded first operating system from a first network. The verification application further verifies the identification of the mobile communication device, transmits information comprising the security key in the trusted security zone to a server to verify network provisioning of the mobile communication device, and changes the toggle key based on the verification results, whereby asset migration between network carriers is achieved and unauthorized activities are avoided while security keys are kept confidential to individual carriers.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

Mobile telephones are electronic devices that are used for mobile voice and/or data communications based on wireless network connectivity, which can be provided by base stations known as cell towers or sites. Such electronic devices may be associated with an electronic serial number (ESN), a stock keeping unit (SKU) number, and other identifying information. Mobile telephones and similar electronic/communications devices may be packaged with operating manuals, warning documents, charging devices, and other accessories in a point-of-sale package suitable for distributing to end users. A plurality of point-of-sale packages, each containing an electronic device, may be shipped together to a retail store or business location. Electronic devices may be configured prior to shipping with unique packaging, hardware and software branding, features and functionality.

SUMMARY

In an embodiment, a mobile communication device is disclosed. The mobile communication device comprises a processor and a memory. The memory comprises a permissive portion, comprising an open mobile alliance (OMA) device management (DM) client application to provision the mobile communication device based on a state of a toggle key. The memory further comprises a trusted security zone portion, comprising the toggle key, wherein the toggle key controls whether or not the profile of the device is allowed to be provisioned into the device, wherein configurations of a network or an operating system associated with the network are provisioned during the profile provisioning. The trusted security zone portion further comprises a verification application, when executed by a trusted security zone portion of the processor examines an integrity of a preloaded open mobile alliance (OMA) device management (DM) payload, wherein a security key in the OMA DM payload is compared with a security key stored in the trusted security zone to determine the integrity of the OMA DM payload and to determine the state of a preloaded first operating system from a first network. The verification application further verifies the identification of the mobile communication device, transmits information comprising the security key in the trusted security zone to a server to verify network provisioning of the mobile communication device, and changes the toggle key based on the verification results, whereby asset migration between network carriers is achieved and unauthorized activities are avoided while security keys are kept confidential to individual carriers.

In an embodiment, a method of provisioning a mobile communication device during initial activation is disclosed. The method comprises verifying the identification of the mobile communication device by the mobile communication device, and transmitting information comprising a security key copied from a trusted security zone of a memory of the mobile communication device and an equipment serial number to a server with a server trusted security zone to verify network provisioning and identification of the mobile communication device. The method further comprises when the mobile communication device is determined by the server to be free from unauthorized provisioning, provisioning the mobile communication device by an OMA DM client application on the mobile communication device. The method further comprises when the mobile communication device is determined by the server to have been provisioned by an unauthorized source, preventing the mobile communication device from being activated, whereby unauthorized devices are prevented from utilizing a network.

In an embodiment, a method of provisioning a mobile communication device triggered by initial activation with a mobile device activation server with a server trusted security zone is disclosed. The method comprises verifying the identification of the mobile communication device by the mobile communication device, and transmitting information comprising a security key stored in a trusted security zone of a memory of the mobile communication device and an equipment serial number to the mobile device activation server. The method further comprises forwarding, by the mobile device activation server, the security key and the equipment serial number to a server at a communications service provider to verify network provisioning and identification of the mobile communication device respectively. The method further comprises when the mobile communication device is determined to be eligible for provisioning by the mobile device activation server, transmitting, by the mobile device activation server, provisioning information to the mobile communication device. The method further comprises when the mobile communication device is determined to be ineligible for provisioning by the mobile device activation server, provisioning, by the mobile device activation server, limited network access to the mobile communication device compared to network access privilege provisioned to mobile communication devices that are eligible for provisioning by the mobile device activation server, whereby secure and efficient access to a network of the mobile device activation server is promoted.

DETAILED DESCRIPTION

Problems may be caused by mobile communication devices that obtain privileged control—for example to deceive a network. The problems may result from mobile communication devices that are rooted. Rooting may be performed with the goal of overcoming limitations that network carriers or hardware manufacturers set on the mobile communication devices. For example, rooting may be done to unlock a phone (e.g., change restrictions on the phone to enable it to activate on a network operated by a different wireless service provider than the service provider who subsidized the user's phone purchase). The result of rooting may be the ability to alter or replace system applications and settings, run specialized applications that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal user of the mobile communication device. Rooting may also facilitate removal and replacement of the device's operating system. Additionally, rooting may enable a mobile communication device to deceive a network that the mobile communication device is not supposed to be supported by. For example, if a mobile communication device was obtained from a first network with a subsidy and is later rooted and activated on a second network, the user of the mobile communication device may stop paying service fees to the first network when the mobile communication device is not receiving services from the first network carrier. A mobile communication device may be considered “stolen” from the first network carrier when the mobile communication device whose purchase was subsidized moves to other networks for service before completion of a contract period. The mobile communication device may deceive to “steal” services from the second network carrier while the mobile communication device is not supposed to be supported by the second network carrier.

The present disclosure teaches a system and method for verifying a mobile communication device before initially provisioning the device. For example, a verification application on a mobile communication device may perform a device verification process on the mobile communication device comprising a variety of functions to verify whether or not the mobile communication device is free from unauthorized manipulation, for example unauthorized provisioning. The device verification may comprise verifying integrity of a preloaded open mobile alliance (OMA) device management (DM) payload, verifying the identity of the mobile device, verifying network provisioning on the mobile device with a server from a wireless communications service provider, or another type of device verification functionality. Under different circumstances, the verification application may perform different functions, for example during initial activation of the mobile communication device, when the mobile communication device migrating from one network to another network, or under some other circumstance.

At the time of initial activation, the verification application may examine the identification of the mobile device to verify the mobile device is what the mobile device indicates to the network that it is, for example by examining an equipment identifier or an equipment identification number of the mobile communication device (e.g., an international mobile station equipment identity or IMEI) with predefined rules. The verification application may examine a preloaded OMA DM payload on the mobile device, if any, with predefined method(s). For example, the size of an OMA DM payload may be calculated and compared to a size value included in the OMA DM payload. When the two sizes match, the OMA DM payload may be determined by the verification application to be free from unauthorized manipulation; otherwise, the OMA DM payload may be determined to have been manipulated by unauthorized source(s) or otherwise unauthorized (e.g., possibly the payload has been garbled in transit). A cyclic redundancy check (CRC) calculation may be performed by the verification application over an OMA DM payload and then compared to an authoritative CRC value. When the CRC value calculated from the OMA DM payload matches the authoritative CRC value, the OMA DM payload may be determined by the verification application to be free from unauthorized manipulation; otherwise, the OMA DM payload may be determined to have been manipulated by unauthorized source(s) or may otherwise be deemed unauthorized. The format of the OMA DM payload may be compared by the verification application to a predefined payload format. When both formats match, the OMA DM payload may be determined to be free from unauthorized manipulation; otherwise, the OMA DM payload may be determined to have been manipulated by unauthorized source(s) or may otherwise be deemed unauthorized.

Additionally, the verification application may transmit a security key stored in a trusted security zone portion of a memory on the mobile communication device, an equipment identification number, or other relevant information to a server for verification. The server may be installed with a server trusted security zone. The mobile device may perform its initial activation with a server from a wireless communications service provider or with a mobile device activation server, for example a third party server not maintained by a wireless communications service provider. A wireless communications service provider may be referred to as a network carrier herein. The server maintained by the network carrier may verify the identification of the mobile communication device and whether or not the mobile communication device is free from unauthorized provisioning. For example, the server may identify the type of the mobile communication device and/or what network the mobile communication device may be on by examining the security key. The server may determine which specific device the mobile communication device is by examining the equipment identification number.

The third party server may be from an organization, for example an enterprise, which is not a wireless communications service provider. The third party server may forward the received security key, the equipment identification number, or other relevant information to a server maintained by a network carrier that supports the mobile communication device or to a server from a common platform. The server may verify the identification of the mobile communication device and whether or not the mobile communication device is free from unauthorized provisioning. For example, the server may identify the type of the mobile communication device and/or what network the mobile communication device may be on by examining the security key. The server may determine which specific device the mobile communication device is by examining the equipment identification number.

A notification comprising a verification result may be transmitted to the mobile communication device when the server that verifies the mobile communication device completes the part of verification on the server side. A toggle key may be stored in the trusted security zone of the mobile communication device and utilized to enable or disable functionality to provision the profile of the mobile communication device. The profile provisioning of the mobile device may comprise provisioning the operating system and/or a supporting network. The toggle key may be set to a default value to indicate that the profile of the mobile device may not be provisioned at the manufacturer. The toggle key may be configured by the verification application under predefined circumstances, for example at initial activation of the mobile device, at migration from one network to another network, or under some other circumstance, after completion of device verification. For example, when the mobile communication device is determined to be free from unauthorized provisioning and/or manipulation by the verification application, the toggle key may be set to a first value that enables the profile provisioning to the mobile communication device; otherwise, the verification application may set a second value to the toggle key to disable profile provisioning to the mobile communication device. When the mobile communication device is determined to be free from unauthorized provisioning and the toggle key allows profile provisioning to the mobile communication device, provisioning content may be transmitted to the mobile communication device, and an OMA DM client application on the mobile communication device may provision the mobile device with the received provisioning content.

When a mobile communication device is migrating from one network to another network, for example from a first network to a second network, from a cellular network to a wireless local area network (WLAN), or another type of migration between networks, the mobile communication device may also be verified before provisioning, for example by a server from the second network carrier. The verification process and provisioning process are similar to the process at initial activation for the mobile communication device. When a mobile communication device is determined to be free from unauthorized provisioning, the mobile communication device may be provisioned by an OMA DM client application with provisioning content received from the server. A second security key may be deposited into a trusted security zone of the memory on the mobile communication device to correspond to the second network and/or a corresponding second operating system. The trusted security zone may be described hereinafter.

Turning now toFIG. 1, a communication system100is described. In an embodiment, the communication system100comprises a plurality of mobile communication devices126and a server102. The mobile device126may comprise a processor108, an operating system124, and a memory122. The memory may comprise a trusted security zone portion110and a permissive sector120. The trusted security zone110may comprise a toggle key112, a plurality of security keys114, and a verification application116. The permissive sector120may comprise an open mobile alliance (OMA) device management (DM) client application118and/or an OMA DM payload130. The mobile device126may be configured to use a radio transceiver to establish a wireless communication link with a base transceiver station (BTS)128, and the base transceiver station128may provide communications connectivity of the device126to a network106. The server102may be a server maintained by a wireless communications service provider and may also have access to the network106. The network106may comprise any combination of private and public networks. A wireless communications service provider may also be referred to as a network carrier herein.

It is understood that the system100may comprise any number of mobile devices126, any number of base transceiver stations128, and any number of servers102. The collectivity of base transceiver stations128may be said to comprise a radio access network, in that these base transceiver stations128may provide a radio communication link to the mobile devices126to provide access to the network106.

The radio transceiver of the mobile communication device126may communicate with the base transceiver station128using any of a variety of wireless communication protocols including a code division multiple access (CDMA) wireless communication protocol, a global system for mobile communication (GSM) wireless communication protocol, a long-term evolution (LTE) wireless communication protocol, a world-wide interoperability for microwave access (WiMAX) wireless communication protocol, or another wireless communication protocol. The mobile device126may be any of a mobile phone, a personal digital assistant (PDA), a media player, a laptop computer, a tablet computer, a notebook computer, or another network/communications capable device. In an embodiment, the mobile communication device126may have other components (not shown) such as a near field communication (NFC) radio transceiver, a short range radio transceiver such as a wireless local area network (WLAN) radio transceiver, or other components.

The toggle key112may be stored in the trusted security zone110. The toggle key112may be utilized to enable or disable functionality to provision the profile of the mobile device126. Provisioning a mobile communication device126may be a process where a mobile communication device126that is not provisioned for a user account currently associated with an active subscription with a service provider (e.g. a wireless communications service provider) is updated with data, parameters, and/or software applications, typically for the first time, associating the mobile communication device126with a user account and supplying service to the mobile communication device126. The toggle key112may be set to a default value to indicate that the profile of the mobile device126may not be provisioned at the manufacturer. The toggle key112may be configured by the verification application116under predefined circumstances, for example at initial activation of the mobile device126, at migration from one network to another network, or under another circumstance.

The profile provisioning of the mobile device126may comprise provisioning the operating system124and/or a supporting network. A value of 1 of the toggle key112may disable profile provisioning the mobile device126and a value of 0 of the toggle key112may enable the provisioning the profile of the mobile device126. For example, when the toggle key112is set to be 1, the operating system124and/or the supporting network of the mobile device126may not be set or changed. For example, the OMA DM client application118may examine the value of the toggle key112before provisioning the mobile communication device126, and the operating system124and/or the supporting network may not be set or changed by the OMA DM client application118when the toggle key112is set to 1. When the toggle key112is set to be 0, the operating system124and/or the supporting network of the mobile device126may be set or changed.

The toggle key112may be configured by the verification application116, for example after completion of device verification. The device verification may comprise verifying integrity of a preloaded OMA DM payload130, verifying the identity of the mobile device126, and/or verifying network provisioning on the mobile device126with the server102. The toggle key112may be examined by the OMA DM client application118before the OMA DM client application118provisions the mobile device126. When the toggle key112allows the profile of the mobile device126to be provisioned, the OMA DM client application118may provision the mobile device126with an operating system or portions of an operating system and/or a supporting network.

The security key114may be stored in the trusted security zone110. A plurality of the security keys114, for example 8, 16, 24, or another number of security keys114, may be stored in the trusted security zone110. Each of the security key114may correspond to an instance of profile provisioning items, for example an operating system124or a network carrier. Security keys114may be known to different carriers who use them to access and interact with carrier dedicated sub-trusted-security-zones. Thus, security keys may be kept confidential to individual carriers. The security keys114may be compared by the verification application116against a security key114from the OMA DM payload130, for example to determine whether the OMA DM payload130is free from unauthorized provisioning. When any of the security keys114matches up with the security key from the OMA DM payload130, the OMA DM payload130may be determined to be free from unauthorized provisioning.

The server trusted security zone104may be stored in a memory of the server102. The server trusted security zone104may communicate with the trusted security zone110on the mobile device126. For example, the trusted security zone110may transmit network provisioning information and/or other information to the server trusted security zone104. The server trusted security zone104or a trusted application in the server trusted security zone104may examine the network provisioning information and/or other information from the mobile device126to determine whether the network provisioning of the mobile device126is free from unauthorized sources. For example, the server trusted security zone104may identify the type of the mobile device126and/or what network the mobile device126may be on by examining the security key114. The server trusted security zone104may determine which specific device the mobile device126is by examining the equipment identification number. When the mobile device126is determined to be free from unauthorized network provisioning, the server trusted security zone104may transmit a notification to the server trusted security zone110indicating that the mobile device is free from unauthorized network provisioning.

The OMA DM client application118may be stored in the permissive sector120of the memory122on the mobile device126. The OMA DM client application118may provision the mobile device126under predefined circumstances, for example, at the time of a hands-free activation (HFA) device profile reset, at the time of a complete device factory reset, at the time of a new network device start-up, at the time of an OMA DM profile change, or under another circumstance. The provisioning may comprise profile provisioning and non-profile provisioning. With profile provisioning, an operating system, a network, or both may be provisioned to the mobile device126. The profile may comprise information that promotes conducting wireless communications, for example a network access identity. The network access identity may be used to authorize access of the mobile communication device126to the wireless link provided by the base transceiver station128and/or to the network106.

The profile may further comprise information that may be used to generate operational run-time parameters for wireless communication. The information may comprise one or more lists of wireless communication networks that the mobile communication device126is authorized to attach to, a rule set for prioritizing among the networks identified in the one or more lists, and one or more tables of device rules. For example, the lists of wireless communication networks may comprise one or more of a PRL, a PLMN list, an OPLMN list, an EHPLMN list, an HPLMN list, an MSPL table, and an MLPL table.

PRL stands for a preferred roaming list. PLMN stands for public land mobile network. The PLMN list may comprise a list of public land mobile networks and/or other lists, such as an EHPLMN list or an OPLMN list. OPLMN stands for operator controlled PLMN. EHPLMN stands for an equivalent home PLMN. The HPLMN list is a home PLMN file that may comprise a list of networks or communication systems identified by mobile country code (MCC). MSPL stands for MMSS (multi-mode system selection) System Priority List. MLPL stands for MMSS Location Associated Priority List.

These lists and/or tables may be said to implement, define, and/or describe a coverage map. In an embodiment, before the mobile device126can be provisioned, the mobile device126may be examined to determine whether the mobile device126is free from unauthorized or malicious manipulation, for example whether or not the mobile device126has been rooted.

Rooting may be done to unlock a phone (e.g., change restrictions on phone to enable it to activate on a network operated by a different wireless service provider than the service provider who subsidized the user's phone purchase). The result of rooting may be the ability to alter or replace system applications and settings, run specialized applications that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal user of the mobile communication device126. Rooting may also facilitate removal and replacement of the device's operating system. Additionally, rooting may enable a mobile communication device126to deceive a network that the mobile communication device126is not supposed to be supported by.

The OMA DM client application118may communicate with the verification application116to obtain an examination/verification result for the mobile device126. For example, before provisioning the mobile device126, the OMA DM client application118may send an inquiry to the verification application116requesting the device verification result. Alternatively, the verification application116may send a notification to the OMA DM client application118indicating the device verification result when the device verification process is complete.

The OMA DM client application118may also examine the value of the toggle key112before provisioning the mobile communication device126. For example, a function of the verification application116may be invoked by the OMA DM client application118, and the verification application116may access the toggle key112. Or, the verification application116may comprise an application programming interface (API) that resides in the permissive sector120. The OMA DM client application118may invoke functions of the application programming interface, and the application programming interface may communicate with the verification application116. The verification application116may access the toggle key112to examine its value. Alternatively, a portion of the OMA DM client application118may be stored in and/or executed in the trusted security zone110. For example, a verification component or functionality of the OMA DM client application118may access the toggle key112.

When the value of the toggle key112allows the mobile communication device126to be provisioned by the OMA DM client application118and when the mobile device126is determined to be free from unauthorized or malicious manipulation, the OMA DM client application118may provision the mobile device126. As discussed earlier, the provisioning may comprise profile provisioning and non-profile provisioning. The non-profile provisioning may comprise service provisioning, or another type of provisioning. With the network provisioning, the mobile device126may be provisioned with network related settings, for example a category of network, a quality of network, or another type of network related settings.

When the mobile device126is provisioned with network provisioning, the mobile device126may have the capability to communicate with the network106. The service provisioning may comprise service settings, application installation, or another type of service provisioning. When provisioned with service provisioning, the mobile device126may have more functionality than only communicating with the network106. For example, service provisioning may enable games, media playing, or another type of functionality other than network ability. When the mobile device126is determined to have been manipulated by unauthorized source(s) (e.g., rooted), the OMA DM client application118may not provision the mobile device126. When the mobile device126is not provisioned by the OMA DM client application118, the mobile device126may not have the capability to communicate to the network106, or to another mobile device through the network106.

The verification application116may be stored in the trusted security zone110. When executed by a trusted security portion of the processor108, the verification application116may perform a variety of processes to examine whether or not the mobile device126is free from unauthorized manipulation. For example, the verification application116may perform a verification process for the mobile device126. The verification application116may communicate with the OMA DM client application118on the mobile device126and/or the server trusted security zone104on the server102during the verification process for the mobile device126.

The verification application116may monitor triggering events that may trigger the OMA DM client application118to provision the mobile device126. Alternatively, the OMA DM client application118may transmit a notification to the verification application116when a triggering event occurs. When a triggering event occurs, the verification application116may start the verification process to determine whether or not the mobile device126is free from unauthorized manipulation. For example, the verification application116may verify identification of mobile device126with predefined rules. The mobile device126may comprise an equipment identification number, for example an equipment serial number, an international mobile equipment identity (IMEI), or another type of identification number.

The verification application116may examine the integrity of a preloaded OMA DM payload130. For example, when one security key114is stored in the trusted security zone110, the verification application116may compare the security key114stored in the trusted security zone110with a security key stored in the OMA DM payload130. When the two security keys match, the OMA DM payload130may be determined to be free from unauthorized manipulation, for example unauthorized provisioning. When more than one security key114is stored in the trusted security zone110, the verification application116may compare the security key stored in the OMA DM payload130with the plurality of security keys116stored in the trusted security zone110. If any of the security keys114from the trusted security zone110matches the security key from the OMA DM payload130, the OMA DM payload130may be determined to be free from unauthorized manipulation.

The verification application116may communicate with the server trusted security zone104to examine whether or not the mobile device126is free from unauthorized provisioning. For example, the verification application116may transmit network provisioning information, a security key114stored in the trusted security zone110, an equipment identification number, and/or other information to the server trusted security zone104. The equipment identification number may be an equipment serial number, an international mobile equipment identity (IMEI), or another type of identification number.

In an embodiment, the server trusted security zone104may determine whether or not the mobile device126is free from unauthorized network provisioning with the network provisioning information, the security key114stored in the trusted security zone110, the equipment identification number, and/or the other information transmitted from the verification application116. For example, the server102may identify the type of the mobile device126and/or what network the mobile device126may be on by examining the security key114. The server102may determine which specific device the mobile device126is by examining the equipment identification number.

The verification process that the verification application116performs may comprise a root detection process. The root detection process may examine default files, configurations, or other relevant elements on the mobile device126. For example, it may be examined whether or not relevant over-the-air (OTA) certificates are present on the mobile device126. When any of the relevant over-the-air certificates are not found, the mobile device126may be determined to have been provisioned by unauthorized source(s). The configurations that the root detection process may examine may include permission settings.

When any of the above steps of the verification process fails, the mobile device126may be determined to have been provisioned by unauthorized source(s), and the mobile device126may not be provisioned to use the network106. Alternatively, the mobile device126may be provided with limited access to the network106and/or may be offered with an option to register to the network106for further action.

The verification application116may change the toggle key112value based on verification results. For example, if the mobile device126is determined to be free from unauthorized provisioning, the verification application116may set the toggle key112value to indicate that the profile of the mobile device126may be provisioned by the OMA DM client application118. On the other hand, if the mobile device126is determined to have been provisioned by and/or tampered with by unauthorized source(s), the verification application116may set the toggle key112value to indicate that the profile of the mobile device126may not be provisioned by the OMA DM client application118. When the profile of the mobile device126is not provisioned, the mobile device126may have limited access to the network106, for example to make emergency calls, customer care calls, or another type of service. Before provisioning the mobile device126, the OMA DM client application118may examine the toggle key112to determine whether or not the profile of the mobile device126may be provisioned.

The verification application116may communicate with the OMA DM client application118to learn and/or determine whether or not the mobile device126is free from unauthorized manipulation. For example, the verification application116may transmit a notification to the OMA DM client application118when the mobile device126is determined to be free from unauthorized provisioning. The OMA DM client application118may provision the mobile device126when the mobile device126is determined to be free from unauthorized provisioning. The verification application116may also transmit a notification to the OMA DM client application118when the mobile device126is determined to have been provisioned by unauthorized source(s). The OMA DM client application118may not provision the mobile device126when the mobile device126is determined to have been provisioned by unauthorized source(s).

Under various predefined circumstances, the verification application116may perform different functions, for example, at initial activation with a wireless communications service provider that provides cellular communications service to the mobile device126, at initial activation with a third party server other than a wireless communications service provider that provides cellular communications service to the mobile device126, at migration from one network to another network, or under another predefined circumstance. The case of initial activation with a wireless communications service provider that provides cellular communications service to the mobile device126may be discussed below with reference toFIG. 2. The case of initial activation with a third party server other than a wireless communications service provider that provides cellular communications service to the mobile device126may be discussed below with reference toFIG. 3. The case of the mobile device126migrating from one network to another network may be discussed in the following section.

When the verification application116is executed at migration of the mobile device126from a first network to a second network, for example from a first network carrier to a second network carrier, or from a cellular network to a wireless local area network (WLAN) such as a WiFi network, the verification application116may perform a verification process comprising a variety of functions. For example, the verification application116may examine a preloaded OMA DM payload130to verify the integrity of the OMA DM payload130. For example, the size of an OMA DM payload130may be calculated and compared to a size value included in the OMA DM payload130. When the two sizes match, the OMA DM payload130may be determined by the verification application116to be free from unauthorized manipulation; otherwise, the OMA DM payload130may be determined to have been manipulated by unauthorized source(s). A cyclic redundancy check (CRC) calculation may be performed by the verification application116over an OMA DM payload130and then compared to an authoritative CRC value. When the CRC value calculated from the OMA DM payload130matches the authoritative CRC value, the OMA DM payload130may be determined by the verification application116to be free from unauthorized manipulation; otherwise, the OMA DM payload130may be determined to have been manipulated by unauthorized source(s). The format of the OMA DM payload130may be compared by the verification application116to a predefined payload format. When both formats match, the OMA DM payload130may be determined to be free from unauthorized manipulation; otherwise, the OMA DM payload130may be determined to have been manipulated by unauthorized source(s).

The mobile device126may be loaded with a first network and/or a corresponding first operating system. The verification application116may examine the state of the first operating system to determine whether or not the mobile device126is intact. The verification application116may determine the identification of the mobile device126. Additionally, the verification application116may transmit a first security key114stored in the trusted security zone110, an equipment identification number, and/or other relevant information to the server102. The server102may determine whether the mobile device126is intact based on the received relevant information from the verification application116and transmit a notification comprising verification results to the mobile device126.

When the mobile device126passes the verification process, the mobile device126may be provisioned by the server102. A second network and/or a corresponding second operating system may be provisioned to the mobile device126as part of the provisioning process. A second security key may be transmitted by the server trusted security zone104and stored into the trusted security zone110of the mobile device126to correspond to the second network and/or the corresponding second operating system. The second security key may be deposited in a different slot than the first security key114. Thus, asset migration between network carriers may be achieved and unauthorized activities may be avoided while security keys114may be kept confidential to individual carriers. When a user of a mobile communication device126decides to terminate service with the network and the security key114is matched at the network, the mobile communication device126may be removed from a network access permission list.

A total of a predefined number, for example 8, 16, 24, or another number of security keys114may be deposited in the trusted security zone110, to correspond to a plurality of distinct operating systems, a plurality of distinct networks, or any combination of the two. Each of the security keys may be associated with a different sub-section or sub-partition of the trusted security zone. For further details about multiple trusted security zones within a trusted security zone, see U.S. patent application Ser. No. 13/571,348, filed on Aug. 10, 2012, entitled “Systems and Methods for Provisioning and Using Multiple Trusted Security Zones on an Electronic Device”, by Stephen J. Bye, et al., which is incorporated by reference in its entirety.

Turning now toFIG. 2, a method200is described. At block202, the identification of the mobile communication device is verified by the mobile communication device. The identification of the mobile communication device126may be verified by the mobile communication device126, for example by examining an equipment identifier or an equipment identification number of the mobile communication device (e.g., an international mobile station equipment identity or IMEI) with predefined rules. At block204, information is transmitted comprising a security key copied from a trusted security zone of a memory of the mobile communication device and an equipment serial number of the mobile communication device to a server with a server trusted security zone to verify network provisioning and identification of the mobile communication device respectively. For example, information may be transmitted comprising a security key114copied from the trusted security zone110of the memory122of the mobile communication device126and/or an equipment serial number to the server102with the server trusted security zone104to verify network provisioning and identification of the mobile communication device126respectively.

Only one security key114may be found in the trusted security zone110at initial activation of the mobile device126. In an embodiment, an application stored in the server trusted security zone104may be executed by a trusted security zone portion of a processor of the server102. The application may compare the security key114from the mobile device126with security key(s) stored in a data store of the server102. The application may compare the equipment serial number from the mobile device126with equipment serial numbers stored in the data store. The type of the mobile device126and/or what network the mobile device126should be on, for example the network that subsidized the mobile device126, may be determined by the server102through examining the security key114. Which specific device the mobile device126is may be determined by the server102through examining the equipment serial number.

At block206, it is determined whether or not the mobile device is free from unauthorized provisioning. When the result of block206is true, which means the mobile device126is free from unauthorized provisioning, the method200proceeds to block208. On the other hand, when the result of block206is false, which means the mobile device126has been rooted, provisioned from unauthorized source(s), or both, the method200proceeds to block210. At block208, the mobile communication device is provisioned by an OMA DM client application on the mobile communication device. For example, the mobile device126may be provisioned by the OMA DM client application118. The OMA DM payload to provision the mobile device126may be transmitted from the server102, for example by the OMA DM server application132.

When the network for the mobile device126is determined by the server102, the profile provisioning content may be determined, for example network provisioning content and/or a corresponding operating system provisioning content. Information of a variety of user groups may be stored on the server102. For example, an executive group, a technology group, and a worker group may be different user groups for an enterprise. Mobile communication devices126associated with distinct groups may be assigned with distinct provisioning content, for example distinct application installation, distinct access right, or other settings. The user group of the mobile device126may be determined by examining the user group information stored in the memory122, the security key114, and/or the equipment identification number of the mobile device126. When the provisioning settings are determined by the server102, the OMA DM server application132on the server102may transmit an OMA DM payload to the mobile device126comprising the provisioning settings. Upon receipt of the OMA DM payload130, the OMA DM client application118may provision the mobile device126with information from the OMA DM payload138.

At block210, the mobile communication device is prevented from being activated. For example, when the mobile communication device126is determined to have been provisioned by unauthorized source(s), the mobile communication device126may be prevented from being activated. For example, the activation process on the mobile communication device126may be disabled. In an embodiment, the mobile communication device126may still be able to make emergency calls and customer care calls even when the mobile communication device126is not activated. At block212, unauthorized devices are prevented from utilizing a network. For example, unauthorized mobile communication devices126may not be activated and thus may be prevented from utilizing the network106.

Turning now toFIG. 3, a method300is described. At block302, the identification of the mobile communication device126is verified by the mobile communication device. At block304, information is transmitted comprising a security key stored in a trusted security zone of a memory of the mobile communication device and an equipment serial number to the mobile device activation server. For example, when the verification application116is executed at the time of initial activation of the mobile device126to communicate with a mobile device activation server, for example a third party server other than the server102maintained by the wireless communications service provider, the verification application116may perform a variety of functions similar to functions performed by the verification application116when the initial activation is performed with the server102from the wireless communications service provider.

The mobile communication device126may be supported by a cellular network maintained by the wireless communications service provider. The mobile device activation server may not be a server from the wireless communications service provider and instead may be a server from an organization, for example an enterprise. The verification application116may transmit a security key114stored in the trusted security zone110, an equipment identification number, and/or other information to a mobile device activation server. The mobile device activation server may be installed with a server trusted security zone.

At block306, the security key and the equipment serial number are forwarded by the mobile device activation server to a server at a communications service provider to verify network provisioning and identification of the mobile communication device respectively. For example, the mobile device activation server may communicate with the server102to determine whether or not the mobile device126is intact. For example, the mobile device activation server may forward the received security key114, the equipment identification number, and/or the other information received from the mobile device126to the sever102.

At block308, it is determined whether or not the mobile communication device is eligible for provisioning by the mobile device activation server. For example, the server102may determine whether or not the mobile device126is intact and transmit a notification comprising the verification result to the mobile device activation server. When the mobile device126is determined by the server102to be free from unauthorized provisioning, the mobile device activation server may further determine whether or not the mobile device126is eligible for the mobile device activation server to provision. When the result of block308is true, which means the mobile device126is eligible to be provisioned by the mobile device activation server, the method proceeds to block310. On the other hand, when the result of block308is false, which means the mobile device126is ineligible to be provisioned by the mobile device activation server, the method proceeds to block312.

At block310, provisioning information is transmitted by the mobile device activation server to the mobile communication device. When the mobile device126is determined to be eligible to be provisioned by the mobile device activation server, the mobile device activation server may determine provisioning content and transmit the provisioning content to the mobile device126, for example through the OMA DM client application118, and request the OMA DM client application118to provision the mobile device126. Alternatively, the server102may transmit the provisioning content to the mobile device126through the OMA DM client application118and request the OMA DM client application118to provision the mobile device126.

Alternatively, a common platform may be utilized for this purpose. For example, a common platform with a platform trusted security zone may communicate with various communications network providers and third parties for device integrity verification and asset migration between communications network providers and third parties. For example, both the server102and the mobile device activation server may communicate with the platform to determine whether the mobile device126is intact. In an embodiment, a token may be used by a network carrier to communicate with the common platform. The token may be a common token for a plurality of network carriers that operate with the common platform or a distinct token for an individual network carrier. The platform may maintain a data store for security keys, equipment identification numbers, network provisioning information, and/or other information for various network carriers.

The mobile device activation server may forward the received security key114, the equipment identification number, and/or the other information received from the mobile device126to the platform. The common platform may determine whether the mobile device126is intact and transmit a notification comprising the verification result to the mobile device activation server. The common platform may determine provisioning content for the mobile device126and/or transmit the provisioning content to the mobile device126, for example from the OMA DM server application132to the OMA DM client application118, and request the OMA DM client application118to provision the mobile device126. Alternatively, the mobile device activation server may determine provisioning content for the mobile device126and/or transmit the provisioning content to the mobile device126, for example from an OMA DM server application on the mobile device activation server to the OMA DM client application118, and request the OMA DM client application118to provision the mobile device126.

With the mobile device activation server, a user group for the mobile device126may be determined. User group specific provisioning content may be transmitted to the mobile device126by the mobile device activation server, the server102, or the common platform.

At block312, limited network access is provided by the mobile device activation server to the mobile communication device126compared to network access privilege provisioned to mobile communication devices126that are eligible for provisioning by the mobile device activation server. At block314, secure and efficient access to a network of the mobile device activation server is promoted. For example, the network of the mobile device activation server may be a third party network. Secure and efficient access to the network of the mobile device activation server may be promoted by provisioning limited network access to mobile devices126that are ineligible for provisioning by the mobile device activation server.

FIG. 4depicts the mobile device400, which is operable for implementing aspects of the present disclosure, but the present disclosure should not be limited to these implementations. Though illustrated as a mobile phone, the mobile device400may take various forms including a wireless handset, a pager, a personal digital assistant (PDA), a gaming device, or a media player. The mobile device400includes a display402and a touch-sensitive surface and/or keys404for input by a user. The mobile device400may present options for the user to select, controls for the user to actuate, and/or cursors or other indicators for the user to direct. The mobile device400may further accept data entry from the user, including numbers to dial or various parameter values for configuring the operation of the handset. The mobile device400may further execute one or more software or firmware applications in response to user commands. These applications may configure the mobile device400to perform various customized functions in response to user interaction. Additionally, the mobile device400may be programmed and/or configured over-the-air, for example from a wireless base station, a wireless access point, or a peer mobile device400. The mobile device400may execute a web browser application which enables the display402to show a web page. The web page may be obtained via wireless communications with a base transceiver station, a wireless network access node, a peer mobile device400or any other wireless communication network or system.

FIG. 5shows a block diagram of the mobile device400. While a variety of known components of handsets are depicted, in an embodiment a subset of the listed components and/or additional components not listed may be included in the mobile device400. The mobile device400includes a digital signal processor (DSP)502and a memory504. As shown, the mobile device400may further include an antenna and front end unit506, a radio frequency (RF) transceiver508, a baseband processing unit510, a microphone512, an earpiece speaker514, a headset port516, an input/output interface518, a removable memory card520, a universal serial bus (USB) port522, an infrared port524, a vibrator526, a keypad528, a touch screen liquid crystal display (LCD) with a touch sensitive surface530, a touch screen/LCD controller532, a camera534, a camera controller536, and a global positioning system (GPS) receiver538. In an embodiment, the mobile device400may include another kind of display that does not provide a touch sensitive screen. In an embodiment, the DSP502may communicate directly with the memory504without passing through the input/output interface518. Additionally, in an embodiment, the mobile device400may comprise other peripheral devices that provide other functionality.

The keypad528couples to the DSP502via the input/output interface518to provide one mechanism for the user to make selections, enter information, and otherwise provide input to the mobile device400. Another input mechanism may be the touch screen LCD530, which may also display text and/or graphics to the user. The touch screen LCD controller532couples the DSP502to the touch screen LCD530. The GPS receiver538is coupled to the DSP502to decode global positioning system signals, thereby enabling the mobile device400to determine its position.

A trusted security zone provides chipsets with a hardware root of trust, a secure execution environment for applications, and secure access to peripherals. A hardware root of trust means the chipset should only execute programs intended by the device manufacturer or vendor and resists software and physical attacks, and therefore remains trusted to provide the intended level of security. The chipset architecture is designed to promote a programmable environment that allows the confidentiality and integrity of assets to be protected from specific attacks. Trusted security zone capabilities are becoming features in both wireless and fixed hardware architecture designs. Providing the trusted security zone in the main mobile device chipset and protecting the hardware root of trust removes the need for separate secure hardware to authenticate the device or user. To ensure the integrity of the applications requiring trusted data, such as a mobile financial services application, the trusted security zone also provides the secure execution environment where only trusted applications can operate, safe from attacks. Security is further promoted by restricting access of non-trusted applications to peripherals, such as data inputs and data outputs, while a trusted application is running in the secure execution environment. In an embodiment, the trusted security zone may be conceptualized as hardware assisted security.

A complete trusted execution environment (TEE) may be implemented through the use of the trusted security zone hardware and software architecture. The trusted execution environment is an execution environment that is parallel to the execution environment of the main mobile device operating system. The trusted execution environment and/or the trusted security zone may provide a base layer of functionality and/or utilities for use of applications that may execute in the trusted security zone. For example, in an embodiment, trust tokens may be generated by the base layer of functionality and/or utilities of the trusted execution environment and/or trusted security zone for use in trusted end-to-end communication links to document a continuity of trust of the communications. Through standardization of application programming interfaces (APIs), the trusted execution environment becomes a place to which scalable deployment of secure services can be targeted. A device which has a chipset that has a trusted execution environment on it may exist in a trusted services environment, where devices in the trusted services environment are trusted and protected against attacks. The trusted execution environment can be implemented on mobile phones and tablets as well as extending to other trusted devices such as personal computers, servers, sensors, medical devices, point-of-sale terminals, industrial automation, handheld terminals, automotive, etc.

The trusted security zone is implemented by partitioning all of the hardware and software resources of the mobile device into two partitions: a secure partition and a normal partition. The secure partition may be implemented by a first physical processor, and the normal partition may be implemented by a second physical processor. Alternatively, the secure partition may be implemented by a first virtual processor, and the normal partition may be implemented by a second virtual processor. Placing sensitive resources in the secure partition can protect against possible attacks on those resources. For example, resources such as trusted software applications may run in the secure partition and have access to hardware peripherals such as a touchscreen or a secure location in memory. Less secure peripherals such as wireless radios may be disabled completely while the secure partition is being accessed, while other peripherals may only be accessed from the secure partition. While the secure partition is being accessed through the trusted execution environment, the main mobile operating system in the normal partition is suspended, and applications in the normal partition are prevented from accessing the secure peripherals and data. This prevents corrupted applications or malware applications from breaking the trust of the device.

The trusted security zone is implemented by partitioning the hardware and software resources to exist in a secure subsystem which is not accessible to components outside the secure subsystem. The trusted security zone is built into the processor architecture at the time of manufacture through hardware logic present in the trusted security zone which enables a perimeter boundary between the secure partition and the normal partition. The trusted security zone may only be manipulated by those with the proper credential and, in an embodiment, may not be added to the chip after it is manufactured. Software architecture to support the secure partition may be provided through a dedicated secure kernel running trusted applications. Trusted applications are independent secure applications which can be accessed by normal applications through an application programming interface in the trusted execution environment on a chipset that utilizes the trusted security zone.

In an embodiment, the normal partition applications run on a first virtual processor, and the secure partition applications run on a second virtual processor. Both virtual processors may run on a single physical processor, executing in a time-sliced fashion, removing the need for a dedicated physical security processor. Time-sliced execution comprises switching contexts between the two virtual processors to share processor resources based on tightly controlled mechanisms such as secure software instructions or hardware exceptions. The context of the currently running virtual processor is saved, the context of the virtual processor being switched to is restored, and processing is restarted in the restored virtual processor. Time-sliced execution protects the trusted security zone by stopping the execution of the normal partition while the secure partition is executing.

The two virtual processors context switch via a processor mode called monitor mode when changing the currently running virtual processor. The mechanisms by which the processor can enter monitor mode from the normal partition are tightly controlled. The entry to monitor mode can be triggered by software executing a dedicated instruction, the Secure Monitor Call (SMC) instruction, or by a subset of the hardware exception mechanisms such as hardware interrupts, which can be configured to cause the processor to switch into monitor mode. The software that executes within monitor mode then saves the context of the running virtual processor and switches to the secure virtual processor.

The trusted security zone runs a separate operating system that is not accessible to the device users. For security purposes, the trusted security zone is not open to users for installing applications, which means users do not have access to install applications in the trusted security zone. This prevents corrupted applications or malware applications from executing powerful instructions reserved to the trusted security zone and thus preserves the trust of the device. The security of the system is achieved at least in part by partitioning the hardware and software resources of the mobile phone so they exist in one of two partitions, the secure partition for the security subsystem and the normal partition for everything else. Placing the trusted security zone in the secure partition and restricting access from the normal partition protects against software and basic hardware attacks. Hardware logic ensures that no secure partition resources can be accessed by the normal partition components or applications. A dedicated secure partition operating system runs in a virtual processor separate from the normal partition operating system that likewise executes in its own virtual processor. Users may install applications on the mobile device which may execute in the normal partition operating system described above. The trusted security zone runs a separate operating system for the secure partition that is installed by the mobile device manufacturer or vendor, and users are not able to install new applications in or alter the contents of the trusted security zone.