Advances in sensing, networking, and actuation technologies have resulted in the IoT wave that is expected to revolutionize all aspects of modern society. This paper focuses on the new challenges of privacy that arise in IoT in the context of smart homes. Specifically, the paper focuses on preventing the user's privacy via inferences through channel and in-home device activities. We propose a method for securely scheduling the devices while decoupling the device and channels activities. The proposed solution avoids any attacks that may reveal the coordinated schedule of the devices, and hence, also, assures that inferences that may compromise individual's privacy are not leaked due to device and channel level activities. Our experiments also validate the proposed approach, and consequently, an adversary cannot infer device and channel activities by just observing the network traffic.

1. Verifiable Round-Robin Scheme
for Smart Homes
6/9/2019 1
Nisha Panwar, Shantanu Sharma, Guoxi Wang,
Sharad Mehrotra, Nalini Venkatasubramanian
Department of Computer Science
University of California Irvine
ACM Conference on Data and Application Security and
Privacy (CODASPY)
March 25-27, 2019

2. Smart home silhouette
6/9/2019 2

3. Continuum of control
6/9/2019 5
t1 t2 t3 t4 t5 t6 t7
t8 t9
d1
d2
d6
d7
d8
d9
d5
d4
d3
morning evening
Scheduled workflows
Synchronized workflows

4. Privacy challenges
• Wireless communication is vulnerable to
inference attacks
• Devices react immediately as a result of
channel ‘or’ other device activity
• Devices know the command much prior to
the execution time
• Wireless protected access in 802.11 ensures
 integrity and confidentiality Revealing
privacy via inference
• MAC address and DNS lookup queries
allow inferences regarding the workflows
 privacy violation
6/9/2019 6
Device activity  channel activity  user activity
04:33
04:34
04:35
04:36
04:37
04:38
04:39
04:40
04:41
04:42
04:43
04:44
Time
0
50
100
150
200
250
300
350
400
Throughput(KBytes/s)
CloudCam
Google Home
WeMo
User arrived at home
User issued voice
command to turn
on lamp
WeMo in
“ON” State
User issued
voice command
to turn off lamp
User moved around in home
User left home
Workflows:

5. Problem statement
workflow inferences
6/9/2019 7Upstream observer
Virtual
periphery
Physical
periphery

6. Problem statement:
workflow execution time
6/9/2019 8
D1
D2
D3
Sequential
operations
Execution length

7. Pre-scheduling
• Thought experiments: with spacetime diagram
• Twin paradox: going in future is not possible
• Grandfather paradox: going in past is not possible
• Logical marker for the future is possible  Scheduling
• Time is unidirectional  we can always lengthen the timeframe
until the marker arrives BUT cannot shrink it
9

8. Artificial delay
• Pre-scheduled workflows
• What should be the order of devices?
• When should the devices execute the commands?
• How to guarantee the “no earlier than” property?
• Resource-intensive deterministic delay
• All devices must wait for a prescribed amount of time
• This waiting period is guaranteed through time-consuming inherently
sequential operations
• Devices cannot skip or pre-compute these operations in order to pre-
pone the command execution
6/9/2019 10

9. Solution sketch
6/9/2019 11
Home owner
Capsule
command
Hub
t1
timing
analysis
t2
t3
t5
t6
t1
t3 t4 t5
Integer
Factorization
Solve puzzle

10. Verifiable delay protocol
• Owner-to-hub: signature based handshake
• Authenticate and send desired workflow to an initial device, i.e., hub
𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒 = ( 𝐷1, 𝐷2 , (𝐷3, 𝐷4))
𝑂𝑟𝑑𝑒𝑟 = (𝑂𝑖𝑑, 𝐻𝑖𝑑, 𝑐𝑙, 𝑆𝑖𝑔𝑛(ℋ, 𝑂𝑆𝐾))
• Hub-to-device: anonymous trigger for command execution
𝒯 = 𝐸( 𝑐𝑙| 𝑑𝑎𝑡𝑎 𝑓𝑖𝑒𝑙𝑑 |𝑏𝑡 𝑜𝑔𝑔𝑙𝑒 , 𝑘𝑠)
• Device-to-device: command execution and verifiable ordering
• Decrypt the command and retrieve the time clock puzzle
𝒫 = (𝑛, 𝑎, 𝑡𝑖, 𝐸𝑧𝑖, 𝐸𝑘𝑖)
• Device-to-hub: anonymous response from devices to the hub
𝑏 𝑂 = 𝑏𝑟 ⨁ bg
6/9/2019 12

