Method and apparatus for h(e)nb integrity verification and validation

This application relates to communications.

Cross-reference of related applications This application is incorporated by reference in its entirety as if fully described herein, US Patent Provisional Application No. 61 / 157,833, filed March 5, 2009, 2009. US Patent Provisional Application No. 61 / 222,067 filed June 30, 2009, US Patent Provisional Application No. 61 / 235,793 filed August 21, 2009, and filed September 3, 2009. Claims the benefit of US Patent Provisional Application No. 61 / 239,698. This application is incorporated by reference, as if fully described herein, and is simultaneously filed with U.S. Patent Application No. 12 / 718,480 entitled "Platform Validation and Management of Wireless Devices." Related to the specification.

H (e) NB (home evolved node B), also known as a femtocell, is generally a small portable access point to a 3G network located on the premises or home of a party called the hosting side (HP). is there. H (e) NB acts as an intermediary for mobile communications and services within a small, designated geographic area. H (e) NB can be used to provide mobile services in areas that were previously inaccessible (due to poor radio conditions), such as premises or factory environments. Since H (e) NB can be a unified access point to broadband Internet and mobile networks, H (e) NB is also an option for SOHO (small office home office) sectors.

This application may raise specific security requirements. For example, these devices are no longer considered i) a closed, immutable environment for storing and handling confidential data, as mobile handsets were traditionally considered, and ii) these specialized devices are generally H ( e) As the primary party to the NB, it is not under the direct physical control of a mobile network operator (MNO) who operates the H (e) NB to service users of mobile communication terminals, iii) these devices In general, they are connected to the core network via insecure links and so that they can be intermittent rather than continuous.

<p> The existing or standardized technology of mobile communication networks is sufficient if the network becomes credible, even if the H (e) NB it operates is credible even if the H (e) NB goes through traditional authentication steps. Can't provide a way to be considered. Therefore, what is needed is a way to help the MNO authenticate and validate the credibility of the device, that is, to manage and provision such a device. is there.</p>

<p> Disclosed herein are devices and methods that enable H (e) NB (home evolved node-B) integrity validation using autonomous validation and semi-autonomous validation.</p>

It can be understood in more detail by the following explanation given as an example together with the attached drawings.<figref num="1">It is a figure which shows the organization example of a module, functionality and a component.</figref><figref num="2">It is a figure which shows the organization example of a component and functionality.</figref><figref num="3">It is a figure which shows the TR069 architecture example for provisioning for software download.</figref><figref num="4">It is a figure which shows the example of a basic integrity measurement and a report.</figref><figref num="5">It is a figure which shows the example of the integrity report and the reference material.</figref><figref num="6">It is a figure which shows an example of comparison between a validation report and a reference manifest.</figref><figref num="7">It is a figure which shows the example of the component information in a reference manifest.</figref><figref num="8">It is a figure which shows the example of the certificate management architecture.</figref><figref num="9">It is a figure which shows the example of the reconstruction of H (e) NB (home evolved-Node B) (H (e) MS).</figref><figref num="10">It is a figure which shows the example of the autonomous validation (AuV) repair.</figref><figref num="11">It is a figure which shows the example of a file package format.</figref><figref num="12">It is a figure which shows the network architecture example of semi-autonomous validation (SAV).</figref><figref num="13A">It is a figure which shows the flowchart example for a SAV procedure.</figref><figref num="13B">It is a figure which shows the flowchart example for a SAV procedure.</figref><figref num="14">It is a figure which shows the flowchart example for SAV repair.</figref><figref num="15">It is a figure which shows the result example of the integrity check.</figref><figref num="16">It is a figure which shows the list example of the failed functionality.</figref><figref num="17A">It is a block diagram showing an example of an entity set and its relationship and an interface for platform validation and management (PVM).</figref><figref num="17B">FIG. 6 is a block diagram showing another example of an entity set and its relationships and interfaces for a PVM.</figref><figref num="18A">It is a signal diagram which shows the example of the validation method using a platform validation entity.</figref><figref num="18B">It is a signal diagram which shows the example of the validation method using a platform validation entity.</figref><figref num="18C">It is a signal diagram which shows the example of the validation method using a platform validation entity.</figref><figref num="19">It is a figure which shows the LTE (long term evolution) wireless communication system / access network.</figref><figref num="20">It is an exemplary block diagram which shows the LTE wireless communication system.</figref>

As used herein, the term "WTRU (Wireless Transmitter / Receive Unit)" refers to UE (User Equipment), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, PDAs (Personal Digital Assistants), computers, or Includes, but is not limited to, any other type of device that can operate in a wireless environment. As used herein, the term "base station" shall operate in a node B, site controller, access point (AP), gateway, customer premises equipment (CPE), or wireless or wireline environment. Includes, but is not limited to, any other type of interface device capable of. When referred to below, the term "HMS" refers to HMS (Home NodeB Management System) and HeMS (Home Enhanced-NodeB Management). Including, but not limited to, System), the two can be collectively referred to as H (e) MS, Device Management System (DMS), Configuration Server (CS), Automatic Configuration Server (ACS), or "Base Station". It can also be referred to as any other type of system that manages configuration or functionality. The terms "WTRU" and "base station" are not mutually exclusive. For example, WTRU can be H (e) NB (enhanced Home Node-B). As used herein, the term "information-theoretically secure" includes, but is not limited to, completely safe, unconditionally safe, and information-theoretic near-safety. When referred to below, the terms "trust," "trusted," and "trustworthy," and their variants, whether the unit works in a particular way. Shows a quantifiable and observable method for evaluating.

Equipment and methods for H (e) NB (home evolved node-B) integrity verification and validation using autonomous validation (AuV) and semi-autonomous validation (SAV) Is described herein. Details common to AuV and SAV are provided, followed by implementation details for AuV and SAV.

A method for determining a reliable reference value (TRV) used in a validation method is described herein. Device integrity checking is a common procedure for validation methods. For device integrity testing, a set of TRVs is required to be able to check the integrity of the measurements made on the component. It may be desirable that such integrity checking of the component should be done before the component is loaded. It may also be desirable for such TRVs to be able to be authenticated and ensured integrity by themselves before being used.

Different integrity check methods can be used to perform integrity checks and provide and generate TRVs. For example, the method of generating the TRV corresponding to the code may include a digital signature method, and a hash-based message authentication code or an encryption-based message authentication code may also be considered.

The digital signature method is described herein. In the digital signature method, public key cryptography can be used. The H (e) NB can digitally sign the hash (or generally the check word) of the module by encrypting the check word with its private key. The encrypted check words can then be sent to the platform validation entity (PVE), which can be decrypted in PVE with the public key of H (e) NB and compared to TRV. For local integrity checks, reference integrity checks can be signed by the manufacturer and verified locally within H (e) NB. As a non-limiting example, Table 1 reveals several digital signature methods.

<tables num="1"><img file="JP2012520024A_D0001.tif" /></tables>

Hash algorithms and hash-based message authentication codes are described herein. Hashing is a unidirectional or nearly unidirectional function that produces a unique (or nearly unique) and irreversible (or nearly irreversible) summary of its input. Digital signatures in many cases are nothing more than encrypted hashes. The digital signature method can use a public / private key pair, and the MAC (message authentication code) can use a shared secret key. Check words can be created via modules (concatenated modules and keys) that have a built-in secret key. As a non-limiting example, Table 2 reveals several hash algorithms as well as hash-based message authentication code methods.

<tables num="2"><img file="JP2012520024A_D0002.tif" /></tables>

An encryption-based message authentication code is described herein. Checkwords can be created by a hash algorithm and then encrypted using a private key. As a non-limiting example, Table 3 reveals some encryption-based message authentication code methods.

<tables num="3"><img file="JP2012520024A_D0003.tif" /></tables>

An integrity metric is a digest (eg, a cryptographic hash value) generated by performing an integrity method on a software component. Components are considered herein to be the smallest possible unit of integrity testing. Individual binary executable or pre-executable files are examples of components. Modules, on the other hand, are considered herein as the smallest unit for a software package manufacturer to certify and distribute. For the rest of this description, in general, as shown in Figure 1, 1) a component can always consist of one or more modules, and 2) any one module appears only once in a component (ie, that is). One module cannot appear in two components). A list of software modules and their associated attributes, such as modules, reference integrity metrics (RIMs) corresponding to severity, and other information to support device integrity checking and validation in AuV and SAV. May have to be provided. The Reference Integrity Metric (RIM) serves as a reference value for the integrity of individual modules. In the case of AuV, the list can be generated by the manufacturer and safely stored on the device, and in the case of SAV, the list is generated by the manufacturer and given to the platform validation entity (PVE) (all modules). , Can also be provisioned in H (e) NB (for Stage 1 and Stage 2 modules in multi-stage startup implementations). How software modules are organized, structured, or stored, and what kind of such modules may be present in the device, may depend on the H (e) NB implementation. , Modules and their attributes can be specified using a common specification language.

For example, XML (extended markup language) and ASN.1 (abstract syntax notation 1) based methods can be used to implement common specification languages. The device configuration data sheet contains a list of software modules and various attributes associated with the modules. The data sheet can also specify the classification of modules into components and functionality.

An XML-based specification of software module attributes that can provide a common highly portable language for specifying H (e) NB components and / or modules and associated attributes is described herein. The language that specifies the module must be evolved to provide information in a portable and H (e) NB architecture-independent manner. The language may be similar to an XML language that includes XML Schema and XML documents. Module formats and various attributes can be standardized, and all manufacturers provide device configuration data sheets that describe software modules in a prescribed format. The format may be similar to the XML schema, and the device configuration data sheet may be similar to the XML document. XML signatures provide support for adding digital signatures for integrity, message authentication and / or signer authentication. Binary XML is a more concise representation and can also be used as the basis for reducing parsing costs and reducing the bandwidth required for communication of configuration data from one entity to another. An example XML schema is shown in Table 4 and may be in standard format where the manufacturer can specify the module.

<tables num="4"><img file="JP2012520024A_D0004.tif" /></tables>

The manufacturer provides a device configuration data sheet and can sign the sheet with a digital signature. This device configuration data sheet can be maintained at H (e) NB for AuV. In cases where the check fails, the appropriate action can be taken if the digital signature of the device configuration sheet itself is verified. This is because software attributes, including information about the effects of any failed module, are compromised even if the software module itself (ie, the binary image) has changed and the integrity check has failed. This is because it means that it is not. In the case of SAV, the device configuration sheet can be maintained at the device and PVE. Additional actions can also be added to support SAV, as described herein.

An ASN.1-based specification of software module attributes that can provide a common highly portable language for specifying H (e) NB components and associated attributes is described herein. In telecommunications and computer network connections, ASN.1 is a standard and flexible notation that describes data structures that represent, encode, transmit, and decode data. ASN.1 can describe the structure of objects that are independent of machine-specific coding techniques and can provide a set of official rules, a precise formal notation that disambiguates. As commonly used to define messages for communication protocols, ASN.1 results in binary coding, along with the coding rules associated with it. Other communication protocols, such as the Internet Protocols HTTP and SMTP, use text tags and values to define messages, sometimes based on ABNF (Extended Backus-Naur Form) notation. This definition, which also defines coding, is in text format.

The ASN.1 method is believed to be more efficient and uses compression coding rules to certainly provide more concise coding. Text techniques are claimed to be easier to implement (by creating and parsing text strings) and easier to debug because they only need to read the encoded message. In the case of the Megaco protocol, two codings were defined based on ASN.1 and ABNF.

The ASN.1 XML Coding Rules (XER) allow text encoding of data structures defined using ASN.1 notation. General string coding rules have also been defined for the sole purpose of presenting and entering data with the user. An example of ASN.1 that conveys the device integrity metric can be shown in Table 5.

<tables num="5"><img file="JP2012520024A_D0005.tif" /></tables>

For each software module on the device, during the SAV procedure, H (e) NB fails the integrity check during the local integrity check procedure if the module attributes associated with it are known to the network. Only the list of identifications (IDs) needs to be sent to the PVE. The network will be aware of the relevant attributes of a particular software module and the impact of module failure via PVE. This information can be used to assess the next steps the network will take, as described herein.

Can be considered to be sent to H (e) NB and is digital certificate or signed by a trusted third party (TTP) such as the H (e) NB Management System (H (e) MS). Software module attributes that can be provisioned as messages are described herein. For example, the overall information element for a code image may include, but is not limited to, the manufacturer of the H (e) NB and the integrity method that can be used to generate a digest or RIM of the module code image.

A method for describing component-specific information is described herein. One or more components form a software module. A component is the basic unit of integrity testing. There is one trusted reference value (TRV) associated with each component. A component-specific information element may include a component ID, which is a uniquely identifiable ID that corresponds to the component description. This is the unit ID of the code that should be checked in one TRV. The information element may further include a TRV that can be used by the integrity check mechanism on the H (e) NB to compare the measured values of the components and verify the integrity of the components.

Module-specific information elements may include, but are not limited to, a module description that describes the unique module functionality within the H (e) NB and a module ID that uniquely identifies the module to the manufacturer. This information element can be a feature description and a globally identifiable ID that identifies the unique functionality of the H (e) NB to which this module is mapped, standardized across multiple vendors, and feature description. It may also include a corresponding function ID. This information element may further include a release version that indicates the component ID and module version number that identifies the component to which this module maps. In cases where there is a one-to-one mapping between components, module-specific information can be virtually identical to component-specific information.

