TW201741925A - Staged control release in boot process - Google Patents

Abstract

Integrity validation of a network device may be performed. A network device comprising a secure hardware module, may receive a root key. The secure hardware module may also receive a first code measurement. The secure hardware module may provide a first key based on the root key and the first code measurement. The secure hardware module may receive a second code measurement and provide a second key based on the first key and the second code measurement. The release of keys based on code measurements may provide authentication in stages.

Description

Stage control release in the hole opening procedure

Cross-reference to related applications. The present application is based on and claims priority to U.S. Provisional Patent Application Serial No. 61/323,248, filed on Jun. It is considered to be fully joined here.

Traditional security methods can allow for binary decisions on resource release, such as a single key for authentication based on a successful, securely initiated reset. A problem can occur if there is no successful safe start after the reset.

A system, method, and instrumentality is disclosed to perform integrity verification of a network device. The network device can include secure memory. For example, secure memory can be included in a secure hardware module. The secure memory can receive the root key. For example, the root key can be received by secure memory at the time of manufacture or provisioning. The root key can be stored in secure memory and is not software or hardware other than the secure hardware module. visible.

The secure hardware module can receive the first code measurement (measurement of the first code). For example, a processor (such as a processor associated with a network device including a secure hardware module) can select the first portion of the code to measure. The first portion of the code can be stored on a memory associated with the network device, such as ROM memory, RAM memory, and the like. The processor can measure a first portion of the code that results in the selection of the first code measurement. The processor can provide the measurement to the secure hardware module.

The secure hardware module can generate the first key based on the root key and the first code measurement. For example, the secure hardware module can obtain or release the first key. When the first code measurement is valid, the generated first key is valid, and when the first code measurement is invalid, the generated first key is invalid. For example, the secure hardware module can obtain the first key based on the first code measurement. If the first code measurement is invalid, the resulting first key is also invalid. The generated first key is generated by the secure hardware module to provide access to the resource. When the code is stored on the secure memory, access to the resource can be provided without code measurement.

The first key may be associated with a first phase of a trust associated with the first function (eg, one or more resources may be associated with the first function). Further, the first stakeholder can use the valid first key to access the first function. If the first key is invalid, the first stakeholder is not allowed To access the first function. That is to say, when the first code measurement is invalid, the secure hardware module can block access to the first function.

The secure hardware module can receive a second code measurement (measurement of the second code). The secure hardware module can generate a second key based on the first key and the second code measurement. The second key may be associated with a second phase of trust associated with the second function (eg, one or more resources may be associated with the second function). Further, the second stakeholder can use the valid second key to access the second function. The key release can be limited to the last known good start-up phase (for example, the last known start-up phase with successful authentication).

The generation and/or release of resources, such as keys and functions based on hardware, code, and/or data integrity measurements, may provide authentication in stages. For example, a device may include several layers, each layer having its own authentication secret. Each authentication secret may correspond to a particular stakeholder in the layer of device capabilities such as manufacturer firmware, trusted execution code, operating system, and third party applications. Further for example, the valid first key can be associated with valid authentication for the first startup phase. The valid first key can be used by a device manufacturer (eg, a first stakeholder) to access firmware on the network device to perform repairs on the firmware. The valid second key may be associated with valid authentication of one or more software components during a subsequent startup phase (eg, an intermediate startup phase). The valid second key can be used by the device manager (eg, the second stakeholder) Accessing the software component, for example, to perform repair of the software. By providing a valid key for each stage of successful authentication, access can be granted, which is comparable to the final stage without authentication failure.

The number of stages of multi-stage authentication disclosed herein may vary and is not limited. Further, multiple authentication paths can be provided. That is to say, at some stage of the integrity check, the authentication can be branched in different ways. For example, each stakeholder can provide one or more policies related to one or more certification phases. At each stage, authentication can be branched in different ways based on stakeholder policies. Stakeholders can manage their strategies externally.

100‧‧‧Long Term Evolution Wireless Communication System/Access Network

105. E-UTRAN‧‧‧Evolved Universal Terrestrial Radio Access Network

110, WTRU ‧ ‧ wireless transmitter receiving unit

120, eNB‧‧‧E-UTRAN Node B

130‧‧‧MME/S-GW

MME‧‧‧Mobility Management Entity

S-GW‧‧‧ service gateway

122. HeNB‧‧‧Home eNB

132. HeNB GW‧‧‧HeNB gateway

200‧‧‧LTE wireless communication system

LTE‧‧‧ Long-term evolution

214, 219‧‧‧ transceiver

216, 217, 233‧‧ ‧ processors

218, 221‧‧ antenna

220‧‧‧Battery

215, 222, 234‧‧‧ memory

TrE‧‧‧ Trusted Environment

DVF‧‧‧ device confirmation function

DAF‧‧‧ device authentication function

SPC_DA‧‧‧Safe handling capacity

Kpriv_DA‧‧‧ device certified private key

DevCert‧‧‧ device proof

ROM‧‧‧Read-only memory

KDF‧‧ phase specific key export function

RN‧‧‧ relay node

UE‧‧‧User equipment

OP‧‧‧ operator

DM‧‧‧Device Management

DeNB‧‧‧Supply to eNB

The invention can be understood in more detail from the following description, which is given by way of example with reference to the accompanying drawings.

1 is an exemplary Long Term Evolution (LTE) wireless communication system diagram; FIG. 2 is a block diagram of an exemplary LTE wireless communication system; FIG. 3 is a diagram showing an example apparatus having binding between device acknowledgment and device authentication; Figure 4 shows an example physical binding using authentication and integrity checking for the Common Trusted Environment (TrE); Figure 5 shows the device for confirmation and pre-shared secrets. Example of binding between cards; Figure 6 shows an example of confirmation and authentication based on pre-shared key; Figure 7 shows an example of binding caused by TrE permission conditional access; An example of binding between confirmation and proof-based device authentication is shown; Figure 9 shows an example of binding of validation and proof-based authentication; Figure 10 shows binding caused by TrE permission conditional access An example of the setting; Figure 11 shows an example of binding using a gating function; Figure 12 shows an example of performing authentication in a plurality of stages related to the example startup procedure; Figure 13A shows Example wafers that can be used to implement embodiments of the disclosed systems and methods; FIG. 13B illustrates an example wafer that can be used to implement embodiments of the disclosed systems and methods; FIG. 13C illustrates an example that can be used to implement the disclosure. Example wafer of an embodiment of the system and method; Figure 14 illustrates an example key derivation work Figure 15 shows an example key derivation detail, including a signature mechanism; Figure 16 shows an example multi-stage key derivation detail; Figure 17 shows an example startup sequence; Figure 18 shows an example startup sequence; An example startup sequence flow; Figure 19 shows an example network communication related to multi-stage authentication; Figure 20 shows an example startup and post-boot configuration procedure; Figure 21 shows an example that can be used to implement the disclosure An example wafer of an embodiment of the system and method; and FIG. 22 shows an example of extending the integrity check procedure to UE communication.

The drawings may relate to example embodiments in which the disclosed systems, methods, and tools may be implemented. However, although the invention is described in connection with the example embodiments, the invention is not limited thereto, and it should be understood that other embodiments may be used or modified and supplemented in the described embodiments so as not to The same function as the present invention. Some disclosed systems and methods can provide multi-stage security certification. Although the description generally refers to wireless devices and networks, the disclosed systems and methods And tools are not limited to this application, and are applicable to any suitable device, network, and/or system capable of implementing the disclosed authentication. Further, the multi-stage certification disclosed below may describe multi-stage authentication associated with activities in the startup phase. However, the description is for illustration, and the disclosed systems, methods, and tools are not limited to implementations of the startup phase. Multi-stage certification can be broadly applied to any appropriate multi-stage program.

As referred to hereinafter, the term "wireless transmit/receive unit (WTRU)" includes but is not limited to user equipment (UE), mobile station, advanced mobile station (AMS), station (STA), fixed or mobile subscriber unit, Pager, mobile phone, personal digital assistant (PDA), computer, or any other type of device that can operate in a wireless environment. The terms WTRU and UE are used interchangeably. As referred to hereinafter, the term "base station" includes but is not limited to Node-B, Advanced Base Station (ABS), Site Controller, Access Point (AP), Home Node B (HnB), or in a wireless environment. Any other type of peripheral device that is running in. The terms "WTRU" and "base station" are not mutually exclusive.

1 is an illustration of a Long Term Evolution (LTE) wireless communication system/access network 100 that includes an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 105. The EUTRAN 105 may include a plurality of E-UTRAN Node Bs (eNBs) 120, a Home eNB (HeNB) 122, and a HeNB Gateway (HeNB GW) 132. The WTRU 110 may communicate with the eNB 120, the HeNB 122, or both. The eNBs 120 can interface with each other using the X2 interface. Each eNB 120 and HeNB GW 132 can be mobility managed through the S1 interface. The interface of the entity (MME) / service gateway (S-GW) 130. The HeNB 122 can be the interface of the HeNB GW 132 through the S1 interface, the interface of the MME/S-GW 130 through the S1 interface, or the interface between the two. Although only one WTRU 110, one HeNB, and three eNBs 120 are shown in FIG. 1, it will be apparent that any combination of wireless and wired devices can be included in the wireless communication system/access network 100.