11. Example
6/9/2019 13
Hub
𝑡 𝑟𝑐𝑣
1 𝑡 𝑟𝑐𝑣
2
𝑡 𝑏𝑒𝑔
𝐻 𝑡 𝑟𝑐𝑣
𝑁
𝐷1 𝐷2 𝐷 𝑁
𝑡 𝑐𝑜𝑚
1
𝑡 𝑐𝑜𝑚
2
𝑡 𝑐𝑜𝑚
𝑁𝑡 𝑐𝑜𝑚
𝑁−1
𝑡 𝑟𝑐𝑣
1
𝑡 𝑟𝑐𝑣
2
𝑡 𝑏𝑒𝑔
𝐻 𝑡 𝑟𝑐𝑣
𝑁
𝑡 𝑐𝑜𝑚
1
𝑡 𝑐𝑜𝑚
2
𝑡 𝑐𝑜𝑚
𝑁
𝑡 𝑐𝑜𝑚
𝑁−1

12. Properties
• Authentication:
• During workflow release from homeowner to hub
• The key exchange for signature verification is part of setup phase
Pr (𝑂𝑆 𝐾, 𝑐𝑙) → 𝑆𝑖𝑔𝑛 ≥ 1 − 𝜖
• Anonymity:
• For consistent circulation of encrypted commands
• No channel activity correlates to device activity
Pr 𝒯(𝑚𝑖) − Pr 𝒯′(𝑚𝑗) < 𝜖
• No inferences on device generated data can be mapped to device activity
Pr 𝒯(𝑏 𝑟) − Pr 𝒯(𝑏 𝑜) < 𝜖
• Verifiable delay:
• No inferences on device activity before the device executes the command
Pr[𝑡 𝑐𝑜𝑚
𝐴 |state] ≅ Pr[𝑡 𝑐𝑜𝑚
𝐴 ]
6/9/2019 14

13. Experiment setup
6/9/2019 17
• Hub and IoT devices communicate in Wi-Fi Ad-hoc mode.
• A laptop with Wi-Fi interface working in monitor mode is deployed in the room next to
the the lab, acts as passive listener adversary
Mock-up testing IoT app:
IoT device awaits command
from Owner.
”SET”: change a local variable
“READ”: read variable, system
stats and send back to owner

14. Results
6/9/2019 18
• Impact of scheduling on channel to device activity decoupling
• Run the same workflow (D1:READ|D2:SET|D2:READ|D3:READ) in two
settings
0 10 20 30 40 50
Time (s)
0
250
500
750
1000
1250
1500
1750
Throughput(Bytes/s)
D1
D2
D3
Devices working in common IoT settings
(Wi-Fi infrastructure mode)
0 10 20 30 40 50 60
Time (s)
1000
1500
2000
2500
3000
3500
4000
Throughput(B/s)
D1
D2
D3
Devices working with our proposed system

15. Results
6/9/2019 19
• Impact of ring topology on the latency
• X-axis: The number of IoT devices in the ring topology
• Y-axis: Latency between Hub sends and receives the token

16. Previous work: traffic shaping
• A privacy-preserving traffic shaping scheme*
• The traffic is vulnerable to privacy threats at ISP level
• The original traffic rate variations must not be obvious to ISP (malicious)
• Fixed-rate leaky bucket generates cover traffic beyond the hub, regardless of any
activity within the LAN
• The authors proposed to mask channel activity through dummy traffic
• If [shaped traffic rate] < [device traffic] than packets must be queued
• If [shaped traffic rate] > [device traffic] than dummy packets must be added
• However, this scheme
• does not protect the mapping between wireless channel to device activity (inferences
on the incoming traffic)
• does not consider device level scheduling guarantees
6/9/2019
*Apthorpe et al “A Smart Home is No Castle:
Privacy Vulnerabilities of Encrypted IoT Traffic” arXiv:1705.06805v1 20

17. Previous work: comparison
Properties Kumar
et. al. [11]
Shen
et. al. [13]
Apthorpe
et. al. [6]
Our scheme
Upstream
direction
Downstream
direction
Verifiable
delay
Partial
ordering
Total
ordering
Privacy
Passive attack
resistance
Active attack
resistance
6/9/2019 21

18. Conclusion
• Workflows in smart homes are inherent and so does the
privacy centric inferences regarding those workflows
• Traffic shaping can avoid upstream inferences by the last
mile attacker BUT does not ensure secure device ordering
• Logical timelines enable decoupling from channel to device
or device to channel activity
6/9/2019 22

19. Nisha Panwar
(npanwar@uci.edu)
23