IoT Notary: Attestable Sensor Data Capture in IoT Environments (2108.02293v1)

Abstract: Contemporary IoT environments, such as smart buildings, require end-users to trust data-capturing rules published by the systems. There are several reasons why such a trust is misplaced -- IoT systems may violate the rules deliberately or IoT devices may transfer user data to a malicious third-party due to cyberattacks, leading to the loss of individuals' privacy or service integrity. To address such concerns, we propose IoT Notary, a framework to ensure trust in IoT systems and applications. IoT Notary provides secure log sealing on live sensor data to produce a verifiable `proof-of-integrity,' based on which a verifier can attest that captured sensor data adheres to the published data-capturing rules. IoT Notary is an integral part of TIPPERS, a smart space system that has been deployed at the University of California Irvine to provide various real-time location-based services on the campus. We present extensive experiments over realtime WiFi connectivity data to evaluate IoT Notary, and the results show that IoT Notary imposes nominal overheads. The secure logs only take 21% more storage, while users can verify their one day's data in less than two seconds even using a resource-limited device.

• The paper introduces IoT Notary, demonstrating secure and verifiable sensor data capture in IoT environments using SGX-driven attestation mechanisms.
• It details a two-phase model—notification and log sealing—that enforces data-capture rules for both mandatory and consent-based collection.
• The framework shows low overhead, with user log verification under 1 second using optimized per-user logging for practical deployment.

This paper introduces IoT Notary, a framework designed to enhance trust in IoT environments by enabling users to verify that sensor data collection adheres to pre-defined data-capture rules (2108.02293). The core problem addressed is the potential for IoT systems or malicious actors to misuse sensor data, violating user privacy or service integrity, especially in environments like smart buildings where users have limited control over sensors. The framework was developed and deployed as part of the TIPPERS smart space system at UC Irvine, using WiFi connectivity data as a primary use case.

System Model and Entities:

• Infrastructure Deployer (IFD): Deploys and manages sensors (e.g., university IT department managing WiFi access points).
• Service Provider (SP): Uses sensor data to offer services (e.g., TIPPERS providing location-based services). Defines data-capture rules.
• Users: Individuals whose data might be captured by sensors and who use services provided by the SP.
• Auditor (Optional): A trusted third party that can verify the entire log integrity.
• Secure Hardware (Intel SGX): Used by the SP as a trusted agent to enforce rules, seal logs securely, and prevent tampering by the potentially untrusted SP.

IoT Notary Phases and Mechanisms:

1. Notification Phase: Informs users about data-capture rules.
   • Notice-Only Model (NoM): For mandatory data capture where user consent isn't required. Requires a trusted notifier (like the IFD or a public website) to broadcast encrypted and signed rules generated by the SGX enclave.
   • Notice-and-ACK Model (NaM): For discretionary data capture requiring user consent. SP sends encrypted rules (from SGX) directly to users, who must send back a secure acknowledgment to the SGX enclave to opt-in. SGX maintains a list of consented devices.
2. Log Sealing Phase: Creates verifiable, tamper-proof logs of sensor data processing within the SGX enclave at the SP.
   • Data Processing: The enclave receives encrypted sensor data (e.g., $\langle d_i, s_j, t_k\rangle$), decrypts it, checks against notified data-capture rules, and assigns a state ($s_j.state = 1$ for capture, $s_j.state = 0$ for discard).
   • Cryptographic Sealing: Uses hash chains and XOR-linked lists to create immutable logs. Data is processed in chunks for efficient verification.
     • Hash Chain ($\mathcal{PI}$ - Auditor Log): $h_i \leftarrow H(\mathit{data}_i || h_{i-1})$. Creates a chain linking each record cryptographically. The final hash $h_n$ is combined with end-of-chunk proof $S_{eoc}$ (derived from random strings of adjacent chunks) and signed using the enclave's private key ($\mathit{PR}_E$). This allows auditors to verify the integrity of the entire log sequence.
     • User/Service Log ($\mathcal{PU}$ - User Log): To protect privacy, user IDs ($d_i$) are hashed with timestamps ($o_i = H(d_i || t_k)$) before being included in the log. A separate hash incorporating the sensor state ($hu_i = H(o_i || s_j.state)$) is computed for each entry. An XOR sum of these hashes ($\mathit{hu}_{end}$) is combined with $S_{eoc}$ and signed. This allows users to verify the presence/absence and correct processing of their own data without seeing others' data.
   • Handling Discarded Data (State=0): To avoid storing large amounts of data when rules dictate non-capture, the system logs only the first entry with state 0 in a sequence, discarding subsequent state 0 entries until a state 1 entry appears. The hash chain incorporates this transition.
   • Optimizations: To reduce log size and improve verification speed, especially with alternating active/passive states:
     • Per-Sensor Logging: Maintain separate logs/buffers within the enclave for each sensor (or groups of sensors), applying sealing logic independently.
     • Per-User Logging: Maintain separate logs/buffers based on hashed user device IDs. This significantly speeds up user verification as they only need to check chunks relevant to their device group. Padding is used to ensure uniform output sizes across buffers, preventing information leakage.
3. Attestation Phase: Allows auditors or users (verifiers) to check log integrity.
   • Key Establishment: Uses the SIGMA protocol (based on Diffie-HeLLMan) for mutual authentication and secure session key establishment between the verifier and SP before log transmission, protecting the verifier's identity.
   • Verification:
     • Auditor: Downloads relevant log chunks (cleartext data for $\mathcal{PI}$ verification), random strings for $S_{eoc}$, and the $\mathcal{PI}$ proof. Recomputes the hash chain and $S_{eoc}$, verifies the signature using the enclave's public key ($\mathit{PK}_E$).
     • User: Downloads relevant hashed user data ($o_i$), timestamps, sensor states, random strings for $S_{eoc}$, and the $\mathcal{PU}$ proof. Verifies their presence by computing $H(d_{user} || t_k)$, recomputes the XOR sum $\mathit{hu}_{end}$ and $S_{eoc}$, and verifies the signature using $\mathit{PK}_E$.

Implementation and Evaluation:

• Deployment: Implemented within the TIPPERS system at UC Irvine using live WiFi association data from 490 access points across 30 buildings. The university IT department acts as IFD and trusted notifier. SGX runs on a Microsoft Azure cloud server.
• Overheads:
  • Storage: Secure logs ($\mathcal{PI}$ and $\mathcal{PU}$) add ~21% storage overhead compared to cleartext data for a 5MB chunk size.
  • Computation (SP): Log sealing takes ~310ms per 5MB chunk (approx. 37K events) on a 4-core/16GB SGX machine.
• Verification Performance:
  • Auditor: Verifying one day's data (~50 chunks) takes < 1 minute.
  • User: Verifying one day's data takes < 30 seconds even on a resource-constrained device (1-core/1GB RAM). Optimized per-user logging reduces this to < 1 second.
• Parameters: Chunk size affects latency, storage, and verification time (trade-offs exist). Parallelism offers minor speedups. Optimized logging (especially per-user) significantly reduces storage and user verification time.

Conclusion:

IoT Notary provides a practical framework for establishing trust in IoT data collection by enabling cryptographic verification of adherence to data-capture rules. It leverages secure hardware (SGX) to ensure log integrity even when the service provider is untrusted. The system demonstrates low overheads and efficient verification, making it suitable for real-world deployment in user-centric IoT environments.