2 is an example block diagram of an LTE wireless communication system 200 that includes a WTRU 110, an eNB 120, and an MME/SGW 130. While eNB 120 and MME/S-GW 130 are shown simply, it will be apparent that examples of HeNB 122 and HeNB GW 132 may include substantially similar features. As shown in FIG. 2, WTRU 110, eNB 120, and MME/S-GW 130 may be configured to support a mobility induced power save mode.

In addition to the elements that can be found in a typical WTRU, the WTRU 110 may also include a processor 216 with optional link memory 222, at least one transceiver 214, an optional battery 220, and an antenna 218. Processor 216 can be configured to perform bandwidth management. Transceiver 214 can communicate with processor 216 and antenna 218 to facilitate the transmission and reception of wireless communications. An optional battery 220 can be used in the WTRU 110 to power the transceiver 214 and the processor 216.

In addition to the elements that can be found in a typical eNB, the eNB 120 may also include a processor 217 with an optional link memory 215, a transceiver 219, and an antenna 221. Processor 217 can be configured to perform bandwidth management. Transceiver 219 can communicate with processor 217 and antenna 221 to facilitate the transmission and reception of wireless communications. The eNB 120 can connect to the mobility management entity / A service gateway (MME/S-GW) 130, which may include a processor 233 with optional link memory 234.

The LTE network shown in Figures 1 and 2 is just one example of a particular communication network, and other types of communication networks can be used. A variety of implementations can be implemented in any wireless communication technology. Some examples of wireless communication technologies include, but are not limited to, Worldwide Interoperability for Microwave Access (WiMAX), 802.xx, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA2000), Universal Mobile Telecommunications System (UMTS), or any Future technology.

As referred to hereinafter, the term "macrocell" includes, but is not limited to, a base station, an E-UTRAN Node B (eNB), or any other type of interface device capable of operating in a wireless environment. As referred to hereinafter, the term "Home Node B (HNB)" includes, but is not limited to, a base station, a Home evolved Node B (HeNB), a femtocell, or any other type capable of operating in a closed subscriber group wireless environment. Interface device.

For the purposes of explanation, various embodiments are described in the Long Term Evolution (LTE) context, but these embodiments can also be implemented in any wireless communication technology. Some examples of wireless communication technologies include, but are not limited to, Worldwide Interoperability for Microwave Access (WiMAX), 802.xx, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA2000), Universal Mobile Telecommunications System (UMTS), or any Future technology.

The terms client and device can be used synonymously. In addition, the terms "device integrity confirmation", "device confirmation", and "confirmation" may also be used synonymously. "confirmation" can be a test A procedure for the integrity of a letter or computing part or all of a component. Some or all of the components may be, for example, hardware (HW), software (SW), firmware (FW), and/or configuration information. Device authentication may refer to a procedure in which the identity of a communication or computing device is verified against the authenticator for authenticity.

In the context of H(e)NB, a binding procedure can be performed, such as binding the result of the device integrity verification of the H(e)NB with the program or result of the device authentication. There are several ways to perform the binding between device acknowledgment and device authentication.

Although an example of a binding method applied to device integrity confirmation and device authentication is for 3GPP H(e)NB, it will be appreciated that these methods can be applied to any other communication requiring device integrity confirmation and device authentication. Or application device.

A typical device authentication procedure in H(e)NB may be limited to verifying AKA certificates contained in a Trusted Environment (TrE). These programs may not address device authentication or acknowledgment, and/or the possibility of binding hosting party authentication to device authentication.

Binding between the confirmed device and the device certified program and/or results can be performed. Two types of bindings can be performed. In a logical binding, a logical entity (or multiple logical entities or programs or materials) used in or for device validation procedures and a logical entity (or multiple logical entities or programs) for device authentication procedures can be declared and verified. Or logical correspondence between data. In physical binding, a specific physical entity (such as a physical TrE and/or a specific secret or key it owns) used in or for device validation procedures may be associated with a physical entity (such as an application) used in or for device authentication procedures. soft There is a direct correspondence between the file or the data or the key.

Figure 3 shows two different types of bindings represented as device functions. In both examples, the actual device integrity validation procedure can be performed by a trusted entity, such as a hardware-based security environment that is securely embedded in the device. In the H(e)NB context, for example, a trusted entity may refer to the TrE of H(e)NB. Figure 4 is a diagram of a common TrE binding mechanism that performs 1) integrity verification of the device and 2) strict or sensitive functionality of device authentication.

In Figure 4, the secure and trusted TrE can be located in a communication or computing device. The TrE can perform one or more of the following functions. Device integrity check, such as device integrity confirmation, where such acknowledgement can be performed locally on the device. The TrE may include the interface (1) of Figure 4 and the ability to access and use certificates for validation, stored in the TrE or stored by the TrE. The TrE can secure the portion of the device authentication program that requests secure processing, including the interface (3) of Figure 4 and the ability to access and use secret certificates for device authentication, stored in the TrE or stored by the TrE. Other capabilities may include performing secure processing to support applications that are requesting security sensitive processing outside of the TrE. These applications can access or use their own secret certificates (not shown in Figure 4). The TrE can include an interface to device functions/applications located outside of the TrE. For example, but not limited to, the interface (2) for performing device authentication processing on the device in FIG. 4 and/or the other non-authentication application interface for internal security request processing from the TrE in the fourth figure (5) .

Additionally, the non-TrE portion of the device can perform one or more of the following types of functions. A feature can be non-secure for device authentication section. Another feature can be used for applications that do not require secure processing from the TrE. Another feature can be used for applications that require secure processing from the TrE (except device authentication). The non-TrE portion of the device can support the interface, including the interface (4) for message exchange between device authentication, device capability (d), and/or network-based AAA server (g) in FIG. The interface (6) of Fig. 4 can be used for message exchange for requesting functions from secure processing within the TrE on the device side. The interface (7) of Fig. 4 can be used for message exchange for not requesting functions from secure processing within the TrE on the device side. The certificate for device authentication and the certificate for device integrity confirmation may be different. However, these certificates can be configured to be bound to each other.

Figure 4 is an example of a device that can use physical binding in H(e)NB. For example, physical binding can be performed by using TrE for acknowledgment and device authentication. For example, in H(e)NB, the TrE can be designed to perform all the procedures required for device validation. These programs may include at least a portion of the program that requires the most secure or trusted processing of the program required for device authentication or the entire program itself. For example, if the device authentication protocol is designed to use a pre-shared key based approach, such as EAP-AKA, the TrE and H(e)NB holding the AKA certificate can be further bound to each other. For example, the H(e)NB may encrypt the data required to calculate the AKA certificate for device authentication so that the decryption is limited to TrE before transmitting the data to the TrE. The TrE can securely store the keys needed to decrypt the data. In addition, further binding can be obtained by combining information about device acknowledgment and device authentication in the same session of a public safety agreement (such as IKEv2). In this case, the device confirmation suitable for this binding can make: at H(e)NB (in And its TrE) and the network entity need an interaction and message exchange.

As mentioned earlier, logical binding is another type of binding that can be used for device validation and authentication. An example of a logical binding may be to use a continuous session of the same packet, message, session, or same or common communication protocol message to perform a message that needs to be transferred out of the device for purposes of device validation and device authentication. It should be noted that the physical binding method and the logical binding method can be used in combination with each other.

Device acknowledgment can be tied to client-side authentication based on pre-shared secrets.

The device acknowledgment of the H(e)NB may be performed to bind to the pre-shared key based authentication in one or any combination of the following physical and/or logical binding mechanisms. Physically bind the TrE to the H(e)NB by using an encryption key and certificate for message exchange between the Trusted Environment (TrE) and the rest of the H(e)NB, at least in TrE and H(e) The NB internally protects the key and certificate. This can be applied to message exchange between TrE and H(e)NB for device authentication.

Referring to Figure 5, the TrE can first verify the integrity of the H(e)NB. If successful, it can proceed to the connection (5) of Figure 5; if unsuccessful, the TrE cannot proceed to the connection (2), but instead locks the function, which may include the device authentication function of the H(e)NB. To verify the integrity of the H(e)NB, the TrE can confirm the certificate using the device stored in the TrE (see wire (1) in Figure 5).

