Managing data for authentication devices

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit of PCT Application Serial No. PCT/CA2011/050278, entitled “Managing Data for Authentication Devices,” filed on May 6, 2011, the entire contents of which is hereby incorporated by reference.

BACKGROUND

0002This specification relates to managing authentication data for an authentication device. Some products can authenticate product accessories to ensure that the accessories are approved by the product manufacturer. For example, some smartphones can authenticate a battery upon installation of the battery, before charging, or at other times. In such cases, authentic batteries that are approved by the smartphone manufacturer include an authentication device that generates data that can be authenticated by the smartphone. The authentication device and other components of the battery are typically manufactured and assembled by multiple different entities during the battery manufacturing process.

BRIEF DESCRIPTION OF THE DRAWINGS

0003<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of an example device authentication system.

0004<figref idref="DRAWINGS">FIG. 2</figref> is a diagram of an example mobile device.

0005<figref idref="DRAWINGS">FIG. 3</figref> is a diagram of an example manufacturing process.

0006<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram showing an example technique for managing authentication data during a manufacturing process.

0007<figref idref="DRAWINGS">FIG. 5</figref> is a flow chart showing an example process for managing authentication data.

0008Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

0009Product makers incorporate authentication devices in their products to reduce the potential of counterfeiting. The authentication device contains authentication data (e.g., a secret key value, certificate data, etc.) that can be used to establish the authenticity of the product. Authentication devices are often manufactured and then integrated into an end product. For example, an authentication device for a mobile device battery is typically manufactured by a semiconductor manufacturer, then integrated into a circuit board by a circuit board manufacturer, and the circuit board is then integrated into the mobile device battery by the battery manufacturer. As such, the authentication device may pass through many locations and be handled by multiple different entities before the product is completed or delivered to the product manager.

0010Complex manufacturing and supply chains can be vulnerable to overproduction and siphoning schemes, in which legitimate products are stolen and redirected to illegitimate (e.g., counterfeit, underground, etc.) markets. For example, legitimate authentication devices could potentially be overproduced and incorporated into counterfeit batteries, and if the overproduced authentication device were operational, the counterfeit battery could be authenticated by the smartphone handset. As another example, legitimate batteries with legitimate authentication devices could potentially be overproduced and sold through underground channels. Counterfeit devices can pose problems for product makers and consumers alike. For example, counterfeit devices may pose safety hazards, exposing companies to litigation as well as displacing genuine products. As another example, a counterfeit device may not perform as expected by the consumer. In some scenarios, overproduction is difficult to prevent, and overproduced devices are difficult to track or detect.

0011Complex manufacturing and supply chains can also be vulnerable to data security concerns. For example, authentication devices are authenticated based on authentication data (e.g., certificate data, key data, etc.) stored on the authentication device. A malicious party could potentially intercept the authentication data during the manufacturing process and incorporate the authentication data into counterfeit products. For example, authentication devices can utilize public-key cryptography schemes and certificates on the public keys. The private and public keys can be stored on the authentication devices during the manufacturing process, for example, by the authentication device manufacturer. Even if the authentication device manufacturer is trusted, the authentication device may later be incorporated into a subsystem by another manufacturer that is not trusted. As such, in some cases, the product manager is motivated to prevent the authentication device manufacturer from producing valid authentication devices.

0012In some implementations, the risk of legitimate authentication devices being siphoned away and the risk of valid authentication data being stolen during a manufacturing process is reduced by storing the authentication data in an encrypted format during all or part of the manufacturing process. For example, the authentication data can be communicated to the authentication device manufacturer in an encrypted format, and the authentication device manufacturer can store the encrypted authentication data on the authentication device. The authentication data can be decrypted later in the manufacturing process by another entity. Storing the encrypted authentication data on the authentication device also allows the authentication data to be securely transported through the manufacturing process by the authentication device itself, and reduces the counterfeiter's motivation to siphon legitimate devices. For example, because the authentication data are encrypted, a potential counterfeiter cannot efficiently enable operation of the siphoned authentication device without the cryptographic secret (e.g., the secret key that can be used to decrypt the encrypted authentication data). The cryptographic secret that can decrypt the authentication data may be made accessible only to the product maker or another trusted entity later in the manufacturing process, so that the authentication device is not operational, for example, when it leaves the authentication device maker's facility.

0013Moreover, some types of manufacturing processes are performed in locations that have unreliable or inadequate data communication capabilities. As such, communicating the authentication data for each of the authentication devices directly to the manufacturing facility may be impractical or inefficient. In some implementations, transporting the authentication data on the authentication device itself helps to ensure that the required information is available at the end product manufacturing site, but not at semiconductor manufacture. For example, the end product manufacturing site may only need to receive the cryptographic key to decrypt the authentication data, rather than receiving the authentication data itself, which can be much larger than the cryptographic key.

0014As a specific example, the risk of a battery authentication device being redirected to a counterfeit market may be reduced if the battery's authentication device is not operational until later stages of the battery manufacturing process or after manufacturing is complete. Accordingly, to limit the trust required of the semiconductor manufacturer who manufactures the authentication device, encrypted versions of the authentication data (e.g., the certificate on the authentication device's public key) can be provided to the semiconductor manufacturer. In such cases, the semiconductor manufacturer can produce authentication devices that are functional but lack the informational resources needed for authentication by the mobile device. The battery manufacturer who receives the authentication device can later decrypt the authentication data stored on the authentication device.

0015<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of an example authentication system <b>100</b>. The authentication system <b>100</b> includes a primary device <b>106</b> and a secondary device <b>102</b>. The primary device <b>106</b> includes an interrogator module <b>108</b>, and the secondary device <b>102</b> includes an authentication module <b>104</b>. The authentication system <b>100</b> may include additional or different components, which may be configured as shown and described with respect to <figref idref="DRAWINGS">FIG. 1</figref>, or in a different manner.

0016The interrogator module <b>108</b> can approve or deny authentication of the authentication module <b>104</b> based on messages exchanged between the interrogator module <b>108</b> and the authentication module <b>104</b>. For example, the authentication module <b>104</b> can be required to prove to the interrogator module <b>108</b> that it knows some secret information. In the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the interrogator module <b>108</b> sends interrogation messages <b>124</b> to the authentication module <b>104</b>, and the authentication module <b>104</b> sends reply messages <b>122</b> to the interrogator module <b>108</b>. The example interrogation messages <b>124</b> include challenge values, and the example reply messages <b>122</b> include proffered response values and certificate data. In some implementations, the messages include additional or different types of information. If the authentication module <b>104</b> sends the correct response value and a valid certificate, the interrogator module <b>108</b> can approve the secondary device <b>102</b> that includes the authentication module <b>104</b>.

0017Generally, the primary device <b>106</b> and the secondary device <b>102</b> can be any type of systems, modules, devices, components, and combinations thereof. In some examples, the primary device <b>106</b> can be a mobile device. Examples of mobile devices include various types of cellular devices, smartphones, portable media players, personal digital assistants (PDAs), laptops, notebooks, tablets, etc. <figref idref="DRAWINGS">FIG. 2</figref> shows a specific example of a primary device and a secondary device. In the example shown in <figref idref="DRAWINGS">FIG. 2</figref>, the primary device is a mobile device <b>200</b>, and the secondary device is a battery <b>230</b>. In other examples where the primary device <b>106</b> is a mobile device, the secondary device <b>102</b> can be a different type of accessory to be paired with the mobile device. For example, the secondary device <b>102</b> can be a headset, a charger, a keyboard, a pointing device, a replacement part, or another type of accessory for the mobile device.

