Security Issues for Timing Advertisement Dec 2009

1. Security Issues for Timing AdvertisementDec 2009 Alastair Malarky, John Moring, William Whyte Summary of TA Subgroup work

2. Time Knowledge & Trust • “Time knowledge” = knowledge of absolute time (UTC) • Obtained from a time source • Linked to local processor clock • “Trusted time source” is one which has • accuracy known to receiver • is not vulnerable to attack/compromise at receiver • is reliable (i.e. always available)

3. Device Time Sources • Devices with trusted sources don’t need to use TA to sync • e.g. RSE provider will in general have trusted source • Mobile GPS equipped device may still need TA mechanism • Can experience GPS coverage loss • GPS has start up delays also • GPS outage = Loss of accurate location knowledge at same time as loss of accurate time knowledge • GPS spoofing cost ~ $10,000 • Lowest capability device may rely only on TAs plus internal clock stability to manage time knowledge • Such devices generally don’t have location knowledge either • TA mechanism needs to support lowest capability device • This was why it was added in first place

4. Some Time Sources • GPS • Generally considered a trusted time source • Not 100% available on some devices • When not available device can degrade accuracy reported for some time to still be a trusted time source. • At some point time source is not accurate enough to be of value. • Timing Advertisement (TA) as per 802.11p for OCBEnabled • Declared source accuracy • Currently no security or authentication provisions • Currently no rules etc for who transmits • Timing Advertisement is a “potentially vulnerable timing source” • Need to define some trust mechanism(s)

5. Fundamental Questions • What are implications of receiver adopting incorrect time ? • What are “threats” ? • Who can transmit a TA ? • When should TAs be sent ? • How is TA used/accepted ? • Answers to these drive what level of trust is needed on TAs and the security approach

6. Implications of adopting incorrect time • Channel Sync (1609.4) compromised • (temporary) loss or degradation of services • Only need time to mod(1 second) but need (sub-)ms synchronization • Cert changes/expiry compromised • Security risk • Service denial possible • Time sync error allowed = seconds ? • Replay attacks made possible • Security risk • Time sync error allowed = tens of ms ? • Otherwise correct messages to/from victim may not be accepted • Application use of device time knowledge compromised • App performance • Time sync error allowed – varies.

7. Threats • Mechanisms exist to address “innocent” device with poor accuracy time source • Time source accuracy already part of TA • Possible problem: Device with undetected (at source) time error • Deliberate attacker • Motivation: Incorrect time on victim allows other attacks • See previous slide • Transmit TA messages to cause time on receiver devices to be compromised • Originate false TAs • Replay valid TAs as delayed response to query • Replay valid TAs as response to entirely different query • Need some means of “ignoring” attackers in determining time on TA receiver

8. Countermeasures • Aggregation and consistency checking • Allows recipient to filter received TAs before acting on them • Reduces impact of a single bad message • Authentication • Gives recipient a level of assurance that sender has not been compromised • (or if they have been compromised it was recent) • Prevents “originate false TA” attack • Freshness via challenge-response • If combined with authentication, prevents “Replay valid TAs as response to entirely different query” attack

9. TA Consumption • What is consumption pattern for TAs? • What do we expect to be the density of TA-requiring devices? • ie density of devices that have lost synch • What do we expect to be the density of potentially TA-distributing devices? • density of devices that still have synch • TA-requiring devices: • What is the definition of an TA-requiring device? • Context-specific • How quickly should one expect to be resynched? • How often does one need TAs? • How many valid TAs does it need to receive per synch? • Do we need to cover malfunctioning units or just units with known inaccuracies?

10. Who can transmit TAs ? • All devices??? • Not reasonable?????? • ? • Defined senders • Trusted only devices ? • Providers only ? • Public sector only ? • Devices with time error < receiver ? • How do they know what receiver needs?

11. When should TAs be sent • Some use cases support TA broadcast, other use cases support Timing Request • In the interests of saving bandwidth, measures to keep down density of TAs should be adopted, potentially including: • Not all devices send TAs • Default period between unsolicited TA is long • Devices that might send TA listen for other TA and only send adaptively • Devices request TA only when certain conditions are met and other devices only send TA when they see a request • For example, devices should request timing advertisements (responses) if the confidence interval on their internal clock exceeds their acceptable threshold. • Not clear if timing response is just timing advertisement – probably could be • No request mechanism currently exists

12. How is TA used • Not specified • Some devices may use single TA to update time • Others may have more elaborate mechanism • Don’t intent to specify mechanism of use in 1609.

13. How to Trust TAs • If number of TA senders present – erroneous TAs can be excluded due to inconsistency. • Consensus that the Timing Responses (and advertisements?) should be associated with a signature • otherwise it's too easy for an attacker to generate multiple incorrect responses • Could have some pre- or post- authentication • E.g. If using request – then response can include (data) attribute from request in response – i.e. response is unique to request • E.g. If using broadcast – receiver wanting authentication could send authenticate request message and receive authentication response

14. Security on Messages • Certificates • Can be limited in geographic and temporal scope • Updated on regular time basis • Messages • Certificate used to authenticate source • Message time and geographic scope limits in signature • Limits use - prevents “replay” • These protections “defeated” if receiver can be made to have erroneous time and doesn’t have location knowledge