In connection (2), the TrE can be equipped with a key pair, the private part of the key pair is securely stored in the TrE, and the public part is paired with H(e)NB It's useful. The manufacturer of the H(e)NB can generate the key pair and provide the certificate required to make the public key available to the H(e)NB. The device confirmation function of the TrE may use a TrE private key to sign the message (in the connection (2) depicted in Figure 5) to indicate one or more of the following to the device authentication function other than the TrE, for example : ID of the TrE, a message indicating that the TrE has successfully verified the integrity of the remaining H(e)NBs, and/or an authorization material indicating that the TrE authorizes the device authentication function and can be authorized to perform the device authentication procedure. The TrE private key can be used to sign the authorization message. The authorization message can authorize the use of some of the security processing capabilities of the TrE through the device authentication function on the H(e)NB device.

The signed message delivery authenticated by devices other than TrE to TrE can be depicted by the line (3) of Figure 5. The H(e)NB may use a TrE public key that it may need to verify the signature described in the above connection (2). The public key may be pre-provisioned in the certificate, otherwise it is available to the device authentication function prior to its use. The use of the public key can be depicted by the line (4) of Figure 5.

The device authentication function may use the secure processing capabilities for device authentication within the TrE (the latter performing security sensitive functions that may be required for device authentication procedures). The interface for requesting and obtaining the service is depicted in the line (5) of Figure 5. The secure processing capability for device authentication may use the secret device authentication credentials pre-stored in the TrE to calculate the device authentication function that may need to be sent to the AAA server for the latter to authorize the H(e)NB device. This can be depicted in the line (6) of Figure 5.

Device authentication function can exchange data with AAA server, Included from the self-secure processing capability calculations provided by the TrE for device authentication, enables the AAA server to authenticate the identity of the H(e)NB device. This can be depicted by the line (7) of Figure 5. This feature can be done in a suitable message exchange agreement. For example, in the case of H(e)NB, protocols such as IKEv2, TLS, TR069 (application layer agreement), OMA-DM protocol, or higher layer protocols (such as HTTPS) may be considered. It should be noted that the device authentication function can perform security sensitive functions by itself.

The acknowledgment and device authentication can be bound by having H(e)NB and TrE jointly execute the device validation procedure and the specified portion of the authentication procedure using the same packet or the same message. This can be performed in a continuous session of a public communication session or a public safety agreement. Examples of the agreement may include IKEv2 protocol, TLS, TR069, OMA-DM, and HTTPS. The agreement may use protocols based on pre-shared secrets, agreements based on asymmetric keys, protocols based on symmetric keys, and the like.

Figure 6 is an example of such a binding mechanism where the validation data and partial authentication material can be sent in the same agreement/session/message. In Figure 6, the connection (1) shows that the device acknowledgment function (DVF) within the TrE can use the device acknowledgment certificate to perform the necessary device integrity check to verify the integrity of the H(e)NB component. It is maintained. Note that DVF can use the functionality provided by TrE's Encryption Capability (TCC) to perform some of the functions required for device integrity verification and verification. This relationship can be depicted by the dotted line (A) of Figure 6.

After a period of time, the device authentication function (DAF) within the H(e)NB can execute programs, such as the Diffie-Hellmann (D-H) program. To establish an unauthenticated common key for encryption and signature between itself and the external AAA server. This step, depicted by the connection (7-a), can be a pioneering step of device authentication, and a non-authenticated encryption key can be established for use in the device authentication message protocol to be followed. Note that the DAF can perform some interim steps required by the D-H program depending on the TrE's Encryption Capability (TCC). The dotted line (C) can be an interface between the DAF and the TCC, which the DAF can use to request and obtain cryptographic services from the TCC.

The DAF can initiate a device authentication procedure by sending a Dev_Auth_Init_Request message to the AAA server. For example, if the IKEv2 protocol is used, the message can be hosted in the IKE_SA_INIT request message. In the Dev_Auth_Init_Request message, the DAF may include a header (HDR), a security association (SA) capable of providing, for example, a security parameter index (SPI) to the AAA server, a public key KE_DH of the server generated by the DH program, and / or the device's own ID Dev_ID. This step is depicted in the line (7-b) of Figure 6.

The AAA server can send Dev_Auth_Init_Response to the device's DAF (or IKE_SA_INIT response message if the IKEv2 protocol is used). The message may include information elements such as a header (HDR), a device public key KE_DH generated by the D-H program, and an ID Syr_ID of the server itself. This step is depicted in the line (7-c) of Figure 6.

The DAF can send elements to the AAA server in the Dev_Auth_Request message (if the IKEv2 protocol is selected, the IKE_AUTH request message), such as header, SA, Dev_ID, configuration (CONFIG), and / Or an optional server certificate request (Svr_Cer_REQ), as shown in Figure 6 (d-d). Note that from here on, some information elements can be protected by the encryption and signature of the keys generated by the D-H program. For example, Dev_ID, Session_ID, CONFIG, and optional server certificate requests can protect confidentiality and integrity by using keys generated by D-H programs. Note that the DAF can use the TrE's Encryption Capability (TCC) to perform encryption and signature of keys generated using D-H. This relationship can be depicted in the line (B) of Figure 6.

The AAA server can send a Dev_Auth_Response message to the DAF (if the IKEv2 protocol is used, it is an IKE_AUTH response message), including, for example, the header, Syr_ID, Session_ID, and optional server certificate (Svr_Crt) (if the DAF has requested one) An authentication challenge (Auth-Challenge) based on the shared authentication secret between the H(e)NB and the AAA server (stored in the TrE in FIG. 6). This is depicted in the line (7-e) of Figure 6.

The DAF may send a Dev_Auth_Request message to the AAA server (if the IKEv2 protocol is used, it is an IKE_AUTH request message), which may include, for example, a header, a Dev_ID, a Session_ID, an Authentication-Challenge response (AUTH), and/or a confirmation data (Validation_Data). ). This is depicted in the line (7-f) of Figure 6. It is noted that the DAF can rely on the secure processing capability (SPC_DA) for device authentication in the TrE to calculate and forward the AUTH, as shown in the connection (3) of Figure 6. Note that SPC_DA can calculate the AUTH using the pre-shared authentication secret certificate stored in the TrE, as shown in the connection (4) of Figure 6. In addition, SPC_DA can rely on TrE's Encryption Capability (TCC) (see dotted line (C)). Note that SPC can calculate AUTH. The Device Confirmation Function (DVF) can also sign the Validation_Data and any other related supplemental material using the TrE private key before forwarding the Validation_Data to the DAF, as shown in Figure 6 (5). The interface between the DVF and the TrE private key can be used to sign the confirmation data before forwarding it to the DAF, as shown by the connection (2). In this example, in addition to the physical binding of the public TrE and its assets to perform validation and device authentication (or some of its required security), another logical binding mechanism can be used. The same protocol, the same session, and the same message can be used to send information elements about the results of both device acknowledgment (ie, Validation_Data) and device authentication (ie, AUTH) from the device to the AAA server.

After receiving and estimating the AUTH parameter and Validation_Data from the previous Dev_Auth_Request message (see Figure 6), the AAA may send a Dev_Auth_Response message to indicate to the device's DAF whether the AAA server access authentication is successful or not. This is depicted in the line (7-g) of Figure 6.

In the binding mechanism, the TrE can control and release access to sensitive functions or sensitive data to the DAF or SPC_DA, which is required to calculate the necessary output for successful completion of the authentication, which can be successful first. The completed device validation procedure is conditional so that access can be allowed. This type of binding mechanism can be considered both a physical binding mechanism and a logical binding mechanism. Figure 7 is an illustration of this binding mechanism examples.

Referring to Figure 7, DVF can perform two types of gating programs depending on the functions or materials that are allowed to access the TrE. The gating program can depend on the status of the device integrity confirmation results. If the device integrity confirmation result is unsuccessful, the DVF can prevent the DAF from accessing the SPC_DA in the TrE, as shown in Figure 7 (A: Gating). The DVF can prevent the SPC_DA from accessing the device authentication certificate required to perform a successful authentication to the AAA server. This type of gating function can provide other types of logical binding between device acknowledgment and device authentication.

Device validation can be tied to authentication, such as certificate-based device authentication.

The device acknowledgement of the H(e)NB can be bound to the certificate based client and authentication can be obtained using a similar mechanism as described above. Some possible mechanisms are described below. Figure 8 is an example diagram of the use of physical binding, which may perform device integrity verification and validation, as well as some or all of the functionality required for device authentication. For example, these functions can be based on device certification. The procedure may be the same as described in FIG. 5, except that the certificate for device authentication by the secure processing capability (SPC_DA) for device authentication may be a private key (Kpriv_DA) for device authentication, and a device authentication function (DAF) may A device certificate (DevCert) and some other materials calculated by Kpriv_DA are sent to the AAA server.

Referring to Figure 8, the key access and the relationship between SPC_DA and Kpriv_DA are as shown in connection (6). Prove that the relationship between access and DAF and DevCert is as shown in connection (8).