Module-specific information elements can also include severity classifications that specify the impact of current software integrity check failures on system functionality. For example, there may be a multi-level severity classification system. For example, severity 1 may be a module / function failure that results in a high impact on H (e) NB functionality and can guarantee system outage. Module / feature failures can result in disruption along the system based on the fallback code image (FBC). In this case, it may be possible to communicate with a network-based device management system (which would be H (e) MS if the device is H (e) NB). The FBC may be able to send an emergency signal to the designated H (e) MS. In addition, it can support network-initiated firmware / software updates. For example, any module or component for the H (e) NB Reliable Environment (TrE) can have a severity of 1. Severity 2 may be a module / feature failure that may result in limited H (e) NB functionality, which partially functions as a subset of full H (e) NB functionality. Can, or can support a subset of full H (e) NB functionality. In this case, communication with the security gateway (SeGW) may be possible. Severity 3 may be a module / feature failure that cannot affect the core functionality of the system, but in the case of failure it can still be considered significant enough to seek early repair. Failed modules / features can be replaced via an immediate firmware / software update procedure and validated by a subsequent reboot. Severity 4 may be a module failure that cannot affect the core functionality of the system. Failed modules (s) can be replaced via a regular firmware / software update schedule.

Reporting procedures or methods for validation methods are described herein. All device integrity checking procedures can be performed locally for AuV. If the integrity check fails, an emergency signal can be sent to the H (e) MS to indicate the failure. Subsequent actions can be extended from the sender to solve the problem or quarantine the device. Repairs can be performed in cases where a list of failed modules can be reported to the repair server / H (e) MS. In the case of SAV, a list of functionality that failed the integrity check may be reported to PVE.

The module depends on the manufacturer's implementation. A set of compiled software modules can form an object image. Integrity checks can be performed on object image chunks. Therefore, a component is introduced that combines a set of modules for which an integrity check is performed. A module appears once in a component and in only one component (ie, one module cannot appear in two components). Thus, once the integrity check is performed, the module is examined only once. How the H (e) NB manufacturer (which may be the same as or different from the manufacturer of any individual software module) divides the modules into components for device integrity checks based on the architecture. To determine.

Functionality may be based on H (e) NB requirements and functional architecture, and may be standardized identifiers. For example, Iu interface and mobility management are features. Modules can be shared between the two features. Therefore, if a component (which is an integrity check unit) fails an integrity check, the affected module is known. Since each module has the functionality associated with it, a list of failed functionality can be derived. This list of failed functionality is sent to PVE in SAV.

Functional IDs are described herein. The implementation of the architecture governs the number and type of software modules. In order to harmonize the reporting structure and procedures across multiple products and / or stakeholders (such as mobile network operators), reporting can be based on functionality rather than actual modules. Software modules can be grouped based on their functionality. Functional IDs provide a means for classifying modules based on functional descriptions. Table 6 lists some of the functionality that has been derived based on what is currently known. This list can be extended and standardized. In Table 6, numbers with last significant digits 1-9 are set aside for future use or extensibility.

<tables num="6"><img file="JP2012520024A_D0006.tif" /></tables>

<img file="JP2012520024A_D0007.tif" />

<img file="JP2012520024A_D0008.tif" />

The component ID is described herein. To reconcile multiple device integrity checks, modules can be categorized based on the generated image. A set of object files can be archived together in an image file. Such module groups contain the same component ID, are collectively checked for integrity, and therefore have one reliable reference value (TRV) for one component. Each software module has its own reference completeness metric (RIM), so a component's trusted reference value (TRV) is a concatenation of one or more software modules, each of which can have an associated RIM. It can be obtained as a digest (eg, hash). Note that a module that appears with one component ID can be mapped to a different functionality ID than the same module that appears with another component ID. This procedure gives the manufacturer flexibility based on its architecture and compiler, allowing module grouping based on either the object image or the SAV integrity check stage, for example.

Module IDs are used to track various modules of software and can be standardized, if not impossible. If the module ID is not standardized, it is up to the manufacturer to decide which module and how many modules are present. Module IDs can be used to provide, track, and assemble firmware / software update packages.

A method and structure for organizing and describing relationships between various identifiers, such as modules, components and functionality, are described herein. FIG. 1 shows an example method and structure. The software architecture defines the number and type of modules. These modules are categorized based on their functionality and integrity check units. A component consisting of multiple modules has its own TRV. If any component's integrity check using that TRV fails, the component itself has been changed, its digest is no longer the same as the TRV value, or the TRV corresponding to the component has been changed. In either case, if the integrity check fails, it fails (or at least is "affected", using the mapping between the module and the component that failed the integrity check and the mapping between the module and functionality. It is possible to judge the list of functions. A list of affected functional identifiers can be communicated to H (e) MS or PVE.

Figure 2 shows a structural example of components and functionality. As shown in the figure, when a component is a unit for which an integrity check is performed, the component can be determined by the manufacturer. A list of functionality can be associated with each component. Components are based on functionality. Therefore, if a component fails an integrity check, a list of failed functionality can be assembled. The components can be organized in their load order or in their execution order. Therefore, if component 1 fails the check, the functionality of component 2 that uses the functionality in component 1 for either loading or execution can also fail.

Another alternative implementation for extracting a list of failed functionality based on a failed integrity check may be to perform an integrity check on chunks of image object files. Start address and end A in the object image is an image block specified by the address is, if not pass the integrity check, the name of the software features corresponding to the failed segments are extracted. A list of failed H (e) NB functionality can be derived based on the implemented functionality. This derivation can be done because the software function belongs to a module that implements certain H (e) NB functionality. For example, in a UNIX® environment, "nm" provides functionality for extracting the names of features in object files. This information is extracted from the object's symbol table.

Software and TRV downloads and provisioning for validation methods are described herein. The three protocols that can be used are the TR069-based architecture, the OMA (Open Mobile Alliance) DM (Device Management) -based architecture, and the TCG (Trusted Computing Group) IWG (Infrastructure Work Group) -based architecture. In addition, these protocols can also be used to configure H (e) NB with provisioning support. Other protocols besides these three can be considered.

The TR069-based architecture in Figure 3 describes a CPE WAN (wide area network) management protocol intended for communication between CPE (customer premises equipment) and automated configuration servers (ACS). CPE maps to H (e) NB and ACS maps to H (e) MS / Repair Server / OAM (Operation, Management and Maintenance). The CPE WAN management protocol may provide tools for managing downloads of CPE software / firmware image files. This protocol may provide a mechanism for version identification, file download initiation (ACS initiation download and optional CPE initiation download), and notification of success or failure of file download to ACS.

The CPE WAN management protocol can also define a digitally signed file format that can optionally be used to download individual files or packages of files according to the explicit installation instructions that CPE should perform. This signed package format ensures the integrity of the downloaded file and associated installation instructions and allows parties other than the ACS operator to authenticate the file source. The integrity check of the downloaded file can be based on a comparison of the integrity digest (eg, hash) calculated from the individual modules contained in the downloaded file with the corresponding RIM value.

The CPE WAN management protocol can be useful for downloading the TRV required for device integrity checking to the H (e) NB. Such content can be digitally signed with the signature key of the network operator. Upon receiving the signed packet, the H (e) NB can then decrypt the signature and verify the authenticity and integrity of the received TRV. In cases where the component is assembled as an ordered concatenation of several modules, the TRV can be assembled as an ordered concatenation of the RIM corresponding to the module.

The TRV may be encrypted for confidentiality before being digitally signed. The TRV can be attached to the entire or (first or last) part of the software module binary image that the TRV creates for it in the same digitally signed packet.

Additional procedures for dealing with H (e) NB devices are described herein. These additional requirements and procedures can use the interface identified as the H (e) NB-H (e) MS interface in the description below. Validating the H (e) NB may require additional protocol component requirements. H (e) NB-H (e) MS supports SSL / TLS (Secure Socket Layer / Transport Layer Security), certificate-based authentication between H (e) NB and H (e) MS Should be used. This certificate can be the same certificate used to authenticate to SeGW. When a TR069-based architecture is used for the H (e) NB-H (e) MS interface, basic or digest authentication for CPE authentication must be adapted to support certificate-based authentication. obtain.

Procedures or structures that may be required for H (e) MS discovery based on the TR069 architecture are described herein. The H (e) NB should consist of the default H (e) MS URL (uniform resource locator) in the ManagementServer.URL parameter. This initial configuration can be done by the operator or by the manufacturer while distributing the H (e) NB. H (e) NB can support the LAN (Local Area Network) side ManagementServer.URL configuration by an authorized administrator. The H (e) MS URL may be an HTTPS (Hypertext Transfer Protocol Secure) URL. Hosting DHCP (Dynamic Hosting Configuration Protocol) based H (e) MS URL update procedures do not have to be supported. If the value is updated locally, the H (e) NB can contact the new H (e) MS to bootstrap the configuration file and establish affinity. If the URL is a name or IP (Internet Protocol) address, DNS (Domain Name System) resolution may be sought. DNS resolution of a name may return multiple IP addresses, in which case it is certain that multiple IPs should not be returned, or if multiple IPs are returned, H (e). Either NB randomly picks one.

The SeGW discovery based on the TR069 architecture is described herein. Like the H (e) S URL, the SeGW URL can be added as a parameter (SecureGateway.URL). This URL may be configured by the operator based on the location of H (e) NB. Updating this parameter by DHCP cannot be supported. Local updates can be performed by an authorized administrator.

Additional mechanisms for adapting device management protocols such as TR069, OMA DM, or TCG IWG for AuV and SAV purposes are described herein below.

An OMA DM-based architecture that downloads and provisions software and TRVs for validation methods is described herein. OMA DM is a device management protocol jointly specified by the OMA DM workgroup and the DS (Data Synchronization) workgroup. OMD DM was developed for small footprint mobile devices such as phones, PDAs, and other similar devices, but does not support broadband wireline connectivity between the device and the DM server and is short-range wired. Connectivity (eg USB (Universal Serial Bus) or RS232C) or Wireless Connectivity (GSM (Global System for Mobile Communications), CDMA (Code Splitting Multiplexing), WLAN (Wireless Local Area Network), and Other Wireless Communications Only system) is supported and can be useful as a device provisioning and management protocol for H (e) NB. This presents itself as a WTRU (Wireless Transceiver) to the core network, a common serial gateway (CSG) and a non-CSG that connects to it. This may be true for H (e) NB, which can present itself as a base station to WTRU.

OMA DM may support use cases such as provisioning (including initial device configuration, enabling / disabling features), device configuration updates, software upgrades, and diagnostic reporting and querying. The OMA DM server side can support all of these features, but the device may optionally implement all or a subset of these features.

The OMA specification can be optimized to constrain connectivity and support the features listed above for small footprint devices. This specification may also support integrated security using authentication protocols that are part of those specifications (by using protocols such as EAP-AKA (extensible authentication protocol-authentication and key agreement)).

OMA DM can use XML (or, more precisely, a subset of SyncML) for data exchange. This can be useful to provide a standardizable yet flexible way to define and communicate attributes for software modules or functionality for H (e) NB for validation purposes. ..

Device management occurs between the DM server (the management entity for the device) and the client (the managed device). OMA DM supports transport layers such as WAP (Wireless Application Protocol), HTTP, or OBEX (Object Exchange) or similar transports.

DM communication is initiated asynchronously by the DM server using any available method, such as WAP, push or SMS (Short Message Service), using either notification or warning messages. Once the communication between the server and the client can be set up, the sequence of messages can be exchanged to complete a given DM task.

OMA DM communication may be based on a request response protocol, in which the request can only be made by the DM server and the client only needs to respond with a reply message. Both the server and the client have states, which means that any data exchanged due to a unique sequence can only occur after the built-in authentication procedure.

Since DM communication can only be initiated by a DM server, implementing SAV via DM may require a server query-based approach to validation, potentially (immediately). ), Follow the device validation procedure using IKE (Internet Key Exchange) v2 (initiated by the device). Several different message types can be considered as a conveyor for validation data (eg, a list of failed software modules or device functionality). For example, management warning messages can be sent from the device to the server. Alternatively, a user of a generic warning message that can be sent from a device to a DM server after at least one management warning message has been transmitted from either the device or the server can also be considered. All messages, including these warning messages, use the SyncML (Synchronous Markup Language) format, which gives you the flexibility to specify the content and metadata about the content, which can be useful for validating information transfer. DMs can support segmented data transfers, which can be useful for software updates where the size of the update can be large. Segmented data transfer is a failed feature of H (e) NB, from H (e) NB to PVE, in cases that are large enough to require segmentation into multiple messages due to the size of such information. It can also be used to transfer a list of sexes.

A TCG IWG-based architecture that downloads and provisions software and TRVs for validation methods is described herein. The TCG (Trusted Computing Group) and IWG (Infrastructure Working Group) specify detailed formats and protocols for platform integrity management. In the basic model for integrity measurement and reporting, network and service access can be conditioned on the validated state of the platform.

The TCG IWG standard provides a superset of the structures required for H (e) NB SAV or AuV. None of the IWG specifications can be used as is. In addition, profiling the IWG specification into specific use cases for device validation requires modification of the XML schema (eg, omission of required elements), which means a deviation from the IWG standard.

Figure 4 shows the basic dialogue between the requesting platform and the network-side verification source. The verifier needs to look for authoritative information about each of the components of the requesting platform (in the fifth step). That is, the verifier seeks a reference measurement to validate the platform made available by the metric provider. An example of a metric provider is a hardware manufacturer, software vendor, or a trusted provider on behalf of the manufacturer and vendor. The verifier can identify each component of the requesting platform and compare the reported measurements against the expected (baseline) reference measurements (for that component). , You can measure the trust level of the requesting platform. At this stage, the verifier can make decisions regarding the requesting party's request to access the resource / service at the relying party. This is shown in the sixth step.

Note that the IWG integrity verification architecture is largely independent of the presence of a hardware TPM (Trusted Platform Module) on the validated platform. In particular, the data formats specified in the standard can represent generic components and platform security related attributes.

