Secure Data Provenance in Home Energy Monitoring Networks Ming Hong Chia, Sye Loong Keoh, Zhaohui Tang 1
Outline • Data Provenance and Smart Metering • Security Threats and Requirements • Proposed Architecture – Threshold Cryptography – Location Authenticity using BLE • Preliminary Evaluations • Future Work and Conclusions 2
Data Provenance “Data provenance refers to records of the inputs, entities, systems, and processes that influence data of interest, providing a historical record of the data and its origins.” Systems and Internet Infrastructure Security, Penn State University 3
Data Provenance • Cryptography Authentication Encryption Measurement Data Source Data Collector Device • Redundancy and data cross-checking … Data Collector Data Source 4 Measurement Devices
IoT and Smart Metering • Sensor data is typically aggregated – smart meter. Private Realm Public Realm Wide Area Network Home Area Network Utility End Neighbourhood Area (WAN) (HAN) Network (NAN) ZigBee, WiFI, Fibre Optic, WiFi, Cellular Ethernet Cellular Collection WAN NAN Smart Home Smart Utility Appliances Data Meter Concentrator Monitoring Advanced Metering Infrastructure (AMI) 5
Smart Metering • Is smart meter the true data source of energy consumption of the household? Potential compromise? - under reporting of energy usage Home Area Network The real - energy fraud (HAN) data source ZigBee, WiFI, Ethernet Energy Consumption HAN Reporting Smart Home Smart Appliances Meter Utility The real data source 6
IoT Data Provenance • Data provenance = the reported energy usage is collected from the specific appliance as claimed , and that it reflects the real energy consumption. • Specifically, we are interested in: – Source data/identity authenticity – Data integrity and consistency – Location authenticity 7
Secure Smart Plug Secure Smart Plug • A secure plug (SSP) to measure the energy consumption at each Energy data source. Magnetic Sensor • Using multiple Raspberry Smart Pi 3 sensors to track Meter Bluetooth electricity usage. Smart Energy • Using Bluetooth localization to Plug detect changes in the location. Data Source 8
Proposed Approach Source Data / Identity Secure Smart Plug • Using RSA threshold scheme (k,n). Energy Magnetic Data Integrity / Consistency Sensor • Both energy data from the magnetic sensor and the Raspberry energy plug must match. Pi 3 • Aggregated energy data Bluetooth from all data sources must also match the smart Smart meter’s measured data. Energy Plug Location Authenticity • Using Bluetooth Trilateration technique. 9
Proposed Approach 1. Commissioning Phase A. Deployment of Secure Smart SECURITY PROTOCOL Plug - register location B. RSA Key Pair Generation C. Secret Share Generation Commissioning 2. Operational Phase A. Signing and Verification Protocol Operational using Threshold Scheme (3,4) B. Location Verification 10
Commissioning Phase • One-time key generation using (3,4) Threshold Scheme for each data Secure Smart Plug source in the network. Energy Magnetic Public Key: n Share: s 4 Sensor Raspberry Smart Public Key: n Pi 3 Meter Shares: s , s Bluetooth 1 2 Smart 1. RSA Key Pair Generation Energy Public Key: n (PK and SK) Plug Share: s 3 - Public Key (PK): (n, e) - Secret Key (SK): d Data Source 2. Generation of Secret Shares 11 - Secret Shares: s1, s2, s3, s4
Commissioning Phase • Using Trilateration algorithm to determine the location of SSP. • Using RSSI of the Estimote Beacon (Yellow) BLE chip to Estimote compute the Beacon (Candy) (Intersection) Secure Smart Plug distance. • Location of the deployed SSP is Estimote Beacon (Beetroot) registered. 12
Operational Phase Secure Smart Plug ps = { s , n, m 2 , N } MS 1 1 ps PS 2 = = { s , n, m 2 , N } MS 2 MS 2 ps = { s , n, m 2 , N } ps = { s , n, m 2 , N } 4 4 MS 4 4 Energy MS (5) Generate own partial (6) Send all respective partial signature shares to SM Magnetic signature share by signing m (1) Sends m to SM , where m = m 2 Sensor SIGN { s , n , m , N } MS i (1) Sends m ps = { s , n, m 2 , N } (7) Upon receiving the PS , 1 to BT , where 1 MS ps combine and aggregate = { s , n, m 2 , N } 2 m = m 2 2 MS (4) Sends ps MS them to compute as FS for i to MS verification later. COMBINE { PS, PK , m, n, k, N } e Raspberry (2) Check current location(XY) Smart Pi 3 (8) Verifies m with SK d of SP upon receiving m Meter i Bluetooth (9) VERI SM FS ≡ m SK (3) if true, generate own partial d signature share by signing m using PK (1) Sends m e SIGN { s , n , m , N } i to BT , where (10) VERI SM ( m 1 ≡ m 2 ) m = m 1 (4) Sends ps ps SP = { s , n, m 1 , N } SP MS i 1 SP 1 using PK e to SP ps = { s , n, m 1 , N } 2 2 SP Smart (1) Sends m to SM , where m = m 1 (5) Generate own partial SP Energy signature share by signing m (6) Send all respective partial signature shares to SM Plug SIGN { s , n , m , N } ps = { s , n, m 1 , N } i 1 1 SP PS 1 = ps ps = { s , n, m 1 , N } = { s , n, m 1 , N } 2 3 2 3 SP SP SP ps = { s , n, m 1 , N } Data Source 3 SP 3 13
Operational Phase • Using BLE to detect changes in the location of SSP. Estimote Beacon (Yellow) Estimote Secure Smart Plug Smart Meter Beacon (Raspberry Pi 3) (Candy) Wireless WiFi Router Local Area Network (LAN) Estimote Beacon (Beetroot) 14
Attack Simulation I • One of the components in SSP “attempted” to under report the energy consumption. • Resulting in: – Difference in the energy usage at the same data source: M MS ≠ M SP ☛ data inconsistency 15
Attack Simulation II • The re-location of the SSP to measure a data source that is outside of the house. • Resulting in: – Detection of location that is different from the deployed location, hence will not generate partial signatures, ps 1 and ps 2 ☛ incorrect location. – Energy usage data cannot be verified due to the lack of signature shares. 16
Attack Simulation II Estimote Beacon (Yellow) Secured Estimote Relocated Smart Plug Beacon Secure Smart Original Deployed (Candy) Plug Location Location Coordinates Coordinates (x:6.5, y: 10.0) (x:2.5, y: 2.5) Estimote Beacon (Beetroot) 17
Attack Simulation III • Both energy measurement sensors “ were compromised ”. • Resulting in: – (IF Location of SSP is authentic) ☛ collusion between MS and SP yielded a successful attack. – (IF SSP is re-located) ☛ collusion between MS and SP did not work as only two partial signature shares could be generated for a (3,4) Threshold Scheme. 18
Performance Results 19
Performance Results • The RSA threshold scheme is feasible on a Raspberry Pi 3 device, though not very efficient. Entity Components in SSP Key Size (bits) 512 1024 2048 Average (ms) 148.33 863.67 6419 Time taken to generate a partial signature Entity Smart Meter Key Size (bits) 512 1024 2048 Combine Signature (ms) 5 8.33 18.33 Signature Verification (ms) 132 157 875 Time taken to combine partial signatures and verify signature 20
Conclusions • Preliminary study of data provenance in the context of IoT. • ICS systems also use many redundant sensors for critical infrastructure and monitoring. • TPM and software-based attestation will be required to ensure the verification software works correctly ? • Replacement of RSA-based Threshold Scheme with a MAC-based scheme ? • Auto detection of location without deployment of beacons ? 21
Thank you! Contact details: Sye Loong Keoh University of Glasgow SyeLoong.Keoh@glasgow.ac.uk Zhaohui Tang Singapore Institute of Technology Zhaohui.Tang@SingaporeTech.edu.sg 22
Recommend
More recommend
