1、 Access to Additional Content for ATIS 0800034 (Click here to view the publication) This Page is not part of the original publication This page has been added by IHS as a convenience to the user in order to provide access to additional content as authorized by the Copyright holder of this document C
2、lick the link(s) below to access the content and use normal procedures for downloading or opening the files. ATIS 0800034 Additional Content Information contained in the above is the property of the Copyright holder and all Notice of Disclaimer however, before it is trusted, this value should be che
3、cked for authenticity and integrity after reception. By specifying a message format and authentication scheme that can be applied at both preparation and reception of the time values, interoperability will be achieved and use of trusted time can be established. 5.4 Analysis of Secure Time Currency O
4、nce a Secure Time value is received, the ongoing measurement of elapsed time may be applied to that initial value to keep the value temporally current. This may be accomplished by referencing a hardware-based elapsed time measurement device. For example, when the Secure Time value is received (TS),
5、the hardware time reference is read to be X1. Later, when Secure Time is needed, the hardware time reference is read again and returns X2. The current secured time (TC) can be determined from the formula: TC= TS+ X2 X1 The robustness of the hardware time reference should be considered in order to pr
6、event local tampering with the time value. The solution should address the robustness rules for the hardware time reference, such as those stated in section 5.1.6 of ATIS-0800024 2. In some systems, the Secure Time may be used in a manner - or delivered with a frequency - such that currency via the
7、use of hardware time reference is obviated. 5.5 Analysis of Preparation of Secure Time Values One method to provide Secure Time is to respond to a device request by taking the current (implicitly trusted) time source and digitally signing the value. Such a method has the advantage of providing relat
8、ively accurate time information, but has several disadvantages. The most significant disadvantage is the expense or complexity of scaling such a system to the size necessary to support a large population of devices and request traffic. An alternative method to provide Secure Time is to pre-generate
9、a batch of messages in advance, then release these messages one at a time as the corresponding time interval occurs. Depending on the intended use of the Secure Time in the system, the interval may vary widely: for instance, one per day or one per minute. ATIS-0800034 5 The disadvantage of this alte
10、rnative is that the device lacks knowledge about whether the pre-generated time messages are released in a timely and proper fashion, and thus the security of functions relying on this process can be jeopardized. 5.6 Analysis of Secure Time Availability When an IPTV device is first powered on or res
11、et, it may have no knowledge of date or time at all until the first successful delivery of a Secure Time message. Also, the device may be detached from a network where it cannot receive updated Secure Time messages. In the latter case, it may have the last Secure Time message available from persiste
12、nt storage to provide some reference. The system design for Secure Time should recognize that the IPTV device may be in one of the following four states: 1) Unknown Secure Time. 2) Known Secure Time from persistent local storage, but not updated since most recent power cycle. 3) Secure Time has been
13、 updated from the network during the current device power cycle. 4) Secure Time has been updated from the network during the current device power cycle, but an updated value has not been received within a set period of time as specified by a system policy. The example of unknown Secure Time would be
14、 the first power-on of a device. The device must still function to the degree necessary to obtain the Secure Time for the first time. Also, this state may exist when a persistently stored time is lost for example, if it was stored on low-robustness storage such as a disk drive that was reformatted,
15、replaced, or unavailable. An example for the use of stored Secure Time with no update might be an IPTV device that was removed from the network such as taken to a vacation cottage with the expectation that content stored on the device could be viewed at the secondary location. Such a device may appe
16、ar frozen in time, which could contradict system requirements to reliably expire stored content. The use of a dedicated hardware element with battery backup may be considered as a reliable clock to track elapsed time even when the device is powered off. However, the battery may be removed or fail, t
17、he device may drift over prolonged intervals, or the device might be reprogrammed via unauthorized use or circumvention. In the context of reliance on battery backed-up clocks to maintain time when the power is removed or the device is reset, the robustness rules in ATIS-0800024 2 provide some guide
18、lines. A system design might include an expiration timer to ensure that a recent Secure Time value is kept current with periodic updates. Ensuring frequent updates means that any local clock drift or intentional tampering will not accumulate into large differences from actual time. 5.7 Secure Time U
19、pdate Interval It is outside the scope of this standard to provide highly accurate or sub-second precision time information, and it is not the intent of this standard to supplant protocols (e.g., NTP) suited to the dissemination of accurate time signals throughout a network. Secure Time can provide
20、a sanity check on the time delivered by other means to reject attempts to manipulate the non-secure time source outside of a window of tolerance set by system policy. ATIS-0800034 6 Time accuracy can vary because of frequency of update generation. For example, consider a system set up to update the
21、time value in Secure Time messages at the top of each hour of the day, which transmits the same message once per minute. A device joining the network will receive the same message at the beginning and end of a given hour. For this reason, it may be useful to include the updating interval in the Secu
22、re Time message so the recipient knows the expected value of the next Secure Time message. Long intervals between Secure Time updates may be satisfactory for enforcement of, for example, certificate validity. However, in order to accommodate the management of precise event windows, the system may be
23、 designed to provide Secure Time messages more often, such as a Secure Time value update once per minute rather than once per hour. Such a delivery method would have a variability range up to 60 seconds from the actual time, which may be considered suitable for event management. If frequent Secure T
24、ime updates are burdensome to Secure Time servers, another solution is to use non-secure time (such as an NTP signal) to fill in the gap between Secure Time updates. For example, in a system in which Secure Time updates are generated once per hour, a Secure Time message may indicate it is between 5:
25、00Z and 5:59:59Z, and the non-secure time may indicate it is 5:43:23Z (for the same date), then the non-secure time may be a reasonable value to use as a reference for event management. If the non-secure time is outside a pre-defined window of tolerance, relative to the current value of Secure Time,
26、 then it can be ignored. This window of tolerance is a system policy and its definition is out of the scope of this standard. Another possibility to accurately handle time managed events is for the system to provide updated Secure Time messages as the events start and end. In this case, since the re
27、ceiver can know with certainty that the Secure Time point has passed if it has received it in a message, receiving the Secure Time message matching the event window start time can be used to open access to the event. Similarly, receiving the Secure Time message matching the event window ending time
28、can be used to close access to the event. 5.8 Analysis of Secure Time Delivery Mechanisms Several delivery mechanisms may be considered: Request/response mechanism (unicast). Push mechanism (unicast or multicast). Both of these delivery mechanisms may introduce latency between the delivered Secure T
29、ime value and the actual UTC time, depending on the implementation. For example, the execution time needed to perform the authentication function at the Secure Time source may require considerable processing and thus introduce delay. Similarly, network transmission time and execution time of the ver
30、ification function performed at the IPTV device may also introduce delays. In the case of a request/response transaction with the IPTV device, the IPTV device will send a request for Secure Time based on either an event trigger or some other local policy and will receive a Secure Time response from
31、the Secure Time source. The request/response mechanism provides for scenarios in which Secure Time on demand is required. ATIS-0800034 7 5.9 Analysis of Secure Time Latency Depending on the implementation of the Secure Time response, it is possible for the IPTV device to receive a Secure Time messag
32、e that includes a Secure Time value with low latency. Low latency means that the delivered Secure Time value is current from the secure time source and when it arrives at the receiver it is reasonably close to the actual UTC time. However, it is also possible in the secure time on-demand scenario th
33、at a message arrives with moderate or high latency. In the case of the push mechanism, the Secure Time message is transmitted based on policies implemented by the Secure Time source. The Secure Time message can be delivered in a unicast fashion to a target IPTV device or, to increase efficiency, in
34、a multicast fashion to a group of IPTV devices. Note that a single system may implement both delivery methods. 5.10 Mechanisms for Limiting Latency of Secure Time Delivery One thing that may cause the delivered Secure Time values to vary from actual UTC time is the computational times necessary to d
35、igitally sign the Secure Time message. This effect can be compensated for by using a time value accurate for the near future when signing the message and then delaying transmission of the Secure Time message until the actual time occurs. For example, in order to achieve accuracy of one second, in th
36、e case that digital signing takes between 300-800ms, the time value put in the message can be one second in the future and the transmission can be delayed by 200-700ms to ensure that it is always delayed by one second, thus ensuring that the actual time value is transmitted. Likewise on the receivin
37、g side, a hardware clock reference can be used to adjust the Secure Time parsed from a message to account for the processing time of verification. 5.11 Threat Analysis There are several threats to the delivery and management of a Secure Time value that can be exploited unless careful design consider
38、ations are used. One threat that can affect the delivery of Secure Time does not involve generation of any cryptographic data, but rather involves the possibility of an attacker manipulating the delivery of valid network time packets by filtering, delay, and replay. Such attacks use existing valid t
39、ime delivery packets, but from a past actual time interval, in an attempt to trick the device into performing a function which it should not. The design of a Secure Time system should account for and mitigate any negative effects of this type of attack as much as possible. Another threat is the comp
40、romise of any cryptographic material needed to achieve the security of the Secure Time message. When such a compromise is discovered, there needs to be a mitigation strategy in place that allows for the checking and renewal of the integrity of the Secure Time value. A threat arises when Secure Time
41、messages are prepared in advance in a batch for eventual periodic release. An operational malfunction may result in Secure Time messages for future time intervals being released or otherwise exposed. A mitigation strategy needs to be devised to address this situation. Denial-of-service attacks are p
42、ossible when the preparation of the Secure Time message is done on-demand. The resource-intensive cryptographic functions of a Secure Time server may be overwhelmed by a storm of requests. Likewise, the heavy ingestion of time packets to the IPTV Device may consume system resources to the point wher
43、e operation is affected. ATIS-0800034 8 5.12 Mitigating Threats to Secure Time Delivery To mitigate against message filtering and delay attacks, the IPTV device should execute a secured exchange with the server that is providing the Secure Time message. For example, a Transport Layer Security (TLS)
44、session establishes a delivery pathway that is very difficult to tamper with. One alternative is for the requestor to provide a single-use value to the server that must be returned by the server in its authenticated Secure Time message. To mitigate against replay attacks, the IPTV Device may persist
45、ently store the last known Secure Time value received and reject any Secure Time message that presents a time value which is prior to the last stored value. The robustness of the persistent storage should be considered. For example, ATIS-0800024 2 defines low and high robustness rules for persistent
46、 storage. With the use of secure storage to prevent rollback attacks, a problem is introduced if a valid Secure Time message is sent in advance of the actual time. This may occur through an operations error or system malfunction. When the Secure Time provisioning is returned to a normal state, all v
47、alid and accurate Secure Time messages will be rejected because they are inadvertently earlier than the actual time sent. To mitigate against the above potential failure, a simple integer counter Time Epoch value should be included in the Secure Time message. The Secure Time provider can increment t
48、he epoch value in the message when the early-release situation is known to have occurred. All recipients of the Secure Time message can ignore the persistently stored value if the Time Epoch in the stored message is less than the Time Epoch value of the newly received message. In addition, the recei
49、ver must ignore all Secure Time messages received that have a Time Epoch value less than the last known Secure Time message. Note that the Time Epoch value should only be changed to mitigate security compromises such as those described above. It should not be incremented on typical Secure Time messages when no compromise is present. 5.13 Analysis of Secure Time Use Cases The Secure Time value may be used in many different ways in a system. The use cases in this section are intended to provide some considerations for how Secure Time may be used. 5.13.1 U
