HK1156180A - A method and apparatus for secure trusted time techniques - Google Patents

Description

Method and apparatus for secure trusted timing technology

Technical Field

The present methods and apparatus relate to wireless communications.

Background

A trusted local time may be required in various business cases to record the actual time of a particular event. For example, if some consumption data in an "offline" situation is recorded, a reliable internal clock is required to ensure the accuracy of the consumption date. The application areas include applications in energy production (e.g., applications in distributed plants, synchronized software, and Digital Rights Management (DRM) use cases it is often the case that the authority of external time is not all valid due to physical or economic extrinsic factors.

Trusted Computing (TC) provides a way in a Trusted Platform Module (TPM) to communicate the values of time-related counters to other parties and protect them inside the trusted platform. Nevertheless, it would be useful to extend these limited functions to ensure safe timing and provide accuracy reports.

The TCG specification also has some drawbacks when the report allows an external verifier trust scale (tick) counter value to correspond to some actual time value with a defined, verifiable accuracy at an earlier time for the purpose of using the functionality of the trusted platform to obtain a trusted time report.

First, there is no trusted contact in a particular platform P. That is, the tick stamp alone cannot indicate on which platform it was generated in which state. It cannot even indicate whether the platform is a trusted platform with a hardware TPM. Anyone can forge the data structure of the tick stamp, especially by using software emulation techniques of the TPM. Therefore, a reliable method of indexing is desired.

Second, TIR is a factory value that is pre-installed in the TPM context, which may or may not be accurate, and which may lose its accuracy over the lifetime of the TPM. Since TIR is crucial for calculating the actual time value from TCV, it is desirable to have a reliable method of obtaining true TIR at any time.

Third, the accuracy report defined by the TCG specification determines only a point in time associated with the TCV. It is desirable to improve accuracy, i.e., more tightly limit the relationship of the TCV interval constant to the real-time clock value, while maintaining assertion (assertion) trustworthiness.

Fourth, to achieve accuracy, time synchronization in a distributed system may include multiple time sources. It is therefore desirable to incorporate those methods into the extension of trusted time reporting.

Finally, since the TCV must be reset in the event of an unpredictable event according to the TPM specification, its effectiveness is severely limited. Although the TSN makes a functioning tick counter session unique, it is still desirable to bridge the TCV to the RTC value between tick counter sessions. In addition, a true use case of TCVs, for example, in the case of Digital Rights Management (DRM) is also desirable.

Disclosure of Invention

A method and apparatus for protecting time values in wireless communications. The device is equipped with a TPM that performs an information exchange with a Time Authority (TA) to calibrate tick stamps from a tick counter of the TPM of the device with a real-time clock value provided by the TA. The apparatus transmits a timestamp request and receives a timestamp in response to the request. The device generates and transmits a tick stamp and receives an alternative (alternate) accuracy report in response.

In a second embodiment, the device receives the time stamp and generates two consecutive tick stamps for transmission. In this embodiment, the apparatus receives the modified time stamp as a response to the transmitted two tick stamps. After receiving the modified timestamp, the apparatus tick marks the modified timestamp.

In a third embodiment, the accuracy report may be protected by generating a signature authentication key (CSK) from an identity of certificate key (AIK). In this embodiment, a precision report and a trusted time report (TTS) are generated. A (legacy) AIK certificate, a portion of a CSK, an accuracy report, or signature data may be published.

Drawings

The invention will be more clearly understood from the following detailed description, given by way of example, with reference to the accompanying drawings, in which:

fig. 1 is a diagram of an example wireless transmit/receive unit (WTRU) configured to establish a trusted local time;

figure 2 is another diagram of an example WTRU configured to establish a trusted local time;

FIG. 3 is a flow diagram representing an example method of alternative accuracy report generation;

FIG. 4 is another flow diagram representing an example method of alternative accuracy report generation;

FIG. 5 is a flow chart representing a variation of an example method of alternative accuracy generation;

FIG. 6 is a diagram representing an example method of trusted TIR measurement;

FIG. 7 is a diagram representing an example method of protecting an accuracy report;

FIG. 8 is a flow diagram of an example remote attestation (attestation) process;

FIG. 9 is a diagram representing an example method of a meta-session; and

fig. 10 is a flow diagram of an example method of using trusted computing technology in DRM.

Detailed Description

The term "wireless transmit/receive unit (WTRU)" as referred to below includes, but is not limited to, a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a computer, or any other type of user equipment capable of operating in a wireless environment. The term "base station" as referred to below includes, but is not limited to, a node B, a site controller, an Access Point (AP), or any other type of interfacing device capable of operating in a wireless environment. The term "SIM" as referred to below includes SIM ICC, USIM, Universal Integrated Circuit Card (UICC), Removable User Identity Module (RUIM), or any other removable medium that contains WTRU identity information. The TPM, or its mobile variable MTM, is interchangeable below for simplicity purposes.

By definition, tick stamps are time reports made by the TPM, while time stamps are time reports made by an external Time Authority (TA). The TA can be used to ensure that its time report has a certain accuracy. When the tick counter is reset, the tick stamp can be a known unit of time count associated with the time, while the time stamp is the actual time value.

The TPM, or its mobile variable Mobile Trusted Module (MTM), provides a secured, read-only, scale counter value (TCV) that is initialized to zero at certain events, such as the start of a new boot cycle of a TPM-equipped device. The TCV remains active for as long as possible. If a new TCV is required due to the loss of an old TCV (e.g., due to a power failure) or due to a new contract with the service provider requiring a new TCV starting point, the TPM's nonce generator generates a new unique scaled session nonce (TSN) value. The constant TSN value is used to communicate with the external entity for a period of time, referred to as a tick session. The tick session provides a unique security context for the time report issued by the device. One assumption underlying the TCG design is that each calibration session provides at least one external connection to another secure timing calibration. This will adequately meet the requirements of a sufficient number of timestamps required by the TPM application, as long as the scale counter is accurate enough.

The overall timing function of the secure timing function provided by the TCG standard depends on the following functional blocks, data structures, and commands. The timing scale contains the mandatory functionality of a TPM on any platform to maintain and increment a scale counter value (TCV) at a predefined scale increment rate (TIR in milliseconds). The specification does not require the mechanisms required to execute a tick counter in the TPM, or such performance that enables the TPM to increment the tick counter in power cycling or different power modes on the platform. However, at the beginning of each tick session, the TCV must be set to "0". If the TPM loses the ability to add TCVs based on TIR, the TPM must start a new tick session. When these situations occur, a tick session is determined from the execution and is platform specific. In particular, the tick session need not be consistent with the TPM's boot cycle.

It should be noted that if the TPM finds the tamper scale count, the TCG specification requires an explicit procedure. In this case, the TPM must treat this as an attack and shut down further TPM programs, just as in the case of a failure to self-check.

The TSNs are generated by the TPM internal random number generator at the beginning of each new tick session and are forced to be all set to zero at the end of each tick session.

CURRENT _ TICKS (CURRENT _ tick) TPM architecture is characterized in that it contains TCV, TSN and TIR in one architecture. Only this structure is used in all TPM commands that operate with the functions of the timing tick. This ensures that the identification of the tick session can be maintained in all such operations. Furthermore, it allows to link to real time by adding (differential with) the TIR to the TCV, and it is also the basis for the accuracy evaluation (e.g. offset). CURRENT _ TICKS is secure from manipulation (manipulation) by defining a TPM structure. However, maintaining contact with tick sessions and TIRs is the responsibility of the Current _ TICKS data structure when using data outside the TPM.

The TPM _ GetTicks (TPM _ get tick) command returns a CURRENT _ TICKS structure as a data structure. It should be noted that the command is common and does not require authorization.

The TPM _ tickstabblob (TPM _ tick stamp point) command is used to generate a tick stamp on a data point (blob). The execution of the signing operation requires authorization, e.g. by invoking the refer-to signing operation in an authorization session loaded with the signing key stored to be used. The actual signature data depends on the signature scheme contained in the key handle input parameter for the command.

This operation then produces a digital signature (abbreviated as used hereinafter) on the following data. In a "fixed" data field, the signature information is embodied as a TPM _ SIGN _ INFO data structure, into which field the ASCII string "TSTP" is inserted, meaning that the signature is a tick stamp. [ D (blob) ] is the hash value of the point to be tick-marked (DIGEST of tick ToStamp of TPM _ DIGEST type). Generating the summary is the caller's responsibility. The external random number (Ne) is an externally supplied 20-byte value to avoid replay attacks. The caller can insert an arbitrary value for this. The data in CURRENT _ TICKS, i.e., TCV, TSN, and TIR, may also be used.

In the following, the symbols TS [ Key ] (D (blob), Ne, TCV, TSN, TIR) are sometimes used in abbreviated form, such as TS (D, TCV), TS [ Key ] (TCV, TSN), etc., without confusion and without some parameters being functional in the demonstration. In the case of multiple instances of entities, distributed symbols are used, such as TCV _1, TSN _ a, D (blob) _1, or D _1, and TS _1,. -, TS _ n, etc. The actual physical time is denoted t _ 1. At some real time, the value of the scale counter is written as tcv (t).

In the following, temporal (temporal) inaccuracies associated with the invocation and execution of the TPM _ TickStampBlob and TPM _ GetTicks commands are ignored. That is, when any command is called at the actual time t, it returns TS (tcv (t)) and tcv (t), respectively. It should be noted that this occurs with a certain probability, which is the ratio of the TIR and TCV acquisition delay, i.e., the latency (latency) at which the command can retrieve the current TCV. This means that the internal association between TCV and the actual time on the platform is piecewise one-to-one and can be expressed as T (TCV) for the time period in which TCV is constant:

t (TCV): as [ t: TCV (t) ═ TCV ], where | T (TCV) | ═ tir. equation 1

Only when TCV _1 < ═ TCV _2, the intervals of the constant TCV are separated for different TCV values, and T (TCV _1) < ═ T (TCV _2) can be set, which results in full ordering over the interval group of the constant TCV. For some s in T (TCV), the report of the actual time of the interval involving the constant TCV is defined by T (TCV) < ═ t only when s < ═ t. That is, t (tcv) < ═ t means that t is located to the right of or within the t (tcv) interval.

The TCG specification provides a single method of correlation of TCVs with actual time in non-standardized information reviews. It invokes an external Time Authority (TA) that can perform time stamping of arbitrary data, denoted Tstamp (T timestamp) (data, T). The specification makes the following provisions. First, the platform P generates a TS at time t _1 (TCV (t _1)) from some arbitrary known data. The tick stamp is immediately sent to the TA. Second, TA generates a timestamp TStamp (TS (TCV (t _1)), t _ a) at time t _ a and sends it back to P. P then receives this timestamp from TA and immediately generates AS (TCV (T _1), T _ a, TCV (T _ 2)): TS (TStamp (TS (TCV (t _1)), t _ a), TCV (t _ 2)). This is a signed statement that can be used to prove to the external verifier the following relationship to time:

t _1 < ═ T _ a < ═ T _2, where T _ 1/2: t (TCV (T _1/2)) equation 2

In this example, the symbol AS (t _ a) is introduced to specify the accuracy report for time t _ a. It may be stored in the device and assigned to any desired location, such as to a party testing the time stamp or other platform. The difference between T _1 and T _2 is equal to the round trip time from the platform to TA and can be used to evaluate the maximum time difference of the actual TCV from the later actual time. The difference is not greater than:

d (T _1, T _ 2): 1-t _2 |; where T _1/2 is in T _1/2 EQUATION 3

In conjunction with the platform certificate for the TPM and all other certificates (including the certificate from the TA), the device can indicate what the maximum difference is that its time comes from a trusted source and that is based on the actual time of the AS and the clock platform inherent deviation. The platform can make a trusted declaration of the Real Time Clock (RTC) value and its relationship to a certain t (tcv) by using tick stamps, time stamps from the TA, and other trusted computing methods. These statements are called trusted time reports (TTS).

Fig. 1 is an exemplary diagram of a WTRU100 configured to establish a trusted local time. The WTRU100 includes an extended SIM ICC 105, a platform processor 108, an application processor and SW 110, a communication processor 115, and an external memory 120 for data. The application processor 110 may include a Digital Rights Management (DRM) agent (not shown).

The extended SIM ICC 105 includes a SIM function block 125 configured to perform the generally known functions of a generic SIM ICC. In addition, the extended SIM ICC 105 includes a secure time keeping component (STC) 130. The STC 130 includes a time report and synchronization controller 135, an RTC 140, and a tamper detection and power failure unit 145. The extended SIM ICC 105 also includes a TPM unit 150.

The existing SIM functionality 125 located on the extended SIM ICC 105 is configured to control a start password (master secret) that is used to identify the phone and provide authentication services to support establishment of a secure channel between the WTRU and the network. The root identity is securely controlled in the device, never leaking outside the secure or trusted domain of the SIM. The existing SIM function block 125 also performs the functions and operations required for 3GPP Authentication and Key Agreement (AKA) related procedures.

The time reporting and synchronization controller 135, RTC 140 and tamper detection and power failure unit 145 constitute an STC 130 located on the extended SIM ICC 105. The STC 130 is configured to provide a secure record of the time of certain events, or data entities, in the form of a time certificate or time-related data signature, and output to the requesting entity.

The time reporting and synchronization controller 135 is configured to control the functions of the RTC 140 and the tamper detection and power failure unit 145. In addition, the time reporting and synchronization controller 135 may be linked to the existing SIM function 125, the external time mechanism 165, and the platform processor 108. When the time reporting and synchronization controller 135 is linked to an existing SIM function block 125, the SIM function block 125 will be able to utilize the secure time measurements in its database, e.g. the phonebook.

The RTC 140 may include a quartz crystal oscillator. However, those skilled in the art will recognize that other precision timing devices may be used in the RTC 140. The extended SIM ICC 105 can be configured so that physically removing the RTC crystal will render the extended SIM ICC 105 inoperable. This feature may also be combined with the tamper detection and power failure unit 145.

The tamper detection and power failure unit 145 is configured to provide a method of maintaining the security of the STC 130 in the event of a power failure. The unit may include a power connection to provide power to the TPM and RTC. Unit 145 may also include tamper detection circuitry to trigger an alarm when tampering is detected. The tamper detection portion of the unit may also include tamper prevention features to prevent hardware and software level tampering. The power fail portion of the unit 145 may also include a capacitor or other short term energy retention component configured to retain sufficient energy to ensure a long enough hold time to save the RTC content to non-volatile memory in the event of a power failure or an extended SIM may have its own backup battery installed mechanically and cannot be removed.

The TPM 150 is also located on the extended SIM ICC 105 and is linked to both the existing SIM function block 125 and the STC 130. By placing the TPM 150 and STC 130 on the extended SIM ICC 105 at the same time, the SIM ICC 105 is configured to provide a trusted core root and protection for time information generated by the STC 130 and to provide trusted measurement functionality. The presence of the TPM 150 may also ensure that the time records generated by the RTC 140 and the associated time reporting and resynchronization controller 135 are stored in protected memory. This protected memory may be located in the TPM's own non-volatile memory or in memory that is external to the TPM but protected by TPM encryption. This protection against time logging will also be applicable in case of power failure. When the power failure unit 145 issues a power failure alarm to the TPM 150, the TPM 150 retrieves the latest (the last) storable time record from the time reporting and resynchronization controller 135 before the power conservation devices within the power failure unit 145 run out of power.

In the arrangement of the present invention, several features are possible. For example, the extended SIM ICC 105 of the present invention may provide a measurement of the current time to an external requesting application, either directly or through a verification procedure. The current time may be used to authenticate the device to or for an external network to securely provide the current time for synchronization.

The extended SIM ICC 105 may also cryptographically protect the time information by a digital signature and bind it to a device. Alternatively, the extended SIM ICC 105 may protect and bind the time information by encryption in case an encryption key is used to bind the time information to the device. The secure time information controlled by the extended SIM ICC 105 can be stored either internally to the extended SIM ICC 105, externally to the SIM ICC 105 but internally to the external memory 120 of the phone, or both.

The extended SIM ICC 105 may be used to provide a mechanism to enhance existing applications executed by the SIM functionality 125. For example, it may be used to provide secure timestamps for phonebook applications and data, synchronization, mobile payment or ticketing applications and related data, authentication and key management functions, or data related to the mobile communication protocol stack. Furthermore, the extended SIM ICC 105 may have many practical applications for DRM, which will be discussed later in this application.

Optionally, the WTRU100 may include a second RTC155 that is not on the extended SIM ICC 105. The second RTC155 will be coupled to the platform processor 108, and the platform processor 108 may include an optional time reporting and synchronization control SW 157. The combination of the second RTC155 and the optional time reporting and synchronization control SW 157 results in an optional STC function on the WTRU 100. Further, the second RTC155 on the platform may be used in applications where the security level need not be the same as that required by the highly protected first STC 130 within the extended SIM ICC 105. An example of such an application requiring less security is that it can be used in a tick counter for OS, temporary calendar or stop watch applications.

Optionally, the WTRU100 may also include a second TPM unit 160 that is not on the extended SIM ICC 105. The second TPM unit 160 will be connected to the extended SIM ICC 105 to provide additional security functionality. For example, since the SIM ICC 105 may be unplugged, the TPM on each device (SIM ICC and platform) may act as the root of trust for that device. Thus, this second TPM160 may use a slave (slave) TPM 150 in the SIM ICC 105 to verify its functionality and actually perform mutual authentication to bind the communication channel (interface) between the platform and the SIM ICC 105.

Figure 2 is another exemplary diagram of a WTRU200 configured to establish a trusted local time. The WTRU200 includes a generic SIM ICC 205, a platform processor 208, an application processor and SW210, a communication processor 215, external storage for data 220, an RTC 225, and a TPM 230. The application processor 210 may include a DRM agent (not shown).

The WTRU of fig. 1 differs from the WTRU of fig. 2 in that the RTC 225 and TPM 230 are located on the WTRU platform, rather than on the SIM ICC 205. The RTC 225 may be linked to an external time authority 233 and the platform processor 208. The platform processor 208 includes time reporting and synchronization control software 235 to control the RTC 225. The platform processor 208 and the RTC 225 thus act in conjunction as an STC for the WTRU 200.

By placing the RTC and TPM on the WTRU platform instead of on the SIM ICC 205, the WTRU200 will be compatible with the universal SIM ICC. This embodiment still provides the secure time component features as described in the description of the extended SIM ICC 105 of fig. 1. For example, the TPM 230 on the WTRU platform may execute programs to protect and enhance the security of the RTC 225, the time reporting and resynchronization applications, and the generated time record output. In an alternative embodiment, the WTRU200 may be configured to operate without the SIM ICC 105. An example of such an embodiment is a WTRU for a non-3 GPP mobile phone.

Alternatively, the WTRU200 may be configured for use with extended SIM ICCs by including an optional STC 240 on the SIM ICC. The optional STC 240 on the SIM ICC 205 may include a time report and resynchronization controller 245, an RTC250, and a tamper detection and power failure unit 255. Inclusion of the STC 240 on the SIM ICC 205 will provide a more secure source of time for the SIM ICC application.

Optionally, the WTRU200 may be configured for use with the extended SIM ICC 205 by incorporating an optional TPM 260 on the SIM ICC 205. The optional TPM 260 may provide additional trust and security for SIM ICC applications and additional protection for data stored on the SIM ICC 205.

Those skilled in the art will recognize that other several combinations and configurations are possible and can provide additional advantages. For example, the SIM ICC can also be configured with the STC without the TPM or tamper detection unit. Any other implementation incorporating an STC on the SIM ICC shall be considered to be within the scope of the present invention.

In another embodiment (not shown), the WTRU100 of fig. 1 and the WTRU200 of fig. 2 may be combined such that the STC is located on the SIM ICC and the TPM is located on the WTRU platform. The TPM on the WTRU platform may be used to protect and enhance the security of the STC within the SIM ICC as well as the security of any data generated by the STC.

In another embodiment (not shown), the WTRU100 of fig. 1 and the WTRU200 of fig. 2 may be combined such that the STC is located on the WTRU platform and the TPM is located on the SIM ICC. In these two additional embodiments, the WTRU would be configured to perform the same security applications and operations described in the description of fig. 1 and 2. It should be noted that having an STC on the SIM ICC will provide a higher level of security in terms of physical attacks on the RTC itself. Furthermore, without the TPM on the SIM, it is neither possible to secure the channel between the SIM and the platform, nor to perform mutual authentication between the platform and the SIM ICC unless the functionality of the SIM is extended to provide for a network in which a shared key or public/private key pair or a secret in the shared SIM ICC is used to assist in secure channel setup.

The TCG specification describes one basic step for binding an internal TPM scale counter value to an external trusted time source (i.e., a real-time clock source). This will be described in detail below. The TCG specification does not include any concepts beyond the basic mechanism.

This may indicate that few connected, loosely coupled devices use these devices to collect enough data to provide a trusted time report (TTS) to a third party. Binding the external time may occur a long time after the timestamp is generated. In particular, this may be done in a way that most devices never need to know the actual time. The common idea behind these approaches is to obtain the relationship between the scale counter value and the real time clock value through cooperation between the internal scale counter of the TPM on the platform or within the device and other entities. Such a report is embodied by appropriate combined use of a marked scale counter value (scale stamp) and a time stamp.

From a trust and security perspective, the typical accuracy report (AS), i.e., the TPM AS, is not sufficiently satisfactory. The verifier must trust the appropriate functionality of the TPM scale counter with respect to accuracy between periods T _1 and T _ a and T _2, respectively, to evaluate and trust the assertion made by the AS with respect to the actual time difference between them. One way to enhance the binding of T (tcv (T)) to the real time clock value is to construct it between two timestamps. For this embodiment, as an alternative to the above accuracy reporting, the timestamps from the TAs may be merged (fold) around ts (tcv) of P to obtain a semantically different TTS.

FIG. 3 is a flow diagram of an example method 300 that represents alternative accuracy report generation. At some initial time, the platform P requests a timestamp with some arbitrary, known data D from the TA (step 310). At t _ a, TA generates TStamp (D, t _ a) (step 320) and immediately sends it back to P (step 330). P receives the timestamp from TA at time t ≧ t _ a and generates TS (TStamp (t _ a), TCV (t)) (step 340) and immediately sends it back to TA (step 350). The TA receives the structure TS (TStamp (t _ a), tcv (t)) and generates SA (t _ a, tcv (t), t _ b) at t _ b: TStamp (TS (TStamp (t _ a), tcv (t)), t _ b) (step 360) and immediately sends the structure back to P (step 370).

The alternative accuracy report SA (t _ a, tcv (t), t _ b) is a trusted time report that states the following relationship:

t _ a is not less than T not more than T _ b, where T: t (tcv (T)), (equation 4)

This alternative accuracy report can be used by the external TA to prove the estimated range of real time when the TPM tick mark occurs.

FIG. 4 is another variation showing an alternative accuracy report generation 400. At some initial time t _ a, TA issues a time stamp for data d (I) containing an instruction to P to issue two consecutive tick stamps 410 over a predetermined time interval I415. Thus, TStamp (D (I), t _ a) is obtained. Immediately after issuing the timestamp, the TA sends the timestamp to platform P. Upon receipt of TStamp (d (i), t _ a), P generates the first tick mark TS1 by tick mark d (i) | t _ a 420. Thus, P comprises:

TS 1: TS (d (i), t _ a), TCV (t1)) equation 5