To support technical confidence in a given component, the component manufacturer may support the manufacturer's product with information about the source of the component. That is, the manufacturer or a trusted third party must provide some static reference values for that component. These static reference / metric values for a component are called reference measurements and are expressed in the form of a TCG reference manifest (RM) structure. The manifest for a component contains information such as its identification, manufacturer, model number, version number, and more. For the purposes of this application, the reliable reference value (TRV) of the H (e) NB component can be specified by the TCG IWG reference manifest (RM) structure.

When the platform needs to be validated, it was compiled from a set of snapshots covering the components of the platform to the validation source (such as the platform validation entity, or PVE), as shown in Figure 5. A completeness report must be provided. Snapshots represent both measurements and assertions for all relevant components of the platform (and possibly subcomponents of these components). The reference (ID Ref) is used to point to information about the components reported in the integrity report, as shown in Figure 6.

The core elements for RM-based validation are described in the TCG standard. For flexibility, the XML namespace can be used for IWG formats, such as platform-specific profiles for mobile or PC clients.

The interoperable integrity log structure can address some platform-specific constraints by defining "hardware architecture" type values to direct platform-specific coding. Type values can be defined by TCG namespaces that use interoperable namespace mechanisms such as XML namespaces and XRIs.

The RM schema, which is inherited from the core schema by extension, defines the structure for holding references. The RM schema can be roughly understood as consisting of two sets of information, as shown in Figure 7. The first covers information about individual components, such as attributes such as component model, name, version, serial number. This information is incorporated into the ComponentIDtype structure. Peripheral information specific to this component is metadata regarding the acquisition (acquisition) of component information. This data is represented by the IntegrityManifestType structure in the schema. The metadata captured includes the collection (acquisition) method used, the RM signature (and associated signer / issuer information), the digest value (s) for the component (for software), the confidence level, and the confidence level. Includes assertions made and others.

Items specific to AuV are described herein. At AuV, integrity checks can be performed locally. Therefore, any of the digital signatures or message authentication codes described herein may be used. These can be signed by the manufacturer using the manufacturer's private / shared secret and their authenticity can be verified locally using the manufacturer's shared secret or public key to ensure code integrity locally. Can be used to verify.

However, with AuV, device validation can be done locally inside the device and no information is sent to any network entity. Therefore, the determination of the exact method for use in validation can be left to the manufacturer. However, minimum security requirements can be standardized, such as "integrity algorithms must provide security equivalent to or better than SHA-1".

It is described herein how AuV implements TRV certificate management. Since the components of the system depend on the actual implementation, it is necessary to harmonize multiple mechanisms used for device integrity. This can be achieved by standardizing the minimum requirements for the method used to generate a reliable reference integrity metric known as TRV. These TRVs can be generated either by the manufacturer or by a TTP that digitally signs the value. Therefore, the mechanisms for organizing information, generating, distributing, and using TRVs will be reviewed.

The initial TRV certificate initialization is described herein. After fully developing H (e) NB, the manufacturer performs local integrity data initialization. In this process, all software module names are collected in the device configuration data sheet. If any factory settings associated with the configuration file are present, those settings are also included in the device configuration data sheet. Modules are executable files, not source code. Initial provisioning of configuration data is also performed. The device configuration data sheet schema follows the standard schema. The XML or ASN.1 schema presented herein can be used as a baseline. All attributes for severity, compatibility, grade and others are populated based on the device's architecture.

Figure 8 shows the certificate management architecture 800. At the manufacturer's certificate server 805, all module entries 810 are populated with a reference integrity metric. The integrity method attribute and TRV attribute are populated. The device configuration data sheet is then signed by the manufacturer with a private key 820. The data sheet can also be certified by reference to the root certificate issued by TTP to the manufacturer. Thus, the reference integrity metric (RIM) is TRV830.

In alternative architectures, TRVs can be generated by TTP. The manufacturer provides an executable file and a partially completed device configuration sheet that lists all the modules and some submitted attributes that can be met at the manufacturer's site. The digest metric TRV is populated by TTP. The TTP then digitally signs the device configuration certificate.

Since AuV is implemented locally inside the device, the device configuration data sheet can be maintained inside the device. The device configuration data sheet must be kept in secure memory that can only be accessed by authorized parties. Alternatively, the device configuration data sheet must be encrypted and can be decrypted within the H (e) NB when read and used. In either case, only H (e) NB's trusted environment (TrE) should have the authority to release or modify the device configuration data sheet for read access by the application.

During the secure startup process, when the device makes a local measurement of the component, the generated digest is compared to the value specified in the device configuration data sheet. If a discrepancy occurs, it is interpreted as a failure to validate the device integrity. The integrity of the device configuration data sheet must be verified before it can be accessed. The integrity of the device configuration datasheet may be verified after the integrity check failure of one or more of the components specified in the datasheet.

Subsequent TRV certificate update procedures are described herein. For the deployed H (e) NB system, if the manufacturer issues a new software version, the manufacturer may provide the H (e) MS / OAM server / repair server with a device configuration data sheet along with the software module. it can. This can be done asynchronously by performing a "PUSH" operation by the manufacturer. Such PUSH may be scheduled based on a scheduled update / upgrade agreed between the operator and the manufacturer based on a service agreement signed between the operator and the manufacturer.

Following such PUSH, a firmware or software module that reboots when scheduled to instruct the device to perform a "PULL" operation for software / software from the H (e) MS / OAM / repair server. The OAM procedure or TR069 procedure for updating the firmware can be called. Encryption, signatures and nonces can provide security aspects such as confidentiality, integrity, and protection against replay attacks, respectively.

Alternatively, if the device configuration data sheet expires due to a scheduled expiration based on the software release schedule, H (e) NB will start the firmware / software update process and start PULL for software / firmware from the OAM / repair server. be able to. Alternatively, the H (e) MS could perform a scheduled PUSH of software updates based on a known schedule of software releases (eg, obtained from the manufacturer).

Procedures based on the TR069 or OMA DM architecture that support software / firmware downloads to the device are described herein. In the case of AuV, the TR069 protocol may provide support for remote management of customer premises equipment. This protocol may also provide support for device software / firmware updates. TR069 can be used to provide firmware / software updates to H (e) NB devices.

As shown in Figure 9, H (e) NB905 and H (for subsequent updates that can be performed at H (e) NB905 by an authorized administrator or by using a URL update procedure. e) Examples of AuV procedures with MS910 are described herein. The H (e) NB905 first sets the default H (e) MS in the ManagementServer.URL parameter (0) as described above for H (e) MS discovery. It consists of a URL (uniform resource locator). It can be provisioned by the manufacturer. The H (e) MS910 opens a TCP (Transmission Control Protocol) connection (1). An SSL (Secure Socket Layer) connection is established between the H (e) NB905 and the H (e) MS910 to allow secure communication (2). The H (e) MS910 initiates the RPC (remote procedure call) method SetParameterValues and updates the ManagementServer.URL (3). After a successful update, a SetParameterValuesResponse is sent by H (e) NB905 with a status field indicating success or failure (4). H (e) NB905 updates the H (e) MS URL (5).

An AuV procedure that supports file transfer using TR069 for the H (e) NB-H (e) MS interface is described herein. The TR069 supports file transfer via unicast and multicast transport protocols. Unicast protocols include HTTP / HTTPS, FTP (File Transfer Protocol), SFTP (Secure File Transfer Protocol) and TFTP (Trivial File Transfer Protocol). Multicast protocols include FLUTE (one-way transport file distribution) and DSM-CC (digital storage media command and). control) is included. HTTP / HTTPS support is mandatory. FTPS (FTP Secure) may be used in addition to HTTP / HTTPS to adapt TR069 to firmware / software downloads on the H (e) NB-H (e) MS interface and must be added to TR069. There is. FTPS (also known as FTP Secure and FTP-SSL) is an extension to FTP that adds support for TLS (Transport Layer Security) and SSL cryptographic protocols. Since the H (e) NB-H (e) MS interface uses the TLS-SSL interface, FTPS can be implemented for file transfer.

TR069 also provides support for reusing the same TLS connection that downloads files, downloading files that can exist in parallel, or spawning new connections to free the first session. After the download is complete, a TLS connection for signaling is established. If HTTP / HTTPS is used to download the file, you can use the standard TR069 procedure.

Examples of AuV procedures for repair support are provided herein. If the device integrity check fails in AuV, a local emergency flag can be set and the system reboots with a fallback code (FBC). The FBC can be safely stored inside the device and if a secure startup procedure (or any other device process that appears to be "essential" to ensure the basic integrity of the device) fails. Can be loaded and run. The FBC has basic communication capabilities with the core network and has the ability to send emergency signals to a pre-designated H (e) MS. The H (e) MS may have been updated by the H (e) MS discovery procedure. The contents of the emergency signal can be securely stored in the FBC on the device, or provisioned by an MNO and safely stored as part of the device configuration data sheet. The emergency signal may include an error code information element detailing the device integrity check failure. Upon receiving the emergency signal, the network can decide to update the complete image and device configuration file with reliable reference values. The FTP server stores a package file that contains a complete image, device configuration file, and installation instructions. The FTP server can be merged with H (e) MS.

This procedure can be performed by an FBC that supports the TR069 protocol, and Figure 10 shows an example flowchart 1000 between H (e) NB1005, H (e) MS1010 and FTP server 1015. If the device integrity check fails and the FBC has been started at the trusted root (RoT) of H (e) NB1005 (0), then the H (e) NB1005 is the pre-specified H (e) MS. Set up a TCP connection to server 1010 (1). SSL initiation is performed and / or TLS (Transport Layer Security) is set up (2). The H (e) NB1005 then calls the RPC method INFORMATION to the H (e) MS1010, eg, an emergency signal. The emergency signal can include any combination of information elements such as Device ID, Event, MaxEnvelopes and CurrentTime.

The Device ID indicates the manufacturer name, OUI (organizationally unique identifier) of the device manufacturer, and the class of the product to which the serial number corresponds, or the SerialNumber attribute to indicate the TrE ID or H (e) NB Id. A Product Class that can be used to indicate the serial number of a device to be used, and a Serial Number that can be used to send the serial number of a particular device, or to send a TrE ID or H (e) NB ID. It is a structure that can be included.

The Event field may contain the event code that caused the RPC method Inform to be executed. The new event code (X_HeNB_FBC Invoked) may need to be defined to indicate that the device integrity check has failed and that the FBC has been called to send this emergency signal. The MaxEnvelopes value, which indicates the maximum number of occurrences of a parameter called "SOAP envelope" that can be included in a single HTTP response for ACS (eg, H (e) MS), may be set to 1. The value of the MaxEnvelope parameter can be greater than or equal to 1. Since emergency instructions are intended to be sent only once, it is appropriate to set this value to 1. The CurrentTime field is the current date and time value known to H (e) NB1005. Therefore, the Inform RPC method indicates to the H (e) MS1010 that the device has failed the integrity check and is connecting to initiate a firmware / software update.

The rest of procedure 1000 is optional. The H (e) MS1010 can call the download of the RPC method and give the URL of the location of the firmware or software and device configuration datasheet (4). The following parameter values can be set. The CommandKey parameter is a string that can be used by H (e) NB1005 to point to a particular download. This can be any string used to correlate the download with the response. The FileType parameter can be set to "1, Firmware Upgrade Image" for the firmware / software image and "X_ &lt;OUI&gt; _data_sheet" for the device configuration data sheet. The URL parameter is the URL of the download file. HTTP and HTTPS must be supported. FTPS support is also recommended for downloads. The Username parameter can be used by H (e) NB1005 to authenticate to the file server. The Password parameter can be used by H (e) NB1005 to authenticate to the file server. The FileSize parameter is the size of the file to be downloaded. Other parameters can also be set.

The H (e) NB1005 connects to the FTP server 1015 and downloads the firmware image (or software image) and device configuration data sheet (5). The information at FTP server 1015 can be shown as repair information. If the download completes successfully, a DownloadResponse with a Status argument with a value of zero (indicating success) or a failure response (indicating failure) to the download request is sent (6). Alternative procedures may be taken to indicate successful or unsuccessful downloads. After a successful DownloadResponse, the H (e) MS1010 can then call the reboot procedure within the H (e) NB1005 (7). The RPC handler in H (e) NB1005 resets the local emergency flag, boots successfully, and implements the local integrity check procedure (8). The signed package format may include a reboot command, which can be used to instruct the H (e) NB1005 to reboot after the firmware or software has been updated. The TransferComplete RPC method may be called from the H (e) NB1005 to indicate to the H (e) MS1010 that the firmware / software update procedure has been successfully completed (9). Alternatively, SeGW may send a message to the H (e) MS1010 indicating that the device has successfully booted, which can be translated within the H (e) MS1010 as a successful firmware / software update completion message.

The file format example 1100, which can be used for H (e) NB firmware / software updates and is shown in FIG. 11, is described herein. Header 1105 may have a fixed length structure that includes the preamble, format version, and the length of the command list and payload components. Command Listing 1110 contains a set of instructions that can be executed to extract and install the files contained in the package. Each command may be in the form of TLV (type, length, value). Signature field 1115 may include PKCS (Public Key Cryptography Standard) # 7 Digital Signature Blocks, which may contain a set of zero or greater digital signatures. Payload file 1120 may contain one or more files that should be installed according to the instructions in command list 1110. In addition to firmware / software update files, device configuration data sheets are also packaged in a signed package format.

The following new H (e) NB-specific commands can be added to support storage classifier requirements. That is, it can be 1) stored in a secure non-volatile memory (for data such as TRVs and configuration data sheets), 2) stored in non-volatile storage, or 3) stored in volatile storage.