The H(e)NB and TrE may jointly execute the device validation procedure and the specified portion of the certificate-based client authentication procedure in the same packet, message in a continuous session of a public communication session or a public safety agreement (such as the IKEv2 protocol). Effectively, the procedure of the binding mechanism can be similar to that described in FIG. Referring again to Fig. 6, the difference can be as follows as compared with the case of using the pre-shared secret based device authentication. SPC_DA can calculate sensitive temporary results from AUTH challenges based on AUTH challenges from AAA servers and Kpriv_DA, rather than based on AUTH challenges and TrEs from AAA servers (and SPC_DA used to calculate and forward DAF calculations) Pre-shared secrets to calculate the sensitive temporary results. The AAA server can request a device authentication certificate (DevCert) from the DAF. In response, the DAF working with SPC_DA can be calculated and forwarded to the AAA server: 1) Authentication Response (AUTH) (using Kpriv_DA), and/or 2) DevCert. After receiving AUTH and DevCert, the AAA server can first verify the validity of DevCert and then use it to verify AUTH. If the verification result is verified, it has already authenticated the device.

Although there is a difference, logical binding can be performed in a manner similar to the case in authentication based on pre-shared secrets. For example, the DAF can forward AUTH and DevCert to the AAA server, or include Validation_Data in the same message. The Validation_Message is available from the DVF inside the TrE and can be signed by the DVF by using the TrE private key.

Figure 9 is an example diagram of a binding mechanism. In this example, there is no authentication challenge itself from the AAA server to the device. instead, After the server requests the device to send its proof DevCert (see connection (7-c)), the device can send its DevCert and AUTH (calculated from Kpriv_DA) to the AAA server, as shown by the connection (7-d) . The AAA server can verify AUTH and DevCert and send a confirmation of the authentication status (7-e).

The type of gating that is bound can be implemented in certificate-based authentication. This example is similar to the pre-shared secret based authentication example. Figure 10 is an example diagram of the binding mechanism. Referring to Figure 10, the DVF can perform two types of gating procedures (depending on the state of the device integrity confirmation result) by allowing access to some of the functions and materials held by the TrE.

If the device integrity confirmation result is unsuccessful, the DVF can prevent the DAF from accessing the SPC_DA in the TrE as shown in the connection (A: Gating) of FIG. Alternatively, the DVF can prevent the SPC_DA from accessing Kpriv_DA that requires successful authentication of the AAA server. These types of gating functions can provide another type of logical binding between device acknowledgment and device authentication.

Provides a broad binding between device integrity validation and other essential device functions.

The concept of binding between device integrity confirmation and device authentication (as described above) can generally mean that the device integrity, procedures, input and/or usage of intermediate data, and/or results can be "gated" for authentication. Process or program.

The generalization of the concept of binding can be based on the type of device that can be bound, and the program that can be bound to the device integrity confirmation. Set the function. In the most general sense, if there is a device D capable of verifying, reporting, and/or verifying its own device integrity (by itself, or by performing an interaction with external entities and/or capabilities to perform the process is considered Is at least one function X) of the essential function of the device, and it is generally considered that binding can be implemented. The essential function (which is not intended to be performed) may be that device X is not considered to be operational in a normal, useful sense. Examples of the essential functions of a device, such as a mobile phone, may include one or more of the following: ability to transmit a hazard alert, user authentication (to the network), device authentication, core application, communication stack execution, user authentication (to device), device management functions, wireless signal transmission or reception, or power and management functions of the device.

The binding may be defined and implemented as a program in which the device D_V, program P_V or result R_V of the device integrity verification program may indicate to the successful operation of the essential function X such as D_V, P_V and/or R_V And it is difficult or impossible to forge or clone the relationship. The three types of binding mechanisms described in the previous sections can be applied again. Binding due to shared presence and encryption, due to the use of the same or continuous communication protocol packets, messages, bindings brought by one or more sessions, and/or due to gating or conditions to data D_X or program P_X The binding brought by the access is essential to the successful operation of the essential function X, and the successful operation of the function X is based on the condition for successful confirmation of the device D.

Figure 11 is a second type of binding (ie, the type of gating of the binding) that can be made between the validation program (DVF) and the function (X) on the device. An example diagram used. The TrE can have a secure processing capability for function X (SPC_X) and sensitive data (SD_X) required for function X. The DVF can also function on the device itself (X), and any data on the non-TrE portion of the device required for the function (D_X), functions embedded in or connected to the components/modules of the device D (X_EC) ), as well as the network-based function (X_N) and the data it can use (D_X_N) for gating.

Figure 11 shows the various types of gating (A to G), where DVF can gate access to the following items based on the integrity of the device: A) Safe Processing Capabilities SPC_X, and/or B) Functional SPC_X may require sensitive data SD_X in the TrE, and/or C) any function X, and/or D) that may be internal or external to the TrE, and may be required for internal or external TrE and function X Any information on, and/or E) any function X_EC, and/or F) on the embedded component of the device (eg, SoC) or on a discontinuous module (eg, UICC) connected to the device by external Any function X_N executed by the entity (eg, from the network), and/or G) any material D_X_N required by any such external function X_N.

It should be noted that the program X example can include the following functions as communication functions: for example, radio and baseband transmission and reception, device power management (including on/off), user interface, media processor function, GPS, and other positioning. Features, timers and timing synchronization, as well as communication functions (such as WLAN), Bluetooth, cell communication, high-level applications such as networking functions, single sign-on and recognition federation and management functions, such as codec functions Voice and other media features, game features, and security programs for them (such as user authentication, device authentication, application authorization, Includes encryption/decryption and cryptographic operations for signature and signature verification), as well as any other functionality of the device.

SPC_X may include, but is not limited to, encryption plus (decryption), signature generation or verification, random number generation or use, timing synchronization and time stamping, message authentication code generation and verification, encryption key generation, derivation, or management (including Deprecation or isolation), certification verification, and calculation of secret material required by TrE certification, the user of the device, the device itself, or the owner or authorization of the subscriber and/or device.

Examples of functions X_EC may include, but are not limited to, data storage and processing functions, authentication functions, key generation and usage, addition (decryption), signature generation and verification, configuration management, and the like.

Examples of functions X_N may include, but are not limited to, data storage and processing functions, network-to-task-provided applications (such as device management, provisioning, high-level applications (such as network access, etc.), DRM, voice and multimedia services, and gaming functions). , device management services, communication services, single sign-on and identification federation and management, etc.).

The gate program can be cascaded. That is, the DVF can gate access to an application, where the application can gate access to another application or data. DVF can gate multiple programs or materials, some or all of which can have causal or correspondence relationships.

Although the features and elements of the present invention are described in a particular combination, each feature or element can be used alone or in combination with other features and elements. . The method or flow chart provided here can be used by general purpose electricity Implemented in a computer program, software or firmware executed by a brain or processor, wherein the computer program, software or firmware is contained in a computer readable storage medium. Examples of computer readable storage media include read only memory (ROM), random access memory (RAM), scratchpad, cache memory, semiconductor memory devices, such as internal hard disks and removable magnetic disks. Magnetic media, magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVDs).

For example, suitable processors include: general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with the DSP core, control , microcontroller, dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and/or state machine.

A processor associated with the software can be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or any host In the computer. The WTRU may be used in conjunction with modules implemented in hardware and/or software, such as cameras, camera modules, video phones, speaker phones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth ® Module, FM Wireless Unit, Liquid Crystal Display (LCD) Display Unit, Organic Light Emitting Diode (OLED) Display Unit, Digital Music Player, Media Player, Video Game Console Module, Internet Browser And/or any wireless local area network (WLAN) or ultra wideband (UWB) module.

A system, method and tool are disclosed (instrumentality) to perform integrity verification of the network device. The network device can include secure memory. For example, secure memory can be included in a secure hardware module. The secure memory can receive the root key. For example, the root key can be received by secure memory at the time of manufacture or provisioning. The root key can be stored on secure memory and is invisible to software and hardware outside of the secure hardware module.

The secure hardware module can receive the first code measurement (measurement of the first code). For example, a processor (such as a processor associated with a network device including a secure hardware module) can select the first portion of the code to measure. The first portion of the code can be stored on a memory associated with the network device, such as ROM memory, RAM memory, and the like. The processor can measure the first portion of the selected code, which results in the first code measurement. The processor can provide the measurement to the secure hardware module.

The secure hardware module can generate the first key based on the root key and the first code measurement. For example, the secure hardware module can obtain or release the first key. When the first code measurement is valid, the generated first key is valid, and when the first code measurement is invalid, the generated first key is invalid. For example, the secure hardware module can obtain the first key based on the first code measurement. If the first code measurement is invalid, the resulting first key is also invalid. The generated first key is generated by the secure hardware module to provide access to the resource. When the code is stored on the secure memory, access to the resource can be provided without code measurement.

