Method and apparatus for H(e)NB integrity verification and validation

Patent metadata

Field	Value
Publication number	US-9253643-B2
Application number	US-71857210-A
Country	US
Kind code	B2
Filing date	Mar 5, 2010
Priority date	Mar 5, 2009
Publication date	Feb 2, 2016
Grant date	Feb 2, 2016

Abstract

An apparatus and method for providing home evolved node-B (H(e)NB) integrity verification and validation using autonomous validation and semi-autonomous validation is disclosed herein.

First claim

What is claimed is:

1. A method for performing integrity verification of a wireless transmit/receive unit (WTRU), comprising the following steps performed at the WTRU:
measuring, at the WTRU, integrity metrics for at least a component of the WTRU;
retrieving, at the WTRU, a trusted reference value (TRV) for the at least one component from local storage on the WTRU;
comparing, at the WTRU, the measured integrity metrics against the TRV to determine a result of an integrity verification check of the at least one component; and
upon a failed integrity verification check of the at least one component, determining a course of action based on a locally provisioned policy.

2. The method recited in claim 1 , further comprising:
mapping the at least one component that failed the integrity verification check to a functionality to produce a device independent classification of functionality affected by the failed integrity verification check of the at least one component on the WTRU; and
reporting the results of the integrity verification check of the at least one component to a platform validation entity (PVE), and sending the device independent classification of functionality affected by the failed integrity check of the at least one component to the PVE.

3. The method recited in claim 2 , wherein the PVE and the WTRU are separate entities on a network.

4. The method recited in claim 3 , wherein reporting the results of the integrity verification check to the PVE includes sending a device identifier for the WTRU.

5. The method recited in claim 1 , further comprising determining a severity classification associated with the failed integrity verification check and performing predetermined actions based on the determined severity classification.

6. The method recited in claim 5 , wherein a determination of a first severity classification results in rebooting the WTRU with a fallback code image (FBC).

7. The method recited in claim 6 , wherein determination of a second, different severity classification may result in performance of a limited subset of functionality of the WTRU.

8. The method recited in claim 7 , wherein upon determination of another severity classification, replacement of the failed component is carried out via an immediate update procedure.

9. The method recited in claim 7 , wherein upon determination of another severity classification, replacement of the failed component is carried out as part of a normal update schedule.

10. The method recited in claim 6 , wherein the FBC has the capability of basic communications with a core network and a capability to send a distress signal to the core network, the distress signal containing an error code information element indicating details of the failed integrity verification check.

11. The method recited in claim 10 , wherein the distress signal comprises a combination of information elements including one or more of a device identifier for the WTRU, an event field containing information about the failed integrity validation check, and a time field containing an indication of the current date and time known to the WTRU.

12. The method recited in claim 2 , wherein the device independent classification of functionality includes at least one of version information, device model information, or serial number.

13. A wireless transmit/receive unit (WTRU) adapted to:
measure integrity metrics for at least a component of the WTRU;
retrieve a trusted reference value (TRV) for the at least one component from local storage on the WTRU;
compare the measured integrity metrics against the TRV to determine a result of an integrity verification check of the at least one component; and
upon a failed integrity verification check of the at least one component, determine a course of action based on a locally provisioned policy.

14. The WTRU recited in claim 13 , wherein the WTRU is further adapted to:
map the at least one component that failed the integrity verification check to a functionality to produce a device independent classification of functionality affected by the failed integrity verification check of the at least one component on the WTRU; and
report the results of the integrity verification check of the at least one component to a platform validation entity (PVE), and sending the device independent classification of functionality affected by the failed integrity check of the at least one component to the PVE.

15. The WTRU recited in claim 14 , wherein the PVE and the WTRU are separate entities on a network.

16. The WTRU recited in claim 14 , wherein reporting the results of the integrity verification check to the PVE includes sending a device identifier for the WTRU.

17. The WTRU recited in claim 13 , wherein the WTRU is further adapted to determine a severity classification associated with the failed integrity verification check and performing predetermined actions based on the determined severity classification.

18. The WTRU recited in claim 17 , wherein a determination of a first severity classification results in rebooting the WTRU with a fallback code image (FBC).

19. The WTRU recited in claim 18 , wherein determination of a second, different severity classification may result in performance of a limited subset of functionality of the WTRU.

20. The WTRU recited in claim 19 , wherein upon determination of another severity classification, replacement of the failed component is carried out via an immediate update procedure.

21. The WTRU recited in claim 18 , wherein upon determination of another severity classification, replacement of the failed component is carried out as part of a normal update schedule.

22. The WTRU recited in claim 18 , wherein the FBC has the capability of basic communications with a core network and a capability to send a distress signal to the core network, the distress signal containing an error code information element indicating details of the failed integrity verification check.

23. The WTRU recited in claim 22 , wherein the distress signal comprises a combination of information elements including one or more of a device identifier for the WTRU, an event field containing information about the failed integrity validation check, and a time field containing an indication of the current date and time known to the WTRU.

24. The WTRU recited in claim 14 wherein the device independent classification of functionality includes at least one of version information, device model information, or serial number.

Assignees

• Pattar Sudhir B
• Cha Inhyok
• Schmidt Andreas U
• Leicher Andreas
• Shah Yogendra C
• Howry Dolores F
• Greiner David G
• Case Lawrence L
• Meyerstein Michael V
• Guccione Louis J
• Interdigital Patent Holdings

Inventors

• Pattar Sudhir B
• Cha Inhyok
• Schmidt Andreas U
• Leicher Andreas
• Shah Yogendra C
• Howry Dolores F
• Greiner David G
• Case Lawrence L
• Meyerstein Michael V
• Guccione Louis J

Classifications

• H04W12/10 Primary

  Integrity · CPC title

• H04W84/045

  using private Base Stations, e.g. femto Base Stations, home Node B · CPC title

• H04L41/0654

  using network fault recovery (ring fault isolation or reconfiguration in loop networks without recovery actions by a network management system H04L12/437) · CPC title

• H04L41/0869 Primary

  Validating the configuration within one network element · CPC title

• H04L9/32

  including means for verifying the identity or authority of a user of the system {or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials} · CPC title