PATENT DOCUMENT

Publication Number: US-8798677-B2
Application Number: US-201313864990-A
Country: US
Kind Code: B2

Title: Service provider activation

Abstract:
Systems and methods for activating a mobile device for use with a service provider are described. In one exemplary method, a mobile device having a currently inserted SIM card may be prepared for activation using a signing process in which an activation server generates a signed activation ticket that uniquely corresponds to the combination of the device and SIM card, and that is securely stored on the mobile device. In another exemplary method the mobile device may be activated in an activation process in which the device verifies an activation ticket against information specific to the device and SIM card, and initiates activation when the verification of the activation ticket is successful.

Claims:
What is claimed is: 
     
       1. A non-transitory machine readable storage medium storing program instructions which when executed by a device cause the device to perform a method, the method comprising:
 issuing from a device having a currently inserted subscriber identification module (SIM) card, an activation request, the activation request comprising a first data that uniquely identifies the device and a second data that uniquely identifies the currently inserted SIM card; 
 storing in the device a signed activation record comprising the first data and the second data, the activation record having been generated and signed by an activation server responding to the activation request; 
 verifying the activation record against the currently inserted SIM card; and 
 initiating registration of the device with a communications network after successfully verifying the activation record. 
 
     
     
       2. The medium of  claim 1 , wherein the first data that uniquely identifies the device includes a serial number of the device. 
     
     
       3. The medium of  claim 2 , wherein the serial number of the device comprises an International Mobile Equipment Identifier (IMEI) encoded in the device. 
     
     
       4. The medium of  claim 1 , wherein the first data that uniquely identifies the device includes a hardware thumbprint of the device. 
     
     
       5. The medium of  claim 4 , wherein the hardware thumbprint of the device is derived from at least one of a serial number of a baseband component in the device, a serial number of a memory component of the device, a serial number of the device, in combination with a random number. 
     
     
       6. The medium of  claim 1 , wherein the second data that uniquely identifies the SIM card includes a serial number of the SIM card. 
     
     
       7. The medium of  claim 6 , wherein the serial number of the SIM card comprises an Integrated Circuit Card ID (ICCID) encoded on the SIM card. 
     
     
       8. The medium of  claim 1 , wherein the second data that uniquely identifies the SIM card includes a subscriber identifier associated with SIM card. 
     
     
       9. The medium of  claim 8 , wherein the subscriber identifier associated with the SIM card comprises an International Mobile Subscriber Identifier (IMSI) that designates the subscriber authorized to use the SIM card. 
     
     
       10. The medium of  claim 1 , wherein the activation record stored in the device further comprises an activation public key, the activation record having been signed by the activation server using an activation private key corresponding to the activation public key. 
     
     
       11. The medium of  claim 1 , wherein verifying the activation record stored in the device further comprises decrypting a content of the activation record using a device obfuscation key that is derived from a hardware thumbprint of the device and a shared obfuscation key. 
     
     
       12. The medium of  claim 1 , wherein verifying the activation record stored in the device further comprises validating an activation public key contained in the activation record. 
     
     
       13. The medium of  claim 12 , wherein verifying the activation record stored in the device further comprises validating a signature of the activation record stored in the device using the validated activation public key. 
     
     
       14. The medium of  claim 1 , wherein verifying the activation record stored in the device further comprises verifying that a maximum retry counter has not reached a maximum count. 
     
     
       15. The medium of  claim 1 , the method further comprising incrementing a maximum retry counter when the activation record is not successfully verified. 
     
     
       16. A non-transitory machine readable storage medium storing program instructions which when executed by a device cause the device to perform a method of operating a wireless communications apparatus comprising a subscriber identification security module, the method comprising:
 issuing an activation request comprising a first data configured to uniquely identify the communications apparatus, and a second data configured to uniquely identify the security module; 
 storing, in the wireless communications apparatus, a signed activation record comprising at least a representation of the first data and the second data, the signed activation record having been generated by an entity of a communications network, based at least in part on the activation request; and 
 providing a first information configured to enable verification of the activation record against a second information associated with the security module, the first information comprising at least a portion of the signed activation record; and 
 wherein the wireless communications apparatus is configured to be registered with the communications network based at least in part on a successful verification of the signed activation record. 
 
     
     
       17. A method of providing service in a wireless communications network, the method comprising:
 receiving an activation request comprising a first data and a second data, the activation request being received from a wireless communications apparatus which has the first data, the second data, and a subscriber identification security module associated therewith; 
 creating a signed activation record comprising at least a representation of the first data and the second data, the activation record being created by an entity of a communications network, and being created based at least in part on the activation request; 
 causing registration of the wireless communications apparatus with the network, based at least in part on a successful verification of the signed activation record; 
 wherein the first data is configured to uniquely identify the wireless communications apparatus, and the second data is configured to uniquely identify the security module. 
 
     
     
       18. The method of  claim 17 , wherein the registration of the wireless communications apparatus with the network is configured to enable a subscriber associated with the wireless communications apparatus to communicate over the wireless network with at least one other wireless communication apparatus associated with the network. 
     
     
       19. A non-transitory machine readable storage medium storing program instructions which when executed by a device cause the device to perform a method of providing service in a wireless communications network, the method comprising:
 receiving an activation request comprising a first data and a second data, the activation request being received from a wireless communications apparatus which has the first data, the second data, and a subscriber identification security module associated therewith; 
 creating a signed activation record comprising at least a representation of the first data and the second data, the activation record being created by an entity of a communications network, and being created based at least in part on the activation request; 
 causing registration of the wireless communications apparatus with the network, based at least in part on a successful verification of the signed activation record; 
 wherein the first data is configured to uniquely identify the wireless communications apparatus, and the second data is configured to uniquely identify the security module. 
 
     
     
       20. The medium of  claim 19 , wherein the registration of the wireless communications apparatus with the network is configured to enable a subscriber associated with the wireless communications apparatus to communicate over the wireless network with at least one other wireless communication apparatus associated with the network.