0018The primary device <b>106</b> and the secondary device <b>102</b> can alternatively be components of another type of system. Examples of other types of primary devices include consumer electronics, computing devices, consumer appliances, transportation systems, manufacturing systems, security systems, pharmaceutical products, medical devices, and others. In some implementations, the primary device <b>106</b> is a printer and the secondary device <b>102</b> is a cartridge for the printer. In some implementations, the primary device <b>106</b> is a badge reader and the secondary device <b>102</b> is a badge to be read by the badge reader.

0019The primary device <b>106</b> and the secondary device <b>102</b> can communicate through a communication link. Various types of communication links may be used, as appropriate. For example, the primary device <b>106</b> and the secondary device <b>102</b> may communicate through a wired communication link, such as a USB link, a parallel port link, a voltage terminal, or another type of wired contact. As another example, the primary device <b>106</b> and the secondary device <b>102</b> may communicate through a wireless communication link, such as a radio frequency link, an infrared link, or another type of wireless medium. The primary device <b>106</b> and the secondary device <b>102</b> may communicate through a combination of wired and wireless links. The communication link between the primary device <b>106</b> and the secondary device <b>102</b> can include the communication interface <b>117</b> of the interrogator module <b>108</b>, the communication interface <b>116</b> of the authentication module <b>104</b>, or any combination of these and other communication interfaces.

0020The interrogator module <b>108</b> can be implemented by hardware, software, firmware, or a combination thereof. For example, in some cases, all or part of the interrogator module <b>108</b> can be implemented as a software program executed by a microprocessor. As another example, in some cases, all or part of the interrogator module <b>108</b> can be implemented as digital or analog circuitry. In some instances, the interrogator module <b>108</b> is integrated with and/or utilizes other software or hardware resources of the primary device <b>106</b>, or the interrogator module <b>108</b> can be a standalone module. The interrogator module <b>108</b> includes a communication interface <b>117</b> that transmits the interrogation messages <b>124</b> and receives the reply messages <b>122</b>. The communication interface <b>117</b> can include a wired interface, a wireless interface, or a combination of these.

0021The interrogator module <b>108</b> can include a memory or another type of medium that stores challenge-response data. For example, the interrogator module <b>108</b> can include a challenge selector that selects challenge values, and the interrogator module <b>108</b> can include a cryptographic function evaluator that derives response values for selected challenge values. As such, the interrogator module <b>108</b> can include data regarding one or more previously-derived challenge-response pairs, instructions that allow the interrogator module <b>108</b> to derive challenge-response pairs, or other information relating to challenge-response data. In some instances, a random number generator is used to select challenge values and a key-based encryption or signature scheme (e.g., RSA, ECC) is used to derive the response values. The interrogator module <b>108</b> may derive response values for challenge values using a cryptographic function. For example, the response value for each challenge value may be generated at the interrogator module <b>108</b> based on a public key of the authentication module <b>104</b>. When the interrogator module <b>108</b> interrogates the authentication module <b>104</b>, the interrogator module <b>108</b> obtains a challenge value and provides the challenge value to the authentication module <b>104</b> in the interrogation message <b>124</b>.

0022The authentication module <b>104</b> can be implemented by hardware, software, firmware, or a combination thereof. For example, in some cases, all or part of the authentication module <b>104</b> can be implemented as a software program executed by a microprocessor. As another example, in some cases, all or part of the authentication module <b>104</b> can be implemented as digital or analog circuitry. In some instances, the authentication module <b>104</b> is integrated with and/or utilizes other software or hardware resources of the secondary device <b>102</b>, or the authentication module <b>104</b> can be a standalone module. The authentication module <b>104</b> includes a communication interface <b>116</b> that transmits the reply messages <b>122</b> and receives the interrogation messages <b>124</b>. The communication interface <b>116</b> can include a wired interface, a wireless interface, or a combination of these.

0023The authentication module <b>104</b> includes a response-generator module <b>112</b> and authentication data. In the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the authentication data include key data <b>113</b> and certificate data <b>114</b>. An authentication module may include additional or different types of features, including additional or different types of authentication data. The key data <b>113</b> include a secret value that is used by the response-generator module <b>112</b> to generate a proffered response value based on a challenge value received from the interrogator module <b>108</b>. The secret value can be a secret key value of a cryptographic key pair. The cryptographic key pair can be a symmetric or asymmetric key pair. For example, the cryptographic key pair can be a key pair based on ECC, RSA, AES, DES, or another type of encryption scheme. In some instances the key data <b>113</b> include one or both of the keys of the cryptographic key pair. For example, the key data <b>113</b> may include the private key, the public key, or both the public and private keys of an asymmetric key encryption scheme. The key data <b>113</b> may include additional or different types of information.

0024The response-generator module <b>112</b> can generate a response value based on a challenge value received from the interrogator module <b>108</b> and the secret value included in the key data <b>113</b>. For example, the response-generator module <b>112</b> can receive a challenge value from the interrogator module <b>108</b> and generate a proffered response value. The proffered response value can be generated by evaluating a cryptographic function at the response-generator module <b>112</b>. In some implementations, the input data for the cryptographic function can include a private key value and a challenge value. In some instances, the response-generator module <b>112</b> can generate the proffered response value by applying an encryption or digital signature function to the challenge value provided by the interrogator module <b>108</b>. For example, the response-generator module <b>112</b> may use the private key value to apply a digital signature to the challenge value.

0025In the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the certificate data <b>114</b> include a digital certificate that certifies a public key value. In some implementations, the public key value certified by the digital certificate corresponds to the private key value used by the response-generator module <b>112</b> to generate proffered response values. The certificate data <b>114</b> can include an explicit or implicit representation of the public key value, an identification value for the authentication module, a digital signature of a certificate authority, information regarding when the digital certificate was generated, information regarding when the digital certificate expires, information regarding the identity of the certificate authority, or any combination of these and other data elements. The proffered response value and the certificate data <b>114</b> can be transmitted to the interrogator module <b>108</b> in one or more of the reply messages <b>122</b>.

0026In some implementations, digital certificates include one or more of the following features. A digital certificate can be issued by a certificate authority, which is a trusted party that certifies public keys for entities that utilize key-based cryptographic schemes. For example, each authentication device may have a unique identification number and a particular public key value, and a digital certificate can serve as verification from a trusted source that a particular public key value belongs to the authentication device having a particular identification number. As such, the digital certificate can bind the identification value of each authentication device to a particular public key value. Another user entity, such as the interrogator module <b>108</b>, can use a public key of the certificate authority to verify that the digital certificate was signed by the trusted certificate authority. In this manner, the digital certificate serves as confirmation by the trusted third party that the public key value presented by the authentication module <b>104</b> belongs to a legitimate authentication module <b>104</b> and not an impostor.

0027The certificate data <b>114</b> can include any type of digital certificate data, including an implicit certificate or an explicit certificate. In some cases, an explicit certificate includes the certificate authority's signature on the public key value certified for the authentication module <b>104</b>. The explicit certificate can also include the public key value, an identifier of the authentication module <b>104</b>, and other information. An implicit certificate includes information that can be used to construct the authentication module's public key. As such, some implicit certificates include neither an explicit representation of the public key value nor an explicit representation of the certificate authority's digital signature. For example, the implicit certificate can include a public key reconstruction value, which can be used in combination with other available information (e.g., the certificate authority's public key, etc.) to reconstruct the public key value. An example of an implicit certificate scheme is the ECQV implicit certificate scheme.