FIG. 12 shows an example network architecture 1200 for SAV. The H (e) NB1205 acts as a gateway for the user equipment 1210 and communicates via the communication link 1215 to the core network 1220. H (e) NB1205 interacts with SeGW1225 over an insecure communication link 1215. The SeGW1225 can allow an authenticated H (e) NB to access the core network 1220. The H (e) MS1230 acts as the H (e) NB management server and provides repair support. The H (e) MS1230 may support standard protocols for managing the H (e) NB1205. The platform validation entity (PVE) 1235 stores a policy in H (e) NB1205 that defines the action to be taken when a functional set fails. Such failed functionality is reported by H (e) NB1205 during the SAV process. OAM1240 is an operation, management and maintenance server. H (e) MS1230 and PVE1235 are shown as separate entities, but may be merged with each other as a single network entity. Such merged entities may be a single node per network operator or multiple nodes per operator.

Procedures related to SAV are described herein. In summary, before starting to implement the device validation procedure, the H (e) NB TrE first starts with the boot code, fallback code (FBC), basic communication code for SeGW, and H (e). Code that implements procedures that allow the NB to access the H (e) MS, but is not limited to it, and performs an integrity check of a particular pre-specified component. In this step, component integrity verification can be performed locally by comparing the digest output from the integrity measurement with the specified value in the device configuration data sheet. The component will be loaded and executed if it passes the integrity verification.

Further checks can occur either by the TrE itself or by a measuring component within the H (e) NB that is external to the TrE but whose integrity is protected by the TrE. In such late stage checks, the integrity of other components, configurations, or remaining parameters of H (e) NB is available when they are loaded or started, or they are available to the measuring component. If not, it can always be checked at other, predefined runtime events. At this step, the verification of the integrity check can be performed locally.

H (e) NB can then attempt to establish an IKEv2 (Internet Key Exchange) security association with SeGW. In this process, H (e) NB authenticates itself to SeGW and verifies the authenticity of SeGW. This can be done by certificate exchange and certificate authentication. If the authentication is successful, TrE communicates the results of the local integrity verification to PVE by compiling a list of failed functionality that is affected by the component failure. The TrE can then sign the message (using a TrE-protected signing key and thus protecting the integrity of the message), thereby measuring and verifying integrity, as well as failing functionality. The core part of the H (e) NB that made the report (to the PVE) of the list passed the integrity check performed on it (eg by the root of trust (RoT)) and therefore used the signing key. Assert that the signing operation can be performed or is essentially trusted by the use of the private signing key.

Figures 13A and 13B show example SAV procedures 1300 performed by H (e) NB1305, SeGW1310 and PVE1315. After validating the local integrity of the Component 1 and Component 2 modules, the modules are loaded and executed. The device integrity check and verification results for the component 3 module are sent by H (e) NB1305 to SeGW1310 and forwarded to PVE1315 (0).

The H (e) NB1305 can send an IKE_INIT message to initiate the establishment of an IKEv2 security association that includes a security parameter index for cryptographic algorithms, a version number, an IKEv2 flag, a Diffie-Hellmann value, and an initiator (1). SeGW1310 can send an IKE_INIT response to an IKE_INIT request message (2). The SeGW1310 can choose a cipher suite from the H (e) NB1305 and complete the Diffie-Hellmann exchange. H (e) NB1305 can put the certificate in IKE_AUTH_REQ and send it for mutual authentication (3). This may also include the results of integrity verification in the form of a list of failed functionality. If the local integrity verification is successful, then such a list of failed functionality is not included. In this case, an empty list is sent. The relationships between components, modules and functionality are described herein.

SeGW1310 can evaluate the certification of H (e) NB1305 and extract a list of functional IDs that should be sent to PVE1315 if present (4). If the certification evaluation is successful, SeGW1310 indicates this to H (e) NB1305 (5s). The SeGW1310 can also send its own certificate in response to H (e) NB. If the authentication fails, this is communicated to H (e) NB1305 (5f).

If the authentication was successful and the list of failed functions was included in the IKE_AUTH message, SeGW1310 will list the failed functions in H (e) NB. Forward to PVE1315 with ID (6). If there is no list, an empty list is sent to PVE1315. Based on the list of failed functionality, PVE1315 takes actions to be taken, such as quarantining the device, providing full access, providing partial access, or optionally requesting H (e) MS intervention for device repair. Can be determined (7). If PVE1315 determines that its affected functionality is not definitive and therefore H (e) NB1305 can function, it will indicate this to SeGW1310 and allow the device to access the network. (8s). SeGW1310 dictates the results of the device integrity assessment performed by PVE1315. If the failing module is not definitive, PVE1315 may allow H (e) NB1305 full access to the network (9s). If PVE1315 determines that H (e) NB should be sufficiently trusted for authentication, based in whole or in part on the received empty list of failed functionality, then H (e) The "validation" status of NB has been acquired. In this sense, validation translates to the judgment made by PVE1315, which, from a network perspective, shows that H (e) NB1305 is sufficiently credible for further dialogue with PVE1315.

If repair is supported, PVE1315 will direct the H (e) MS1320 to initiate a repair for the device identified by the H (e) NB ID in the message (8f_1). PVE1315 may also include a list of failed modules. Based on the list of failed functionality and the device-specific configuration data sheet, the H (e) MS1320 determines the required firmware or software update. If repairs are supported, PVE1315 can send instructions to H (e) NB1305 to prepare for repairs initiated by H (e) MS1320 (8f_2). Based on the response from PVE1315, SeGW1310 can restrict access and inform H (e) NB1305 of the result (9f). The system reboots in FBC mode to start device start repair (10). This step may be optional as the reboot can be handled by the H (e) MS1320 using the TR069 protocol for repair.

H (e) MS and PVE discovery procedures for SAV are described herein. The H (e) NB may consist of factory settings, including PVE, H (e) MS and OAM IP addresses. These settings can also be reconfigured by H (e) MS using the TR069 protocol using the RPC methods SetParameter and GetParameter supported by the TR069 protocol, as shown in Figure 9. Note that procedures can also be used to change the address of PVE. Similar additional parameters can be defined in the ManagementServer.URL parameter (PlatformValidationServer.URL) to maintain the PVE URL at H (e) NB. Similarly, the PlatformValidationServer.URL factory settings can be preconfigured at manufacturing time and then updated by TR069.

Integrity methods and procedures for SAV are described herein. In SAV, device integrity checks can be performed locally. The results of the integrity check can be passed to PVE in the form of a list of failed functionality. Therefore, any of the integrity checking methods described herein can be used, for example, as shown in paragraphs [0038]-[0040] of the original specification. Integrity checks are not performed by network entities. Therefore, the determination of the exact integrity method for use in validation can be left to the manufacturer. However, minimum security requirements can be standardized, such as "integrity methods must provide security equivalent to or better than SHA-1."

The mechanisms that can be used for TRV certificate management in SAV are described herein. The interfaces and messages that support SAV are listed first. The PVE-SeGW interface can use point-to-point protocol (PPP). PPP may provide authentication, encryption and compression support. Alternatively, TLS / SSL (Transport Layer Security / Secure Socket Layer) may be used.

There are multiple messages that can be sent via the PVE-SeGW interface. For example, the H (e) NB_Integrity_Information message may include a list of failed functionality sent by H (e) NB to SeGW and extracted by SeGW in an IKEv2 NOTIFY message. An example of the content of this message is shown in Table 7.

<tables num="7"><img file="JP2012520024A_D0009.tif" /></tables>

The response to the H (e) NB_Integrity_Information message is H (e) NB_Validation_Result shown in Table 8.

<tables num="8"><img file="JP2012520024A_D0010.tif" /></tables>

Since both are network entities, the PVE-H (e) MS interface can also be based on PPP. Alternatively, TLS / SSL can also be used. In one example, PVE and H (e) MS may be one entity. Table 9 shows an example of a message via this interface.

<tables num="9"><img file="JP2012520024A_D0011.tif" /></tables>

Alternatively, PVE may simply send a list of failed functionality (or, optionally, a list of all functionality checked for integrity, or a list of all functionality not checked for integrity). (e) The MS determines the action itself. This is shown in Table 10. Actions such as immediate remediation, remediation schedule, and request for administrator intervention may be performed by H (e) MS.

<tables num="10"><img file="JP2012520024A_D0012.tif" /></tables>

The H (e) NB architecture and functionality for SAV are described herein. The H (e) NB architecture may include an external TrE integrity checker. The H (e) NB's TrE may delegate the integrity verification task, which was the responsibility of the TrE, to an external entity that may be implemented hardware and / or software. it can. Such cases can be used if the TrE is not fast enough or if there are not enough resources to perform a device integrity check. In such cases, TrE verifies the integrity and authenticity of the hardware and / or software entities that will begin the device integrity validation task. After successful validation, TrE allows the external integrity checker to perform the task and report the results and measurement data to TrE.

The H (e) NB entity may have a local time server for time stamping various events, reports and communications with the network. Such a time server can be synchronized with time using NTP (Network Time Protocol). The time server code and NTP code can also be verified for integrity before being executed by a TrE or external TrE integrity checker.

The H (e) NB architecture may also provide validation and authentication bindings. The binding between validation and authentication, in addition to the mechanism used for validation and authentication binding in the AuV case, is an IKEv2 session, that is, a sensitive key and only when the integrity check is passed. May be provided by the release of authentication functionality. The certificate of authentication in SAV and the result of local validation can be sent in the IKEv2 IKE_AUTH_REQ message. SeGW filters and screens the list of failed modules and forwards them to PVE. If such a list is not included in the message, SeGW relays this information to PVE. PVE determines future actions and presents the results to SeGW and, in some cases, to H (e) MS.