The first key may be associated with a first phase of a trust associated with the first function (eg, one or more resources may Associated with the first function). Further, the first stakeholder can use the valid first key to access the first function. If the first key is invalid, the first stakeholder may not access the first function. That is to say, when the first code measurement is invalid, the secure hardware module can block access to the first function.

The secure hardware module can receive a second code measurement (measurement of the second code). The secure hardware module can generate a second key based on the first key and the second code measurement. The second key may be associated with a second phase of trust associated with the second function (eg, one or more resources may be associated with the second function). Further, the second stakeholder can use the valid second key to access the second function. The key release can be limited to the last known good start-up phase (for example, the last known start-up phase with successful authentication).

The generation and/or release of resources, such as keys and functions based on hardware, code, and/or data integrity measurements, may provide authentication in stages. For example, a device may include several layers, each layer having its own authentication secret. Each authentication secret may correspond to a particular stakeholder in the layer of device capabilities such as manufacturer firmware, trusted execution code, operating system, and third party applications. Further for example, the valid first key can be associated with valid authentication for the first startup phase. The valid first key can be used by a device manufacturer (eg, a first stakeholder) to access firmware on the network device to perform repairs on the firmware. The valid second key may be associated with valid authentication of one or more software components during a subsequent startup phase (eg, an intermediate startup phase). The effective second The key may be used by a device manager (eg, a second stakeholder) to access the software component, for example to perform repair of the software. By providing a valid key for each stage of successful authentication, access can be granted, which is comparable to the last stage where no authentication failed.

The number of stages of multi-stage authentication disclosed herein may vary and is not limited. Further, multiple authentication paths can be provided. That is to say, at some stage of the integrity check, the authentication can be branched in different ways. For example, each stakeholder can provide one or more policies related to one or more certification phases. At each stage, authentication can be branched in different ways based on stakeholder policies. Stakeholders can manage their strategies externally.

Figure 12 shows the multi-stage authentication associated with the startup procedure of device 1200. Apparatus 1200 can be configured with hierarchical startup phase capabilities (eg, releasing one or more valid keys associated with one or more phase authentications). When device 1200 authenticates to the first startup phase, device 1200 can provide a valid first key to the first stakeholder (eg, the manufacturer) at 1201. The first initiation phase may be a low level of authentication, and the key associated with the first activation phase may provide access restricted by the manufacturer's associated firmware. When device 1200 authenticates to the second startup phase, device 1200 can provide a valid second key to the second stakeholder (eg, device administrator) at 1202. The second startup phase may be a startup phase that is later than the first startup phase, and the key associated with the second activation phase may provide access limited by the authentication software. When the device 1200 is authenticated to the last startup phase, the device 1200 can provide the third stakeholder with The third key, the third stakeholder can provide access to the core network, security gateway, and the like.

Using the launcher as an example, access to the authentication secret to the last known good start phase of the restricted wafer resource and boot execution can be released. This phase release may allow for device software/firmware repair of the code (use the lower layer for the trusted remote device management update program for the device). This can depend on a string of trust sources from the trustworthy security unchangeable wafer base. For example, once reset, a particular wafer configuration may be desired to release the first key. This configuration ensures that the processor will jump to the appropriate internal execution code, which can then begin to gather the code to take measurements before the next stage of the series trust execution. If the initial wafer configuration is incorrect, such as the jump vector is not an internal ROM code, then the initial and subsequent integrity measurements may be different than desired, and the device cannot proceed to the next active phase.

Controlled forms may include hardware anchor gating of wafer resources, integrity comparison of measured components, and/or key derivation based on actual measurement integrity of the system. In the latter examples, the disclosed system and method can be used to generate multiple trusted control execution paths for other uses, as the resulting key may be different than required for normal operation. Thus, for example, an external entity can directly control the pins of the device, which can result in different startup sequences and thus result in different keys that are also based on the root of trust.

For example, in addition to the traditional parameters, authentication can be provided by imposing two additional authentication factors on each of the activation levels. Authentication to external entities may need to be known: 1) Start-up phase-specific cryptographic signature secrets Or an encrypted key that is exposed if 2) the startup phase specific code is correct (by integrity check).

The resulting application may be that the external entity can confirm the integrity of the device based on the functionality required by the entity. In addition, independent stakeholders (eg, hardware or different firmware and software layers of the device or device manufacturer) can be assured that other entities may not be able to modify the corresponding firmware or software of the independent stakeholder, and It is not necessary to disable the device function.

The sample phase start sequence begins by forcing the encryption key to detect and use the trusted hardware mechanism to unlock the wafer resources and for the secrets provided for the next stage in the launcher (eg, encryption key, signature key, and integrity measurement) . As each stage is successfully verified, wafer resources and new secrets and measurements become available.

In some cases, the information may be in the core trusted domain and may be available to the hardware but not viewable or possessed by the software/firmware. Wafer resources and other information may be released into the execution environment because of the code-based Each phase is checked and verified to be trustworthy (eg, verified based on code verification, data verification, hardware verification, etc.).

Each startup phase requires privileges and controls corresponding to its location in the secure boot process. Exclusively generating a certificate for a certain stage may allow the control extension to extend beyond the platform, for example to authenticate to an external entity.

For example, in the case of device management and device certification, manufacturing The Chamber of Commerce needs the privilege to update the firmware and the network operator will need to repair or update the software and/or configuration information, but it will not fix or update the firmware. If the device passes the integrity check of the firmware but does not pass the verification of the software, the available key may be used by the network operator to authenticate the device in order to update the software. However, if the device firmware verification also fails, the key used to authenticate the device to the management system can be released, but not the key required to authenticate to the network, meaning that the original program might be remotely located and Securely fix/install the firmware so that the device is no longer launched in an unsafe manner (ie, in a manner other than the trusted root program). This firmware failure triggers the release of an alternate feature to help with the fix (for example, authentication will take a different branch due to failure). The advantage of providing a trust confirmation root is that it allows remote management of the device's firmware trust code base.