In this example, it is noted that t1 is the actual time when the scale mark occurs. P sends it immediately to TA 430. P waits for a time interval I415 and then generates a second tick mark 440, i.e.:

TS 2: TS (d (i)), t _ a | TS1, TCV (t2)) equation 6

Where t2 is a local estimate of t1+ I (at P). P immediately sends the tick mark again to TA 450. After receiving the two tick stamps TS1 and TS2, TA timing Mark 460 is as follows:

SA' (t _ a, d (i), t _ b): TStamp (TS 2| TS1, t _ b) equation 7

The alternative accuracy report SA' is a trusted time report stating the following relationship:

t _ a < (t) 1 < t1+ I < (t _ b) equation 8

Wherein, t 1: t (TCV (T1)), T2: t (TCV (T1+ I)).

Such a report SA' may be used to evaluate the TIR of the TPM.

In the implementation of a composite system that generates SA (t _ a, t _ b) or SA', there are notable variations. First and foremost, the two time mechanism requirements are not the same. P may obtain a first timestamp from TA and a second timestamp from another time authority TA'.

Fig. 5 is an example flow chart showing a second main variation when TA and/or TA' is an internal entity of the platform, namely a Real Time Clock (RTC) in combination with the time stamping function 500. This can be achieved in an elegant (elegant) way by using the trusted computing functionality of the platform as follows. At the beginning of each boot cycle, the trusted platform P initiates a specific program, the Internal Time Agent (ITA) 510. The platform performs an operation to initiate and properly configure the ITA in a trusted, non-compromised state using the secure boot function of the TCG mobile phone working group specification. Alternatively, if the platform only supports measurements of programs loaded at startup, the presence of the ITA and its trustworthiness can be certified to an external verifier at least by remote certification. Many ITAs for dedicated purposes may coexist on P.

