Patent Application
20050137889
Often in the physical world, people carry objects that give permissions, but they do not have the ability or authority to modify or duplicate the permissions. In some cases, there is not even an ability to examine the contents of these objects, nor are individuals aware of (nor care) about the contents. Examples include a subscriber identity module (SIM) card used in a cellular telephone, or a magnetic stripe on subway tickets. These objects act as tickets that grant access, in one case to a cellular network, in the other case to a subway.
In the digital world, it is convenient to be able to construct these types of objects for use. Several cryptographic techniques have been used to create non-forgeable tokens. Such tokens are used in certain computing platforms to limit access of the platform to a given user. A need exists to remotely bind data such as a token to a user device while preventing improper access to the token, even by the device user.
Referring to
A remote agent may be a ticket granting agent, in one embodiment. Alternately, a remote agent may be a rights management agent. Such a ticket granting agent may be an agent associated with an activity or facility to which a ticket or other authorization is needed for access, such as a sporting event, movie, play, digital content usage, airplane flight, or any other such facility or activity. As used herein, “activity” is used broadly to refer to any event, procedure, pursuit, transportation, mechanism, usage, facility and the like.
In various embodiments, the request may be provided from a user device. While such a user device may vary in different embodiments, in certain embodiments, a user device may be a mobile device such as a third generation (3G) cellular telephone. Alternately, the user device may be a personal digital assistant (PDA), a portable computer or the like. In other embodiments the user device may be a personal computer, server computer, set-top box, and the like. The request may be sent in one of a variety of protocols such as Internet Protocol (IP), Transmission Control Protocol/Internet Protocol (TCP/IP), Extensible Markup Language (XML), or the like.
In various embodiments, the user device may include a Trusted Platform Module (TPM) in accordance with the Trusted Computing Platform Alliance (TCPA) Main Specification Version 1.1b, published Feb. 22, 2002 (the “TCPA specification”). Alternately, another such trusted or secure module may be included in a user device.
As used herein, the term “TCPA TPM” refers to protocols and activities associated with one or more TCPA specifications, while the term “TPM” refers generically to a trusted or secure module. Using such a TPM, reliable information may be provided about itself and its current hardware and software processes, and provide attestation to operation of its processes.
In one embodiment, the TPM may be embedded in the user device, and the user of the device has access to a storage root key (SRK), at least one attestation identity key (AIK), and a personal storage key (i.e., a user's key).
Next, a migratable key (e.g., a storage key) may be securely exported to the remote agent (block 30). Such a migratable key may be, for example, a wrap key created in accordance with TCPA TPM commands. The key may be extracted securely in a migratable blob and shipped to the remote agent.
Upon receipt of the migratable key, a ticket granting agent may change the authentication value of the migratable key in a secure manner (block 40). Then the remote agent may create a token using the key it received from the user device through migration (block 50).
This token may be encrypted and sent to the user device for storage in an encrypted manner (block 60). Via such encryption, the token may be bound to the user device and remain protected from modification, duplication, and other unauthorized access. In such manner a device user may thus give control over a portion of the device (i.e., the token) to a third party.
At a later time, when a user of the device desires to redeem the token for access to a desired activity, the user may provide the encrypted token to a redemption agent (block 70). Such a redemption agent may be an agent associated with the activity or facility, and may be the same or different entity than the remote granting agent discussed above. When the redemption agent verifies the encrypted token, the user may be provided access to the activity or facility (block 80).
While discussed above as relating to electronic tickets, it is to be understood that in other embodiments, a token may be created and used for other secure purposes, such as access to secure locations, electronic devices or secure storage contained therein. For example, using an embodiment of the present invention, digital content securely stored on a user device (pursuant to a user request) may be accessed by the user. Such digital content may be, for example, distributed software, digital content, such as movies, programming, music, electronic books, and the like.
Referring now to
Next, a migratable key may be created in the mobile device (block 120). In one embodiment, such a migratable key may be created in accordance with commands in compliance with TCPA TPM specifications (“TCPA TPM commands”). For example, a TPM_CreateWrapKey command may be used. This ticket key may be a storage key, encrypted using Rivest Shamir Adelman (RSA) or Advanced Encryption Standard (AES) cryptographic algorithms, in certain embodiments. The migratable key may be sent to a ticket granting agent via a migratable blob generated by the mobile device (block 130). In one embodiment, a TPM_CreateMigrationBlob command may be used to create the migratable blob.
Still referring to
In certain embodiments, to ensure that the key is not tampered with before the authentication value has changed, the ticket granting agent may perform one or more audits of the mobile device. For example, the ticket granting agent may audit the mobile device upon receipt of a ticket request to check actions performed on the TPM of the mobile device, ensuring that the user did not migrate the key to anyone else (including themselves). In one embodiment, a TPM_GetAuditEventSigned command may be used. A similar such audit may be performed by the remote ticket granting agent after changing the authorization value of the migratable key, in one embodiment using the same audit command as above. In other embodiments, other actions of the TPM may be audited to confirm security. After such audits are completed, the ticket granting agent can ensure that the key in the TPM was properly created, and only the ticket granting agent has access to the key itself. These properties may be guaranteed by the TPM. The ticket granting agent may then use this key to protect data and bind it to the TPM of the mobile device.
Next, the ticket granting agent may create an electronic ticket (block 150). The ticket may be created using the migratable key received from the TPM of the mobile device. In various embodiments, the ticket may be created such that upon delivery to the mobile device, it is bound to the TPM and is protected from modification and/or duplication. That is, access to the ticket may be restricted only to the user who requested the ticket and only upon compliance with certain conditions (e.g., time and place). Similarly, in embodiments relating to digital rights management, access to a token may be restricted to a given user and only upon compliance with conditions such as, for example, date and number of times the content may be accessed. In one embodiment, the ticket may be provided in three distinct parts: a ticket manifest; a ticket portion; and a ticket redemption stub.
The ticket manifest may be a non-redeemable ticket description, signed by the ticket granting agent, that describes what the actual ticket contains. This manifest may be accessed by a user of the mobile device, since the ticket itself is encrypted and may not be inspected by the user. In certain embodiments, the manifest may be signed in order to represent a legal contract that the actual ticket is equivalent to that which is represented in the manifest, and also to protect the manifest from unauthorized modification. The ticket itself may be signed by the ticket granting agent and encrypted using the key previously migrated to the ticket granting agent.
The ticket redemption stub may be used to authenticate the source of the TPM, and may contain the authentication value for the ticket key stored in the TPM, and a ticket identifier. In certain embodiments, the stub may also contain an AIK certificate that may be used to authenticate the TPM prior to ticket redemption. The ticket redemption stub may be encrypted with a public key of the ticket redemption agent, in certain embodiments. Alternately, a communication between a ticket granting agent and a ticket redemption agent may occur to verify that the ticket redemption stub is authentic.
Upon delivery to the mobile device, the electronic ticket may be bound to the TPM of the device (block 160). While the manner of such binding may vary in different embodiments, in one embodiment binding may occur in accordance with the TPM TCPA specification.
Referring now to
The redemption agent may first determine whether appropriate conditions exist to redeem the electronic ticket (diamond 210). For example, based on the ticket request for redemption, it may be determined whether appropriate time, date and/or location conditions have been met. If such conditions have not been met, the redemption agent may disapprove the request (block 215). If the conditions are met, the request may be approved (block 220).
Then the redemption agent may determine whether the mobile device that sent the request is a trusted platform (diamond 225). For example, the redemption agent may perform various checks or audits on data, keys and the like to determine that the mobile device contains an authentic TPM. In one embodiment authentication may proceed by requesting a TPM_Quote using a nonce value. In response, the TPM may produce the requested quote and send the quote information to the ticket redemption agent. If the agent believes the TPM is authentic based on checking the quote data, and the AIK used to sign the quote data is the same AIK as provided in the ticket redemption stub, then this confirms the TPM device that was issued the ticket is conversing with the redemption agent, and thus may be authenticated. If it is determined that the device is not authentic, the request may be disapproved (block 230).
If the device is approved, an unbind request may be sent to the mobile device using an authentication value (block 235). Specifically, in one embodiment the agent may construct a TPM_Unbind request using the authentication value retrieved from the decrypted ticket stub. The user may then decrypt the key using the authentication on the parent key, authenticating that the user is redeeming the key to the TPM. The TPM then decrypts the ticket using the authentication value and returns the decrypted ticket to the user (block 240). Next, the decrypted ticket key may be sent to the redemption agent (block 250).
Still referring to
In various embodiments, when the redemption agent provides a TPM_Unbind request to the TPM, the ticket may be considered redeemed and invalid for further use. This is because the ticket can be decrypted by the user once the TPM_Unbind request is issued. If the user decrypts the ticket and does not return it to the ticket redemption agent, it is possible to duplicate the ticket (because it is now decrypted). Thus by considering the ticket to be redeemed at this point prevents an early redemption attempt that does not return the ticket to the redemption agent, and then duplicates the ticket.
Thus, if a duplication attack is discovered, it can be shown that the user had to collude in such an attempt since the both the AIK used for the TPM_Quote and the user key that is the parent of the ticket key had to be accessed. Access to both these keys requires an authentication value known only to the user.
Embodiments may be implemented in a computer program. As such, these embodiments may be stored on a storage medium having stored thereon instructions which can be used to program a computer system to perform the embodiments. For example, one or more programs in accordance with an embodiment of the present invention may be stored in a trusted software stack (TSS), or other software supporting a TPM. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, magnetic or optical cards, or any type of media suitable for storing electronic instructions. Similarly, embodiments may be implemented as software modules executed by a programmable control device, such as a computer processor or a custom designed state machine.
Also coupled to internal bus 420 may be a trusted module 445. In one embodiment, trusted module 445 may be permanently bonded to a motherboard of mobile device 400. Trusted module 445, which may be a general purpose processor, ASIC, or the like, may have basic so-called “smart card” capabilities. In certain embodiments, these capabilities may include cryptographic abilities such as keys, storage, signing, and encryption as set forth in the TCPA specification. In various embodiments, trusted module 445 may be used for attestation and sealing/unsealing of tokens.
While shown in
As shown in
In certain embodiments, wireless interface 470 may support General Packet Radio Services (GPRS) or another data service. GPRS may be used by wireless devices such as cellular phones of a 2.5G (generation) or later configuration. GPRS may be provided on existing time division multiple access (TDMA) or Global System for Mobile Communication (GSM) networks, for example. Other embodiments of the present invention may be implemented in a circuit switched network such as used by 2G technologies, a Personal Communications System (PCS) network, a Universal Mobile Telecommunications System (UMTS), or UMTS Telecommunications Radio Access (UTRA) network or other communication schemes, such as a BLUETOOTH™ protocol or an infrared protocol (such as Infrared Data Association (IrDA)).
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.