Based on the degree of trust of the system, different stakeholders (eg, operators and application providers) may allow different keys to be used to characterize the results of the measurements in the initiation sequence. This may mean that some operators or device owners may still allow the system to boot to a partially trusted but partially untrusted state in multiple phases. Even in such a state, the device may be required to generate and use a particular encryption key (eg, to indicate an external user's status regarding the device, or to provide security for applications that are still allowed in a partially trusted state of the device) Sex). An option may be to generate and use a high-intensity key (in the example where a high level of trust can be established in the boot sequence) and to use a relatively low-intensity key (if trust is established based on the result of the boot sequence) Relatively low level). The policy should be provided in advance, and the root of trust can use the appropriate key strength, This key strength corresponds to an trust level that can be established. When even partially optimized trust-validated systems need to use cryptographic resources to send specific information to the outside without the need for an additional key strength level (which may be inconsistent with the trust of the booting system), for different levels of The generation and use of multiple keys that are trusted is useful.

The generation of different keys can be based on different startup sequences and different codes so that there can be more than one set of valid phases. Possible device unique secret keys derived from different boot sequences may be derived from the same root of trust (using the same root key) and are therefore trustworthy but distinctly different and mutually exclusive, which allows for distinguishing roles (eg, trusted Test mode for trusted normal operations).

An algorithm selection and signature mechanism for key derivation can be provided. A particular algorithm can be executed for the next stage key derivation and/or current stage signature or authentication. These controls may exist in a dedicated control register field in the encryption certificate package so that once decrypted, the field value can be inserted into the corresponding register of the boot phase authentication module, which can set the execution control. The startup phase authentication module may be a TrE.

Figures 13A, 13B, and 13C illustrate wafers that can implement embodiments of the disclosed systems, methods, and possibly means.

Secure multi-stage boot authentication can be used, for example, in a secure hardware module (eg, startup phase authentication module 1300). The startup phase authentication module 1300 may include four components: a root device single secret key (root key), a control signal and a phase specific key derivation function (KDF), a cryptographic engine, and a signature mechanism. The interface to the module can include configuration and Data bus interface. The configuration register can execute instructions and data streams, such as MMU control or boot execution vectors, wafer I/O, and the like. By being located inside the boot phase authentication module 1300, the key path can be protected from being viewed by the software/firmware. This startup phase configuration interface ensures that the wafer has the proper configuration to initiate a secure boot process.

If the secure boot procedure does not start correctly, for example, if the configuration is for an alternate boot sequence, the access to the resulting phase of the wafer resource and the device's unique secret key may not exist, which in turn prevents entry into the next boot phase. And the decryption of the signature key for a particular phase, and therefore, the external entity may not be able to verify the trust status of the device.

One or more of the following may be combined: a cryptographic hashing algorithm with a key, a device unique secret key, a feedback key path, and a signature mechanism. The layer of authentication secrets can be cryptographically bound to specific devices and the integrity of the measurement information (eg, execution code and launch configuration control). If the measurement information lacks integrity, the subsequent dependent layer of execution may not be able to access or decrypt the authentication secret. For example, if the device does not properly set its processor hopping vector, does not start internally or is not in debug mode, it will detect a different bit pattern, which can generate an incorrect key, which will then not be external Interested parties are certified.

The device can contain a unique secret key. The unique secret key of the device can be derived from the previous boot phase key and from the measured code. Since the device unique key may not exist on the device, it may be derived by the code itself, and if the code is modified, the device unique secret key may be incorrect. The root device unique secret key (root key) can be initially provided It is secretly embedded inside the device at the time of manufacture or at the time of manufacture and is unique to the device. The root device unique secret key may not be available unless the configuration is initiated using a particular device. The root key may not be visible to the software/firmware and may be seeded for device unique keys in subsequent startup phases. It is also invisible to the software/firmware, but can be used for authentication or signature mechanisms, which can verify the secret. The presence of the key and thus the integrity of the device is verified to this stage in the startup sequence.

The root device unique secret key may be a key of appropriate strength (eg, now approximately 256 bits), which may be configured, for example, as a one-time programmable fuse or in memory in a manufacturing process such that it is Software/firmware, eavesdropping on chip signals, probing, simple and differential power analysis, etc. are secret and hidden. It can be unique to the device, nobody knows it, and once reset, the key export function is initially

Figure 14 shows an example of a key derivation function.

The key export feature can serve two functions. It can generate keys for subsequent phases, and it can measure subsequent startup code. It can be a cryptographic hash function with a key, such as HMAC-SHA-256. Due to its one-way nature, it can ensure that any information that the subsequent key does not reveal the previous key, as well as the measurement data, is obtained. Any bit error can result in a very different key that is not related to the correct key. Encryption phase specific signature secrets can be provided with integrity information. The integrity information can provide confirmation of the measured integrity check value of the component or function, and thus release the next phase of functionality.

Figure 15 shows exemplary key derivation details, including a signature mechanism.

For robust device authentication, the key derivation function generates a unique secret key for the boot phase device, which is not directly readable for the chip software/firmware and external entities. Thus the device unique key can be sent in the direct path of the authentication or signature mechanism. The external entity and software can then provide an authentication or signature mechanism with a challenge message to confirm the freshness of the device's startup state via the external chip interface.

Figure 16 shows an example of multi-stage key derivation details.

As the startup process progresses from the initial startup and the program loader sequence to the operating system and application loading, the integrity of each startup phase of the code can be measured before it is executed. The code can be populated with a key derivation function in each phase and a device unique secret key can be generated at each stage. For example, initially, the root device unique secret key (root key) and the first code measurement can be populated into the key derivation function, and the first key (initial stage key) can be generated. This procedure can be repeated for multiple phases until the last good certificate is determined.

Figure 17 shows an example of a startup sequence. The example of Figure 16 shows how the key was derived in multiple phases and how to determine the last good certificate. The initial phase key verifies that the hardware can be configured to trust the execution root, such as verifying that the processor boots the internal ROM, that the hardware integrity test results are correct, and that the security-sensitive I/O pins are properly set, such as not in test mode.

If the startup phase is performed according to the correct startup configuration and code, the final result may be an encrypted or signed key, Can be used externally by a network entity to verify that the device is booted in a trusted manner. Otherwise, if the phase startup code fails, the final signature key is incorrect and the external/remote authentication fails.

The execution chain does not need to track the signature keychain. The boot sequence may be controlled by execution of the test sequence (eg, hardware based), which may load code measurements for device trusted operations. If the measurement is correct, the result can be the final key, which can be used to externally confirm the trusted operation of the device.

Keys and controls derived from the active startup phase can unlock residual passwords or signature keys that are persisted in an instant run. The device management server can use the residual signature key to verify that the device has been securely booted to a trusted state to determine that the server can securely download the application code. On the other hand, removing access to the key at each startup stage can help maintain privileged control of the chip's hardware protection domain, which should be accessible to a particular provider of the particular boot phase code, for example, In order to authenticate the purpose of device personalization, provisioning, debugging, testing, etc.

The startup code executed needs to detect if the next stage measurement has failed integrity. For example, embedded in the cryptographic seal for the next start-up phase may be an indication of an integrity failure, such as a known "integrity indication message" located within a particular field of the cryptographic seal package. An error measured during the next startup phase can result in a garbled integrity indication message in the field of the packet that does not match the expected value (which indicates to the execution startup code that an integrity failure has occurred).

The hardware comparator in the startup phase authentication module (see eg Figure 13A-C) will detect (HW protection, invisible to software or firmware) Matching between the desired integrity value and the resulting integrity value to generate a hardware control signal to control, for example, integrity-dependent hardware configuration, wafer secrets, fuses, I/O, and test pins, Access to LEDs, etc.

The control initiation sequence then chooses to issue an alert outside the wafer indicating to the outside world that an error has occurred. Alternatively, the control boot code can remain idle, waiting for input from the chip interface (network or pin) to attempt authentication to the external entity.

In one operation, the startup phase authentication module decrypts the encryption phase signature secret (packet). However, methods may be needed to encrypt and install the signature secrets at this stage. The module may have a "supply mode" input signal, an "authorized access not allowed" input signal, and an "authorization phase" input signal, which may be 1) for the supply method only during the manufacturing phase The one-time programmable fuse method is locked, and/or 2) becomes accessible on the wafer by an authorized hardware.

If they are not locked by a fuse in the manufacturing process, the chip needs to provide another mechanism to protect the input. If they are not locked by a fuse, the startup phase authentication module will allow the provisioning mode (if the device has been safely booted by its own detection mechanism described in this article). This will prevent the non-secure boot code from entering the provisioning mode. However, unauthorized access to the provisioning mode input can be protected by a secure boot code, a hardware configuration, and other "authorized" hardware on the wafer. That is, the boot phase authentication module can ensure that the secure boot code is executed to protect the boot code authorization sequence used to manage the authorized hardware that protects access to the provisioning mode. In one embodiment, the secure boot process can utilize Constrained keys (eg, public, private, etc.) and challenge response protocols to authenticate and authorize applicants to access the provider and supply mode inputs.

The provisioning mode input allows subsequent stages of the signature secret seal to be encrypted and stored inside the boot phase authentication module in the protected scratchpad that is not available to the software and is not visible to the vendor. The provisioning mode status then switches to encryption mode. The new startup phase code will be loaded into the key export function. After the code is loaded, the new device unique secret key is automatically generated (but not visible to the user or software). The new signature secret corresponding to the new boot code is then inserted into the cryptographic engine and encrypted with the new device unique secret key. This result is stored in a location to replace the previous version.

Subsequent startup phase code can be loaded, which derives a new subsequent device unique secret key that can be used to encrypt the signature key secret for subsequent stages of internal storage. The program will continue until it is completed. The device will be restarted with the new boot phase code and its corresponding signature key. The subsequent start-up phase code and key can remain the same (the new chain of unique secret keys for the stage device is unknown and limited by the new chain). The startup phase prior to the modification phase remains unmodified.

Figure 18 is a flowchart showing an example startup sequence of a device for generating and using a key, wherein the strength of the key (or other security strength characteristics, such as the encryption algorithm itself, or algorithm mode, etc.) may depend on The system credibility result witnessed by the integrity check program executed in the startup sequence.

Open systems and methods can be used for a single stakeholder As a remote user implementation, it can provide a single stakeholder with the flexibility to securely manage the device with varying degrees of functionality. For example, a remote user may need to confirm that the device correctly acquired its full device integrity and/or functionality before using the device for critical and complex functions of security.

To determine the extent to which device integrity and/or functionality is obtained, the user will challenge the device by submitting a temporary number to the device and then retrieving the response after the signature (eg, the temporary number will ensure the freshness of the result). . The user will check the response to determine the stage of integrity of the device and the health check execution. Based on this result, the user can ensure that it can safely interact with the device (for features that have been verified for integrity).

As an example, if the response indicates that a secure launch procedure has not occurred (eg, there is no integrity check), then the user will know that the device is configured to be in a non-secure form and will not be relied upon to process sensitive material. Also, because some device integrity limited keys may not be available, encrypted material that is limited by the secure boot program may not be available.

If the first phase of the procedure is completed, the device may have some security capabilities, such as verifying some of its own failed features, and the ability to send replay protection and/or signed distress signals to the outside. The remote user can determine from this signal that the received disaster signal is non-erroneous and/or deceived by some other device, and take action to repair the device if it is informed that the device sent a disaster signal.

Continue with the example, if the second phase is completed, it means higher A new set of authentication keys for hierarchical capability/device integrity is available on the device, which allows the user to remotely and securely modify the failure code on the device. A variant of this situation is that the second phase of the device implementing integrity can obtain local access to the key, which allows it to the remote user's OAM or device management (DM) server (or the servo) Application) for authentication. In this phase of the example, the device has the ability to authenticate the remote user (or his OAM or DM server or such server application) so that some of the information and code on the device can be used and obtained. Phase-related available keys are loaded and signed. Other stages associated with other competency levels can also be obtained.