Description:
This application is a continuation of co-pending U.S. application Ser. No. 13/088,184, filed on Apr. 15, 2011, which is a continuation of U.S. application Ser. No. 11/849,286 filed on Sep. 1, 2007, now issued as U.S. Pat. No. 7,929,959. 
    
    
     BACKGROUND 
     Mobile devices that are manufactured for use with the Global System for Mobile Communications (GSM) digital cellular phone technology are designed to work with any mobile communications network service provider. The device requires the use of a subscriber identity module (SIM), referred to as a SIM card, which must be inserted into the GSM device to sign on to the subscriber&#39;s service provider network. The SIM card is a small circuit board that contains, among other things, an identifier that identifies the service provider with which the SIM card is allowed to be used. Typically, each service provider, such as AT&amp;T, or Verizon, is assigned their own range of SIM card identifiers for use with their networks. 
     Most GSM devices are manufactured with a service provider lock that restricts the device to SIM cards for a particular service provider. For example, a mobile device manufactured by Nokia that is marketed by an AT&amp;T service provider may have a lock that restricts the device to SIM cards encoded with identifiers falling within the range of SIM card identifiers assigned for use with the AT&amp;T network. 
     The method of enforcing the service provider lock may vary from one manufacturer to the next. When a device is manufactured with a service provider lock, the lock is usually based on a code that is stored in the device or derived using an algorithm. However, the codes and/or algorithms may be compromised such that the device may be unlocked and used with SIM cards having identifiers assigned for use with other service providers. This results in a loss of revenue for the original service provider, since the device is, presumably, no longer being used on their network. 
     From the GSM device manufacturer&#39;s point of view, there are other drawbacks to manufacturing devices with service provider locks. For example, manufacturing a device with a particular service provider lock may require the manufacturer to maintain different part numbers for the mobile devices manufactured for the different service providers, since the locking codes and/or algorithms will vary depending on the service provider. This can add to the logistical complexity of manufacturing the device as well as add significant inventory cost. 
     From the consumers&#39; point of view, most would likely prefer the freedom of purchasing a mobile device without being restricted to one particular service provider. For example, it may be desirable to switch to a different service provider when traveling abroad or to different parts of the country. 
     SUMMARY OF THE DETAILED DESCRIPTION 
     Methods and systems for service provider activation in a mobile device are described. 
     According to one aspect of the invention, a mobile device operates in limited service mode until activated for use with a particular service provider. The mobile device may be prepared for activation through the use of a service provider signing process, and subsequently activated for use with a particular service provider through the use of a service provider activation process. The service provider signing and activation processes are performed in accordance with embodiments of the invention. 
     According to one aspect of the invention, the service provider signing process prepares the device for activation by causing an activation ticket to be stored on the device that securely incorporates information from both the device and the SIM card that is inserted into the device during the signing process. 
     According to another aspect of the invention, the service provider activation process verifies that an activation ticket previously stored on the device is authentic and corresponds to both the device and the SIM card currently inserted into the device prior to activating the device for use on the service provider&#39;s network. 
     According to one aspect of the invention, when a new SIM card is inserted into the device, or when the device is re-booted, the service provider signing and activation processes are repeated as necessary to activate the device for use with the service provider identified in the currently inserted SIM card. For example, when the currently inserted SIM card has already undergone the signing process during a previous insertion into the device, then only the activation process is needed to activate the device. When the SIM card is new to the device (i.e., has not yet been through either the signing or activation process on this device), both the signing and activation processes are repeated to activate the device for use with the service provider. 
     According to one aspect of the invention, the service provider signing process may be repeated for different SIM cards such that more than one activation ticket may be stored on the device. Each activation ticket stored on the device corresponds to one of the SIM cards that were inserted into the device during the signing process. In this manner, the mobile device may be prepared for activation with different service providers corresponding to the different SIM cards used during the signing process (as long as the subscriber accounts with those service providers are still valid at the time of activation). 
     According to one aspect of the invention, the service provider signing process includes generating an activation request into which information is bundled from both the device and the SIM card currently inserted into the device. The bundled information includes, among other data, the Integrated Circuit Card ID (ICCID) and International Mobile Subscriber Identifier (IMSI) of the SIM card currently inserted into the device, the International Mobile Equipment Identifier (IMEI) encoded on the device, and a hardware thumbprint of the device. 
     According to one aspect of the invention, the service provider signing process further includes receiving the activation request in an activation server, where the activation request is typically relayed to the activation server via an activation client in communication with the device. The activation server generates the activation ticket based on the information that was bundled into the activation request. The activation server, in communication with backend servers for the service provider, may first verify whether the subscriber specified in the IMSI is associated with a valid account. In some embodiments, the activation server may perform other policy determinations that govern whether to generate an activation ticket, including such things as confirming whether the mobile country code (MCC) and mobile network code (MNC) specified in the IMSI is consistent with the expected distribution channel for the device, based on the device&#39;s IMEI. 
     According to one aspect of the invention, during the signing process, the activation server generates a signed activation ticket using an activation private key that is stored on, or is otherwise accessible by, the activation server. The generated activation ticket is formatted to include not only the information that was bundled into the activation request, but also an activation public key that will later be used on the device to validate the signature of the ticket. As a further security measure, the content of the activation ticket is obscured using encryption before sending the activation ticket back to the device. Encryption may be performed using a per-device symmetric key that is stored on, or is otherwise accessible by, both the device and the activation server. This key may be referred to as the shared obfuscation key. 
     According to one aspect of the invention, at the conclusion of the signing process, the generated activation ticket is received in the device from the activation server, typically via an activation client in communication with the device. The device stores the activation ticket for use during a subsequent service provider activation process. 
     According to one aspect of the invention, the service provider activation process queries the ICCID of the currently inserted SIM at startup and uses this value to determine whether an activation ticket has previously been stored for this SIM card. If so, the service provider activation process issues a command in the device to verify the activation ticket, including but not limited to, decrypting the activation ticket using the shared obfuscation key, validating the public activation key supplied in the ticket by the activation server, and using the validated key to validate the signature of the activation ticket. 
     According to one aspect of the invention, the service provider activation process verifies the content of the activation ticket against the device and the SIM card currently inserted into the device, including verifying that the IMEI and hardware thumbprints match those in the device, and that the ICCID and IMSI match those in the currently inserted SIM card. If the content of the activation ticket cannot be verified as matching the device and SIM card, then the activation ticket is treated as invalid, and the device is not activated for use with the service provider&#39;s network. If the content of the activation ticket is verified, then the device is activated for use with the service provider&#39;s network. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements. 
         FIG. 1  is a block diagram overview of an architecture for a service provider activation system according to one exemplary embodiment of the invention. 
         FIG. 2  is a block diagram overview of selected components of a mobile device according to one exemplary embodiment of the invention. 
         FIG. 3  is a block diagram overview of a service provider activation system according to one exemplary embodiment of the invention. 
         FIG. 4  is a flow diagrams illustrating certain aspects of performing a method for a service provider signing process according to one exemplary embodiment of the invention. 
         FIGS. 5A-5B  are flow diagrams illustrating certain aspects of performing a method for a service provider activation process according to one exemplary embodiment of the invention. 
         FIG. 6  is a block diagram overview of an exemplary embodiment of a general purpose computer system in which certain components of a service provider activation system may be implemented according to one exemplary embodiment of the invention, including but not limited to, components such as the activation client, activation server, and other back end servers of the service providers of mobile communications networks. 
     
    
    
     DETAILED DESCRIPTION 
     The embodiments of the present invention will be described with reference to numerous details set forth below, and the accompanying drawings will illustrate the described embodiments. As such, the following description and drawings are illustrative of embodiments of the present invention and are not to be construed as limiting the invention. Numerous specific details are described to provide a thorough understanding of the present invention. However, in certain instances, well known or conventional details are not described in order to not unnecessarily obscure the present invention. 
     The description may include material protected by copyrights, such as illustrations of graphical user interface images. The owners of the copyrights, including the assignee of the present invention, hereby reserve their rights, including copyright, in these materials. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyrights whatsoever. Copyright Apple Computer, Inc. 2007. 
     Various different system architectures may be used to implement the functions and operations described herein, such as to perform the methods shown in  FIGS. 4 ,  5 A- 5 B. The following discussion provides one example of such an architecture, but it will be understood that alternative architectures may also be employed to achieve the same or similar results. The service provider locking system  100  shown in  FIG. 1  is one example which is based upon the iPhone device sold by Apple Computer, Inc. and back end clients and servers associated with the iPhone device and the mobile communication networks with which the iPhone device may be used. It should be understood, however, that the architecture  100  may differ and may further be used with devices and mobile communication networks not related to the iPhone device. The architecture  100  includes a mobile device  102 , such as the iPhone device, and one or more SIM cards  104  which may be inserted into the mobile device  102 . The SIM cards  104  enable the device to register with and use a mobile communications network  118  operated by a service provider associated with one of the SIM cards  104  and/or the device  102 . 
     The mobile device  102  may further communicate with an activation client  108  operating on a personal computer (PC)  106  or other type of computing device to which the device  102  is connected. The activation client  108  is in communication with one or more activation servers  110 , typically over a network  116 . The network  116  may be any private or public internetwork or other type of communications path over which communications between the activation client  108  and activation server  110  may be transmitted. The activation server  110  may, in turn, be in communication with back end servers  112  of the service provider and a service provider database  114  that may contain information regarding the subscribers and devices that are allowed to register with and use the service provider&#39;s mobile communications network  118 . 
       FIG. 2  is a block diagram overview of selected components  200  of a mobile device  100  according to one exemplary embodiment of the invention. The mobile device  100  may include an application processor (AP)  202  that is used to perform some of the functions of the service provider activation system in accordance with an embodiment of the invention. The AP  202  is typically implemented as firmware that operates in conjunction with a baseband (BB)  204  integrated circuit. Among other things, the BB  204  provides the operating system platform on which the functions of the mobile device are carried out. In atypical embodiment, the BB  204  incorporates a stored IMEI  206  that uniquely identifies the mobile device, as well as a shared obfuscation key  208 , the use of which will be described in detail with reference to the activation ticket processing below. The device  100  further includes a memory component  210  that includes both volatile and non-volatile memory that may be used to store, among other data, the activation tickets used in the service provider activation system that will be described in further detail below. 
     The mobile device  100  may further include a SIM card slot into which a SIM card  212  may be inserted. The SIM card  212  may include an ICCID  214  that uniquely identifies the SIM card  212  and an IMSI  216  that designates the subscriber, and which is used to provision the mobile communications network  118  with which the device is to be used. 
       FIG. 3  is a block diagram overview of a service provider activation system according to one exemplary embodiment of the invention. As illustrated, having a BB  294  and an AP  208  may have inserted one of three SIM cards  302 , SIM Card A  302 A, SIM Card B  302 B, and SIM Card C  302 C. It should be understood that device  100  may be used with any one of a number of SIM cards, and that the three SIM cards are illustrated as an example only. 
     In one embodiment, the mobile device  100  may be a “generic” device, meaning that it was manufactured without a service provider lock. A device without a service provider lock is usable with any one of SIM cards A, B, and C,  302 A, B, and C. In other embodiments, the mobile device  100  may have been previously locked so that it cannot be used with the SIM cards A, B, and C unless it is first unlocked. Once the device  100  is unlocked, it is generally capable of operating in only a limited service mode, meaning that it can only be used for emergency calls, and is not yet activated on a service provider network. 
     In one embodiment, upon detecting the insertion of one of the SIM cards A, B, or C,  302 , or, alternatively, when the BB  204  boots, the AP  208  determines whether there is already stored an activation ticket  308  associated with the inserted SIM card A, B, or C. If not, the AP  208  initiates a signing process by issuing an activation request  304  to the activation server  110 . The activation request  304  comprises information from the device  100  and currently inserted SIM card  302 , including, for example, the IMEI,  206  IMSI  216 , and ICCID  214  values, and bundled into the activation request  304 . 
     In one embodiment, upon receipt of the activation request  304 , the activation server  110  determines whether to generate an activation ticket  306  based on the information that was bundled into the activation request  304 . An activation ticket  306  incorporates identifying information from both the device  100  and the inserted SIM card A, B, or C, using a ticket generator logic  310  and an activation public/private key pair  312  as will be described in further detail with reference to  FIG. 4 . 
     In a typical embodiment, the determination whether to generate an activation ticket  306  will depend, at least in part, on whether the service provider server  112  and/or service provider database  114  indicate that the IMSI  216  bundled into the activation request can be activated on the service provider&#39;s communication network  118 . In some embodiments, the determination whether to generate the activation ticket will depend on other policy considerations, such as whether to generate an activation ticket  306  for a given IMEI/ICCID pair (using the IMEI/ICCID that was bundled into the activation request  304 ). If the activation server  110  determines that it cannot generate an activation ticket  306 , then the activation request  304  will fail. 
     In one embodiment, once the activation ticket  306  has been generated, the activation server  110  obfuscates the content of the activation ticket  306  prior to returning the ticket to the device  100  to safeguard the contents of the activation ticket. In one embodiment, the activation ticket  306  is obfuscated by encrypting it with a per-device symmetric key. The per-device symmetric key may be derived from data unique to the device  100  and a key that is shared between the device and the activation server  110 . The shared key is referred to in the illustrated example as a Shared Obfuscation Key  208  on the device  100 , and also stored as one of the Keys  312  defined on the activation server  110 . As an example, the per-device symmetric key is referred to as a Device Obfuscation Key, and is derived using the hardware thumbprint of the device  100  and the Shared Obfuscation Key stored on the server in Keys  312  using the following algorithm: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 DeviceObfuscationKey = SHA-1(HardwareThumbprint || 
               
               
                   
                 SharedObfuscationKey) 
               
               
                   
                   
               
            
           
         
       
     
     After the activation ticket  306  has been generated and encrypted, the activation ticket  306  is ready to be sent back to the device  100 , where it is stored along with any other previously stored activation tickets  308 . The stored activation tickets  308 A, B, and C, can subsequently be used by the AP  208  to initiate the activation process as will be described in further detail with reference to  FIGS. 5A-5B . 
     In one embodiment, the format of the activation ticket  306 / 308  is as shown in Table 1. The format of the Activation Public Key that is included in the activation ticket is as shown in Table 2. 
     
       
         
           
               
             
               
                 TABLE 1 
               
             
            
               
                   
               
               
                 Format of Activation Ticket 
               
            
           
           
               
               
               
               
            
               
                   
                 NAME 
                 SIZE (Octets) 
                 ENCODING 
               
               
                   
                   
               
            
           
           
               
               
               
               
            
               
                   
                 Version 
                 1 
                 BCD 
               
               
                   
                 Activation PublicKey 
                 N 
                 Public Key 
               
               
                   
                 ICCID 
                 10 
                 BCD 
               
               
                   
                 IMSI 
                 8 
                 BCD 
               
               
                   
                 IMEI 
                 8 
                 BCD 
               
               
                   
                 Hardware Thumbprint 
                 20 
                 Binary 
               
               
                   
                 TicketSignature 
                 Key Length/8 
                 Binary 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                 TABLE 2 
               
             
            
               
                   
               
               
                 Format of Activation Public Key 
               
            
           
           
               
               
               
               
            
               
                   
                 NAME 
                 SIZE (Octets) 
                 ENCODING 
               
               
                   
                   
               
               
                   
                 Record Length 
                 4 
                 Binary 
               
               
                   
                 Serial Number 
                 4 
                 Binary 
               
               
                   
                 KeyLength 
                 4 
                 Binary 
               
               
                   
                 Exponent 
                 4 
                 Binary 
               
               
                   
                 Modulus 
                 Key Length/8 
                 Binary 
               
               
                   
                 Montgomery Factor 
                 Key Length/8 
                 Binary 
               
               
                   
                 KeySignature 
                 Mkey Length/8 
                 Binary 
               
               
                   
                   
               
            
           
         
       
     
     In one embodiment, the Version field of the activation ticket  306 / 308  allows the processing of activation tickets to be forward compatible. In one embodiment, the encoded integer Version allows future firmware releases in the device  100  to recognize older activation tickets and support them. The Version is also included in the digest of the activation ticket to verify that it cannot be altered. In one embodiment, the BB  204  will have a minimum record version compiled into it that can prevent rollback attacks if an activation ticket format is compromised. 
     In one embodiment, the Activation Public Key field in the activation ticket  306 / 308  may be formatted as shown in Table 2. It should be noted, however, that other public key formats may be employed with departing from the scope of the claims that follow. 
     The ICCID (Integrated Circuit Card ID) is a 20-digit number, defined in ISO/IEC 7812-1 that consists of: a 2 digit major industry identifier (89 for SIMs), a 1-3 digit country code (ITU-T E.164), an issuer identifier code, 1-4 digits (depending on country code length), which usually contains the MNC of the issuing network, an individual account identification number, and a 1 digit checksum. 
     The IMSI (International Mobile Subscriber Identifier) is a 15-digit number, defined in 3GPP TS 23.003 that consists of a 3 digit mobile country code (MCC), a 2 or 3 digit mobile network code (MNC), and a 9 or 10 digit mobile subscriber identity number (MSIN). 
     In one embodiment, the Hardware Thumbprint is a value that is typically derived from data that is unique to the device, such as the serial numbers of the hardware components of the device and the IMEI, plus a defined random sequence. For example, in one embodiment the thumbprint may be computed as follows:
         HardwareThumbprint=SHA-1(SGold-SerialNumber∥FlashSerialNumber∥IMEI∥Salt), where Salt is a random sequence.       

     In one embodiment, the Ticket Signature is generated as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 Message = Version || ICCID || IMSI || IMEI || 
               
               
                   
                 HardwareThumbprint 
               
               
                   
                 Hash = SHA-1(Message) 
               
               
                   
                 EncodedMessage = 0x00 || 0x04 || PaddingString || 0x00 || 
               
               
                   
                 Hash 
               
               
                   
                 TicketSignature = RSAEncrypt(activationPrivateKey, 
               
               
                   
                 EncodedMessage) 
               
               
                   
                   
               
            
           
         
       
     
     It should be noted that the described format of the activation ticket  306 / 308  set forth in Table 1 is just one example of a format that may be used, and other formats and data Fields may comprise the activation ticket without departing from the scope of the claims that follow. 
       FIGS. 4 ,  5 A, and  5 B are flow diagrams illustrating certain aspects of service provider activation according to one exemplary embodiment of the invention. In  FIG. 4 , a method for a service provider signing process  400  is described. The method  400  to be performed begins at block  402 , in which the device  100  detects a baseband boot or the insertion of a new SIM card. At block  404 , the method  400  bundles the IMSI, ICCID, IMEI and a hardware thumbprint into an activation request, and sends the request from the device to an activation server. At block  406 , the activation server receives the request, and determines whether to generate an activation ticket in response to the request based on certain policy considerations, such as whether the back end servers associated with the service provider confirm that the IMSI information is valid for the service provider&#39;s communication network. 
     In one embodiment, at process block  408 , the method  400  generates the activation ticket using the ICCID, IMSI, IMEI, and hardware thumbprint information that was bundled into the activation request. In one embodiment, the method  400  includes an activation public key into the ticket and, at block  410  signs the ticket using a corresponding activation private key that is securely stored on the activation server. At block  412 , the method  400  obscures the contents of the activation ticket by encrypting the contents with a device obfuscation key that is derived from information specific to the device, such as the hardware thumbprint provided in the activation request, and a shared obfuscation key that is available to both the activation server and the device. At process block  414 , the method  400  concludes with sending the activation ticket back to the device for storage. For example, the activation ticket may be stored in memory on the device that is accessible to the device&#39;s baseband. 
     Turning now to  FIGS. 5A-5B , a method for a service provider activation process  500  is described. The method  500  to be performed begins at block  502 , in which the device  100  queries the ICCID of the currently inserted SIM card at startup. At block  504 , the method  500  uses the ICCID to locate an activation ticket corresponding to the current ICCID. At block  506 , the device issues a command to initiate verification of the activation ticket. Verification of the activation ticket will cause the device&#39;s baseband to transition out of limited service mode and register on a communications network. The command will return an error code if the ticket cannot be successfully verified. 
     In atypical embodiment, the method  500  performs ticket verification after determining whether the SIM Card currently inserted into the device is in a ready state, i.e., whether the SIM is unlocked. If not, then the method  500  performs ticket verification after the SIM card has been successfully unlocked. 
     The method  500  continues at process blocks  508 A- 508 H, to perform the various aspects of activation ticket verification. At block  508 A, the method  500  first verifies that the retry count has not been exceeded. A retry counter will be incremented for each unsuccessful attempt to unlock and activate service on the device using the activation ticket verification command. Only a pre-defined number of attempts at verification are allowed to prevent against brute-force attacks, in which there are numerous attempts to activate the device. 
     In one embodiment, the method  500  continues at blocks  508 B/ 508 C, to parse out the version information in the activation ticket from the encrypted information, and to determine whether the version of the activation ticket to be verified is supported in the current version of the device&#39;s baseband. 
     At block  508 D, the method  500  decrypts the contents of the activation ticket using a device obfuscation key that is derived from the shared obfuscation key stored on the device and information that is specific to the device, such as the device&#39;s hardware thumbprint. At block  508 E, the method  500  validates the activation public key supplied in the activation ticket, and at  508 F uses the public key to validate the ticket signature. At blocks  508 G/H, the method  500  concludes the ticket verification process by verifying whether the decrypted hash value of the activation ticket compares correctly to the computed hash value. If so, the method continues at process block  510 ; otherwise the ticket verification fails and the method branches to block  516 . 
     At process block  510 , in order to prevent an activation ticket from one device being used on another device, the IMEI in the activation ticket is compared to the IMEI stored in the device. In one embodiment, all 15 digits of the respective IMEIs must match. If they do not, the BB activation ticket is treated as invalid. 
     At process block  512 , the method  500  continues to verify the activation ticket by determining the value of the hardware thumbprint contained in the activation ticket, and comparing that to the hardware thumbprint of the device. If they do not match, the activation ticket is treated as invalid. 
     At process block  514 , the method  500  continues to verify the activation ticket by comparing the value of the ICCID contained in the activation ticket to the ICCID of the SIM card currently inserted in the device. In special cases, the ICCID verification is bypassed, such as when the ICCID is encoded with 10 0xFF octets. Similarly, at process block  516 , the method  500  continues to verify the activation ticket by comparing the value of the IMSI contained in the activation ticket to the IMSI of the SIM card currently inserted into the device. Again, in special cases, the IMSI verification is bypassed, such as when the IMS is encoded with 10 0xFF octets. 
     At process block  516 , the method increments the retry counter and returns an error in response to the command should any of the activation ticket verification processes fail. At process block  518 , if the verification processes are successful, then the device can activate service on the device by initiating registration of the device on the service provider&#39;s mobile communication network. 
       FIG. 6  illustrates an example of a typical computer system in which some aspects of the invention may be practiced, such as the backend clients and servers used to provide service activation of a mobile device. Note that while  FIG. 6  illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components as such details are not germane to the present invention. It will also be appreciated that network computers and other data processing systems which have fewer components or perhaps more components may also be used with the present invention. The computer system of  FIG. 6  may, for example, be a Macintosh computer from Apple Computer, Inc. 
     As shown in  FIG. 6 , the computer system  601 , which is a form of a data processing system, includes a bus  602  which is coupled to a microprocessor(s)  603  and a ROM (Read Only Memory)  607  and volatile RAM  605  and anon-volatile memory  606 . In one embodiment, the microprocessor  603  may be a G3 or G4 microprocessor from Motorola, Inc. or one or more G5 microprocessors from IBM. The bus  602  interconnects these various components together and also interconnects these components  603 ,  607 ,  605 , and  606  to a display controller and display device  604  and to peripheral devices such as input/output (I/O) devices which may be mice, keyboards, modems, network interfaces, printers and other devices which are well known in the art. Typically, the input/output devices  609  are coupled to the system through input/output controllers  608 . The volatile RAM (Random Access Memory)  605  is typically implemented as dynamic RAM (DRAM) which requires power continually in order to refresh or maintain the data in the memory. The mass storage  606  is typically a magnetic hard drive or a magnetic optical drive or an optical drive or a DVD RAM or other types of memory systems which maintain data (e.g. large amounts of data) even after power is removed from the system. Typically, the mass storage  606  will also be a random access memory although this is not required. While  FIG. 6  shows that the mass storage  606  is a local device coupled directly to the rest of the components in the data processing system, it will be appreciated that the present invention may utilize a non-volatile memory which is remote from the system, such as a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface. The bus  602  may include one or more buses connected to each other through various bridges, controllers and/or adapters as is well known in the art. In one embodiment the I/O controller  608  includes a USB (Universal Serial Bus) adapter for controlling USB peripherals and an IEEE 1394 controller for IEEE 1394 compliant peripherals. 
     It will be apparent from this description that aspects of the present invention may be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM  607 , RAM  605 , mass storage  606  or a remote storage device. In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the present invention. Thus, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system. In addition, throughout this description, various functions and operations are described as being performed by or caused by software code to simplify description. However, those skilled in the art will recognize what is meant by such expressions is that the functions result from execution of the code by a processor, such as the microprocessor  603 .

Metadata:
Filing Date: 20130417
Publication Date: 20140805
Grant Date: 20140805
Priority Date: 20070901
Inventors: DE ATLEY DALLAS
BUSH JEFFREY
HAUCK JERRY
HUANG RONALD KERYUAN
SATHIANATHAN BRAINARD
Assignee: APPLE INC
CPC Classifications: [{"code": "H04B1/3816", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04W8/265", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W12/06", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04B1/3816", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04W8/265", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W12/35", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W12/35", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 39875067