In an alternative binding method, the H (e) NB is pre-equipped with a key pair, the private part of this pair is securely stored inside the TrE of the H (e) NB, and the public part is the H (e). Made available to NB. The manufacturer of H (e) NB could generate this key pair and therefore provision private and public keys. The H (e) NB receives from the AAA server in order for cryptographic means to generate validation and authentication bindings (where the AAA server calculates the secret-based calculated credentials and sends them to the AAA server. Encrypt the message (for example, IKE_AUTH response message) that requests H (e) NB to return it with the public key obtained from the certificate, and forward the encrypted data to TrE. TrE then decrypts the data and secret-based credentials needed to verify the authenticity of the H (e) NB's identification against AAA (eg, EAP-AKA RES if symmetric authentication is used). Calculate parameters (such as AUTH parameters based on the use of private keys if certificate-based authentication is used).

In an alternative binding method, used by H (e) NB's IKEv2-based device validation application, TrE keys and other sensitive computing powers have been successfully local integrity checks for H (e) NB. Unless known to TrE, it will not be made accessible to such applications.

The policy specifications stored in H (e) NB and PVE are described herein. The H (e) NB device configuration file describes the policies stored in H (e) NB, which describe attributes such as functionality ID, component ID, and module ID, which are described in detail herein. The device configuration sheet is initialized at the time of manufacture. Procedures for initializing this information and subsequent updates for AuV have been described herein and are applicable to SAV cases.

PVE policy configuration files can contain mappings between failed functionality and SeGW actions, H (e) NB actions, and H (e) MS actions. Based on the list of failed functionality, PVE may determine the action to be taken by H (e) NB, SeGW and H (e) MS. Table 11 defines these actions.

<tables num="11-1"><img file="JP2012520024A_D0013.tif" /></tables>

<img file="JP2012520024A_D0014.tif" />

<img file="JP2012520024A_D0015.tif" />

<tables num="11-2"><img file="JP2012520024A_D0016.tif" /></tables>

Methods of supporting repair in SAV are described herein. To support the repair, the H (e) NB interacts with the H (e) MS. This connection can be via SeGW or directly over the Internet using TLS / SSL. During the secure startup process, if the device integrity check fails with respect to the Stage 1 or Stage 2 code, which is pre-specified by the manufacturer and contains the code required for authentication and communication with SeGW, along with the code for TrE, the FBC It will be executed and a repair will be attempted.

FIG. 14 shows an example flowchart 1400 for SAV repair involving H (e) NB1405, H (e) MS1410 and FTP server 1415. If the device integrity check fails, and after RoT is started using FBC (0), the H (e) NB1405 makes a connection to the pre-specified H (e) MS server 1410 (eg TCP). Set up (using a connection) (1). SSL initiation is then performed and / or then TLS is set up (2). H (e) NB1405 then calls the RPC method Inform (eg, emergency signal) with H (e) MS1410 (3). The emergency signal can include Device ID, Event, MaxEnvelopes and CurrentTime.

The device ID is used to indicate the manufacturer name and the device manufacturer's OUI (organizationally unique identifier) and serial number to indicate the class of product in question, or to indicate the TrE ID or H (e) NB Id. A ProductClass that can be used to indicate the serial number of a device, and a TrE ID or H (e) NB ID that can be used to send the serial number of a particular device, to force the user to use the SerialNumber attribute. A structure that can contain a Serial Number field that can be used to send.

The Event field may contain the event code that caused the RPC method Inform to be executed. In order for TR069 to adapt to SAV repair, a new event code (X_HeNB_FBC Invoked) must be defined to indicate that the device integrity check failed and that FBC was called to send this emergency signal. possible. The MaxEnvelopes value is set to 1. This value can be ignored, but is set to 1. The CurrentTime field is set to the current date and time value known to H (e) NB1405.

The Inform RPC method indicates to H (e) MS that the device has failed the integrity check and is connecting to initiate a firmware update. H (e) MS then calls the RPC method Upload to instruct H (e) NB to upload a list of failed functionality and a manufacturer-specific list of error codes (4). These error codes can also refer to software modules that correspond to components that have failed the integrity check, or can include debug-specific error codes. Given the URL of the FTP server 1415 where the file should be uploaded. Note that FTP server 1415 can be maintained by the manufacturer. The FTP server 1415 may be a repair server provided by the manufacturer.

The H (e) MS1410 instructs the FTP server 1415 to prepare for uploading the list of failed functionality by sending the message Prepare_For_Upload (5). H (e) NB1405 then calls the HTTP / HTTPS / FTPS procedure to upload a file containing a list of failed functionality (6). After receiving the file, the FTP server 1415 or H (e) MS1410 collects the uploaded file and evaluates the required patch or firmware / software update to resolve the issue (6a). .. If a file containing a list of failed functionality is uploaded to FTP server 1415, FTP server 1415 sends a Download_Package_Ready message to H (e) MS after the required patch evaluation (7). This message is not requested if H (e) MS has already collected the uploaded file. Alternatively, this message may not be required if the functionality of the H (e) MS1410 and FTP server 1415 is merged.

Alternatively, the information can be received directly from PVE and steps 1-5 may not be required.

H (e) MS1415 then calls the RPC method Download and gives the URL of the location of the firmware or software and device configuration datasheet (8). The following parameter values can be set. The CommandKey parameter is a string that can be used by H (e) NB1405 to point to a particular download, and can be any string. This parameter is used to correlate downloads and responses. The FileType parameter is "1" for the firmware image. It can be set to "Firmware Upgrade Image" or "X_ &lt;OUI&gt; _data_sheet" for device configuration data sheets. The URL parameter is the URL of the download file. HTTP and HTTPS must be supported. FTPS support may also be recommended for downloads. The Username parameter can be used by H (e) NB1405 to authenticate to FTP server 1415. The Password parameter can be used by H (e) NB1405 to authenticate to FTP server 1415. The FileSize parameter is the size of the file to be downloaded. Other parameters may also be set according to TR069 protocol requirements.

The H (e) NB1405 connects to the FTP server 1415 and downloads the firmware or software image and device configuration data sheet (9). If the download completes successfully, a DownloadResponse with a Status argument of zero (indicating success) or a failure response (indicating failure) to the Download request can be sent (10). Successful or unsuccessful downloads may be indicated according to the alternative procedures described herein.

After a successful DownloadResponse, H (e) MS1415 then calls the Reboot procedure within H (e) NB1405 (11). H (e) The RPC handler in NB1405 resets the local emergency flag, boots successfully, and performs the local integrity check procedure as shown above (11a). The signed package format may include a reboot command used to instruct the H (e) NB1405 to reboot after the firmware or software has been updated.

You can optionally call the TransferComplete RPC method from H (e) NB to indicate to H (e) MS that the firmware / software update procedure has completed successfully (12). Alternatively, SeGW can send a message to H (e) MS to indicate that the device has successfully booted, which is translated by H (e) MS as a successful firmware or software update completion message. Note that it can be done.

FIG. 15 shows a flowchart 1500 for performing SAV repair by PVE. This procedure involves H (e) NB1505, SeGW1510, PVE1515, H (e) MS1520 and FTP server 1525. During the secure startup process, if the Phase 1 and Phase 2 codes pass the integrity check, are loaded and executed, and the authentication is successfully performed, the H (e) NB1505 communicates with the SeGW1510 to perform the local integrity check. The result of can be sent in an IKEv2 message (1). The H (e) NB1505 sends a list of failed functionality and a list of manufacturer-specific error codes to the SeGW 1510 in the IKEv2 NOTIFY message 1600 shown in Figure 16.

The SeGW1510 can then send the results of the local integrity check in an H (e) NB_Integrity_Information message that may contain a list of failed functionality and / or a manufacturer-specific list of error codes (2). Based on the information received, the PVE1515 can respond to the SeGW1510 with an H (e) NB_Validation_Result message that may include a SeGW action and an H (e) NB action (3). The SeGW1510 may forward the H (e) NB action to the H (e) NB1505 (5). The H (e) NB may prepare accordingly and may prepare for repair locally or take no action.

Based on the information received, the PVE may contain a list of failed functionality, a manufacturer-specific list of error codes, an H (e) MS action (s) and an H (e) NB ID, H (e) NB_Validation_Result. The message may be sent to H (e) MS1520 (4). Based on the actions sent by PVE1515 to H (e) MS1520, H (e) MS1520 can schedule repair updates or immediate updates. In both cases, the H (e) MS1520 sends the list to the manufacturer-specific repair FTP server.

The H (e) MS1520 may forward an H (e) NB_Validation_Result message to the FTP server 1525, which may include a list of failed functionality, an H (e) NB ID, and a manufacturer-specific list of error codes (4a). The FTP server 1525 can evaluate the firmware / software download file and prepare the download package (4b). The FTP server 1525 sends a Download_Package_Ready message to the H (e) MS1520. This message does not have to be prompted if the H (e) MS1520 collects the uploaded files. Alternatively, this message may not be sent if the H (e) MS1520 and FTP server 1525 have been merged.

The H (e) MS1520 then calls the RPC method Download and gives the URL of the location of the firmware / software and device configuration datasheet (7). The following parameter values can be set. The CommandKey parameter is a string that can be used by H (e) NB1505 to point to a particular download, and can be any string that can be used to correlate the download with the response. The FileType parameter is "1" for firmware / software images. It can be set to "Firmware upgrade image" and "X_ &lt;OUI&gt; _data_sheet" in the case of device configuration data sheet. The URL is the URL of the download file. HTTP and HTTPS must be supported. FTPS support is also recommended for downloads. The Username parameter can be used by H (e) NB1505 to authenticate to the file server. The Password parameter can be used by H (e) NB1505 to authenticate to the file server. The FileSize parameter is the size of the file to be downloaded. Other parameters can be set according to TR069 protocol requirements.

The H (e) NB1505 connects to the FTP server 1515 and downloads the firmware / software image and device configuration data sheet (8). If the download completes successfully, a DownloadResponse with a status argument of zero (indicating success) or a failure response (indicating failure) to the download request is sent to H (e) MS1520 (9). Successful or unsuccessful downloads can also be indicated according to the alternative procedure described in TR069.

After a successful download response, the H (e) MS1515 then calls the Reboot procedure within the H (e) NB1505 (10). H (e) The RPC handler in NB1505 resets the local emergency flag, boots successfully, and performs the local integrity check procedure as shown above (10a). Alternatively, the signed package format includes a reboot command used to instruct H (e) NB1505 to reboot after the firmware / software has been updated. After a successful completion of the firmware / software update, the transfer completion may be sent to the SeGW 1510 (11). Alternatively, TransferComplete The RPC method can be called from the H (e) NB1505 to indicate to the H (e) MS1520 that the firmware / software update procedure has been successfully completed. In another example, the SeGW1510 could send a message to the H (e) MS1520 to indicate that the device boot was successful, and this message was successfully completed by the H (e) MS1520 for a successful firmware / software update. Can be translated as a message.

An architecture and method using SAV in a platform validation and management (PVM) architecture is described herein. PVM provides a systematic way to validate and manage devices, which first come with a communication network and then partially rely on security technology from Trustworthy Computing. Attempts to monitor device integrity. PVM can safely start up by 1) validating the device before network connectivity is allowed, 2) managing the device configuration via OtA (via wireless), and 3) checking the RIM at component load / start. Then, 4) install a new RIM on the device for configuration change, that is, take RIM.

The following terms can be used in PVM: The term "verification" can be used for internal verification of device components during secure startup, and the term "validation" is used for the entire process of checking a device by an external entity. used. Therefore, the introduction of "internal" vs. "external" validation is avoided. If validation is applied in the usual sense of cryptographic checking or data matching, it should be clearly stated so as not to cause confusion.

PVM uses at least SeGW, PVE, and DMS. The TrE inside the device performs the essential tasks of validation inside the device, and generally the TrE communicates with other entities. Other components of the device, such as the network interface required for this communication, are not necessarily an integrated part of TrE, but TrE evaluates the integrity of these components to ensure end-to-end security. Should be possible.

A strict distinction between missions requires that each entity be restricted to its core task. For example, SeGW builds a secure interface between a trusted (unreliable) device and the CN of the MNO. This interface acts as a barrier for the CN of the MNO as well as a network access control and enhancement instance. The interface also performs all security-related functions needed to act as such barriers, including authentication, encryption / decryption of communication with devices, security associations and session establishment. SeGW can be used as an example of a network entity that builds boundaries between the CN of an MNO and the outside world, such as an external device. It may be possible to perform device validation using the PVM method without the need for SeGW. This may include a direct connection of the device to the DMS using a secure connection, such as TLS (Transport Layer Security).

For PVE, it acts as a validation entity within the CN and performs integrity validation. PVE receives integrity verification data and checks if the reported values are known and good. PVE issues statements about device integrity to other entities in the CN.

For DMS, it acts as a central entity for managing device components, including software updates, configuration changes, OTA management and failure mode repair. DMS is similar to the enhanced version of H (e) MS when starting this feature based on platform validation.

In addition to the above entities, PVM also includes a RIM manager (RIMman). RIMman performs the following tasks, including managing and provisioning reference values for comparison in validation. RIMman also ingests certificates, especially foreign RIM certificates, validates RIM certificates, generates (operator-specific) RIM certificates, and checks certificate validity, for example by withdrawal, time limits, and trust relationships. to manage. That is, the RIM Manager is a unique entity and is authorized to manage the validation database (V_DB). V_DB and RIMman are protected CN components. Write access to V_DB is limited to RIMman only, so PVE cannot write to V_DB. RIMman is of particular importance with regard to security as it manages the (SHO-CN) external trust relationships required for PVMs.

The PVM also includes a Configuration Policy Manager (CPman) that manages and provisions device configurations. CPman also manages ingestion of policies, in particular outpatient configurations and policies from TTPs (trusted third parties), as well as (operator-specific) target device configurations and policy generation. That is, CPman is a unique entity and is authorized to manage the configuration policy database C_DB. CPman is of particular importance with regard to security as it manages the (SHO-CN) external trust relationships required for PVMs.

Figures 17A and 17B show examples of minimum entity sets, their relationships, and interfaces for PVM. Additional entities such as AAA (Authentication, Authorization &amp; Accounting) server and WTRU (Wireless Transmitter / Receive Unit) and its interfaces are illustrated.

The PVM architecture or system 1700 in Figure 17A includes device 1705 with TrE1710. The WTRU1712 (or user entity (UE)) can communicate with device 1705 via the I-ue interface 1714. Device 1705 communicates with SeGW 1720 via Ih interface 1715. In general, the interface I-h1715 between device 1705 and SeGW1720 does not have to be protected and, with authenticity, integrity and options, special measures for confidentiality may be applied to this secure channel. I-h1715 can be used to establish a link between device 1705 and SeGW1720 and therefore CN. For example, the SeGW1720 may communicate with the AAA server via interface I-aaa1775. The operator may have established appropriate measures to ensure the security of the interface.

The I-pve interface 1722 can be used by SeGW1720 to contact PVE1724 during validation. The PVE1724 can use the I-pve interface 1722 to signal the validation output to the SeGW1720. The I-dms interface 1730 can be used for device configuration related communication between the DMS1735 and the SeGW1720. The I-pd interface 1732 can be used by PVE1724 to communicate with the DMS1735 and vice versa. This interface, I-pd1732, can be used during device management procedures, such as for device software updates and configuration changes.

Interfaces I-v1726 and I-d1738 can be used to read RIM from V_DB1740 by PVE1720 and to read configurations allowed by DMS1735 from C_DB1750, respectively. Interfaces I-r1728 and I-c1734 can be used by PVE1720 to communicate with RIMman1760 and by DMS1735 to communicate with CPman1770, such as in the case of RIM not in V_DB1740. The RIMman1760 and CPman1770 can use interfaces I-rdb1762 and I-cdb1772 to read, write, and manage the validation of database V_DB1740 and configuration policy database C_DB1750, respectively.

Figure 17B shows a PVM1782 in which device 1705 can connect directly to DMS1735. If the device is an H (e) NB, the DMS1735 becomes an H (e) MS, as described above herein. For example, if device 1705 is in fallback mode where it cannot enforce the security protocol with SeGW. In this case, DMS1735 acts as the first contact point for device 1705 via interface I-dms_d1784 and communicates with PVE1724 via interfaces I-pve1786 and I-pd1788 to validate and validate. Or at least you can find out which component failed during a secure startup. DMS1735 may act on this information for repair.

As mentioned herein, PVM can use any version of validation. Embodiments of semi-autonomous validation (SAV) linked with PVM are described herein. Focus on the advanced validation method of semi-autonomous validation (SAV). Another advantage of this solution for SAV is that the CN is completely protected from bad devices. Quarantine is effectively established by SeGW during SAV. No direct threat to PVE and DMS is posed by the device as it receives only data limited to that task only over a secure connection with SeGW or via a connection established by SeGW. The validation process in SAV does not require direct communication between the device and any entity in the CN. Only after successful validation using SAV is the connection to the CN allowed. This ensures that only certified secure devices can communicate with the entities inside the CN.

Figures 18A, 18B, and 18C show examples of SAV validation methods using the PVM infrastructure. The PVM infrastructure includes the entities described herein, including TrE1805, SeGW1807, PVE1809, DMS1811, V_DB1813 and C_DB1815. Following Mutual Authentication (1820), the TrE1805 includes Dev_ID, manufacturer, device capabilities, communication capabilities such as supported data rates, transmission power levels, signaling features and other capabilities, and TrE capabilities. Device information such as unrestricted device capabilities, and properties including RoT, TrE_information including ID, credentials, manufacturer, build version, and optionally model, make, and serial number, and 1) a list of device failures. , And / or 2) PCR (Platform Configuration Register) values, a list of validation bindings such as signatures with PCR values or failed device functionality, and an ordered list of component indicators (CInds) for components Clist of data called validation data. Part or all can be collected and may include parameters and timestamps (reliable or unreliable) for the component (1822). The validation message / data from TrE1805 to SeGW1807 may include the above date (1824).