The final successful phase indicates that the device is fully capable of performing functions that the remote user needs to fully access and use.

The invention need not include some functional phases and is not limited to one or more stakeholders. In one form, the device can perform a single verification phase with a single representative result, which results in a single authentication key for autonomous validation from a remote user perspective. This can be used, for example, to identify devices that attempt to attach to the network. The disclosed systems and methods can also be extended to allow representative flexibility of the device's trustworthy state to allow for disaster indication, device monitoring, device management functions (diagnostics and repair), and authentication procedures for devices, services, and/or application levels. .

Other authentication information may be subject to an integrity check procedure (e.g., an authentication key required for a different purpose than the master key required for better network access for the device). Examples of such "other authentications" may be authentication for OAM, authentication of application hierarchy services, or different Authentication of security protocols (such as IPsec or TLS) at the layer of the access layer. Other examples include authentication devices and/or their profiles (e.g., group members, etc.), users/users, services, or applications. For example, referring to Figure 13C, a service subscription key is sent to the KDF. The resulting key may be a device unique secret key for authentication to the service provider. A challenge to the device can authenticate both user and device integrity. In this case, the service subscription key can be added at the appropriate stage. In one embodiment, an integrity-backed subscription key is provided in a previous phase, while an application key that guarantees integrity is provided in a later phase. Additional information is combined in the KDF input to ensure binding to the necessary information. By binding other authentication information into the integrity checker, more than one independent authentication resource can be provided.

The disclosed systems, methods, and means allow for dynamic extension of trust to allow secure and remote configuration of the device. For example, after shipment, the device can be safely booted to a known, unconfigured state. Such a device should first use the certificate included in the supplier's certificate. The authentication key available in this phase allows an external management entity (such as an OAM or DM server) to remotely access the configuration data structure on the device and allow the authenticated external management entity to insert a new certificate (eg, a new signature secret) The key or the operator proves that it may include a new signature key, etc.). These new certificates can be protected using the methods described in this article. The new profile can be signed with a new key and can be inserted into a new execution phase, which can also be signed by the success phase key. An authentication key can be added, which can be protected by the successful completion of the final configuration check. For example, if the device is reset, it can Automatically restart completely to verify the new phase of the new configuration data. If the new configuration data matches, the resulting authentication key is available. The external entity then authenticates the device. If the authentication is passed, the external entity can ensure that the device is properly configured.

Figure 19 shows an example of network communication associated with multi-stage authentication.

The 3GPP relay node (RN) may serve as a UE (ie, a relay UE) for a donor eNB (DeNB) or an eNB (ie, a relay eNB) for a UE connected thereto. Since relay nodes can be used locally, for example, for emergency response or for temporarily overwriting gap fill tasks, they cannot be fully configured at deployment time and have no full functionality for full operation. However, since the RN is a network device, security requirements (including device security requirements) may be high, which results in a need for integrity verification that allows for a phased operational state. This phased operational state is required for both post-deployment configuration and certificate enrollment.

Figure 20 shows an example of a startup and post-boot configuration procedure that includes multi-phase authentication and certificate configuration using an exemplary 3GPP relay node.

In this example, if a particular phase of integrity is passed, the RN is enabled to access a known carrier (OP) management box (eg, OAM or DM server box, etc.) and the vendor's OAM/DM server. However, if the RN fails in subsequent phases, it may not be allowed to access the certificate (which may or may not already exist on the RN), which is required for full access to the OP Mobility Management Entity (MME) of. therefore, The RN will not pass the full access authentication attempt to the OP MME. However, such failures occur continuously, and the RN may be restricted to authenticate to the known OP OAM/DM and indicated to be reconfigured by the vendor OAM/DM using the pre-provided vendor certificate. If reconfiguration is obtained and by passing a further phase of integrity checking, the RN can now gain access to the credentials required to access the OP MME.

Open systems and methods are sensitive to tampering and immediate failure. A separate tampering monitoring program (eg, the monitoring program and the trusted root link) can be established at or before device integrity establishment. The monitor can verify the code, 埠 or anything that can indicate interference or tampering. Once such an event occurs, the unique secret key value of the establishing device is automatically removed, which makes the authentication key unavailable. Referring to Figure 21, there is shown an example of a wafer using an embodiment of the disclosed system and method. Attempts to re-establish a secure connection to the device using an integrity-based authentication key may fail. This provides continuous protection for external entities that rely on device security.

Figure 22 shows how the integrity check procedure can be extended to UE communication. The network can pass the UE key to the relay node using the integrity-qualified authentication key. If the relay node is no longer secure due to integrity or tampering events, the relay node will not be able to decrypt the encrypted key and the security of the communication from the UE is maintained.

The disclosed system and method can provide one or more of the following: a device signature key phased mechanism that allows partial or phased remote determination of device trustworthiness; wafer resources and authentication A secret phased release method in which successful measurement of code for the current startup phase of the device, configuration information, and status of the secure boot process can be used to directly derive control signals that can allow for further access to wafer resources And release secrets for authentication; enable trusted reporting, management, and repair between external entities and potentially partially failed devices; eliminate the need for explicit integrity check procedures in the launcher, and eliminate storage and protection boot The need for code reference values; or access authentication for different stakeholders across common interfaces (such as wafer boundaries or public internet).

The Platform Integrity Policy Engine (PIPE) can be part of the overall platform trust system architecture. PIPE can control multi-stage authentication and key release procedures. The PIPE can control different functions, including the flow of the secure boot process, the processing of the integrity check measurements of the software and/or data elements, the subsequent execution actions according to the policy, and/or the flow of subsequent software load control. The policy may be defined by one or more external stakeholders (eg, manufacturer and/or operator) and provided on the device and updated in the field via a remote update procedure.

By continuing to install more and more functional capabilities and maintaining dynamic loading of components during runtime, PIPE can control the risk of compromised software functionality being loaded through controlled software and data verification and load operations. As an illustrative example, depending on the stage of progress in the load operation, the PIPE may apply one or more of the following in response to the authentication failure: power reduction to the platform; avoid loading damaged components or isolated components Trigger to an external entity (for example, a security gateway in the network) Or fix the manager's warning to notify low-level failure or compromised functionality; prevent access to features or security information on the platform, such as authentication keys, etc.; or, prevent security features on the platform Access, such as authentication algorithms.

In some cases the failure can be so severe that even a trusted environment may not be able to secure trust in the platform because core TrE functionality has been compromised. A low level of failure may trigger basic operations, such as generating a warning message for a preset trusted root signature, which may include integrity as well as replay protection and confidentiality protection. That is, in the event of a low-level security failure, disaster messages are released to the network through one or more available communication channels.

As the functionality of the load is built and becomes more complex, the device performs more complex actions, such as acting as a secure and trusted proxy for the network entity, which facilitates diagnosis, reporting, and/or replacement. Inquiring procedures for compromised software and/or configuration data; performing body code or data reload/update procedures or investigating more details, including complete verification of suspected tamper-evident components with more precise details to isolate the wrong location of the component.

Depending on the level of successful verification functionality, different access to resources on the platform can be provided (eg, via PIPE). If the component's integrity check fails, it will not be trusted. The detected failure can be safely flagged and indicated to the network (either explicitly or implicitly), and due to the failure condition, the startup process will branch. This type of integrity check failure can be considered as an execution process failure, whereby the verified component cannot be trusted, and launching the component can result in malicious, damaging, Wrong or incorrectly configured code, and this also causes the device to perform functions in a non-specific and unpredictable form. In this way, the loading of new components and available functionality is affected by the integrity of previously loaded components.

Therefore, the execution environment can be changed according to the control execution program and access privileges in each startup phase and each immediate program. For example, at each stage of the startup process, a decision needs to be made based on the integrity measurements made at the time. Subsequent phases and strategies use information passed from previous stages to determine its own operations through any available security method that exceeds the storage or information transfer of the execution phase (state, variables, parameters, registers, files, etc.). For example, the upper application authentication function can use the integrity information of previously loaded components to determine its own operations, including gating the key release required for successful authentication of external entities.