The ITA may replace the TA in the accuracy report generation as follows. There is a secure channel between the ITA and the RTC over which the ITA can obtain an authentic actual time value at any time (step 520). The ITA may use the encryption functions of the TPM to protect the RTC values (step 530), for example, by encrypting them using the TPM _ Seal (TPM _ Seal) and TPM _ UnSeal (TPM _ UnSeal) commands. The ITA generates timestamps from these RTCs using a software encryption library or signature function of the TPM, such as a TPM _ sign command (step 540). The signing key used by an ITA may be, for example, a unique key associated with a particular ITA instance. Another option is for the ITA to use a signature authentication key (CSK) bound to the certificate identity key (AIK) of P, which refers to proving that the certificate of the CSK was signed by the AIK. This can be analogized directly to the method described below. It has the advantage of proving the presence of an ITA on a particular trusted platform P whose state can be verified by an external entity through a remotely certified TC function under the presence and uncompromisation (uncompromise) functionality of the ITA.

In some cases, tight binding of the RTC to the TCV may be required, and TCG specification may be extended in this particular way. Given that the RTC and ITA have a comparable or even higher security level than the TPM's internal tick counter (e.g., both are implemented in dedicated protection hardware), the RTC may be used as an internal time mechanism as described above, but also positively affects the tick counter at the same time. For example, the RTC and the scale counter may be driven by the same clock source. The RTC may also reset the scale counter or provide a correction (correction) value, either directly or through the ITA, when a deviation is detected. This potentially increases the confidence in the TPM _ TickStampBlob output accuracy. With the protection of the RTC (or its output), the trust in the ITA (which uses the RTC output and the TPM scale mark to declare the time value) is increased, so that the TPM scale mark using the more trusted RTC (or its output) is more trusted.

It should also be noted that additional information from the RTC may be incorporated into unused space in the TPM _ SIGN _ INFO data structure. Alternatively, the enhanced TPM _ SIGN _ INFO data structure may be specified to provide an absolute indication of the date and time rather than just the TCG delegated session values (TCV and TSN).