0028In some aspects of operation, the interrogator module <b>108</b> generates an interrogation message <b>124</b> and sends the interrogation message <b>124</b> to the authentication module <b>104</b>. The interrogation message <b>124</b> includes a challenge value. The authentication module <b>104</b> receives the interrogation message <b>124</b> and generates a reply message <b>122</b>. The reply message <b>122</b> includes the certificate data <b>114</b> and a proffered response value. The certificate data <b>114</b> and the proffered response value can be sent in a single message or in multiple different messages. The response-generator module <b>112</b> generates the proffered response value by evaluating a cryptographic function. In some implementations, the response-generator module <b>112</b> uses the secret value in the key data <b>113</b> to apply the cryptographic function to the challenge value received from the interrogator module <b>108</b>. For example, the response-generator module <b>112</b> may use a private key value to apply a digital signature to the challenge value.

0029In some aspects of operation, the interrogator module <b>108</b> receives the reply message <b>122</b>. In response to receiving the reply message <b>122</b>, the interrogator module <b>108</b> validates the certificate data <b>114</b>. Validating the certificate data <b>114</b> indicates that the public key presented by the authentication module <b>104</b> is a trusted public key that has been certified by the certificate authority. For example, the interrogator module <b>108</b> may use the certificate authority's public key to validate the certificate data <b>114</b>. The interrogator module <b>108</b> can obtain the certificate authority's public key by retrieving the certificate authority's public key from the certificate authority, by accessing the certificate authority's public key from a local memory available to the interrogator module <b>108</b>, or in another manner. If the certificate data <b>114</b> are validated, the interrogator module <b>108</b> also compares the proffered response value to the correct response value. Determining that the proffered response value matches the correct response value indicates that the authentication module <b>104</b> has the private key corresponding to the trusted public key. If the interrogator module <b>108</b> determines that the authentication module has provided a valid reply, the secondary device can be authenticated. In some implementations, a valid reply includes both the valid certificate data <b>114</b> and a valid response value generated based on the key data <b>113</b>. In such cases, both the certificate data <b>114</b> and the key data <b>113</b> are required to generate a valid response to the interrogation message <b>124</b>.

0030<figref idref="DRAWINGS">FIG. 2</figref> is a schematic diagram of an example mobile device <b>200</b>. For example, the mobile device <b>200</b> can be a BLACKBERRY® mobile device and/or another type of mobile device. In some implementations, the mobile device <b>200</b> is a dual-mode mobile device. The example mobile device <b>200</b> in <figref idref="DRAWINGS">FIG. 2</figref> includes a microprocessor <b>202</b>, a communication subsystem <b>204</b>, random access memory (RAM) <b>206</b>, non-volatile memory <b>208</b>, a display <b>210</b>, one or more auxiliary input/output (I/O) devices <b>212</b>, a data port <b>214</b>, a keyboard <b>216</b>, a speaker <b>218</b>, a microphone <b>220</b>, a short-range wireless communications subsystem <b>222</b>, other device subsystems <b>224</b>, a SIM/RUIM card (i.e., a Subscriber Identity Module or a Removable User Identity Module) <b>226</b>, a SIM/RUIM interface <b>228</b>, a rechargeable battery <b>230</b>, a battery interface <b>232</b>, and possibly other components. The mobile device <b>200</b> may include the same, additional, and/or different features, which may be arranged and/or operate in the manner shown or in a different manner.

0031The example mobile device <b>200</b> is a battery-powered device that includes a battery interface <b>232</b> that receives direct current electrical power from one or more rechargeable batteries <b>230</b>. The battery <b>230</b> can be a smart battery with an embedded microprocessor or a different type of battery. The battery interface <b>232</b> may be coupled to a regulator (not shown), which may assist the battery <b>230</b> in providing power V+ to the mobile device <b>200</b>. Additionally or alternatively, the mobile device <b>200</b> may receive power from an external source (e.g., an alternating current power source, an adapter, a converter, etc.) and/or a different type of internal power source.

0032The example mobile device <b>200</b> shown in <figref idref="DRAWINGS">FIG. 2</figref> is a two-way communication device having voice and data communication capabilities. The mobile device <b>200</b> may communicate over wireless networks, including wireless telecommunication networks, wireless data networks, combined voice and data networks, and/or other types of wireless networks. Thus, the mobile device <b>200</b> may communicate over a voice network, such as any of the analog or digital cellular networks, and may also communicate over a data network. Voice and data networks may be implemented as separate communication networks using separate infrastructure, such as base stations, network controllers, etc., or the voice and data networks may be integrated into a single wireless network. The networks can include one or more local, regional, national, or global networks. The networks can include one or more cellular networks. In some implementations, wireless networks utilize one or more communication protocol standards, for example, 3G, 4G, GSM, CDMA, GPRS, EDGE, LTE or others.

0033In the example mobile device <b>200</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>, the communication subsystem <b>204</b> includes a receiver <b>250</b>, a transmitter <b>252</b>, antennae <b>254</b> and <b>256</b>, one or more local oscillators <b>258</b>, a digital signal processor (DSP) <b>260</b> and possibly other features. The antennae <b>254</b> and <b>256</b> may include antenna elements of a multiple-element antenna, embedded antennae, radio frequency (RF) antennae, and/or other types of antennae. The communication subsystem <b>204</b> is used to communicate with the network. The DSP <b>260</b> is used to receive and send signals through the receiver <b>250</b> and the transmitter <b>252</b>, respectively, and the DSP <b>260</b> provides control information to the receiver <b>250</b> and the transmitter <b>252</b>. For example, the gain levels applied to communication signals in the receiver <b>250</b> and the transmitter <b>252</b> may be adaptively controlled through automatic gain control algorithms implemented in the DSP <b>260</b>. Additional and/or different types of control algorithms may be implemented in the DSP <b>260</b> to provide more sophisticated control of the communication subsystem <b>204</b>.

0034In some implementations, the local oscillator <b>258</b> is a single local oscillator that provides a reference signal for the receiver <b>250</b> and the transmitter <b>252</b>, for example, where voice and data communications occur at a single frequency, or closely-spaced sets of frequencies. Alternatively, for example if different frequencies are utilized for voice communications and data communications, the local oscillator <b>258</b> may include multiple local oscillators that are used to generate multiple different frequencies corresponding to the voice and data networks. Information, which may include both digital voice and digital data information, can be communicated within the mobile device <b>200</b> to and from the communication subsystem <b>204</b> through a link or bus between the DSP <b>260</b> and the microprocessor <b>202</b>. The design and configuration of the communication subsystem <b>204</b>, such as frequency band, component selection, power level, etc., may depend on the communication network in which the mobile device <b>200</b> is intended to operate. For example the communication subsystem <b>204</b> may be configured for 2G, 2.5G, 3G, <b>4</b>G, and other voice and data networks, such as GSM, CDMA2000, GPRS, EDGE, W-CDMA (UMTS), FOMA, EV-DO, TD-SCDMA, HSPA, HSOPA, and the like.

0035After any required network registration or activation procedures have been completed, the mobile device <b>200</b> may send and receive communication signals, including both voice and data signals, over the wireless networks. Signals received by the antenna <b>254</b> from the communication network are routed to the receiver <b>250</b>, which provides signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital signal conversion. Analog to digital conversion of the received signal allows the resulting digital signal to be decoded by the DSP <b>260</b>. Signals to be transmitted to the network are processed (e.g., modulated, encoded, etc.) by the DSP <b>260</b> and are then provided to the transmitter <b>252</b> for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the communication network via the antenna <b>256</b>.

