The problem
IoT access control works at device granularity and relies on the device being trustworthy.
An attacker who compromises a device through an exploit or a backdoor can sense and actuate at will. Even a humidity sensor or a motion-activated light can reveal whether a room is occupied. Component-level schemes target smartphones and enable or disable access for long periods, and access control on cloud platforms includes the devices and the entire cloud in its TCB.
Approach
The PEGs and the deployment manager form a distributed reference monitor.
The manager makes the access decisions for the whole deployment, and the PEGs enforce them before a sensor is sampled or an actuator is driven.
Design
The manufacturer and the PEG it adds are trusted, and all other code on the device is untrusted.
- Peripheral. A sensor or actuator, e.g. a microphone or an electric door strike.
- Peripheral Guard (PEG). Sits between the peripherals and the Runtime and blocks all access by default. Runs on a separate microcontroller or, without extra hardware, in the ARM TrustZone secure world.
- Runtime. Applications and OS or hypervisor, untrusted. Relays messages between the PEG and the manager.
- Deployment manager. Trusted, one per deployment such as a household or office. Runs on a local or remote server, e.g. the home router, and decides on and logs every access request.
PAIR · pairing
AUTH · authorization
ENF · enforcement
PERS · persistence
Example policies
- Security cameras are off while the owners are home.
- The stove cannot be switched on while the owners sleep.
- The audio and video system in a hotel room is off during a confidential meeting.
Pairing and persistence
To pair a device, the owner scans the code printed on it and presses the PEG's button, which starts a Noise-inspired handshake with the manager. The persistence module lets the manager detect when a device leaves the deployment.