Patent Application
20070042754
Embodiments of the present invention relate to trusted computer platforms, and more specifically to security parameter provisioning for trusted platforms within a 3rd Generation (3G) network.
The 3GPP Technical Specification 33.220 V6.0.0 provides for a generic bootstrapping architecture (GBA). The GBA infrastructure may be used to enable application functions in the network and on the user side to establish shared keys. Thus, a 3GPP operator can provide bootstrapping of application security to authenticate the subscriber.
A network model for bootstrapping is illustrated in
The Network Application Function (NAF) represents a generic network application function which may provide one or more applications or services to the User Equipment (UE) (106). The UE may include Mobile Equipment (ME), Terminal Equipment (TE), and a Subscriber Identity Module (SIM).
The BSF (104) and the NAF (108) interface via the Zn interface. Finally, the NAF (108) and the UE (106) interface via the Ua interface.
The requirements for each network element and each interface are set forth in the 3GPP Technical Specification 33.220 V6.0.0.
As mobile computing becomes more prevalent, there is a need for providing a secure, 3GPP compliant interface between secure applications running on a platform and a Subscriber Identity Module (SIM) or a UMTS Subscriber Identity Module (USIM).
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
In the following description, for purposes of explanation, numerous details are set forth in order to provide a thorough understanding of embodiments of the present invention. However, it will be apparent to one skilled in the art that these specific details are not required in order to practice the present invention as hereinafter claimed.
Embodiments of the present invention concern security parameter provisioning for 3G networks. Although the following discussion centers on 3G networks, it will be understood by those skilled in the art that the present invention as hereinafter claimed may be practiced in support of any type of network having similar protocol requirements. For example, embodiments of the present invention may be used with future network protocols including B-3G (beyond-3G) networks. Embodiments may also be applies to any network/capabilities built on top of 3G or beyond networks, including S3G, High-Speed Downlink Packet Access (HSPDA), and others.
Reference throughout this specification to “one embodiment” or “an embodiment” indicates that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
A system may include a Home Subscriber System (HSS) (202), a Bootstrapping Server Function (BSF) (204), a computing device or platform (208), and a SIM (206), which may be a Universal Mobile Telecommunications System (UMTS) SIM (USIM).
The Home Subscriber System (HSS) (202) interfaces with the Bootstrapping Server function (BSF) (204) via the Zh interface.
The BSF (204) is communicatively coupled to the SIM (206) through the Ub interface. This interface may be a wired or wireless interface. The Ub interface is defined by the 3GPP Generic Bootstrapping Architecture (GBA) Specification. The BSF (204) and the SIM (206) run the 3GPP GBA protocol to generate a shared key, Ks. The shared key, Ks, is sent from the BSF to the SIM. The SIM uses the shared key, Ks to generate a platform shared secret key (210), which is used to ensure security on the Ua interface, thus enabling a trusted channel (212) between the SIM (206) and the platform (208).
The platform (208) may be a substitute for a Network Application Function (NAF), or may augment a NAF. In one embodiment, the platform may be a mobile computing device, such as a notebook computer, a handheld device, or a mobile telephone.
The platform may include a platform certificate (209), which contains information including but not limited to the manufacturer of the platform, the generation and stepping of microprocessor used in the platform, and the generation and stepping of the chipset used in the platform.
A trusted application (211) may run on the platform. In one embodiment, the platform may utilize Intel Corporation's LaGrande Technology (LT) to provide a secure environment for the trusted application.
The BSF (204) interfaces with the platform (208) or with a trusted application running on the platform (211) via the Zn interface. The Zn interface is typically an operator-specific or proprietary protocol. The Zn interface may allow a generic NAF, such as a trusted application (211) running on a platform, to fetch the key agreed to by the BSF (204) during a previous GBA protocol transfer over the Ub interface between the BSF (204) and the SIM (206). Thus, the platform may receive the shared key, Ks, from the BSF (204) over the Zn interface. The transfer of Ks over the Zn interface is described in more detail below, in conjunction with
After the platform (208) receives the shared key, Ks, from the BSF (204), the platform generates a platform shared secret key (210). The platform shared secret key generated by the platform and the SIM are the same, and are used to secure the Ua interface, thus enabling a trusted channel (212) between the SIM (206) and the platform (208).
First, the BSF (302) and the SIM (304) run the 3GPP GBA protocol to generate a shared key (310) at both the BSF and the SIM.
Next, the BSF (302) runs a challenge/response protocol (312) with a trusted application running on a platform (306). The challenge/response protocol may be a proprietary protocol determined by a mobile network operator (MNO). The challenge/response protocol is used to determine the trustworthiness of the trusted application prior to authentication of the platform. In one embodiment, the platform may be a mobile computer, such as a notebook. The platform may be a secure platform, for example, an Intel® notebook computer with LaGrande Technology, which is running a trusted application.
After successful completion of the challenge/response protocol (312), the BSF authenticates the platform (314) and determines the trustworthiness of the platform's hardware and software environment. In one embodiment, the trustworthiness may be checked using the LaGrande Technology (LT) attestation process, which is described in detail below in conjunction with
When the platform has been authenticated by the BSF, the BSF transfers the shared key to the platform (316). The shared key is sealed to the platform's hardware and software environment that was deemed trustworthy by the BSF during the authentication process (314).
Finally, after both the SIM (304) and the platform (306) have received a shared key from the BSF, the SIM runs a key derivation function to generate a platform shared secret key (318) and the platform runs a key derivation function to generate a platform shared secret key (320). The platform shared secret key derived by the SIM and by the platform is used to ensure trusted communications over the Ua interface between the platform or a trusted application on the platform and the SIM.
The BSF needs both static and dynamic information from the platform. Static information may include, but is not limited to, the manufacturer of the platform, the specific generation and stepping of the processor, and the specific generation and stepping of the chipset. Dynamic information may include, but is not limited to, the specific identity of a loaded virtual machine monitor (VMM), the specific identity of a loaded secure transfer monitor (STM), the specific identity of a Basic I/O System (BIOS) module, or other software, monitors, or modules that the BSF wants the platform to attest to.
The static information may be provided in the form of a platform certificate provided by the platform original equipment manufacturer (OEM). The dynamic information may gathered and reported each time an attestation request is received. The goal of the attestation process is for the BSF to be able to receive and verify the static and dynamic information in order to make a trust decision about provisioning the shared key into the platform.
To begin the attestation process, the platform (406) requests service (410) from the mobile network operator (MNO). The service request is routed to the MNO's BSF (402).
Upon receiving a service request, the BSF creates a nonce, which is used to prevent replay attacks, and sends the nonce and a request for attestation (412) to the platform.
When the platform receives the attestation request, it internally generates the necessary commands to gather the static and dynamic information required by the BSF for attestation. In one embodiment, the platform may generate trusted platform module (TPM) commands to retrieve the current platform configuration register (PCR) value (414).
The trusted platform module then creates a digital signature of the current PCR value (416). This digital signature may include the nonce received from the BSF. A private key may be used to provide the digital signature, and may be bound to the platform certificate, an attestation identity key (AIK), or other credentials, to protect privacy.
After the digital signature is created, it is sent from the platform to the BSF (418). The BSF verifies the digital signature (420), validates the nonce, and evaluates the information from the PCR provided in the digital signature to determine if the platform is trustworthy. In one embodiment, determining whether the platform is trustworthy may include comparing a PCR value to a list or database containing one or more known good PCR values.
If the platform is deemed trustworthy (e.g. if the PCR value from the platform matches a known good PCR value), then the BSF transfers the shared key to the platform (422).
The platform may seal the shared key to the PCR value (424). This ensures that each time the shared key is accessed within the notebook, the original environment represented by the PCR to which the shared key was sealed must be present. Thus, the shared key will no longer be valid if the PCR value changes.
Thus, a method, apparatus, and system for provisioning a platform shared secret key to enable a trusted channel between an application running on a platform and a SIM are disclosed. In the above description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description. Embodiments have been described with reference to specific exemplary embodiments thereof. It will, however, be evident to persons having the benefit of this disclosure that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments described herein. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
