[OpenTRV-dev] Security issues

[Damon Hart-Davis]

Hi,

Tony B, who will join one or both of these lists in due course when he has time, was kind enough to perform an initial security analysis of (standalone) OpenTRV systems, viz:

> Open TRV initial security assessment.
> 
> Approach suggested in A Framework for Assessing and Improving the Security Posture of Industrial Control Systems (ICS), Systems Network and Analysis Centre, NSA, Pub: Aug 20, 2010, version 1.1
> 
> As the Open TRV project is an open source project, it is therefore assumed that any & all of the technical details are freely available to anyone who wants to download them or buy a unit. This assessment concentrates on the attacks that can be carried out on the radio communications and what information can be derived from intercepting, jamming or spoofing them.
> 
> Unknown: the range of the radio transmitter units, how the “family” of devices in a house are considered unique or keyed to one boiler control unit.
> 
> Assumption: The OpenTRV units and the boiler controller are not connected to the Internet
> 
> Q1 - is the radio transmission encrypted, if so how is it implemented and the key(s) managed?
> 
> Attack 1: Alter process status in transit: i.e. the unit transmits a heat request to the central controller, which is somehow intercepted and replaced by stay off instruction.
> Likelihood: low Impact Over heated or under heated room(s), boiler firing more or less than normal.
> 
> Attack 2: randomly request the boiler to fire or not.
> Likelihood: Low unless there is a mechanism by which the boiler can authenticate or know which requests are valid. It’s unknown how complex it would be to implement this, nor the overhead.
> 
> Attack 3: Denial of service attack on the system
> Continually tell the boiler to either stay off (cold house) or run (hot house). aim: disrupt the system and hence under the occupant’s uncomfortable.
> 
> Attack 4: Disable the device
> It is thought more likely this would happen by battery failure or human error than deliberate attack.
> Likelihood: low Mitigation: clear instructions. widespread operational testing in households with children and pets to increase the number of potential different  for
> 
> Attack 5: install malicious software
> Whilst this is a possible exploit it would require considerable skill and expertise
> Likelihood: Low, mitigation pot the processor chip:
> 
> Attack 6: Installation of the devices incorrectly
> Likelihood: High (has already happened. Mitigation: clear instructions and public liability insurance.
> 
> Question - does this system process any (sensitive) personal data?
> The data concerned (boiler on or off) is not sensitive personal data as defined in the Data Protection Act 1998. Additionally the data would need to be combined with the dwelling address before anyone could be identified. Even then, it is unclear what malicious uses the data could be put to that simple observation of the house would also not yield. (i.e. the data is considered equivalent to that in the public domain).


To which in part I responded:


At the moment all the protocols are open and clear text and (legal) ranges are probably a few hundred metres.

My doom scenario is a bored teenager forcing off all the rads in mid-winter for his own block of flats or the next door OAP home, with nasty real health risks.

So authentication/pairing of some sort is an early goal.

Encryption of data such as occupancy another.





Just putting this on the record for others to see.

Rgds

Damon