0036In some implementations, the mobile device <b>200</b> can send and receive communication signals over the wireless network after wireless network registration or activation procedures have been completed. The wireless network registration or activation procedures for the mobile device <b>200</b> may vary based on the type of network or networks with which the mobile device <b>200</b> operates. Wireless network access for the example mobile device <b>200</b> shown in <figref idref="DRAWINGS">FIG. 2</figref> is associated with a subscriber or user of the mobile device <b>200</b>. In particular, the SIM/RUIM card <b>226</b> in the SIM/RUIM interface <b>228</b> identifies the subscriber or user of the mobile device <b>200</b>. With the SIM/RUIM card <b>226</b> in the SIM/RUIM interface <b>228</b>, a subscriber can access all subscribed services through the wireless network. For example, subscribed services may include web browsing, e-mail, voice mail, Short Message Service (SMS), Multimedia Messaging Services (MMS), and/or others. The SIM/RUIM card <b>226</b> in the SIM/RUIM interface <b>228</b> communicates with the microprocessor <b>202</b> on the mobile device <b>200</b>. To identify the subscriber, the SIM/RUIM card <b>226</b> may include user parameters, such as an International Mobile Subscriber Identity (IMSI) and/or another type of subscriber identifier. The SIM/RUIM card <b>226</b> may store additional and/or different subscriber information, including calendar information, call log information, contacts information, and/or other types of information. Additionally or alternatively, user identification information can also be stored in the non-volatile memory <b>208</b>.

0037The data port <b>214</b> may include a serial port, a parallel port, and/or another type of connection port. In some implementations, the data port <b>214</b> is a Universal Serial Bus (USB) port that includes data lines for data transfer and a supply line that can provide a charging current to charge the battery <b>230</b> of the mobile device <b>200</b>. The mobile device <b>200</b> may be manually synchronized with a host system, for example, by connecting the mobile device <b>200</b> through the data port <b>214</b> (e.g., in an interface cradle and/or another type of wired connection) that couples the mobile device <b>200</b> to a data port of a computer system or other device. The data port <b>214</b> may also be used to enable a user to set preferences through an external device or software application, or to download other programs for installation. The wired connection of the data port <b>214</b> may be used to load an encryption key onto the device, which may be more secure method than exchanging encryption information via the wireless network.

0038The short-range communications subsystem <b>222</b> provides for communication between the mobile device <b>200</b> and different systems or devices, without the use of the wireless network. For example, the short-range communications subsystem <b>222</b> may include an infrared or radio frequency device and associated circuits and components for short-range communication. Examples of short-range communication standards include standards developed by the Infrared Data Association (IrDA), BLUETOOTH®, the 802.11 family of standards developed by IEEE, and others.

0039The microprocessor <b>202</b> manages and controls the overall operation of the mobile device <b>200</b>. Many types of microprocessors or microcontrollers may be used. Additionally or alternatively, a single DSP <b>260</b> may be used to carry out one or more functions of the microprocessor <b>202</b>. Low-level communication functions, including data and voice communications, may be performed through the DSP <b>260</b> in the communication subsystem <b>204</b>. High-level communication applications, such as voice communication applications, data communication applications, and/or other types of software applications may be stored in the non-volatile memory <b>208</b> for execution by the microprocessor <b>202</b>. The microprocessor <b>202</b> also interacts with other device subsystems, such as the display <b>210</b>, the RAM <b>206</b>, the auxiliary input/output (I/O) devices <b>212</b>, the data port <b>214</b>, the keyboard <b>216</b>, the speaker <b>218</b>, the microphone <b>220</b>, the SIM/RUIM interface <b>228</b>, the battery interface <b>232</b>, the short-range communications subsystem <b>222</b>, and any other device subsystems generally designated as <b>224</b>.

0040The non-volatile memory <b>208</b> includes erasable persistent storage, for example, flash memory, battery-backed-up RAM, and/or other types of memory. In the example shown in <figref idref="DRAWINGS">FIG. 2</figref>, the non-volatile memory <b>208</b> stores instructions and data associated with an operating system <b>234</b>, programs <b>236</b> that provide various types of functionality for the mobile device <b>200</b>, and other types of information. The non-volatile memory <b>208</b> may include a file system to facilitate storage of data items on the device. For example, the operating system <b>234</b>, the programs <b>236</b>, and/or other modules executed on the microprocessor <b>202</b> may store, retrieve, modify, delete, and/or otherwise manipulate data by accessing (e.g., read, write, etc.) the file system provided on the non-volatile memory <b>208</b>.

0041Data stored in the non-volatile memory <b>208</b> and/or other computer-readable media on the mobile device <b>200</b> may include user application data, text files, image files, voicemail data, and other data generated by the user at the mobile device <b>200</b> or received and stored by the mobile device <b>200</b>. The user application data may include, for example, e-mail message data, address book data, contact information data, calendar appointment data, instant message data, SMS message data, voicemail data, user-entered data, and/or other types of application data. Voicemail data may include digitized audio recordings and/or stub entries available for viewing in a messaging application indicating the availability of a voicemail message stored at another location. User-entered data may include text-based, graphic, or other multimedia files loaded onto the mobile device <b>200</b> by the user.

0042The operating system <b>234</b> controls low-level functions of the mobile device <b>200</b> and facilitates operation of the programs <b>236</b>. For example, the operating system <b>234</b> may provide an interface between one or more of the programs <b>236</b> and one or more hardware components on the mobile device <b>200</b>. The programs <b>236</b> include computer program modules that can be executed by the microprocessor <b>202</b> (and/or the DSP <b>260</b> in some instances). In some implementations, one or more of the programs <b>236</b> are executed by the microprocessor <b>202</b> and provide a high-level interface between a user and the mobile device <b>200</b>. The user interface provided by a program <b>236</b> typically includes a graphical component provided through the display <b>210</b>, and may additionally include an input/output component provided through the auxiliary I/O devices <b>212</b>, the keyboard <b>216</b>, the speaker <b>218</b>, and/or the microphone <b>220</b>. The operating system <b>234</b>, specific device applications or programs <b>236</b>, or parts thereof, may be temporarily loaded into a volatile store, such as RAM <b>206</b>, for faster operation. Moreover, received communication signals may also be temporarily stored to RAM <b>206</b> before they are permanently written to a file system in the non-volatile memory <b>208</b>.

0043The programs <b>236</b> stored in the non-volatile memory <b>208</b> may include, for example, a message application, a calendar application, one or more third party applications, and other types of applications. The programs <b>236</b> may include additional or different modules, programs, or applications, such as, for example, a Personal Information Manager (PIM) module, a connect module, a device state module, an IT policy module, a multi service platform manager, and/or others. The programs <b>236</b> may include programs that control basic device operations, which would typically be installed on the mobile device <b>200</b> during its manufacture and/or initial configuration. Other types of software applications, such as, for example, third party applications and/or other types of modules, may be added after the manufacture and initial configuration of the mobile device <b>200</b>. Examples of third party applications include games, utilities, internet applications, etc. Generally, any of the programs <b>236</b> may be updated and/or modified at any time. The additional applications and/or updates to applications can be loaded onto the mobile device <b>200</b> through the wireless network, the auxiliary I/O devices <b>212</b>, the data port <b>214</b>, the short-range communications subsystem <b>222</b>, or any other suitable device subsystem <b>224</b>. The non-volatile memory <b>208</b> may also store keys, which may include encryption and decryption keys and addressing information for use in communicating between the mobile device <b>200</b> and servers.