An example of a PIPE functional flow can include one or more of the following. The RoT will be verified and its integrity will be verified. The baseline TrE can be verified by RoT and its integrity will be verified. If there is a failure in the TrE check, one or more of the following are executed: blocking the release of the key needed to attach to the network; triggering a warning to the network (a fallback code can be loaded, which allows the warning to be sent Go to the network and / or this warning will trigger the remote body update program to replace the TrE); or reduce the device power. The basic communication connectivity code can be loaded, which can include one or more of the following: checksum loading the baseline operating system module; checksum loading the baseline management client; or verifying and loading the communication module. If a failure occurs, one or more of the following are performed: blocking the release of the key required to attach to the network; triggering the principal update procedure to replace the component by a warning (can be loaded Entering a fallback code, which can cause a warning to be sent to the network and/or the warning will trigger a remote body update to replace the base code); initiate a warning and remote component update; or reduce the device power. The checksum loads the remaining operating system and manages the client components. Checksum loads dynamic, relocatable, and/or reloadable function modules, and if a failure occurs, one or more of the following are performed: Blocking the release of keys needed to attach to the network Send a failure report through an agreement to the network (failure report will indicate failed components updated by the remote end of the network); send a warning and request remote component update program; or reduce device power.

PIPE actions will vary based on the successful validation of the startup chain. At each stage of the launch process, decisions need to be made based on the policies that have been applied and the integrity of the partial or overall evaluation of the underlying platform, which has been integrity checked at that time (or before). These strategies can be adopted by new strategies or replaced by new ones depending on the level of trust gained. The execution environment can be changed according to the control strategy of each startup phase. Subsequent phases and strategies use the information passed in the previous phase through information transfer or storage of available security methods that are beyond the execution phase (status, variables, parameters, registers, files, etc.). PIPE strategies can be provided by one or more stakeholders. For example, a stakeholder may have access to each policy, and each stakeholder may have access to some policies (eg, depending on the priority level or associated with a particular function). As another example, manufacturers can control low-level code policies, operators can control software and configuration policies, and application service providers can control high-level functional modules.

Although features and elements are described above in particular combinations, those of ordinary skill in the art will understand that each feature or element can be used alone or in combination with other features and elements. Moreover, the methods described herein can be implemented in a computer program, software or firmware, which can be incorporated into a computer readable medium executed by a general purpose computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read only memory (ROM), random access memory (RAM), scratchpad, cache memory, semiconductor memory device, magnetic media (eg, internal hard) Discs and removable magnetic disks), magneto-optical media and optical media (such as CD-ROM discs, and digital versatile discs (DVD)). The processor associated with the software is used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

The above-described embodiments are merely examples for the convenience of the description, and those skilled in the art will be modified as described above, and are not intended to be protected as claimed.

Claims (28)

A device for safely activating a device, the device comprising: performing an integrity measurement on a first code to be loaded and to be activated on the device; based on (1) a securely stored in the device a root device unique secret key and (2) the integrity measure of the first code to generate a first key, wherein the first key is valid when the integrity measure of the first code is valid And performing an encryption operation using the first key on at least one of data to be processed on the device, locally stored material on the device, and data communication with an external entity. The method of claim 1, further comprising: performing an integrity measurement of a second code loaded and activated on the device; based on (1) the first code and (2) The integrity measure of the second code to generate a second key, wherein the second key is valid when the integrity of the first code and the second code is determined to be valid; and The encryption operation is performed using the second key on at least one of the processed material, the material stored locally on the device, and the material communication with an external entity. The method of claim 1, wherein: the first code is a code that is first loaded after the device is securely launched using an unchangeable root of trust; The root device unique secret key securely stored on the device is only accessible to the key derivation function performing the generation of the first key; after generating the first key, the root device The unique secret key is made inaccessible to any element of the device; and the first key is accessible to the first code. The method of claim 1, wherein the first key is generated using a one-way key derivation function. The method of claim 2, wherein the second key is generated using a one-way key derivation function. The method of claim 1, wherein: generating a first certificate from the first key, the first certificate comprising a first asymmetric key comprising a first public key and a first private key a pair of keys, wherein the first asymmetric key pair is associated with the integrity measure of the first code; and data to be processed on the device, data stored locally on the device, and an external entity The first certificate is used to perform an encryption operation on at least one of the data communications. The method of claim 6, further comprising: signing the first public key with a private key associated with a device authentication, and transmitting the signed public key by a trusted entity Used for beaconing or authentication generation; and receiving a beacon or other authentication that includes the first public key and is signed by the trusted entity. The method of claim 7, further comprising: using the signed first public key to transmit the integrity measure of the first code, the device authentication, an identity of the device, and the At least one of a public key associated with the device authentication. The method of claim 2, wherein: generating a second certificate from the second key, the second certificate comprising a second asymmetric key comprising a second public key and a second private key a pair of keys, wherein the second asymmetric key pair is associated with the integrity measure of the second code; and data to be processed on the device, locally stored material on the device, and an external entity The second certificate is used to perform an encryption operation on at least one of the data communications. The method of claim 9, further comprising: transmitting, by the trusted entity, the integrity measure of the second code and the second public key for signal or authentication generation; and receiving the The second public key and a beacon or device authentication signed by the trusted entity. The method of claim 2, further comprising: deleting the generated data related to the second key after generating the second key, including the integrity measurement for the second code Loading and starting the second code; passing control of the device to the second code; and wherein the second key is accessible to the second code. The method of claim 1, wherein the first code package Includes executable code and documentation. The method of claim 2, wherein the second code comprises executable code and data. The method of claim 1, further comprising deleting the generated data related to the first key, including the integrity measure for the first code, after generating the first key; Loading and starting the first code; passing control of the device to the first code; and wherein the first key is accessible to the first code. A device comprising a processor and a memory, the memory storing a computer executable indication, the computer executable instruction causing the device to perform an operation when the computer executable instruction is executed by the processor, comprising: Performing on the device an integrity measurement of a first code to be loaded and to be initiated; based on (1) a device unique secret key securely stored in the device and (2) the first code The integrity measure to generate a first key, wherein the first key is valid when the integrity measure of the first code is valid; and the data to be processed on the device is The encryption operation is performed using the first key on at least one of locally stored material on the device and data communication with an external entity. The device of claim 15, wherein when the indication is executed by the processor, the device is caused to perform more operations, including: executing, on the device, a first to be loaded and to be activated Two code An integrity measure; generating a second key based on (1) the first code and (2) the integrity measure of the second code, wherein when the first code and the second code are integrity The second key is valid when the measurement is valid; and the second is used on at least one of the device to be processed on the device, the data stored locally on the device, and the data communicated with an external entity The key performs an encryption operation. The device of claim 15 wherein: the first code is code that is first loaded after the device is securely activated using an unalterable root of trust; is securely stored on the device The root device unique secret key is only accessible to the key derivation function that performs the generation of the first key; after generating the first key, the root device unique secret key is made Any element of the device is inaccessible; and the first key is accessible to the first code. The apparatus of claim 15, wherein the first key is generated using a one-way key derivation function. The apparatus of claim 16, wherein the second key is generated using a one-way key derivation function. The device of claim 15, wherein when the indication is executed by the processor, causing the device to perform more operations comprises: generating a first certificate from the first key, the first certificate comprising a first asymmetric key comprising a first public key and a first private key a pair of keys, wherein the first asymmetric key pair is associated with the integrity measure of the first code; and data to be processed on the device, data stored locally on the device, and an external entity The first certificate is used to perform an encryption operation on at least one of the data communications. The apparatus of claim 20, wherein when the indication is executed by the processor, causing the apparatus to perform more operations, comprising: signing the first public key with a private key associated with a device authentication Key, and the signed public key is sent by a trusted entity for beaconing or authentication generation; and receiving a beacon or other authentication that includes the first public key and is signed by a trusted entity . The apparatus of claim 21, wherein when the indication is executed by the processor, causing the apparatus to perform more operations, comprising: using the signed first public key to transmit the first code At least one of the integrity measure, the device authentication, an identity of the device, and a public key associated with the device authentication. The apparatus of claim 16, wherein the apparatus, when executed by the processor, causes the apparatus to perform more operations, comprising: generating a second certificate from the second key, the second certificate comprising a second asymmetric key pair of a second public key and a second private key, wherein the second asymmetric key pair is associated with the integrity measure of the second code; and on the device Processed data, local storage on the device The stored data and the second certificate are used to perform an encryption operation on at least one of the data communication with an external entity. The device of claim 23, wherein the indication is executed by the processor, causing the device to perform more operations, comprising: transmitting the integrity measure of the second code by a trusted entity The second public key is used for beaconing or authentication generation; and receiving a beacon or device authentication that includes the second public key and is signed by the trusted entity. The device of claim 16, wherein when the indication is executed by the processor, causing the device to perform more operations, comprising: deleting the second key after generating the second key The generated data, including the integrity measure for the second code; loading and starting the second code; passing control of the device to the second code; and wherein the second key is The second code is accessible. The device of claim 15, wherein the first code comprises executable code and data. The device of claim 16, wherein the second code comprises executable code and data. The device of claim 15, wherein when the indication is executed by the processor, causing the device to perform more operations, comprising: deleting the first key after generating the first key The generated data, including the integrity measure for the first code; loading and starting the first code; Passing control of the device to the first code; and wherein the first key is accessible to the first code.