The SeGW1807 must check / compare the received time stamp with the local time to detect the deformation (1826). If the reported timestamp does not match the local time, SeGW operates according to the properties of the reported timestamp. If the device timestamp is a trusted timestamp and indicates a change, the SeGW1807 should trigger a revalidation of the TrE and its trusted time source. In the case of untrusted timestamps, SeGW1807 adds its own trusted timestamp to the message. If the device cannot provide a reliable time stamp, the SeGW1807 may add a reliable time stamp as protection against replay attacks.

Upon receiving this message, SeGW1807 can check for the existence of a validation binding in the form of a signature from TrE (1828). This check ensures the authenticity of the validation data. SeGW1807 then creates a PVM token (T PVM) (1830) and time-stamps the T-PVM prior to sending to ensure freshness and prevent asynchronous message flow (1832).

SeGw1807 forwards T_PVM to PVE1809 (1834), and PVE1809 queries V_DB1813 using TrE information (1836). If an untrustworthy decision is returned to PVE1809 (1838), PVE stamps T_PVM with a time stamp (1840) and forwards it to SeGW1807 (1842). SeGW1807 sends a device validation refusal to TrE1805 (1844).

If a credible decision is returned to PVE1809 (1846), PVE queries C_DB using Dev_ID (1848) and C_DB returns the configuration policy (1850) to PVE1809. PVE1809 evaluates the policy configuration (1852).

If PVE1809 determines that the configuration is unreliable (1854), PVE1809 modifies the T-PVM and applies a time stamp (1856). PVE1809 then forwards T_PVM to SeGW1807 (1858), which sends a device validation refusal to TrE1805 (1860).

If PVE1809 determines that the configuration is credible and allows the configuration (1862), PVE1809 retrieves the RIM from V-DB1813 for all entries in the Clist or C_List (1864). PVE1809 recalculates the correct validation data from RIM (1866) and compares the calculated validation data with the reported validation data (1868). In the case of SAV, the validation data calculated from RIM is in the form of an "empty list" of failed functionality. PVE1809 then modifies the T-PVM and applies a time stamp (1870). PVE1809 then forwards T_PVM to SeGW1807 (1872). SeGW1807 inspects (or extracts from T_PVM) T_PVM for PVE validation results (1874). SeGW1807 sends a device validation denial or permission to TrE1805 (1876). If the PVE validation result is negative, TrE1805 reboots and revalidates (1890).

Optionally, after PVE1809 compares the calculated validation data with the reported validation data (1868), PVE1809 can send a list of failed components to DMS1811 (1878). If the list of failed components is not empty, DMS1811 may determine that a software or firmware update can be applied (1880) and, if applicable, prepare an OTA update (1882). DMS1811 also ensures that RIM for updates exists in V_DB1813 (1884). DMS1811 sends a T_PVM to SeGW1807 (1886) and a revalidation trigger to TrE1805 (1888) with a revalidation instruction. TrE1805 reboots and revalidates (1890).

Details regarding the processing in FIGS. 18A, 18B, 18C are provided herein. To carry out platform validation, TrE collects the following data and communicates it to SeGW. That is, device information such as Dev_ID, manufacturer, properties including TrE capabilities and RoT, and TrE_information including ID, credential, manufacturer, build version, and optionally model, make, and serial number, and integrity verification data (IVD). (One example of IVD may be a signed PCR (Platform Configuration Register) value, another example is simply that its integrity has been checked by a device-local integrity check process, and further local to such a device. A list of components or functionality that has been evaluated as having failed a complete integrity check), validation bindings such as signatures with PCR values, and an ordered list of component indicators (CInds) for component Clist for components. A Clist that can contain parameters. The list of components helps identify the validating RIM, for example by pointing to the RIM certificate, RIMcs. An ordered list of indicators for a component and its parameters will contain entries such as indexes, component_indicator CInd, and data fields called component_parameters. CInd gives a reference to the component and may be in URN format (eg URN: //vendor.path.to/component/certificate). Optionally, there is a time stamp (which can be a trusted time stamp or a regular time stamp that is generally not always reliable).

In the case of devices, validation messages include identity, credentials, manufacturer, model, version, make, serial number, TrE capabilities and properties including RoT, device security policy, integrity and post-inspection component loading. It may further include device information such as modules that are checked for integrity at different stages of the step process, HW build version numbers, and optionally SW build version numbers and integrity measurement data.

Using RIM for validation is the preferred but optional method for SAV. Used here as a base case, other options deviate from this case. For example, there is a validation that does not recalculate the validation data from RIM, and there is even the possibility that the implementation PVM will be done completely without RIM.

Validation bindings may be optional if validation messages are bound to authentication by means other than those involving device integrity, for example due to the presence and use of secure channels.

SeGW can detect deformation by checking / comparing the received time stamp with the local time. If the reported timestamp does not match the local time, SeGW operates according to the properties of the reported timestamp. If the device timestamp is a trusted timestamp and indicates a change, SeGW can trigger a revalidation of TrE and its trusted time source. In the case of untrusted timestamps, SeGW adds its own timestamp to the message.

TrE_info may be optional. Dev_ID can give a reference to TrE_info. Such a mapping can be given by a database that can be queried by the MNO to get the TrE_info for any given Dev_ID, since not all MNOs know all TrEs, and therefore all TrE_info data. TrE_info can be in TrE_certificate. The TrE_certificate should be signed by a TrE or TTP vendor, such as the German BSI.

The use of URN as an indicator (CInd) for a component is advantageous because it allows this unique identification of the component and where the RIM or RIM certificate can be retrieved at the same time.

SeGW creates a PVM token (T_PVM) that can be used as a rolling token and is passed from entity to entity during communication. All entities time stamp tokens before sending to ensure freshness and prevent asynchronous message flow. Timestamps on tokens can be used to provide a way to follow the state of the token. Tokens can travel many rounds from entity to entity within a CN and can therefore be tracked by an entity. Optionally, the entity ID can be included in the chain of time stamped data.

T_PVM can include Dev_ID. If the original timestamp does not exist or is not trusted, T_PVM may include a new timestamp issued by SeGW. Otherwise, T_PVM may include the original timestamp from the validation message.

Timestamps can be used to protect against replay attacks. Timestamps can be combined with or replaced by nonce or monotonically increasing counters. Timestamps can also be used to assess the freshness of validation data. It is advantageous to combine both purposes and can be provided by a time stamp.

In the first variant, for subsequent device management by the DMS, the T_PVM may include a communication secret that builds a secure tunnel between the DMS and the TrE, eg, a TLS certificate.

SeGW maintains a token database T_DB containing all active T_PVMs.

SeGW extracts validation data, TrE_info, and Clist data from validation messages. Before sending this data with the token T_PVM, SeGW time stamps T_PVM and forwards it to PVE. SeGW can check validation messages and some of their formats to mitigate threats from malformed data attacks. Otherwise, an attacker could attempt to correct the data in the validated message of the compromised TrE so that a pure inspection of this data in PVE would lead to a system error or failure. ..

PVE is the entity that determines the validity of a device. In other words, in policy system terms, it is the policy decision point (PDP). Under the technique of strict mission distinction, PVE is the only PDP in a PVM system. The PDP relies on SeGW and DMS to enforce policies such as acting as a Policy Enforcement Point (PEP). PVM remains unquestioned in its overview where it is stored / managed, such as how the policy is generated and where the PVE gets the policy. Some of the more detailed variants and accompanying methods described below (with validation and minimal validation for specific parameters) include some examples of policy conditions and actions. In general, validation policy decisions can be based not only on the validity of a single component, but also on other data contained in the Clist. In particular, the allowed parameters (range) and the order of loading (Clist is ordered) can be evaluated.

There are some underlying classes of failure conditions that can occur during the validation process performed by PVE. For example, the failure condition F1 indicates a "TrE invalid" scenario. By its authenticated Dev_ID and distributed TrE_info, PVE identifies the device and / or its TrE as untrustworthy. Note: The information that can be used to determine if a TrE can be invalid can be carried on the SAV validation message itself, or inferred from other messages or other means. In its basic form, the presence of a SAV validation message can implicitly indicate that TrE itself must be valid. Details on how F1 can be detected are incorporated by reference as fully described herein and are simultaneously filed under the name "Platform Validation and Management of Wireless Devices". Discussed in US Patent Application No. 12 / 718,480.

Another example is the failure condition F2, which shows three scenarios for "IVD validation failure". Scenario F2a shows an integrity measurement / validation data discrepancy. F2a indicates the failure of the device's secure startup process and / or the presence of fake and / or revoked RIM and / or RIM certificates on the device, which in turn initiates the invalid component. Scenario F2b shows a lack of RIM, i.e. it lacks RIM for components and needs to be retrieved somewhere else. Scenario F2c shows an expired RIM certificate.

Failure condition F3 presents two scenarios for "Clist policy failure". For scenario F3a, a single component is valid, but the configuration fails policies for, for example, load order, or unwanted components, or parameters. Scenario F3b shows that the configuration is unknown so that the "known good values" in Clist are not available.

A method for detecting and handling failure condition class F2 is described herein. For failure condition F2, PVE retrieves RIM from V_DB for all components in the received Clist. The validation database V_DB stores only certified RIMs. The corresponding RIM certificate must be securely stored in V_DB.

If the IVD is in the form of a simple list of "local integrity checks failed, corresponding to device components, device components", as described in the narrowly defined SAV procedure described herein. IVD_ref is simply in the form of a null list. That is, IVD_ref should be just the expected list of failed functionality in this case, which is NULL if all components are expected to pass the integrity check local to the device. Should be a table.

If the IVD_ref does not match the received IVD, then the safe startup process on the device has been compromised, or the wrong RIM has been stored on the device, and therefore the invalid component loads during the safe startup process. Has been done.

Depending on the F2a policy, if an F2a failure is detected, several options may be applicable. One option is rejection. PVE signals the output result of validation to SeGW. SeGW may then deny network access or put the device in the quarantine network. The second option is an update. After receiving the validation result (T_PVM) indicating the validation data failure, the DMS starts the management process to replace the component that failed the validation. Details of such a repair process are incorporated by reference, as fully described herein, and simultaneously filed, US Patent Application No. 12 entitled "Platform Validation and Management of Wireless Devices." / 718,480 Discussed in the specification.

If none of the policy failure conditions are met, the device is valid. PVE signals this to SeGW, which in turn allows connections to CN.

Missing RIM In case of failure condition F2b, this means that RIM is not in V_DB or is not in the device (as a result, in this case the device can perform an integrity check procedure local to the device). It will not be possible), so it can happen. Details on how F2 can be detected and handled are incorporated by reference, as fully described herein, and are simultaneously filed as "Platform Validation and Management of Wireless Devices." The name is discussed in US Patent Application No. 12 / 718,480.

A method for detecting and handling failure condition class F3 is described herein. The F3 failure condition is that a single component is valid but the component's configuration fails the policy (for example, the load order does not match), or the configuration is unknown, that is, the "known good value" of the Clist. Occurs when it is not available. Details on how such failure conditions can occur and how such failure conditions can be handled are incorporated by reference as fully described herein. It is discussed in US Patent Application No. 12 / 718,480, entitled "Platform Validation and Management of Wireless Devices," which was filed at the same time.

FIG. 19 shows the E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 1905 that can be used with the LTE (Long Term Evolution) Wireless Communication System / Access Network 1900 including H (e) NB. The E-UTRAN1905 includes the WTRU1910, and some eNB (evolved Node-B) 1920s. The WTRU1910 communicates with the eNB 1920. The eNB1920 interfaces with each other using the X2 interface. Each eNB1920 interfaces with MME (Mobile Management Entity) / S-GW (Serving Gateway) 1930 via the S1 interface. Although a single WTRU1910 and three eNB 1920s are shown in Figure 19, it will be clear that any combination of wireless and wired devices can be included in the wireless communication system access network 1900.

FIG. 20 is an exemplary block diagram of the LTE wireless communication system 2000 including the WTRU1910, eNB1920, and MME / S-GW1930. As shown in FIG. 20, the WTRU1910, eNB 1920 and MME / S-GW 1930 are configured to perform H (e) NB integrity and validation methods using autonomous and semi-autonomous validation. To.

In addition to the components that can be found in a typical WTRU, the WTRU1910 includes a processor 2016 with optional linked memory 2022, at least one transceiver 2014, an optional battery 2020, and an antenna 2018. Processor 2016 is configured to perform H (e) NB integrity verification and validation methods using autonomous and semi-autonomous validation. Transceiver 2014 communicates with Processor 2016 and Antenna 2018 to facilitate the transmission and reception of wireless communications. In the case where Battery 2020 is used within the WTRU1910, Battery 2020 powers Transceiver 2014 and Processor 2016.

In addition to the components that can be found in a typical eNB (including H (e) NB), the eNB 1920 includes a processor 2017 with optional linked memory 2015, a transceiver 2019, and an antenna 2021. Processor 2017 is configured to perform H (e) NB integrity verification and validation methods using autonomous and semi-autonomous validation. Transceiver 2019 communicates with processor 2017 and antenna 2021 to facilitate the transmission and reception of wireless communications. The eNB 1920 is connected to an MME / S-GW (Moving Management Entity / Serving Gateway) 1930 that includes a processor 2033 with an optional linked memory 2034.

SeGW and PVE are not shown in Figures 19 and 20, but in addition to the components found in typical SeGW and PVE, optional linked memory, transceivers (s), antennas (s), And may include processors with communication ports. The processor is configured to implement platform validation and management functions and implement PVM procedures. Transceivers and communication ports communicate with processors and antennas as needed to facilitate transmission and reception of communication content.

Embodiment 1. A method of performing integrity verification of H (e) NB (home evolved Node B), which includes measuring the integrity metric for a component prior to loading the component.

2. A method further comprising authenticating a trusted reference value (TRV) in the method of Embodiment 1.