0044The non-volatile memory <b>208</b> can include an interrogator module. For example, the interrogator module can be implemented as a software module that is executed by the microprocessor <b>202</b>. The interrogator module can include the features and attributes of the interrogator module <b>108</b> of <figref idref="DRAWINGS">FIG. 1</figref>, or a different type of interrogator module. The interrogator module of the mobile device <b>200</b> can communicate with accessories of the mobile device <b>200</b>, for example, to authenticate the accessories. In some instances, the interrogator module authenticates the battery <b>230</b>, the SIM card and/or other internal or external components or devices associated with the mobile device <b>200</b>. As such, the battery <b>230</b>, the SIM card and/or other internal or external components or devices may include an authentication module, such as the authentication module <b>104</b> of <figref idref="DRAWINGS">FIG. 1</figref> or a different type of authentication module.

0045In some examples, the battery <b>230</b> includes an authentication module that communicates with the interrogator module by voltage-modulated signals transmitted through a terminal of the battery interface <b>232</b>. For example, the battery <b>230</b> may send the microprocessor <b>202</b> an authentication request, receive a challenge message from the microprocessor <b>202</b>, and send the microprocessor <b>202</b> a reply message by voltage-modulated signals transmitted through the battery interface <b>232</b>. The microprocessor <b>202</b> can convert the voltage-modulated signals from the battery <b>230</b> to messages that can be processed by the interrogator module. Similarly, the microprocessor <b>202</b> can convert the messages from the interrogator module to voltage-modulated signals that are transmitted to the battery <b>230</b>.

0046The schematic diagram in <figref idref="DRAWINGS">FIG. 3</figref> illustrates example techniques for managing authentication data for the authentication device during the manufacturing process <b>300</b>. The manufacturing process <b>300</b> may include the same, additional or different operations performed in the order shown or in a different order. The manufacturing process <b>300</b> can be used for manufacturing any number of identical, similar, or diverse types of products. For example, the manufacturing process <b>300</b> can be used for mass production, customized production, and other types of production. The product <b>318</b> can include a single component, or the product <b>318</b> can include multiple product components in addition to the product component <b>316</b> shown.

0047Implementations of the example manufacturing process <b>300</b> may include various conventional manufacturing techniques and sub-processes that are not specifically shown or described. For example, various implementations of the manufacturing process <b>300</b> may include material processing operations, fabrication operations, assembly operations, formatting operations, build operations, and other types of manufacturing operations. A particular example of a product that can be manufactured by the example manufacturing process <b>300</b> is a mobile device battery. Although certain aspects of the manufacturing process <b>300</b> are described with respect to the particular example of a mobile device battery, the manufacturing process <b>300</b> can be utilized for any other type of product that includes or otherwise utilizes an authentication device. Examples of other types of products include other types of accessories or components for mobile devices, printing systems, imaging systems, gaming systems, and others.

0048As shown in <figref idref="DRAWINGS">FIG. 3</figref>, the manufacturing process <b>300</b> involves operations and interactions of multiple entities: a product manager <b>302</b>, an authentication device manufacturer <b>306</b>, a product manufacturer <b>304</b>, and a component manufacturer <b>308</b>. The product manager <b>302</b> is concerned with the secure production of the product <b>318</b> by the product manufacturer <b>304</b>. In some implementations, the product manager <b>302</b> is a contracting company, and the product manufacturer <b>304</b> is the contracted manufacturer.

0049The product manufacturer <b>304</b> employs the component manufacturer <b>308</b> to produce components of the product <b>318</b>. In some implementations, the product manufacturer <b>304</b> is the contracted manufacturer (contracted by the product manager <b>302</b>), and the component manufacturer <b>308</b> is a sub-contracted manufacturer. For example, where the product <b>318</b> is a mobile device battery, the product manager <b>302</b> can be the mobile device company that distributes the mobile device batteries, the product manufacturer <b>304</b> can be the battery manufacturer, the authentication device manufacturer <b>306</b> can be a semiconductor manufacturer, and the component manufacturer <b>308</b> can be a circuit manufacturer. The component manufacturer <b>308</b> or the authentication device manufacturer <b>306</b> may implement a lower level of information security assurance, for example, than the product manufacturer <b>304</b>.

0050In some implementations, the product manager <b>302</b> provides product specifications to the product manufacturer <b>304</b>, and the product specifications include specifications regarding the authentication device <b>314</b>. The authentication device manufacturer <b>306</b> produces the authentication device <b>314</b>, which is incorporated into the product <b>318</b> at the product manufacturer <b>304</b>. The product manager <b>302</b> may not fully trust one or more of the authentication device manufacturer <b>306</b>, the component manufacturer <b>308</b>, the product manufacturer <b>304</b>. As such, the product manager <b>302</b> may not want the authentication device manufacturer <b>306</b> to be able to produce a functioning version of the authentication device <b>314</b> without approval from the product manager <b>302</b>. Moreover, the product manager <b>302</b> does not want the product manufacturer <b>304</b> to be able to overproduce a valid product <b>318</b>. Similarly, the product manager <b>302</b> does not want the authentication device manufacturer <b>306</b> or the component manufacturer <b>308</b> to be able to divert valid authentication devices to counterfeit markets.

0051In the example shown in <figref idref="DRAWINGS">FIG. 3</figref>, encrypted authentication data <b>310</b><i>a </i>are delivered to the authentication device manufacturer <b>306</b>. The authentication device <b>314</b> may have a serial number or other identifying information. The identifying information and authentication data are injected into the authentication device <b>314</b> by the authentication device manufacturer <b>306</b>. The authentication device manufacturer <b>306</b> can inject a complete set of authentication data (e.g., private key, public key, certificate, etc.) into the authentication device <b>314</b>. All or part of the injected authentication data can include the encrypted authentication data <b>310</b><i>a</i>. The injected authentication data can also include authentication data that are not encrypted. The encrypted authentication data <b>310</b><i>a </i>can include encrypted key data (e.g., an encrypted public key value, an encrypted private key value, or both), encrypted certificate data, or any other type of authentication data in an encrypted format. For example, the encrypted authentication data <b>310</b><i>a </i>may include an encrypted version of all or part of the key data <b>113</b> or the certificate data <b>114</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. In some instances, the product manager <b>302</b> may trust the authentication device manufacturer <b>306</b> to produce the encrypted authentication data <b>310</b><i>a</i>, and in some instances the product manager <b>302</b> may wish to produce such encrypted material by itself or by another party.

0052Decryption data <b>312</b> are delivered to the product manufacturer <b>304</b>. For example, the decryption data <b>312</b> can be delivered over a secure communication channel, by courier, or by another secure information distribution scheme. Because the decryption data <b>312</b> are typically smaller in size than the authentication data, the amount of data transferred to the product manufacturer <b>304</b> may be substantially less than the amount of authentication data on the authentication device <b>314</b>. In some examples, the decryption data <b>312</b> can be delivered to the product manufacturer <b>304</b> by a low-speed secure communication technique. The decryption data <b>312</b> include the information needed to decrypt the encrypted authentication data <b>310</b><i>a</i>. For example, the decryption data <b>312</b> may include a secret key value. As another example, if the authentication data include a certificate (such as an ECQV implicit certificate) that is reconstructable from a secret value, then the decryption data <b>312</b> may include the secret value needed to reconstruct the certificate.

0053The authentication device manufacturer provides the authentication device <b>314</b> to the component manufacturer <b>308</b>. The component manufacturer <b>308</b> manufactures the component <b>316</b>, which includes the authentication device <b>314</b>. The component manufacturer <b>308</b> provides the component <b>316</b> to the product manufacturer <b>304</b>. In the example shown in <figref idref="DRAWINGS">FIG. 3</figref>, the authentication data stored on the authentication device <b>314</b> includes the encrypted authentication data <b>310</b><i>a </i>before the authentication device <b>314</b> is provided to the product manufacturer <b>304</b>. As such, the authentication device <b>314</b> does not have the information resources need to generate a valid reply message before the authentication device <b>314</b> is provided to the product manufacturer <b>304</b>.