The TA may be configured to compensate for signature delays because in most cases, the TA will be better equipped than P to make highly accurate time reports. The simple mode of TA assumes that both the time D _ t at which UTC time is required to be obtained from its time source and the time D _ t at which time stamps are required to be generated are known with high accuracy (e.g. by continuous measurement or as a defined functional parameter). For time-dependent TPM operations on P, we also assume d _ t to be 0 for TA. The following method of locally generating d _ t > 0 is straightforward. In the following, we describe an accuracy report of signature delay compensation, denoted by SA (t, t').

To compensate for D _ t in the generation of the accuracy report of the signature delay compensation represented by SA (t _ a, t _ b), the method shown in fig. 3 may be modified such that TA includes D _ t in the first timestamp 320. In an alternative embodiment, as (D _ t, variable a), the TA generates a time stamp TS (D ', t _ a) at time t ═ t _ a for the signature delay compensated data packet denoted by D', wherein D '═ D _ t or D' ═ D _ t, and incorporates this time stamp TS (D ', t _ a) into the trusted time report SA (t _ a, D', t _ b). Here, D _ t represents a strictly (rightly) known (or estimated) time period for which TA generates a timestamp for the data. Thus, if D '═ D _ t, the TA just time stamps the delay it needs to generate the time stamps, and if D' | D _ t, then not only the delay, but also the data D itself of the TA time stamp 320. In a second alternative embodiment, for (D _ t, variable b), the TA adds D _ t to t _ a and generates a timestamp TS (D, t _ a + D _ t) at time t _ a, and incorporates this timestamp TS (D, t _ a + D _ t) into the trusted time report SA (t _ a + D _ t, D, t _ b) and immediately sends back P the time report SA (t _ a + D _ t, D, t _ b). The resulting trusted time report SA (t _ a, D' ═ D _ t, t _ b) (from variable a) or SA (t _ a + D _ t, D, t _ b) (from variable b) is then:

t _ a + D _ T ≦ T ≦ T _ b, where T: t (tcv (T)), (equation 9)

This results in a stricter time bound (bound) than when only SA (T _ a, D, T _ b) is used, since for SA (T _ a, D, T _ b) only T _ a ≦ T ≦ T _ b, where T: t (tcv (T)).

It should be noted that if the method is applied to the accuracy report AS defined by the TCG instead of the SA, a more strict time bound can be obtained which is reliable and generally not possible only if it can verify the accuracy of the scale value. That is, the accuracy reporting AS defined using TCG will only replace (shift) the RTC value represented by the timestamp in the middle of two scale values without adding any statement about the external TCV. This again highlights the shortcomings of TCG accuracy reporting AS.

The scale increment rate is a factory parameter of the TPM in the platform. Even if its initial value is trusted for practical purposes and is sufficiently accurate, this may change over time as the hardware properties used to determine the actual TIR of a particular TPM may change over a long span of time. Here, a method is proposed to measure the actual TIR of the TPM in P with arbitrary accuracy.

FIG. 6 is an exemplary graph representing a trusted TIR measurement 600. P generates two accuracy reports S _ 1: SA (t _ a, TCV (t _1), t _ b) and S _ 2: SA (t _ c, TCV (t _2), t _ d) (step 610). Thus, the external verifier to which P delivered S _1 and S _2 calculates the current estimate of the actual TIR as the average of the TIRs in the time interval encompassed by S _1 and S _2 (step 620), as follows:

t' _ 1: (t _ b-t _ a)/2, and t' _ 2: equation 10 of (t _ d-t _ c)/2

cTIR (S _1, S _ 2): equation 11 (t '_ 2-t' _1)/(TCV (t _2) -TCV (t _1)) is given by

As the accuracy report is concerned with yield (yield) bounds over the time interval of constant TCV around t _1 and t _2, respectively, the tir also obeys upper and lower bounds. The limits are: (t _ c-t _ b)/(TCV (t _2) -TCV (t _1)) ≦ cTIR ≦ (t _ d-t _ a)/(TCV (t _2) -TCV (t _1)) equation 12

Measuring TIR using two SA-type accuracy reports accompanies this approach while providing upper and lower bounds on TIR. This can be used in many traffic situations where there is a reverse interest to balance. For example, in the case of DRM, the rights holder has the benefit of limiting the allowed period of consumption of the media, while the consumer has the benefit of extending that period. This involves an actual increase in the difference between the first and second scale count values. Both the cTIR and the bounds can be computed by anyone owning S _1 and S _ 2. This may be an external verifier or ITA in P. The latter, in this example, next passes the cTIR to an external entity to provide correction for the inaccuracy of the TPM's TIR (step 630). Furthermore, each time mechanism may be independently selected in the TIR measurement. In particular some of them may be related to the internal RTC value. To further increase the accuracy of the estimation of the cTIR, the above-described approach to delay compensation may be used.

It should be noted that the accuracy of the limit can be continuously improved by using more and more time statements, since not only the scale but also the sample space of the accuracy report generation (where the time for round trip communication and signature generation may be different) becomes larger and thus the statistical error will be smaller thereafter. The rate of deviation of the TIR can be obtained by using time statements spread over a sufficiently long time interval. The deviation ratio may also be expressed as the first derivative of the TIR.

Aging of the timing device or the process on the device can be seen by the slowly increasing deviation from the factory value of the true TIR, while the deviation from the aging behavior (devision) can yield valuable information. Thus, the cTIR and the measurements including the accuracy reports leading to them can be used in a variety of different situations to derive an assessment of the state, functional parameters, or trustworthiness of P.

In tamper detection, an active side channel attack on the device or its TPM or MTM may cause a deviation in ctri, since such attacks are mostly applied to the timing of the device internal programs. One way to detect such an attack is to look at the statistical variation of the measured tir. If the statistical variation is greater than a certain predetermined value (which can be determined experimentally on a properly functioning device sample), it can be interpreted as an attack on the device (platform P), TPM or scale counter.

In fault detection, the cTIR may be continuously and significantly lower or higher over a period of time and higher than normal deviations due to aging. This situation can be interpreted by an external observer as a proof of the device scale counter or the failure of the device itself.

Detection of a malfunctioning condition: if the cTIR is arbitrarily and significantly lower or higher over a period of time and higher than normal deviations due to aging, voltage changes or temperature changes, etc., this can also be interpreted by an external observer as a malfunction or as evidence of tampering of the scale counter or device.

The detection methods described above may be largely embedded in trusted devices used in the art that may not have other functionality (e.g., enhanced sensors) to detect anomalies than the methods described above. Embedding a TPM in a long-term unattended or unattended machine-to-machine (M2M) system for use may be one area of intended application.

The trusted time report described so far does not itself make any statement as to the trustworthiness and/or nature of P. It is clear that the latter is signed with a graduated stamp based on the signature key used by P. This is the key to security for accuracy reporting and later tick stamping, depending on them. That is, the TA itself does not know the status of the platform requesting the report; worse still, it does not even know that he is communicating with the TPM at all, since the tick stamp operation and the tick counter itself can be emulated. Thus, without further protection, the accuracy report would face all types of attacks, including TCV manipulation, counterfeit tick stamps, man-in-the-middle attacks, and so on. Fig. 7 illustrates one example approach that may overcome some of these problems.

FIG. 7 is an exemplary diagram illustrating a method of protecting an accuracy report 700. Assume that P has generated a certificate identity key (AIK) and for this purpose has an AIK certificate from the private ca (pca) that it requests according to the protocol defined by the TCG. The accuracy report is bound to the platform identity (platform identity) in the following manner. P may generate a signature authentication key CSK from the AIK (step 710). P and TA may then generate accuracy reports AS () and SA () respectively, each marked by the P scale, designated to use CSK AS the signing key, i.e., TS CSK (TCV (t)) calls a scale stamp in either protocol at each time t (step 720).

The CSK used above may be dedicated to this single operation and discarded after the accuracy report is generated, or may be used in further operations, in particular for subsequent calibration marks. To prove to verifier V at a later time t that trusted platform P owns a data blob d, P may generate tts (t): TS [ CSK ] (D, tcv (t)), where CSK may be a new key authenticated by AIK, or one originally used in accuracy report generation (step 730). P may publish the AIK certificate, the public part of the CSK, the accuracy report or signature data therein, tts (t), D, and tcv (t) to V (step 740). V may then verify that the accuracy report was created by the trusted platform under an active TPM (step 750) that substantially meets the security requirements specified by the TCG, and in particular with respect to a timing scale or a trusted time report tts (t) generated by the same platform (step 760).

Similarly, not only the accuracy report, but any other trusted time report may use the CSK. In particular, each tick stamp operated by the TPM may use the CSK to generate a TTS that represents possession of some data at a particular TCV.

The PCA may act as a TA to provide an accuracy report by integrating the steps of AIK authentication and TTS generation. The process of authenticating the AIK between platform P and PCA is as follows.

When P requests AIK authentication from the PCA, P also issues a request for an accuracy report SA according to the method described above. The PCA and P run the above protocol for generating the SA, with the signature data D specified as a common part of, or connected to, the AIK for the requested authentication. It should be noted that in this protocol the tick stamp of P cannot be signed by the CSK for the AIK requested, since the latter is only activated for use after being authenticated by the PCA. Another signing key must therefore be used by P for the tick stamps and it is the responsibility of PCA and P to mitigate man-in-the-middle attacks on the SA generation protocol. This is achieved by using encryption and random numbers in the AIK authentication process. Only after the encryption and random number are used will the PCA proceed with AIK authentication.

The TTS alone has the importance of receiving an AIK authentication request. The importance of the TTS generated and the AIK certificate when presented to the verifier together are: p is a trusted platform that requests AIK authentication at some particular moment in time and the time of the AIK authentication request is among two time values represented by two TCVs in the SA, i.e., an authenticatable report like TTS generated above.

The TTS is bound by a reference point to a particular AIK of P. Thus, each subsequent tick stamp issued by P or another accuracy report generated by P can be bound to this reference point in time and its trusted relationship to the TCV of the CSK using the AIK is as described above. One use case for such a statement is to revoke, invalidate, respectively, the AIK credential of a rogue platform.

When the generation of TTS is delayed until AIK authentication of the PCA occurs in the following manner, the above-noted problem of requiring an additional signing key can be circumvented. When P requests AIK authentication from the PCA, it also sends a request for an accuracy report SA according to the method described above. The PCA performs AIK authentication and generates a certificate. The PCA generates a first timestamp of an SA generation protocol that includes a public portion of the AIK or the entire AIK certificate as signature data. The PCA sends the AIK certificate and first timestamp to P and optionally starts a timer. P and PCA complete the SA generation process, where P uses CSK for AIK. Alternatively, the PCA may force a refresh of the TTS generated by generating the latest timestamp only when the timer value is not greater than a certain preset value, so that the TCV represented therein stays only for a limited time after AIK authentication.

The TCG introduces the concept of remote attestation to prove to a verifier that a platform not only contains a TPM that is available, but is also in an accurately determined, dependable state. One major problem with this concept is that the state of the platform often changes over time.

The remote attestation process can be extended to include a report on the time when it occurred. Fig. 8 is an exemplary flow diagram of a remote attestation process 800. After receiving the attestation request from the authenticator (step 810) and establishing an authorization session between the attestation client and the TPM, a tick stamp TS _ a is generated (step 820). This may be performed using the CSK for the subsequent AIK for remote attestation. P then proceeds with remote attestation using the TPM _ Quote command by signing the Platform Configuration Registration (PCR) with AIK (step 830).

As a further extension, in order to measure the time difference between the state of P represented by the signed PCR and the storing of the measurement log (SML), a second tick stamp TS _ B may be generated (step 840) immediately before sending the Attestation Package (AP) (step 850) to the verifier. The advantage of this approach is that the SML actually stores events at a certain granularity, that is, not all information changes of the platform state are recorded in the SML, let alone physical changes. The depth of the SML depends on the execution of P, in particular the trusted operating system. There may be events that are not stored in the SML that occur between signing the PCR value and retrieving the SML. The likelihood of this situation can be evaluated by using the time difference represented by the difference between TS _ B and TS _ a.

Various options may be implemented, for example, the attestation client may request a timestamp from the TA in any of the ways described above to generate the accuracy report, the attestation client may act as or cooperate with an internal ITA to generate the accuracy report, instead of just a tick stamp based on the RTC value, which may be integrated in the modified attestation packet data structure, or the platform's Stored Measurement Log (SML) may be extended by the tick stamp.

The time report incorporated in the remote attestation by the method just described may be used to partially relieve the verifier from the burden of maintaining a large database of trusted platform states. For example, the PCA may maintain a list of rogue platforms (e.g., information that sometimes affects the platform in a certain state using certain malware) and the verifier may submit the AP, TS _ A, TS _ B, to the PCA to obtain information about the trustworthiness of P at attestation time ("second view").

The time report may also be more useful when compared to the proof by the status of P at an earlier time. For this reason, the same identification, i.e. AIK (although this is somewhat contrary to the spirit behind the idea of AIK intended to be the identification of the protection platform) has to be used to perform the subsequent proof. The verifier may then evaluate whether the platform state has changed in an undesirable manner between the proofs at the same time.

In each reset of the TPM counter, a random number is required in order to obtain a well-defined security context to transfer the time report to an external entity. The tick session random number (TSN) is then used to associate a timestamp with the reset operation. The random number needs to be unique to the device and each reset operation, and is therefore generated by a random number generator internal to the TPM. The actual TSN may be obtained by generating a TPM _ GetTicks command. This TSN value is included in the resulting CURRENT _ TICKS data structure.

Current TCG specifications make no request for functionality of the TPM to maintain the ability to increment the tick counter across power cycles or in different power modes on the platform, which results in loss of session. In order to establish a session that can remain in a restart period and different power modes, a meta-session concept is needed to provide sessions that can span different TSN sessions using meta-TSN (mtsn).

Fig. 9 is an exemplary method 900 of representing a meta-session. The mTSN may be provided by an external time provider or Time Authority (TA), or internally by a random number generator of the TPM. In the first case, the TA receives a mTSN request from the device at a particular point in time during the initialization process of the platform (step 910), for example, boots the operating system to generate a mTSN (step 920), stores the mTSN (step 930), and securely (TPM-sealingly) transmits the mTSN to the device (step 940). In the second case, the device generates a mTSN and binds it to the platform manifest and sends the bound mTSN to the TA to indicate that the mTSN was generated by an active, invariant TPM on a non-compromised platform. This mTSN is then used as the nonce for the TPM _ tickstampbob command. Each generated stamp then includes the mTSN, which is assigned to a particular meta-session.

It should be noted that in both cases, during the session initialization period, the device must either send a request for the mTSN to the TA or send the mTSN it generates itself to the TA.

The use of mTSN is not protected by hardware and therefore requires a trusted operating environment defined in the TC. The operating environment is verified by a attestation operation, which allows the encapsulation of mtsns in a particular well-defined state of the overall system. It also leverages the latest TSN as a random number for the next stamp operation rather than using a fixed mTSN. This may result in a link to the session. To prove the integrity of the link requires the addition of at least offline attestation data to the first stamp. This allows for delayed verification of the system state.

The need for a random number database at a time provider (TA) or operator can be eliminated and mitigated by the extensive use of signatures issued by the TA and operator. This scheme provides a great improvement in resilience since the network side communication reduces the traffic to a minimum. At the device side, the random number corresponds to a COOKIE (session value) which allows several different time services and reference frames that may be used in the communication.

Another approach to spanning the gap between single sessions and proving session unity is to include a Real Time Clock (RTC) in the platform design that is considered trusted. The trusted RTC provides a signing date whose signature is included according to the mTSN scheme demonstrated above. This is done using at least the first random number. Implementing a trusted RTC requires the establishment of protected cryptographic functions and unique identifications.

In some use cases, it is desirable to predict future TCVs using the TCVs and TIR reported in the most recent report. If the initial session is terminated due to, for example, a power failure, it is necessary to ride through the event and map the old TCV to subsequent sessions. This is done by using the AS of the initial session and the received data and a timestamp binding the TCV to a specific point in time. Each subsequent session also receives an AS. By using these two AS, date and time information and the TIR it is possible to calculate the TCV related elapsed time of an event in a subsequent session. Furthermore, by analyzing the system log and the interaction profile, it is possible to estimate the "out-of-session" duration (e.g., power failure time). This underlying scheme may also be combined with the previously presented concept of mTSN.

One application of trusted computing technology is for DRM. In the DRM case, the accuracy report can be used in two phases. The following example uses the terminology of the open mobile alliance. The usual case assumes that the device is configured with a DRM agent, i.e. an entity that uses access control on content in compliance with rights set by a specific rights holder.

Fig. 10 is an exemplary flow diagram of a method 1000 for using trusted computing techniques in DRM. In this example, a Rights Issuer (RI) may request an AS and a tick stamp from a DRM device during execution of the authorization object acquisition protocol (ROAP) AS defined in the oma DRM v2.0 standard (step 1010). The AS may be bound to an attestation report on the platform to allow the RI to check its integrity (step 1020). In this way, the RI obtains assurance that the DRM agent is available and non-compromised, and has access to precise, tamper-free time. If all of these checks are successful, only the authorization object (RO) is passed (step 1030). The RI can then encode the time limit in the usage rights directly from the TSN and TCV in the RO (step 1040). Upon receiving the RO during the initialization phase of rights acquisition, the DRM agent may cooperate with, or may even be integrated with, the ITA on the device (step 1050). The DRM agent can then obtain the tick stamp from the TPM (step 1060) and compare the TSN and TCV to the limits indicated in the RO and apply access control to the content accordingly.

In a second example, the time limits in the RO use a standard time format, e.g., UTC, numeric values, and joining them with the TCV is the task of the DRM agent. The DRM agent can use the AS generated at boot time to ensure that the TCV is bound to the exact external time and belongs to the same session of the scale counter (by comparing the TSN and MTM non-volatile memory in the AS). Again, the DRM agent has a valid time associated with the TCV to base access control to the content. When the time span between AS and time of accessing the content is long, significant drift in TCV may occur, which can be corrected using the method described above.

In the DRM case, the validity limit of the TCV to a single tick session represented by a unique TSN may be useful. When resetting the tick counter and updating the TSN, the rights can be bound to a specific TSN value and the DRM agent will not grant access to the protected content. If some entity, such as the MTM, DRM agent or ITA, is able to reset the tick counter (either by any means of disabling the tick counter and forcing a reset as specified, or by extending the functionality specified in the TCG standard), this can be used to invalidate access rights to the content in any TSN session, desired time or TCV. On the other hand, if it is desired to maintain access rights beyond a single TSN session, the RI, DRM agent and/or ITA may use methods to span the session and update the validity limits of the TCV and TSN.

There are many situations when a trusted mobile phone will receive an external RIM certificate from an external entity and convert that certificate into an internal RIM certificate that it will hold and use for internal platform certification purposes. In many cases, the external certificate will have validity information in terms of date and time. However, the current TCG Mobile Phone Working Group (MPWG) description does not contain explicit date and time fields. The background to this decision of MPWG is that neither the TPM nor the platform are expected to have the ability to have trusted time information to validity check the certificate in the near future. The internal RIM _ Certificate of the mobile phone currently uses only a monotonic counter for validity checking purposes. This significantly limits the kinds of validity checks that can be made on RIM _ Certificate.

Nevertheless, if there is a secure time source, such as provided by the methods described herein before, the validity of the RIM certificate can be checked according to the validity period expressed in terms of the true date and time.

In an alternative embodiment, the internal Reference Integrity Metric (RIM) certificate of a trusted mobile phone may be made more secure in a system comprising a secure and trusted Internal Time Agent (ITA). The ITA securely processes the real time information provided by the secure RTC. For phones with this capability, the single (monotonic) counter field in the internal RIM _ Certificate structure can be replaced or supplemented with the date and time field provided by the ITA. Likewise, if the session span and/or TCV value of a TSN can be obtained from the ITA and TPM of the phone, a chain record of the session value and/or TCV of the TSN can also be included in an appropriate place of the internal RIM certificate. Using a hash extension may be an option to obtain the session value of the TSN and/or the history of the TCV in a manner that is verified by the verifier.

To the extent that such supplementary information is included on the TSN/TCV as date/time or session span information, an extended classification field (64 bytes) available in the current RIM _ Certificate format may be used. It should be noted that this field is categorized for proprietary or ancillary data fields and thus may provide a location for inserting the date and time data.

Although the features and elements of the present invention are described in the particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided herein may be implemented in a computer program, software, or firmware executed by a general purpose computer or a processor. Examples of the computer-readable storage medium include read-only memory (ROM), random-access memory (RAM), registers, buffer memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM optical disks and Digital Versatile Disks (DVDs).

For example, suitable processors include: a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any Integrated Circuit (IC), and/or a state machine.

Examples

1. A method for protecting time values in wireless communications, the method comprising:

transmitting a timestamp request;

receiving a timestamp in response to the timestamp request;

generating a scale stamp;

transmitting the scale stamp; and

an alternative accuracy report is received.

2. The method of embodiment 1 wherein the received alternative accuracy report is a trusted time report.

3. A method for protecting time values in wireless communications, the method comprising:

receiving a first timestamp;

generating two tick stamps for continuous transmission;

receiving a modified timestamp; and

the scale marks the modified timestamp.

4. The method of embodiment 3, wherein the two timestamps are transmitted consecutively at a predetermined time interval.

5. The method of embodiments 3 or 4, wherein the first timestamp comprises data.

6. The method as in any one of embodiments 3-5 wherein the data comprises instructions to generate the two tick stamps.

7. The method as in any one of embodiments 3-6 wherein the first timestamp and the modified timestamp are received from different time authorities.

8. The method as in any one of embodiments 3-7 wherein at least one of the different time authorities is an internal time agent.

9. The method as in any one of embodiments 3-8, further comprising:

acquiring a real-time clock value;

protecting the actual clock value; and

and generating a time stamp according to the real-time clock value.

10. The method according to any of the preceding embodiments, further comprising:

a Trusted Platform Module (TPM) is used to protect the local clock.

11. The method according to any of the preceding embodiments, wherein the method is based on a trusted computing method.

12. The method of any preceding embodiment, wherein the TPM is securely bound to an external clock.

13. The method according to any of the preceding embodiments, further comprising:

at least one accuracy report (AS) is used to audit data provided by a time source that provides an initial time.

14. The method according to any of the preceding embodiments, further comprising:

online Certificate Status Protocol (OCSP) responders are ignored in the application of x.509 certificates in order to reduce the cost of operating a trust center.

15. The method according to any of the preceding embodiments, further comprising: the certificate is checked using a secure time source.

16. The method according to any of the preceding embodiments, further comprising:

enabling a mobile device to have multiple usage scenarios for establishing a trusted time report by the device, possibly through cooperation with other entities.

17. The method according to any of the preceding embodiments, wherein the accuracy report (AS) provides a trusted link between the hardware protected device side counter value and the actual time.

18. The method of embodiment 17 wherein the AS is established and protected by a trusted computing method and provides sufficient flexibility and adjustment of the trustworthiness of the resulting time report.

19. The method of any preceding embodiment, wherein an external time is bound to the TPM after timestamp generation.

20. The method according to any of the preceding embodiments, wherein there is cooperation between an internal scale counter on the platform of the TPM and other entities in order to obtain the relationship between the scale counter value and the real time clock value.

21. The method of embodiment 20 wherein the signed tick counter value and the timestamp are used in combination.

22. The method according to any of the preceding embodiments, wherein when multiple instances of an entity are used, and wherein subscript symbols such as scale counter value (TCV) TCV _1, scale session random number (TSN) TSN _ a, D (blob) _1 or D _1, and TS _1,.., TS _ n are used, such that the true physical time is represented as t _1,..., t _ n, and the value of the scale counter at some real time is written as TCV (t).

23. The method of embodiment 21 or 22, wherein if AS is not sufficiently satisfactory for trustworthiness and security, a verifier is required to verify proper functioning of the TPM scale counter with respect to accuracy in the periods between T _1 and T _ a and between T _ a and T _2, respectively, thereby evaluating the actual time difference between them.

24. The method of embodiment 23 or 23 wherein to better bind T (tcv (T)) to the real time clock value, the value is constructed between two timestamps.

25. The method as in any one of embodiments 22-24 wherein timestamps from the TAs are merged around ts (tcv), resulting in different Trusted Timestamps (TTS).

26. A method as in any of the embodiments 22-25 wherein at some initial time, the platform (P) requests a timestamp from the TA with some known data D.

27. The method as in any one of embodiments 22-26 wherein at t _ a, the Time Authority (TA) creates TStamp (D, t _ a) and immediately sends it back to P.

28. The method as in any of embodiments 22-27 wherein P receives a timestamp from TA at time t > ═ t _ a and creates and immediately sends a TS (TStamp (t _ a), tcv (t)) back to TA.

29. The method as in any one of embodiments 22-28 wherein the TA receives TS (TStamp (t _ a), TCV, and creates SA (t _ a, TCV (t), t _ b) at t _ b, TStamp (TS (TStamp (t _ a), TCV (t)), t _ b), and immediately sends the structure back to P.

30. The method as in any one of embodiments 22-29 wherein T _ a < (T) < ═ T _ b, where T: t (tcv (T)).

31. A method as in any of the embodiments 22-30 wherein at time t _ a TA issues a time stamp to P of data (D) containing an instruction to issue two consecutive tick stamps at a predetermined time interval (I).

32. The method as in any one of embodiments 22-31 wherein the TA obtains TStamp (D (I), t _ a) after issuing a timestamp, the TA immediately sending the timestamp to platform P.

33. The method of any of embodiments 22-32 wherein P, upon receiving TStamp (d (i), t _ a), scales mark d (i) | t _ a.

34. The method as in any one of embodiments 22-33, wherein P obtains: TS 1: TS (d (i), t _ a), TCV (t 1)).

35. The method as in any one of embodiments 22-34 wherein t1 is the actual time when the tick mark occurred and P immediately sent the tick mark to TA.

36. The method as in any one of embodiments 22-35 wherein P waits for time interval I and then the tick marks a second tick mark of TS 2: TS (D ((I, t _ a) | TS _1, TCV (t2)), where t2 is t1+ I and P immediately sends the local estimate of the tick stamp to TA (at P).

37. The method as in any one of embodiments 22-36 wherein the TA, upon receiving the tick stamps TS1 and TS2, time stamps SA' (t _ a, d (i), t _ b): TStamp (TS 2| TS1, t _ b).

38. The method as in any one of embodiments 22-37 wherein the alternative accuracy report (SA') is a trusted time report stating the relationship t _ a < ═ t1 < t1+ I < > t _ b where t 1: t (TCV (T1)), and T2: t (TCV (T1+ I)).

39. The method according to any one of the preceding embodiments, wherein at the start of a boot cycle, the trusted platform (P) method comprises:

initiating an Internal Time Agent (ITA); and

the ITA is forcibly initiated and properly configured in a trusted, non-compromised state using the secure boot feature described by the TCG mobile phone working group.

40. The method of embodiment 39, wherein the trustworthiness of the ITA is certified by remote certification to an external verifier if the platform supports only the measurement of the loader at boot time.

41. The method according to any one of embodiments 39 or 40, wherein a specific purpose ITA paradigm is co-located on P.

42. The method as in any one of embodiments 39-41 wherein the ITA replaces the TA in the creation of the accuracy report.

43. A method as in any one of embodiments 39-42 wherein there is a secure channel between the ITA and the RTC over which the ITA obtains a trusted actual time value at any time.

44. A method as in any one of embodiments 39-43 wherein the ITA uses the TPM's encryption functionality to protect the RTC value.

45. A method as in any of embodiments 39-45 wherein the ITA uses a software encryption vault or a signature function of the TPM to create a timestamp from the RTC value.

46. The method as in any one of embodiments 39-46 wherein the ITA uses a signature authentication key (CSK) bound to the P's certificate identity key (AIK), whereby a certificate authenticating the CSK is signed by the AIK.

47. A method as in any preceding embodiment wherein the RTC and the scale counter are driven by the same clock source.

48. The method as in any one of the preceding embodiments, wherein additional information of the RTC is incorporated into unused space of the TPM _ SIGN _ INFO data structure.

49. The method of any preceding embodiment, wherein an enhanced TPM SIGN INFO data structure is specified to provide an absolute indication of date and time.

50. The method according to any of the preceding embodiments, wherein the time D _ t required to obtain universal clock (UTC) time from its time source and the time D _ t required to create a timestamp are noted with high accuracy.

51. The method of embodiment 50 wherein the time-dependent TPM operation on P is assumed to be d _ t-0.

52. The method as in any one of embodiments 50 or 51 wherein the accuracy report of signature delay compensation is represented by SA (t, t').

53. The method as in any one of embodiments 50-52 wherein to compensate for D _ t in creating the accuracy report of signature delay compensation represented by SA (t _ a, t _ b), the TA includes D _ t in the first timestamp such that SA is modified at time t _ a to (D _ t, variable a), the TA creates D ' ═ D _ t, or D ' ═ D | _ D _ t TStamp (D ', t _ a), and immediately sends it and D _ t back to P.

54. The method as in any one of embodiments 50-53 wherein the TA adds D _ t to t _ a and creates at time t _ a (D _ t, variable b), the TA creates TStamp (D, t _ a + D _ t) and immediately sends it back to P.

55. The method of embodiment 54 wherein the trusted time report is represented as SA (T _ a, D '═ D _ T, T _ b) (variable 2a), or SA (T _ a + D _ T, D', T _ b) (variable 2b) followed by T _ a + D _ T < ═ T _ b, where T: t (tcv (T)), which obeys stricter time bounds than SA (T _ a, D, T _ b), because under SA (T _ a, D, T _ b) only T _ a < T _ T < T _ b, where T: t (tcv (T)).

56. The method of any preceding embodiment, wherein the scale increment rate is a factory parameter of a TPM in the platform.

57. The method according to any of the preceding embodiments, wherein P creates two accuracy reports S _ 1: SA (t _ a, TCV (t _1), t _ b), and S _ 2: SA (t _ c, TCV (t _2), t _ d).

58. The method as in any one of embodiments 56 or 57 wherein the external verifier to which P passes S _1 and S _2 calculates a current estimate of actual TIR as an average of the TIR over the time span between S _1 and S _ 2.

59. The method as in any one of embodiments 56-58, wherein t' _ 1: (t _ b-t _ a)/2, and t' _ 2: (t _ d-t _ c)/2 and tir (S _1, S _ 2): (t '_ 2-t' _1)/(TCV (t _2) -TCV (t _ 1)).

60. The method as in any one of embodiments 56-59 wherein the cTIR complies with an upper and lower bound as a compliance bound (yield bound) on a time interval of constant TCV around t _1 and t _2, respectively, with respect to the accuracy report.

61. The method of embodiment 60 wherein at least one of the limits is represented by (t _ c-t _ b)/(TCV (t _2) -TCV (t _1)) ≦ cTIR ≦ (t _ d-t _ a)/(TCV (t _2) -TCV (t _ 1)).

62. The method as in any one of embodiments 56-61 wherein accuracy increases with a difference between the included first and second scale counter values and both the cTIR and the range are calculated by an entity having S _1 and S _ 2.

63. The method as in any one of embodiments 56-62 wherein each time mechanism in the TIR measurement is independently selected.

64. The method as in any one of embodiments 56-63 wherein the accuracy of the range is continuously demonstrated using additional time proofs and an estimate of the rate of deviation of the TIR is obtained using time proofs over a long time interval.

65. The method of any of embodiments 56-64, wherein the cTIR and measurements comprising accuracy reports leading to the cTIR are used in a variety of different scenarios to derive an assessment of state, functional parameters, or trustworthiness of P.

66. The method as in any one of embodiments 56-65 wherein if the statistical difference in measured cTIRs is greater than a certain preset value, an attack on the device (platform P), TPM, or tick counter is interpreted.

67. The method as in any one of embodiments 56-66 wherein if the cTIR is continuously and significantly lower or higher over a period of time and above the normal deviation due to aging of the time device, then such a condition can be interpreted by an external observer as evidence of a failure of the device scale counter.

68. The method as in any one of embodiments 56-67 wherein if the cTIR is arbitrarily and significantly lower or higher over a period of time and is higher than the normal deviation caused by aging, voltage change, or temperature change, then this can be interpreted as a malfunction or a tamper evidence of a scale counter or device.

69. The method as in any one of embodiments 56-68 wherein the plurality of expected application fields are a TPM embedded in the system.

70. The method of any preceding embodiment, wherein the TA is unaware of the status of the platform requesting the report or the platform is in communication with the TPM.

71. The method of embodiment 70 wherein P has created a certificate identity key (AIK) and to this end has an AIK certificate from the private ca (pca) that P requests according to the protocol defined by the TCG.

72. The method as in any one of embodiments 70 or 71 wherein the accuracy report is bound to a platform identification.

73. The method as in any one of embodiments 70-72 wherein P creates a signature authentication key CSK from the AIK.

74. The method AS in any one of embodiments 70-73 wherein P and TA create accuracy reports AS () and SA, respectively, wherein each scale instance labeled by P is designated to use CSK AS a signing key.

75. A method as in any of embodiments 70-74 wherein to prove to a verifier V at a later time t that a trusted platform P has a data blob D, the method further comprises:

p creates tts (t): TS [ CSK ] (D, tcv (t)), where CSK may be a new key authenticated by AIK, or one originally used in the creation of the accuracy report; and is

P publishes AIK certificate, public part of CSK, accuracy report or data signed therein, tts (t), D, and tcv (t) to V.

76. The method as in any one of embodiments 70-75 wherein V authenticates that the accuracy report was created by a trusted platform under an active TPM.

77. The method as in any one of embodiments 70-76 wherein V authenticates that the trusted time report TTS (t) is created by the same platform.

78. The method of any preceding embodiment, wherein each tick stamp operated by the TPM uses the CSK to create a TTS that indicates some data is present at a particular TCV.

79. The method as in any one of the preceding embodiments, wherein the PCA functions as a TA to provide accuracy reporting by integrating AIK authentication and TTS creation processes.

80. The method of embodiment 79, further comprising:

the AIK is authenticated between platform P and the private CA PCA, where P requests attestation of the AIK from the PCA and issues a request for an accuracy report SA.

81. The method of any of embodiments 79 or 80, wherein authenticating the AIK between platform P and private CA PCA further comprises:

PCA and P run a protocol for creating SAs in which signature data D is specified as a public part of, or connected to, an AIK for which attestation is requested.

82. The method as in any one of embodiments 79-81 wherein authenticating the AIK between platform P and private CA PCA further comprises:

the PCA proceeds with AIK authentication.

83. The method according to any of the preceding embodiments, wherein the TTS has the importance of receiving an AIK authentication request.

84. The method according to any of the preceding embodiments, wherein the importance and AIK certification of the TTS generated is: when presented together to a verifier, P is a trusted platform that requests AIK authentication at some particular time; and the time of the AIK authentication request is among the two time values represented by the two TCVs in the SA.

85. The method according to any one of the preceding embodiments, wherein the TTS is bound to a specific AIK of P.

86. The method according to any of the preceding embodiments, further comprising:

PCA performs AIK authentication and creates a certificate;

creating a first timestamp of the SA creation protocol including a public portion of the AIK or the entire AIK certificate as signature data;

sending the AIK certificate and the first timestamp to the P, and optionally starting a timer; and

the SA creation process is completed by P and PCA, where P uses CSK for the AIK in question.

87. The method of embodiment 86 wherein the PCA forces a refresh of the TTS created by issuing the latest timestamp only when the timer value is not greater than a certain preset value, whereby the TCV represented therein stays only for a limited time after AIK authentication.

88. The method of any preceding embodiment, wherein the remote attestation process is extended to include a report on a time of the TPM change.

89. The method according to any of the preceding embodiments, wherein the tick stamp TS _ a is created after receiving the attestation request from the authenticator and after establishing an authorization session between the attestation client and the TPM.

90. The method of embodiment 89 wherein the authorization session is established using a CSK for an AIK used in subsequent remote attestation.

91. The method of embodiment 90, wherein P proceeds with remote attestation using a TPM _ Quote command by signing PCRs with AIKs.

92. The method as in any one of embodiments 88-91 wherein the second tick mark TS _ B is created immediately before sending the Attestation Package (AP) to the verifier.

93. The method as in any one of embodiments 88-92 wherein a certifying client requests a timestamp from a TA in any one of the above-described ways to generate an accuracy report.

94. A method as in any of embodiments 88-93 wherein the certifying customer acts as an internal ITA to generate an accuracy report in lieu of a RTC-based tick stamp alone.

95. The method of any preceding embodiment, wherein the tick stamps are integrated into the modified certification package data structure.

96. The method of any preceding embodiment, wherein a Storage Measurement Log (SML) of the platform is extended by a tick stamp.

97. The method of any preceding embodiment, wherein time reporting incorporated in remote attestation is used to partially relieve the burden on a verifier to maintain a large database of trusted platform states.

98. The method of any preceding embodiment, wherein the time report is compared to the proof by the state of P at an earlier time.

99. The method of any preceding embodiment, wherein in each reset of the TPM counter, a nonce is required to obtain a well-defined security context to transfer the time report to the external entity.

100. The method of embodiment 99 wherein a tick session random number (TSN) is subsequently used to associate a timestamp with the reset operation.

101. The method of embodiment 99 or 100, wherein the random number is unique to the device and each reset operation, such that the random number is generated by a random number generator internal to the TPM.

102. The method as in any one of embodiments 99-101 wherein the actual TSN is obtained by issuing a TPM _ GetTicks command and the TSN value is included in the resulting CURRENT _ TICKS data structure.

103. A method as in any of embodiments 99-102 wherein to establish a session that can remain in a restart period and different power modes, a meta-session is required to provide a session that can span different TSN sessions using a meta-TSN (mtsn).

104. The method as in any one of embodiments 99-103 wherein the mTSN is generated by an external time provider or Time Authority (TA), or internally by a nonce generator of the TPM.

105. The method as in any one of embodiments 99-104 wherein the TA receives the mTSN request from the device at a particular point in time during an initialization process of the platform.

106. The method as in any one of embodiments 99-105 wherein demand on a database of random numbers at a time provider (TA) may be reduced by extensive use of signatures issued by the TA and an operator.

107. The method of any preceding embodiment, wherein a Real Time Clock (RTC) is incorporated into the platform design.

108. The method according to any of the preceding embodiments, wherein the method is performed by a Digital Rights Management (DRM) device.

109. The method of embodiment 108 wherein a Rights Issuer (RI) requests an AS and a tick stamp from a DRM device during execution of an authorization object acquisition protocol (ROAP).

110. The method AS in any one of embodiments 108 or 109 wherein the AS is bound to an attestation report on the platform.

111. The method as in any one of embodiments 108-110 wherein the RI obtains assurance that the DRM agent is available and non-compromised and has access to an accurate, tamper-free time.

112. The method as in any one of embodiments 108-111 wherein the authorization object is only transferred if all checks are successful.

113. The method as in any one of embodiments 108-112 wherein the RI encodes the time limit in the usage right directly from the TSN and TCV in the authorization object (RO).

114. The method as in any one of embodiments 108-113 wherein the DRM agent cooperates with or is integrated with the ITA on the device upon receiving the RO during the initialization phase of rights acquisition.

115. The method as in any one of embodiments 108-114 wherein the DRM agent obtains the tick stamp from the TPM and compares the TSN and TCV to the bounds indicated in the RO and applies them accordingly to access control of the content.

116. The method as in any one of embodiments 108-115 wherein the time bounds in the RO use a standard time format and associating them with the TCV is a task of the DRM agent.

117. The method as in any one of embodiments 108-116 wherein a unique TSN is used to represent the validity limits of a TCV for a single tick session.

118. The method as in any of embodiments 108-117 wherein when the tick counter is reset and the TSN is updated, the rights are bound to a specific TSN value and the DRM agent will not be granted access to the protected content.

119. The method as in any of embodiments 108-118 wherein the trusted time report is for a RIM certificate.

120. The method of embodiment 119 wherein the validity of the RIM certificate is checked against a validity period expressed in terms of a true date and time.

121. The method of embodiment 119 or 120, wherein the trusted mobile internal RIM certificate uses a trusted Internal Time Agent (ITA).

122. The method as in any one of embodiments 119-121, wherein the session value of the TSN and/or the history of the TCV is captured in a manner verified by the verifier using a hashed extension.

123. A wireless transmit/receive unit (WTRU) configured to use the method of any of the preceding embodiments.

124. A wireless transmit/receive unit (WTRU), comprising:

a Trusted Platform Module (TPM) configured to

Transmitting a timestamp request;

receiving a timestamp in response to the timestamp request;

generating a scale stamp;

transmitting the scale stamp; and

an alternative accuracy report is received.

125. A wireless transmit/receive unit (WTRU), comprising:

a Trusted Platform Module (TPM) configured to

Receiving a first timestamp;

generating two tick stamps for continuous transmission;

receiving a modified timestamp; and

the scale marks the modified timestamp.

126. The WTRU of embodiment 124 or 125 wherein the TPM is configured to transmit two tick stamps consecutively at predetermined time intervals.

127. The WTRU as in any one of embodiments 124 and 126 wherein the TPM is configured to receive a first timestamp comprising data.

128. The WTRU as in any one of embodiments 124 and 127 wherein the TPM is configured to generate the two tick stamps based on data received in the first timestamp.

129. The WTRU as in any one of embodiments 124 and 128 wherein the TPM is configured to receive the first timestamp and the modified timestamp from different time authorities.

130. The WTRU as in any one of embodiments 124-129 wherein the TPM further comprises an internal time agent.

131. The WTRU as in embodiment 130 wherein the internal time agent is configured to:

acquiring a real-time clock value;

protecting the real-time clock value; and

generating a timestamp based on the real-time clock value.

132. A method for protecting accuracy reports in wireless communications, the method comprising:

generating a signature authentication key (CSK) from the certificate identity key (AIK);

generating an accuracy report;

generating a trusted time report (TTS); and

publishing an AIK certificate, a portion of the CSK, the accuracy report, or signature data.

133. A wireless transmit/receive unit configured to use the method of embodiment 132.

A processor associated with software may be used to implement a radio frequency transceiver to facilitateFor use in a Wireless Transmit Receive Unit (WTRU), User Equipment (UE), terminal, base station, Radio Network Controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a video phone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, and BluetoothA module, a Frequency Modulation (FM) radio unit, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.

Claims (18)

1. A method for protecting time values in wireless communications, the method comprising:

transmitting a timestamp request;

receiving a timestamp in response to the timestamp request;

generating a scale stamp;

transmitting the scale stamp; and

an alternative accuracy report is received.

2. The method of claim 1, wherein the received alternative accuracy report is a trusted time report.

3. A method for protecting time values in wireless communications, the method comprising:

receiving a first timestamp;

generating two tick stamps for continuous transmission;

receiving a modified timestamp; and

scale marking the modified timestamp.

4. The method of claim 3, wherein the two timestamps are transmitted consecutively at a predetermined time interval.

5. The method of claim 3, wherein the first timestamp comprises data.

6. The method of claim 5, wherein the data comprises instructions to generate the two tick stamps.

7. The method of claim 3, wherein the first timestamp and the modified timestamp are received from different time authorities.

8. The method of claim 7, wherein at least one of the different time authorities is an internal time agent.

9. The method of claim 8, further comprising:

acquiring a real-time clock value;

protecting the real-time clock value; and

generating a timestamp from the real-time clock value.

10. A wireless transmit/receive unit (WTRU), comprising:

a Trusted Platform Module (TPM) configured to

Transmitting a timestamp request;

receiving a timestamp in response to the timestamp request;

generating a scale stamp;

transmitting the scale stamp; and

an alternative accuracy report is received.

11. A wireless transmit/receive unit (WTRU), comprising:

a Trusted Platform Module (TPM) configured to

Receiving a first timestamp;

generating two tick stamps for continuous transmission;

receiving a modified timestamp; and

scale marking the modified timestamp.

12. The WTRU of claim 11, wherein the TPM is configured to transmit two tick stamps consecutively at predetermined time intervals.

13. The WTRU of claim 11, wherein the TPM is configured to receive a first timestamp containing data.

14. The WTRU of claim 13, wherein the TPM is configured to generate the two tick stamps based on data received in the first timestamp.

15. The WTRU of claim 11, wherein the TPM is configured to receive the first timestamp and the modified timestamp from different time authorities.

16. The WTRU of claim 15, wherein the TPM further comprises an internal time agent.

17. The WTRU of claim 16, wherein the internal time agent is configured to:

acquiring a real-time clock value;

protecting the real-time clock value; and

generating a timestamp based on the real-time clock value.

18. A method for protecting accuracy reporting in wireless communications, the method comprising:

generating a signature verification key (CSK) from the certificate identity key (AIK);

generating an accuracy report;

generating a trusted time report (TTS); and

publishing an AIK certificate, a portion of the CSK, the accuracy report, or signature data.