3. A method further comprising comparing the measured integrity metric to a TRV in the method described in any of the above embodiments.

4. A method according to any of the above embodiments, further comprising starting H (e) NB, either as a normal code or a fallback code, depending on the integrity verification result.

5. In the method described in any of the above embodiments, the software module and the reference integrity metric and at least one of the severities for at least one of the H (e) NB and the platform validation entity (PVE) are included. A method that further includes providing, with a list of associated attributes.

6. In the method described in any of the above embodiments, the device configuration data sheet contains a list of software modules and associated attributes to at least one of the H (e) NB and the platform validation entity (PVE). The method given.

7. In the method described in any of the above embodiments, the associated attributes allow mapping of software modules with respect to components and functionality.

8. In the method described in any of the above embodiments, at least one of the device configuration data sheet and the list of software modules and associated attributes is of H (e) NB and Platform Validation Entity (PVE). How to store in at least one.

9. A method according to any of the above embodiments, further comprising sending a integrity check failure message in which the PVE includes at least a module identifier that can determine an action based on it.

10. A method according to any of the above embodiments, further comprising performing a predetermined action based on a severity classification for integrity verification failure.

11. In the method described in any of the above embodiments, a predetermined action comprises sending an emergency message, initiating a code update, initiating a repair, and reporting a list of failed functionality.

12. In the method described in any of the above embodiments, the list of software modules and associated attributes comprises at least one of component-specific information elements, module-specific information elements and functional elements.

13. In the method described in any of the above embodiments, the component-specific information element comprises at least one of a component description, a component identification (ID) and a trusted reference value (TRV).

14. In the method described in any of the above embodiments, the module-specific information element includes at least one of module description, module identification (ID), function description, function ID, component ID, release version and severity. Method.

15. In the method described in any of the above embodiments, the module is examined at least once during the integrity verification.

16. In the method described in any of the above embodiments, the module appears in only one component.

17. In the method described in any of the above embodiments, the module is shared between the two functions.

18. In the method described in any of the above embodiments, each module has the associated functionality.

19. In the method described in any of the above embodiments, a module group is associated with the same component, shares the same component identifier (ID), and is collectively verified for integrity with the same component.

20. In the method described in any of the above embodiments, modules having one component identifier (ID) are classified by different functional identifiers (IDs).

21. In the method described in any of the above embodiments, modules are classified based on functionality and integrity check units.

22. In any of the above embodiments, modules with the same component identifier have one trusted reference value (TRV) and all failed component identifiers, provided that the trusted reference value fails. Modules are the method used to determine the list of failed functionality.

23. A method of validating H (e) NB (home evolved Node B), including starting the above H (e) NB with a fallback code as a result of device integrity check failure. ..

24. A method further comprising sending an emergency message in the method of embodiment 23 above.

25. The method according to any of 23 to 24 above, further comprising receiving a downlink message for retrieving repair information.

26. A method according to any of embodiments 23-25 above, further comprising downloading repair information in response to a downlink message.

27. A method further comprising restarting H (e) NB based on installed repair information in the method according to any of embodiments 23-26 above.

28. A method according to any of embodiments 23-27 above, further comprising uploading failure information to allow the preparation of repair information.

29. In the method according to any of embodiments 23-28 above, the emergency message comprises at least one of manufacturer identification, reliable environmental identification, H (e) NB identification, and failure code.

30. In the method according to any of embodiments 23-29 above, the severity measure is a method of specifying the effect of device integrity check failure.

31. In the method according to any of the above embodiments 23 to 30, the device integrity check is performed locally.

32. In any of the methods 23-31 above, the failure information is sent to either the H (e) NB management system (H (e) MS) or the platform validation entity (PVE). ..

33. In the method according to any one of the above embodiments 23 to 32, H (e) NB is a method of sending an emergency message using SSL / TLS (Secure Socket Layer / Transport Layer Security).

34. In the method according to any one of the above embodiments 23 to 33, H (e) NB is a method composed of a default H (e) MS URL (uniform resource locator).

35. In the method according to any of embodiments 23-34 above, the device configuration data sheet is maintained within the secure memory of the device and accessed by an authorized party.

36. In the method according to any of the above embodiments 23 to 35, H (e) NB starts an update process when the device configuration data sheet expires and pulls data from the repair server.

37. In the method according to any one of the above embodiments 23 to 36, H (e) NB is a method of performing a device integrity check of a predetermined component.

38. A method further comprising receiving an H (e) NB action from PVE in the method according to any of embodiments 23-37 above.

39. H (e) A method of performing NB (home evolved Node B) validation, including establishing an IKE (Internet Key Exchange) security association.

40. In the method of Embodiment 1, a method further comprising sending a certificate for mutual authentication and instruction of device integrity check results in an IKE_AUTH request.

41. A method of any of the above embodiments 39-40, further comprising receiving an instruction as a result of authentication and device integrity validation.

42. A method of any of the above embodiments 39-41, further comprising receiving an action based on an evaluation of the device integrity check results.

43. In the method according to any of embodiments 39-42 above, the device integrity check result comprises a list of failed functionality.

44. In the method according to any of the above embodiments 39 to 43, the received action is a method of calling a repair.

45. In the method of any of embodiments 39-44 above, the device integrity check results within the H (e) NB are quarantined, gained full access, gained partial access, or repaired. How to get personnel intervention for.

46. A method of any of the above embodiments 39-45, further comprising sending an emergency message in response to an action indicating repair.

47. The method of any of the above embodiments 39-46, further comprising receiving a downlink message to retrieve repair information.

48. A method of any of the above embodiments 39-47, further comprising downloading repair information in response to a downlink message.

49. A method further comprising restarting H (e) NB based on installed repair information in the method according to any of embodiments 39-48 above.

50. In the method according to any one of the above embodiments 39 to 49, a method of uploading failure information and allowing preparation of repair information.

51. In the method according to any of the above embodiments 39 to 50, the failure information includes a list of failed functions.

52. In any of the methods 39-51 above, the failure information is sent to either the H (e) NB management system (H (e) MS) or the platform validation entity (PVE). ..

53. In the method according to any of embodiments 39-52 above, the failure information includes a list of checked functionality.

54. In the method according to any of embodiments 39-53 above, the failure information includes a list of unchecked functionality.

55. In the method according to any of embodiments 39-54 above, the validation and authentication binding is the method provided by the IKE session.

56. In the method of any of embodiments 39-55 above, the validation and authentication binding is the method provided by the preceding authentication procedure provided that the device integrity check is successful.

57. A method of binding device validation, including binding a trusted environment (TrE) to an authentication procedure.

58. In the method of embodiment 57, the authentication procedure is an EAP-AKA (Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement) procedure.

59. In the method according to any one of embodiments 57-58, the procedure is a method of validating the AKA qualification.

60. In the method according to any one of embodiments 57 to 59, the AKA qualification is included in TrE.

61. A method further comprising binding a validated device and EAP-AKA-based authentication in the method according to any one of embodiments 57-60.

62. In the method according to any one of embodiments 57-61, EAP-AKA authentication comprises binding a TrE holding AKA certification to a procedure for EAP-AKA-based authentication.

63. A method according to any one of embodiments 57 to 62, further comprising performing a logical binding of a TrE holding AKA qualification to a HeNB (enhanced home node B).

64. A method for validating the integrity of the device platform in the method according to any one of embodiments 57-63.

65. A method further comprising performing a physical binding of a TrE holding an AKA qualification to the HeNB in the method according to any one of embodiments 57-64.

66. In the method according to any one of embodiments 57-65, the actual integrity validation for hardware and software is performed by a hardware security component securely embedded in HeNB.

67. In the method described in any one of embodiments 57-66, the qualifications suitable for EAP-AKA authentication and the associated application stored in the physically bound TrE are removable hardware to the hosting device. A method that is configured to validate component bindings.

68. In the method according to any one of embodiments 57-67, TrE and HeNB holding the AKA qualification are further bound.

69. Data required to calculate the AKA credential used for device validation so that only TrE can decrypt the data in the method described in any one of embodiments 57-68. A method that further involves HeNB encrypting.

70. A method according to any one of embodiments 57-69, further comprising the TrE securely storing the key required to decrypt the HeNB encrypted data.

71. A method according to any one of embodiments 57-70, further comprising combining information about device validation and device authentication during the same session of a common security protocol to obtain additional bindings. ..

72. In the method according to any one of embodiments 57 to 71, the common security protocol is IKEv2 (Internet Key Exchange version 2).

73. In the method according to any one of embodiments 57-72, device validation involves interaction and message exchange between the HeNB and the network entity.

74. In the method according to any one of embodiments 57 to 73, HeNB comprises TrE.

75. A method according to any one of embodiments 57-74, further comprising performing a HeNB validation by a network entity.

76. A method according to any one of embodiments 57-75, further comprising transmitting signaling between the HeNB and the network entity performing the validation by the security gateway.

77. A method further comprising binding device validation to certificate-based authentication in the method according to any one of embodiments 57-76.

78. In the method according to any one of embodiments 57-77, binding involves physically binding the HeNB TrE to a certificate-based device validation procedure.

79. In the method according to any one of embodiments 57-78, binding involves logically binding the HeNB TrE to a certificate-based device validation procedure.

80. In the method according to any one of embodiments 57 to 79, the TrE and HeNB holding the certificate qualification are further bound.

81. HeNB encrypts the data required to calculate the certificate entitlement used for device validation using the encryption key in the method described in any one of embodiments 57-80. , And a method that further involves the TrE decrypting the encrypted data inside the TrE using a key that the TrE holds securely.

82. To validate a certificate-based authentication session by having both procedures use the same or contiguous sessions of a common protocol session in the method described in any one of embodiments 57-81. A method that further includes binding to the procedure of.

83. In the method described in any one of embodiments 57-82, device validation involves HeNB and a network entity that allows the network to perform device integrity validation of HeNB. A method that involves interaction through a common protocol session between.

84. A method according to any one of embodiments 57-83, further comprising binding the device validation of the bound HeNB to EAP-AKA-based client authentication.

85. A method according to any one of embodiments 57-84, further comprising binding the TrE to the HeNB using an encryption key and credentials for exchanging messages between the TrE and the rest of the HeNB. ..

86. In the method according to any one of embodiments 57-85, the message exchange between the TrE and the rest of the HeNB includes a message exchange related to device validation.

87. In the method according to any one of embodiments 57-86, the key and qualification are protected inside the TrE.

88. In the method according to any one of embodiments 57-87, during the same or consecutive sessions of the common security protocol, the specified portion of device validation and EAP-AKA-based client authentication is HeNB. And methods that further include what TrE does.

89. A method further comprising binding HeNB device validation to certificate-based client authentication in the method according to any one of embodiments 57-88.

90. In the method according to any one of embodiments 57-89, TrE comprises a key pair.

91. In the method according to any one of embodiments 57 to 90, the key pair includes a private part and a public part.

92. In the method according to any one of embodiments 57 to 91, the privately owned portion is safely stored inside the TrE.

93. In the method according to any one of embodiments 57-92, the public unit is made available to HeNB.

94. Certificate required by the HeNB manufacturer to generate a key pair and make a public key available to HeNB in the method according to any one of embodiments 57-93. A method that further includes giving.

95. A method according to any one of embodiments 57-94, further comprising creating a validation and authentication binding by cryptographic means in EAP-AKA-based authentication.

96. A method according to any one of embodiments 57-95, further comprising the HeNB encrypting the response with the public key from the certificate and forwarding the encrypted data to the TrE.

97. In the method according to any one of embodiments 57 to 96, the method in which the response is an IKE_AUTH response.

98. In the method described in any one of embodiments 57-97, the TrE is then required to decrypt the data and to authenticate the HeNB to the AAA (Authentication, Authorization and Accounting) server. A method that further includes computing the EAP-AKA response (RES) parameters that are made.

99. A method according to any one of embodiments 57-98 , further comprising the HeNB using the public key to encrypt the data required to calculate the AUTH parameter in TrE. ..

100. A method according to any one of embodiments 57-99, further comprising decoding the data and calculating the AUTH parameter required for the TrE to authenticate the HeNB to the SeGW.

101. A method according to any one of embodiments 57-100, further comprising binding device integrity and device ID cryptographically.

102. In the method according to any one of embodiments 57-101, cryptographically binding device integrity and device ID is a method performed by TrE and HeNB.

103. In the method according to any one of embodiments 57 to 102, TrE and HeNB are equipped with their respective public key pairs.

104. In the method according to any one of embodiments 57 to 103, TrE and HeNB are equipped with their respective symmetric shared keys.

105. In the method according to any one of embodiments 57-104, TrE and HeNB use the key to protect communication and for mutual authentication.

106. In the method according to any one of embodiments 57-105, the IKEv2 protocol for device validation is the method used to bind TrE to HeNB.

107. In the method according to any one of embodiments 57-106, device integrity is bound to a device ID by binding a device integrity validation and device authentication procedure.

108. In the method according to any one of embodiments 57-107, device integrity validation and device authentication are performed within a protected TrE.

109. In the method according to any one of embodiments 57-108, the TrE is a protected, trusted entity.

110. In the method according to any one of embodiments 57-109, TrE is a method of performing a device integrity validation and device authentication procedure.

111. In the method according to any one of embodiments 57 to 110, the IKEv2 protocol session, or the session immediately following it, is the method used for both device integrity validation and device authentication.

112. A method further comprising combining a device validation procedure with a new message exchange in the method according to any one of embodiments 57-111.

113. In the method according to any one of embodiments 57-112, the new request and response exchange precedes another similar exchange performed for device authentication.

114. In the method according to any one of embodiments 57-113, the request and response exchange used by device authentication is the method used in the device validation procedure.

115. In the method according to any one of embodiments 57 to 114, additional data required for device integrity validation is incorporated into the selected message field.