0054The product manufacturer <b>304</b> utilizes an information management system <b>305</b> to decrypt the encrypted authentication data <b>310</b><i>a </i>based on the decryption data <b>312</b>. Decrypting the encrypted authentication data <b>310</b><i>a </i>generates unencrypted authentication data <b>310</b><i>b</i>, which is then stored on the authentication device <b>314</b>. The encryption and decryption of the authentication data can be carried out, for example, based on a symmetric encryption scheme (e.g., AES, triple-DES, etc.), an asymmetric encryption scheme (e.g., ECC, RSA, etc.), or another type of encryption scheme. The number of decryption keys utilized can be determined by the product manager <b>302</b>. For example, the product manager <b>302</b> can allocate one or more decryption keys to a given product manufacturer <b>304</b> for a given period of time.

0055The information management system <b>305</b> generally includes a computing system that can securely store the decryption data <b>312</b> and decrypt the encrypted authentication data <b>310</b><i>a</i>. For example, the information management system <b>305</b> can include a hardware security module (HSM), or another type of computing device with cryptographic capabilities. The information management system <b>305</b> can include an information storage sub-system and information processing sub-system. The information storage sub-system can include a memory or another type of computer-readable medium that stores the decryption data <b>312</b> in a secure manner. The information processing sub-system can include data processing apparatus that performs decryption operations, for example, by evaluating a cryptographic function. In some instances, the information management system <b>305</b> implements some or all of the process <b>500</b> shown in <figref idref="DRAWINGS">FIG. 5</figref>, or another technique for managing authentication data. In some implementations, some or all of the information management system <b>305</b> is implemented by the product manager <b>302</b> or another entity other than the product manufacturer <b>304</b>. For example, instead of or in addition to providing the decryption data <b>312</b> to the product manufacturer <b>304</b>, the product manager <b>302</b> can retain the decryption data <b>312</b>. In such cases, all or part of the encrypted authentication data <b>310</b><i>a </i>can be decrypted by an information management system <b>305</b> at the product manager <b>302</b>. The information management system <b>305</b> may also retain log information on which authentication devices have been activated. The log information may be secured with the secure hardware associated with the authentication management system <b>305</b>. The log information may be made available for audit by the product manager <b>302</b>.

0056The information management system <b>305</b> can access the encrypted authentication data <b>310</b><i>a </i>stored on the authentication device <b>314</b>, generate the unencrypted authentication data <b>310</b><i>b </i>by decrypting the encrypted authentication data <b>310</b><i>a</i>, and store the unencrypted authentication data <b>310</b><i>b </i>on the authentication device <b>314</b>. The information management system <b>305</b> can include a communication interface adapted to access information stored on the authentication device <b>314</b>. For example, the authentication device <b>314</b> may include an interface such as the communication interface <b>116</b> of <figref idref="DRAWINGS">FIG. 1</figref>, and the information management system <b>305</b> can include a module adapted to communicate with the communication interface <b>116</b> or another interface of the authentication device. As another example, the information management system <b>305</b> may include a battery interface (e.g., similar to the battery interface <b>232</b> of the mobile device <b>200</b> in <figref idref="DRAWINGS">FIG. 2</figref>) adapted to communicate with a mobile device battery.

0057In the example shown in <figref idref="DRAWINGS">FIG. 3</figref>, the product manufacturer <b>304</b> manufactures the product <b>318</b> using the component <b>316</b> received from the component manufacturer <b>308</b>. The information management system <b>305</b> can then store the unencrypted authentication data <b>310</b><i>b </i>on the authentication device <b>314</b>, and the manufactured product <b>318</b> can be provided to the product manager <b>302</b>. Because the product <b>318</b> includes an authentication device <b>314</b> having a complete set of unencrypted authentication data when it leaves the product manufacturer <b>304</b>, the product <b>318</b> can be authenticated by an interrogator. For example, the authentication device <b>314</b> can generate a valid reply message upon interrogation by an interrogation device. In some implementations, the product <b>318</b> is incorporated into another product, sold individually, or disposed of in another manner.

0058In some aspects of the example shown in <figref idref="DRAWINGS">FIG. 3</figref>, the authentication device <b>314</b> can provide a communication pathway for the encrypted authentication data <b>310</b><i>a</i>. In some implementations, only part of the authentication data are encrypted. For example, the encrypted authentication data <b>310</b><i>a </i>may include only the certificate authority's signature on the certificate data, and additional non-encrypted authentication may be stored on the authentication device <b>314</b> by the authentication device manufacturer <b>306</b>. In some cases, encrypting less than all of the authentication data increase efficiency and provides information that can be used for tracking and control of the authentication device <b>314</b> without allowing the authentication device <b>314</b> to be used.

0059<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram showing an example process <b>400</b> for managing authentication data during a manufacturing process. Generally, the process <b>400</b> may be implemented in connection with any type of manufacturing process. For example, the process <b>400</b> may be implemented as part of the manufacturing process <b>300</b> shown in <figref idref="DRAWINGS">FIG. 3</figref>, or as part of a different type of manufacturing process.

0060The example process <b>400</b> is described with regard to manufacturing a product that includes multiple components, and the components are provided by component manufacturing entities. For example, the product can be a mobile device battery or another type of accessory for a mobile device. In the example of a mobile device battery, the product components can include battery cells, a battery console, a battery interface, a battery chip, a battery authentication device, or any combination of these and other components of a mobile device battery. In some implementations, the process <b>400</b> can be adapted for use in connection with manufacturing of other types of products or generally any article of manufacture. For example, the product can be a battery or another type of component for an electronic device, an appliance, a vehicle, a computing system, a consumer product, etc. The process <b>400</b> may include the same, additional, or different operations performed in the order shown, and/or in a different order. One or more of the operations may be repeated, iterated, or omitted, as appropriate in various implementations. In some implementations, one or more of the operations in the process <b>400</b> is iterated, for example, until a terminating condition is reached.

0061The example process <b>400</b> shown in <figref idref="DRAWINGS">FIG. 4</figref> includes operations performed by three example entities involved in a manufacturing process. The first entity is the product managing entity <b>402</b> that is responsible for the product. The second entity is the product manufacturing entity <b>404</b> that is responsible for manufacturing the product and providing the manufactured product to the product managing entity <b>402</b>. The third entity is the component manufacturing entity <b>406</b> who is responsible for providing a product component to the manufacturing entity <b>404</b>. The component provided by the component manufacturing entity <b>406</b> includes an authentication device. For example, the component manufacturing entity <b>406</b> may provide the authentication device as an individual component, or the component manufacturing entity <b>406</b> may provide a component that includes the authentication device. The process <b>400</b> may be implemented by a different number of entities, including additional or different types of entities, as appropriate in various manufacturing processes.

0062At <b>410</b>, the product managing entity <b>402</b> obtains product authentication data. For example, the product authentication data may include certificate data, key data, or another type of authentication data. In some implementations, obtaining the product authentication data includes generating certificate data or receiving certificate data from a certificate authority. In some implementations, obtaining the product authentication data includes deriving one or more values relating to a key pair or receiving one or more key pair values from a cryptographic module.

0063At <b>412</b>, the product managing entity <b>402</b> encrypts the product authentication data. In some implementations, another entity encrypts the product authentication data. For example, the product authentication data may be encrypted when they are obtained at <b>410</b>. The product authentication data can be encrypted using a key-based cryptographic scheme. For example, the product authentication data may be encrypted according to a symmetric encryption scheme, an asymmetric encryption scheme or another type of scheme. As such, the encrypted authentication data can be decrypted using a private key value, or another type of decryption data. At <b>420</b>, the encrypted product authentication data are sent to the component manufacturing entity <b>406</b>.

