[OpenTRV-dev] Call for participation: initial design sketch for simple security/auth layer for OpenTRV over TinyHAN and other comms, possibly involving pairing

[Damon Hart-Davis]

Hi,

We don’t have lots of space for lots of abstraction or indeed anything very complicated on the current ATMega328P (or similar) OpenTRV target hardware.

We’re aiming for as-required authentication and encryption on a low-data-rate channel.  Enough to prevent a heating system being messed with, and stats with privacy and security implications such as occupancy being observed, by anyone in radio range of valves and boiler.  So the boiler may be by default set to respond to calls for heat from specific authenticated valves only, for example.  This is not a scheme for protecting communications beyond the hub over the Internet, just within the home/building.

A data back channel may not be available most of the time.

Keys *may* (TBD) be initially exchanged by pairing while in close proximity to a hub / concentator / boiler node, and I’d like each leaf/valve node to be able to pair with up to *two* hubs to allow split boiler and Internet access, and/or redundancy.

The end user can pair devices.

***

I don’t yet have a specific set of times and dates for meetings etc but I’d like the process to be complete and thoroughly scrutinised well before *next* winter if at all possible.  Some of this can be done in conjunction with our IoT Launchpad work since there is overlap.

Could anyone interested in partipating in this process mail me (and/or Mark) outside of this list so that I don’t miss anyone.  I will have to go through my mailbox for people who have specifically expessed an interest in this area.

Can we keep technical discussion to the ***dev*** list please?

Rgds

Damon

PS. Some starters for our buzzword bingo: AES128, HMAC, IPsec, max ~60-byte data frames, pairing, LED/LDR/buttons, lowered radio TX power, ethics, Data Protection, lossy channels