116. In the method according to any one of embodiments 57-115, the data required for device integrity is a signed statement about the output of a local autonomous integrity check or semi-autonomous validation. How to include.

117. In the method according to any one of embodiments 57-116, the message field comprises a protected notification field.

118. A method further comprising combining a device validation procedure with an existing message exchange in the method according to any one of embodiments 57-117.

119. A method further comprising combining a device validation procedure with a new request and response exchange in the method according to any one of embodiments 57-118.

120. A method according to any of the above embodiments, further comprising performing an integrity check and using the information generated by the integrity check to influence network decisions.

121. In the method described in any of the above embodiments, the information element comprises a manufacturer and an integrity algorithm.

122. In the method described in any of the above embodiments, the component-specific information element includes a component description, a component identification (ID) and a trusted reference value (TRV).

123. In the method described in any of the above embodiments, the module-specific information elements include module description, module identification (ID), function description, function ID, component ID, release version and severity.

124. In the method described in any of the above embodiments, the severity is the method of specifying the effect of failure of the integrity check.

125. In the method according to any of the above embodiments, the severity is classified on a scale of 1 to 4.

126. In the method described in any of the above embodiments, severity 1 can indicate a high impact on H (e) NB functionality and guarantee stop operation, and the fallback code image (FBC) , A method that can send an emergency signal to the specified H (e) MS.

127. In the method according to any of the above embodiments, severity 2 is a method of asserting limited H (e) NB functionality.

128. In the method described in any of the above embodiments, severity 3 does not have to affect core functionality, module / feature failures are replaced by firmware update procedures and validated by reboot. How to be done.

129. In the method described in any of the above embodiments, the severity of 4 does not have to affect the core functionality and the failed module can be replaced through a normal firmware update.

130. In the method described in any of the above embodiments, the device integrity check is performed locally during autonomous validation.

131. A method in which an emergency signal is sent to a home mobile station (H (e) MS), provided that the integrity check fails, in any of the above embodiments.

132. In the method described in any of the above embodiments, a list of functions that failed the integrity check during semi-autonomous validation is reported to the Personal Video Encoder (PVE).

133. In the method described in any of the above embodiments, the module is checked only once during the integrity check.

134. In the method described in any of the above embodiments, the module appears in only one component.

135. In the method described in any of the above embodiments, the module can be shared between two functions.

136. In the method described in any of the above embodiments, each module has associated functionality and a list of failed functionality is derived in semi-autonomous validation (SAV) and personal video encoder. How it can be sent to (PVE).

137. In the method according to any of the above embodiments, the functional identifier (ID) is a method of giving a classification of modules.

138. In the method according to any of the above embodiments, the modules are classified based on the generated image.

139. In the method described in any of the above embodiments, a method in which a group of modules contains the same component identifier (ID) and is collectively checked for integrity.

140. In the method according to any of the above embodiments, modules having one component identifier (ID) are classified by different functional identifiers (IDs).

141. In the method described in any of the above embodiments, the module identifier (ID) is a non-standardized method used to track various software modules.

142. In the method described in any of the above embodiments, modules are classified based on functionality and integrity check units.

143. In the method described in any of the above embodiments, all modules with the same component identifier (ID) have one trusted reference value of the failed component, provided that the trusted reference value fails. All modules are used to determine a list of failed functionality and are transmitted to a home mobile station (H (e) MS) or personal video encoder (PVE).

144. In the method described in any of the above embodiments, the list of functionality is the method associated with the component.

145. In the method described in any of the above embodiments, the components are organized in the order in which they are loaded.

146. In the method described in any of the above embodiments, the integrity check is performed on a part of the image object file, and the failed segment name is provided on the condition that the image object file does not pass the integrity check. How to be extracted.

147. In the method described in any of the above embodiments, the CPE (customer premises equipment) is used to download the trusted reference to the H (e) NB, which is by the network operator's signature key. How to digitally sign.

148. In the method described in any of the above embodiments, upon receiving a signed packet containing a trusted reference value, H (e) NB decrypts the signature and the authenticity of the received trusted reference value. And how to verify integrity.

149. In the method described in any of the above embodiments, the trusted reference value is encrypted for confidentiality before being digitally signed.

150. In the method described in any of the above embodiments, a reliable reference value is added as part of the software module binary image.

151. In the method described in any of the above embodiments, the H (e) NB and the home mobile station H (e) MS support SSL / TLS (Secure Socket Layer / Transport Layer Security) and are certificate-based. How to use authentication.

152. In the method described in any of the above embodiments, the TR069 based architecture is a method of supporting certificate-based authentication.

153. In the method described in any of the above embodiments, the H (e) NB is composed of the default home mobile station H (e) MS URL (uniform resource locator) in the ManagementServer.URL parameter.

154. In the method described in any of the above embodiments, H (e) NB is a method for supporting a LAN (local area network) side ManagementServer.URL configuration.

155. In the method described in any of the above embodiments, the security gateway (SeGW) URL (uniform resource locator) is a parameter.

156. A method in which a digital signature or message is signed with a private key during autonomous validation in any of the methods described above.

157. A method in which information is not sent to a network entity during autonomous validation in any of the above embodiments.

158. In the method described in any of the above embodiments, the minimum requirement is a method standardized for a reliable reference integrity metric or an algorithm used to generate a reliable reference value.

159. In the method described in any of the above embodiments, the trusted reference value is generated and digitally signed by a trusted third party.

160. A method in which local integrity data initialization is performed in any of the above embodiments.

161. A method in which initial provisioning of configuration data is performed in the method described in any of the above embodiments.

162. In the method described in any of the above embodiments, the reference integrity metric is a method of providing a reliable reference value.

163. In the method described in any of the above embodiments, the device configuration data sheet is maintained within the secure memory of the device and accessed by an authorized party.

164. In the method according to any of the above embodiments, the device configuration data is encrypted and decrypted by H (e) NB.

165. In the method described in any of the above embodiments, during the secure boot process, the generated digest is compared to the value specified in the device configuration data sheet.

166. In any of the above embodiments, a method in which the H (e) NB initiates a firmware update process to pull data from the repair server, provided that the device configuration data sheet expires.

167. In the method described in any of the above embodiments, the home mobile station (H (e) MS) starts an RPC (remote procedure call) and updates the ManagementServer.URL.

168. A method in which FTPS (File Transfer Protocol Secure) is implemented to transfer a file in any of the above embodiments.

169. In the method described in any of the above embodiments, the device integrity check fails in autonomous validation, the local emergency flag is set, and the fallback code (FBC) is stored on the device.

170. In the method according to any of the above embodiments, the emergency signal comprises the details of the device integrity check failure.

171. In the method described in any of the above embodiments, the FTP (File Transfer Protocol) server is merged with the home mobile station (H (e) MS).

172. In the method described in any of the above embodiments, during semi-autonomous validation (SAV), H (e) NB interacts with a secure gateway (SeGW) over an insecure link.

173. In the method described in any of the above embodiments, the secure gateway (SeGW) is a method that allows only authenticated H (e) NBs to access the network.

In the method described in any of the above embodiments, the home mobile station (H (e) MS) acts as an H (e) NB management server to provide repair support.

174. In the method according to any of the above embodiments, in SAV, H (e) NB is a method of performing a pre-designated component integrity check.

175. In the method described in any of the above embodiments, in SAV, component authentication is performed locally by comparing the digest output from the integrity algorithm with the specified value in the device configuration sheet. Method.

176. In the method described in any of the above embodiments, the transport element (TrE) of the H (e) NB is a method of performing a predefined component integrity check.

177. In the method described in any of the above embodiments, H (e) NB is a method of establishing an IKE (Internet Key Exchange) security association at a secure gateway (SeGW) by exchanging certificates.

178. A method of loading and executing a component by a device after validating the local integrity of the component in any of the above embodiments.

179. A method of sending an Internet Key Exchange (IKE) element in any of the above embodiments to establish a security association that includes a security parameter index for cryptographic algorithms.

180. In any of the above embodiments, a secure gateway (SeGW) sends a response to an IKE (Internet Key Exchange).

181. In the method described in any of the above embodiments, H (e) NB sends the certificate in IKE_AUTH_REQ for mutual authentication.

182. In the method described in any of the above embodiments, the secure gateway (SeGW) evaluates the H (e) NB certification and extracts a list of functional identifiers.

183. In the method described in any of the above embodiments, the secure gateway (SeGW) sends an instruction to H (e) NB if the authentication validation is successful.

184. In the method described in any of the above embodiments, the secure gateway (SeGW) sends an instruction to H (e) NB if the authentication validation fails.

185. In the method described in any of the above embodiments, SeGW sends a list of failed functionality to a personal video encoder (PVE).

186. In the method described in any of the above embodiments, PVE includes requesting home mobile station (H (e) MS) intervention for device quarantine, full access provision, partial access provision or repair. How to determine an action.

187. In the method described in any of the above embodiments, PVE will notify SeGW of the decision.

188. In the method described in any of the above embodiments, the personal video encoder (PVE) sends a notification to start the repair and a list of failed modules to the home mobile station (H (e) MS).

189. In the method described in any of the above embodiments, the personal video encoder (PVE) sends a notice of repair to H (e) NB.

190. In the method according to any of the above embodiments, the secure gateway (SeGW) is the method of presenting the results of the device integrity assessment to H (e) NB.

191. In any of the above embodiments, the transport element (TrE) delegates integrity verification to an external entity.

192. In the method according to any of the above embodiments, H (e) NB includes a local time server that synchronizes time using NTP (Network Time Protocol).

193. In the method described in any of the above embodiments, the authentication certificate in SAV and the result of local validation are sent in an IKE_AUTH_REQ message.

194. In the method described in any of the above embodiments, the secure gateway (SeGW) filters the list of failed modules before passing the list to the personal video encoder (PVE).

195. In the method described in any of the above embodiments, the H (e) NB is connected to the home mobile station (H (e) MS) by connecting via a secure gateway or via the Internet. How to interact and support repairs.

196. In the method described in any of the above embodiments, the home mobile station (H (e) MS) calls RPC (remote procedure call) and H (e) NB fails a list of functionality and errors. A way to indicate that you are uploading a list of codes.

197. In the method described in any of the above embodiments, the home mobile station (H (e) MS) instructs FileSever to prepare for uploading a list of failed functions.

198. In any of the above embodiments, H (e) NB calls a procedure for uploading a file containing a list of failed functions.

199. In the method described in any of the above embodiments, FileSever sends a Download_Package_Ready message to the home mobile station (H (e) MS) after evaluating the uploaded file.

200. In the method described in any of the above embodiments, the home mobile station (H (e) MS) calls RPC (remote procedure call) and gives the URL (uniform resource locator) of the device configuration sheet.

201. In the method described in any of the above embodiments, the H (e) NB connects to an FTP (File Transfer Protocol) file server and downloads a firmware image and a device configuration sheet.

202. In the method according to any of the above embodiments, the home mobile station (H (e) MS) calls the reboot procedure upon receiving a successful download response.

203. In the method according to any of the above embodiments, the H (e) NB resets the local emergency flag upon receiving a successful download response.

204. In the method according to any of the above embodiments, the home mobile station (H (e) MS) receives a message from the secure gateway (SeGW) indicating that the device has been successfully booted.

205. In any of the above embodiments, the H (e) NB communicates with the security gateway provided that the integrity check is loaded and executed during the secure boot process and the authentication is successfully performed. Method.

206. A method further comprising transmitting the results of a local integrity check in the method according to any of the above embodiments.

207. A method according to any of the above embodiments, further comprising forwarding the result of a local integrity check to a personal video encoder (PVE).

208. In the method described in any of the above embodiments, H (e) NB sends a list of failed functionality and a list of manufacturer-specific error codes to SeGW in an IKEv2 NOTIFY message.

209. In the method described in any of the above embodiments, SeGW is a method of forwarding a list of failed functions to a personal video encoder (PVE).

210. In the method described in any of the above embodiments, PVE determines a SeGW action, an H (e) NB action and forwards a list of actions to SeGW.

Suitable processors include, for example, general purpose processors, special purpose processors, traditional processors, DSPs (digital signal processors), multiple microprocessors, one or more microprocessors associated with DSP cores, controllers, microcontrollers, ASICs. Includes (application specific integrated circuits), ASSPs (application specific integrated circuits), FPGA (field programmable gate array) circuits, any other type of IC (integrated circuits), and / or state machines.

The processor associated with the software is for use within a WTRU (Wireless Transceiver), UE (User Equipment), terminal, base station, MME (Mobile Management Entity) or EPC (Evolved Packet Core), or any host computer. Can be used to implement radio frequency transceivers. WTRU is a module implemented in hardware and / or software including SDR (Software Radio), as well as cameras, video camera modules, videophones, speakerphones, vibrating devices, speakers, microphones, TV transceivers, hands-free headsets. , Keyboard, Bluetooth (registered trademark) module, FM (frequency modulation) wireless unit, NFC (short-range wireless communication) module, LCD (liquid crystal display) display unit, OLED (organic light emitting diode) display unit, digital music player, media player Can be used with other components such as video game player modules, internet browsers, and / or any WLAN (Wireless Local Area Network) or UWB (Ultra Broadband) modules.

Although features and elements have been specifically described above, each feature or element may be used individually without other features and elements, or in various combinations with or without other features and elements. it can. The methods or flowcharts described herein can be implemented in a computer program, software, or firmware embedded in a computer-readable storage medium for execution by a general purpose computer or processor. Examples of computer-readable storage media include ROM (read-only memory), RAM (random access memory), registers, cache memory, semiconductor memory elements, internal hard disks and magnetic media such as removable disks, magneto-optical media, and CD-ROMs. Includes discs and optical media such as DVDs (digital versatile discs).