0064At <b>422</b>, the decryption data are sent to the product manufacturing entity <b>404</b>. The decryption data may include, for example, a secret value (e.g., a private key value) that can be used to decrypt the encrypted product authentication data, an identification of the encryption scheme used to encrypt the product authentication data (at <b>412</b>), the parameters of the encryption scheme used, or a combination of these and other data. For example, if the product authentication data are encrypted at <b>412</b> by an ECC encryption scheme using a public key value, the decryption data sent at <b>422</b> may include the private key value (that corresponds to the public key value) and an identification of the ECC parameters used for the encryption. In some instances, the decryption data are transmitted over a secure communication channel or otherwise securely transported to the product manufacturing entity <b>404</b>.

0065At <b>414</b>, the component manufacturing entity <b>406</b> obtains an authentication device. For example, the component manufacturing entity <b>406</b> may manufacture the authentication device, receive the authentication device from another entity, or obtain the authentication device in another manner. At <b>426</b>, the component manufacturing entity <b>406</b> stores the encrypted product authentication data on the authentication device. For example, the encrypted product authentication data may be stored in a memory or another type of computer-readable medium of the authentication device. The encrypted product authentication data may then be transported or communicated by transporting the authentication device itself.

0066At <b>432</b>, the product manufacturing entity <b>404</b> obtains product components to be included in the product. The product components may include components manufactured by the product manufacturing entity <b>404</b>, components manufactured by the component manufacturing entity <b>406</b>, or components manufactured by any combination of these and other entities. In the example shown in <figref idref="DRAWINGS">FIG. 4</figref>, the product manufacturing entity <b>404</b> obtains the authentication device from the component manufacturing entity <b>406</b>. For example, the product manufacturing entity <b>404</b> may obtain a product component, such as a printed circuit board or another type of component, that includes the authentication device, or the product manufacturing entity <b>404</b> may obtain the authentication device as an individual component.

0067At <b>434</b>, the product manufacturing entity <b>404</b> manufactures the product. The product may be manufactured by any type of manufacturing process or related operations. Some manufacturing processes include, for example, fabricating, building, formatting, or assembling components. Generally, manufacturing processes can include any combination of these and other types of manufacturing operations and sub-processes. Manufacturing processes may be performed in one or more locations by a single entity or by multiple different entities.

0068At <b>436</b>, the product manufacturing entity <b>404</b> decrypts product authentication data stored on the authentication device. For example, the product authentication data that were encrypted at <b>412</b> and stored on the authentication device at <b>426</b> can be decrypted at <b>434</b>. The product authentication data can be decrypted using the decryption data received at <b>422</b>. Storing the decrypted product authentication data on the authentication device can enable the authentication device to generate a valid reply message. For example, some authentication devices are configured to provide a reply message in response to receiving an interrogation message from an interrogation device, and the authentication device accesses or otherwise uses the authentication data to provide the reply message. Without the unencrypted authentication data, the authentication device may lack the informational resources (e.g., key data, certificate data, etc.) needed to provide a reply message that can be authenticated by the interrogation device. At <b>440</b>, the product manufacturing entity <b>404</b> provides the product to the product managing entity <b>402</b>.

0069In some implementations of the process <b>400</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>, all or part of the decrypting operation (at <b>436</b>) may be performed using the process <b>500</b> shown in <figref idref="DRAWINGS">FIG. 5</figref>. Although the decrypting operation <b>436</b> in <figref idref="DRAWINGS">FIG. 4</figref> is performed by the product manufacturing entity <b>404</b> after the product has been manufactured, all or part of the decrypting operation may be performed at other times and by other entities. For example, the product managing entity <b>402</b> may decrypt all or part of the authentication data. As another example, all or part of the authentication data may be decrypted after the manufacturing process has been completed, for example, after the product has reached a packaging facility, a distributor facility, a retail location, or an end user.

0070In some implementations of the process <b>400</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>, the same encrypted product authentication data can be stored on multiple different authentication devices. For example, the product managing entity <b>402</b> can obtain (at <b>410</b>) a single product authentication data set to be used with multiple different authentication devices. In such cases, the product authentication data set can be encrypted (at <b>412</b>) and sent (at <b>420</b>) to the authentication device manufacturing entity <b>406</b>, and the encrypted authentication data set can then be stored on multiple different authentication devices (at <b>426</b>).

0071In some implementations of the process <b>400</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>, different authentication data sets are encrypted using the same encryption scheme. For example, the product managing entity <b>402</b> can obtain (at <b>410</b>) different authentication data sets for different authentication devices, and the product managing entity <b>402</b> can encrypt (at <b>412</b>) all of the different authentication data sets using the same encryption key. In such cases, the encrypted authentication data sets can be sent (at <b>420</b>) to the authentication device manufacturing entity <b>406</b>, and each of the encrypted authentication data sets can be stored (at <b>426</b>) on a different authentication device.

0072Accordingly, in some implementations of the process <b>400</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>, the same decryption data may be used to decrypt the product authentication data stored on multiple different authentication devices. For example, the decryption data can be sent (at <b>422</b>) to the product manufacturing entity <b>404</b> and then used to decrypt (at <b>436</b>) the authentication data stored on multiple different authentication devices. In some implementations, the encrypted authentication data, the decryption data, or both are only used in relation to a single device.

0073<figref idref="DRAWINGS">FIG. 5</figref> is a flow chart showing an example process <b>500</b> for managing authentication data for an authentication device. The process <b>500</b> may be used to manage authentication data for a battery authentication device as described below. The process <b>500</b> may also be implemented with other types of authentication devices. For example, an authentication device for another type of product, component, or object of manufacture may be substituted for the battery authentication device in the process <b>500</b>. The process <b>500</b> may include the same, additional, or different operations performed in the order shown, and/or in a different order. One or more of the operations may be repeated, iterated, or omitted as appropriate.

0074In a particular example, the process <b>500</b> may be performed as part of a manufacturing process. The process <b>500</b> may be performed apart from a manufacturing process. For example, all or part of the process <b>500</b> may be implemented as a part of a packaging or shipping process, as a part of initializing or using a mobile device or a mobile device battery, or in connection with other types of processes. As such, the process <b>500</b> can be implemented in various types of contexts. For example, all or part of the process <b>500</b> can be implemented at a manufacturing facility, at a packaging facility, at a testing facility, at a shipping facility, at a retail location, at locations where the battery authentication device is used or installed, or in a combination of these and other locations. Accordingly, some or all of the operations in the process <b>500</b> may be performed in the same location or in multiple different locations.

0075At <b>502</b>, a battery authentication device is obtained. For example, the battery authentication device can be the authentication module <b>104</b> of <figref idref="DRAWINGS">FIG. 1</figref>, or another type of authentication device. The battery authentication device may be part of a mobile device battery or another type of battery. For example, the mobile device battery can be the battery <b>230</b> of <figref idref="DRAWINGS">FIG. 2</figref> or another type of battery.

0076When the battery authentication device is obtained at <b>502</b>, the battery authentication device contains encrypted authentication data. For example, the authentication device may include any type of memory or computer-readable medium that stores the encrypted authentication data. When the battery authentication device is obtained at <b>502</b>, the authentication device may include additional (non-encrypted) authentication data in addition to the encrypted authentication data. The encrypted authentication data may include, for example, certificate data, public key data, private key data, cryptographic function data, and/or other types of information.

0077The encrypted authentication data are authentication data that have been encrypted by any type of encryption scheme. For example, the authentication data may be encrypted by a key-based encryption scheme, including symmetric schemes, asymmetric schemes, and possibly other types of schemes. Examples of symmetric key schemes include AES, DES, and others. Examples of asymmetric key schemes include RSA, ECC, and others. A secret value may be required to decrypt the encrypted authentication data. For example, in some implementations the authentication data has been encrypted by an ECC scheme using a particular public key value, and the corresponding private key value is needed to decrypt the authentication data efficiently.

0078The authentication data that are encrypted on the authentication device include authentication data that the battery authentication device uses to provide a valid reply message when the battery is interrogated. As such, as long as the battery authentication device can only access the encrypted authentication data, the battery authentication device cannot provide a valid reply message upon interrogation. For example, if the authentication device cannot access unencrypted certificate data, then the authentication device cannot provide a reply message that includes a valid certificate. As another example, if the authentication device cannot access unencrypted key data, then the authentication device cannot generate a valid response value for a challenge value received from an interrogator.

0079At <b>504</b>, the encrypted authentication data are read from the battery authentication device. The encrypted authentication data may be read by a device or system external to both the battery authentication device and the mobile device battery. For example, an information management system may extract the encrypted authentication data from the battery authentication device. In some implementations, the encrypted authentication data are read from a memory of the battery authentication device through an interface of the mobile device battery. All or part of the encrypted authentication data can be preserved on the battery authentication device when the encrypted authentication data are read. All or part of the encrypted authentication data can be deleted from the battery authentication device when the encrypted authentication data are read.

0080At <b>506</b>, the encrypted authentication data are decrypted. Decrypting the encrypted authentication data generates unencrypted authentication data. The authentication data are decrypted using the decryption scheme corresponding to the encryption scheme used to encrypt the data. For example, the authentication data may be decrypted by a key-based encryption scheme. To the extent that a secret value (e.g., a secret key for a key-based encryption scheme) is needed for the decryption scheme, the secret value may be received separately from the battery authentication device. For example, the secret value may be delivered from a different source over a secure channel, and the secret value may be stored by an information management system.

0081At <b>508</b>, the decrypted authentication data are written to the battery authentication device. The decrypted authentication data can replace all or part of the encrypted authentication data on the battery authentication device. In some implementations, the encrypted authentication data can be preserved on the battery authentication device after the unencrypted authentication data has been written. Writing the decrypted authentication data to the battery authentication device enables the authentication device to provide a valid reply message when the battery is interrogated. In some cases, writing unencrypted certificate data to the battery authentication device may allow the authentication device to provide a reply message that includes a valid certificate. As another example, writing unencrypted key data to the battery authentication device may allow the authentication device to generate a valid response value for a challenge value received from an interrogator. In some implementations, the operations <b>504</b>, <b>506</b>, and <b>508</b> may be performed in an iterative fashion, where each iteration reads, decrypts, and writes a different block or segment of the authentication data.

0082The unencrypted authentication data can include at least part of the informational resources that the authentication device uses to generate a valid response when a mobile device interrogates the battery associated with the authentication device. For example, when the battery is coupled to a mobile device, the mobile device can interrogate the battery. If the battery authentication device provides a valid response to the interrogation, the mobile device can approve the battery for use. If the battery authentication device does not provide a valid response, the mobile device can reject the battery. For example, the mobile device may reject the battery for all purposes of battery use, the mobile device may reject the battery for all purposes other than a limited range of mobile device functionality (e.g., making emergency calls, etc.), or the mobile device may take another action. In some instances, the mobile device may report the rejected or non-authenticated battery to a trusted source.

0083The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources. The term “data processing apparatus” encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.

0084A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computing device or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

0085The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

0086Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computing device. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computing device are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computing device will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more storage devices for storing data. However, a computing device need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

0087To provide for interaction with a user, subject matter described in this specification can be implemented on a computer having a display device, e.g., an LCD (liquid crystal display) screen for displaying information to the user and a keyboard and a pointing device, e.g., touch screen, stylus, mouse, etc. by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computing device can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

0088Some of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computing device having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a data network.

0089The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a data network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some implementations, a server transmits data to a client device. Data generated at the client device can be received from the client device at the server.

0090While this specification contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular implementations. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

0091Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

0092In a general aspect of the present disclosure, encrypted authentication data are decrypted and stored on an authentication device. In some cases, the encrypted authentication data are accessed from the authentication device and replaced by the unencrypted authentication data, for example, to enable an operational aspect of the authentication device.

0093In some aspects, encrypted authentication data are stored on an authentication device. Unencrypted authentication data are generated by decrypting the encrypted authentication data. The unencrypted authentication data are stored on the authentication device to enable authentication device to provide a valid reply message. The authentication device is configured to generate the valid reply message in response to receiving an interrogation message from an interrogation device.

0094Implementations of these and other aspects may include one or more of the following features. The authentication data include certificate data. The authentication device is enabled during a manufacturing process. The manufacturing process includes receiving the authentication device having the encrypted certificate data stored thereon. The manufacturing process includes associating the authentication device with a particular article of manufacture prior to generating the unencrypted certificate data. The article of manufacture includes a mobile device component configured to be interfaced with a mobile device. The mobile device includes the interrogation device. The mobile device component includes a mobile device battery. The valid reply message includes the unencrypted certificate data and a proffered response value. The authentication device is configured to generate the proffered response value based on evaluating a cryptographic function using a secret value stored on the authentication device. The valid reply message further includes additional certificate data stored on the authentication device and not included in the unencrypted certificate data. A decryption key is received independent of accessing the encrypted certificate data. The encrypted authentication data are decrypted using the decryption key. The unencrypted certificate data include implicit certificate data.

0095In some aspects, encrypted authentication data stored on an authentication device associated with a mobile device battery are accessed. The mobile device battery is configured to provide electrical power to a mobile device and to receive an interrogation message from the mobile device. Unencrypted authentication data for the authentication device are generated by decrypting the encrypted authentication data. The unencrypted authentication data are stored on the authentication device associated with the mobile device battery. Storing the unencrypted authentication data on the authentication device enables the authentication device to provide a valid reply message in response to receiving the interrogation message from the mobile device.

0096Implementations of these and other aspects may include one or more of the following features. The authentication device is configured to generate a proffered response value based on a private key value associated with a public key value. The authentication device is configured to include the proffered response value in the valid reply message. The unencrypted authentication data include all or part of the private and/or public key data. The authentication device is configured to include certificate data in the valid reply message. The certificate data certify the public key value corresponding to the private key that is used to generate the proffered response value. The unencrypted authentication data include all or part of the certificate data. The unencrypted certificate data include all or part of an implicit certificate or an explicit certificate. The implicit certificate is an ECQV implicit certificate. The unencrypted certificate data include a public key reconstruction value of the implicit certificate.

0097Additionally or alternatively, implementations of these and other aspects may include one or more of the following features. A decryption key is received independent of accessing the encrypted authentication data, and the encrypted authentication data are decrypted using the decryption key. The decryption key is used to decrypt the encrypted authentication data according to a symmetric encryption scheme, an asymmetric encryption scheme, or a combination. The unencrypted authentication data are stored on the mobile device battery before the mobile device battery is coupled to the mobile device. The unencrypted authentication data are stored on the authentication device during a battery manufacturing process. The battery manufacturing process includes receiving, at a first manufacturing entity, the authentication device previously manufactured by a second manufacturing entity. The authentication device received from the second manufacturing entity has the encrypted certificate data stored thereon. The battery manufacturing process includes associating, at the first manufacturing entity, the authentication device with the mobile device battery.

0098Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.