This blog post originally appeared on Medium.
TL;DR: We created a proof of concept where smart meter data is obtained via a Raspberry Pi and published via IOTA Masked Authenticated Messaging. A consumer can proof he owns the Raspberry Pi, and the consumer can give and revoke consent to service providers to access the smart meter measurements for a specific goal. All on the IOTA Tangle.
Alliander is a Dutch energy grid operator that ensures 6 million citizens have access to energy. At Alliander R&D we research technologies that will improve our infrastructure and lead to a more sustainable future.
Sharing smart meter data with service providers can help the energy transition. For example, in the UK energy usage was reduced after providing citizens an app with usage insights connected their smart meter. If anyone can access energy usage data it can help balance the grid and more.
At the same time smart meter data is privacy-sensitive. Power consumption can be associated with appliances used and with measurements every 0.5 seconds it is possible to see what television channel is being watched!
Power consumption peaks can be associated with individual appliances. (Source: Privacy Issues Related to Smart Grid Technologies, Megan J. Hertzler)
You can ponder if we should care about privacy in the face of the slow-moving climate change apocalypse. But it's the law. Energy usage data cannot be legally shared without adhering to it.
The General Data Protection Regulation (GDPR) came into effect May 25. It provides data and privacy protection for European citizens. When dealing with personal identifiable information (like the measurements of a smart meter) a service provider has to:
(Ignoring other parts of the GDPR that cannot be encoded in software, but that need to be enforced juridically, like right of erasure).
So, for open usage of smart meter measurements a solution needs to be provided that adheres to the requirements of the GDPR. Two goals of this solution are:
When data or consent is stored centrally, for example in a cloud, there are privacy concerns. A cloud is a single point of failure (what if consent is irrevocable because a server is down?), that is susceptible to misuse and hacks. Central storage can also lead to vendor lock in, where the owner of the smart meter data reader determines what service providers can use the data, instead of creating a level playing field where you can authorize anyone to access the data. Distributed ledger technology could address these issues.
Dutch Smart meters have a P1 port which gives consumers access to real time measurements with a high resolution. We investigated how distributed ledger technology can be used to provide open access to P1 energy measurements where the consumer is in control. Because it scales and has no transaction fees (who wants to pay to give consent?) we use the IOTA Tangle.
A Raspberry Pi running IOTA interfacing software connected via a P1 cable (USB to RJ11) to a Dutch smart meter
IOTA aims to be the backbone for the Internet of Things whereby devices can communicate and transact with each other. E.g., your washing machine buys energy from the solar panels of the neighbours while your self-driving car is instructed to pick up your kids. To read more about IOTA Tangle see The Tangle: an Illustrated Introduction.
–>
Every data or value transaction on the IOTA Tangle must validate two earlier transactions by solving a cryptographical puzzle that takes computing power (proof of work). This way all nodes agree with each other on the state of the Tangle. For more information on how IOTA works see The Tangle: an Illustrated Introduction. (Image source) –>
Component diagram
IOTA Masked Authenticated Messaging (MAM) is a feature of the IOTA Tangle that allows to publish and fetch encrypted messages. In restricted mode both the address of a data stream as well as a side key (with which the data is encrypted) needs to be known to read and decrypt the data. MAM can be used for data integrity and access control.
When I first heard about MAM I thought that it would solve all GDPR issues. Then we stumbled upon the problem of exchanging keys...
After you have paired with the Raspberry Pi (see Scenario: Pairing with a Device for a way how ownership can be proved via IOTA using a secret on the Pi itself), when you give a service provider consent to access your data (you do this in a type of IOTA wallet that manages your paired devices and consent policies), the service provider has to receive the restricted MAM channel's root and side key. How can this be done?
In our solution, the service provider can request access to data by sending its address and the goal for usage (for what reason energy data access is required as per the GDPR) to the consent wallet (called My Home). Then when a Raspberry Pi owner gives consent to access the data, the Raspberry Pi sends the access keys to the service provider's IOTA address.
From the console output of the Raspberry Pi we see the creation of a zero value IOTA transaction containing the Pi's MAM root and side key to an authorized service provider's IOTA address
In the IOTA transaction above the MAM root and side key in the IOTA transaction are encrypted. Why?
Because on the IOTA Tangle all communication is public, the above key exchange needs to be encrypted. Otherwise eavesdroppers can see the IOTA transaction and obtain the root and side key as well. When an attacker has the keys, he has access to your privacy-sensitive energy usage data.
As stated, when using restricted MAM between two parties a key exchange needs to take place: the root and side key of the restricted MAM channel need to be communicated to the authorized service provider. IOTA has no asymmetric encryption. IOTA only has signing. So you cannot encrypt data with, for example, an IOTA address, and only decrypt it if you have the seed. So for asymmetric encryption we need something outside IOTA.
Since one of the benefits of IOTA is that its secure against quantum computers (IOTA's signing and proof of work are quantum proof), we don't want to lose this benefit by using classical asymmetric encryption algorithms like RSA). These are broken once quantum computers arrive.
The author of the CHIOTA health care chat application helped us. CHIOTA came up with a quantum proof key exchange for IOTA. A method to deterministically generate a key pair using an IOTA seed and address. We use a similar approach, but in JavaScript instead of C#. Using this method and an IOTA seed you can generate a public and private key.
I think it would be helpful if quantum-proof asymmetric encryption is integrated in IOTA as an IXI module. Since you cannot encrypt with someone's IOTA address itself, a directory of public keys is needed somewhere. CHIOTA stores the public key on a user's first IOTA address. Perhaps we will see asymmetric encryption integrated in the IOTA Tangle or in MAM in the future.
By using the quantum proof encryption described, the MAM root and side key can be encrypted with the public key of the service provider. This way, although communication is public, only the service provider can decrypt it.
In our solution a tryte-encoded public key is sent along with the data access request, but a possible solution could also be that the public key is available in a central place. Something like an energy data usage app store where consumers can vouch for the trustworthiness of service providers.
The service provider wattt.nl receives the MAM data (root and side key) from the device and decrypts it
Thanks to Harm van den Brink for sharing this idea.
Asymmetric encryption is also used in the case of access revocation. Multiple service providers can read the same MAM data stream with P1 energy data. When the software on the Raspberry Pi is instructed that a service provider's access is revoked (see next issue), it changes its side key and sends out a key rotation message. This message is published on the same MAM stream as the energy data, so service provider's only need to listen to that. The published message contains the new side key, encrypted with the public keys of the remaining authorized service providers (click here for the code). This way all service providers that are listening that are still authorized can decrypt the message and update the side key, but the service provider of which consent is revoked cannot.
The service provider shows plots earlier received data, but is not included in the KEY_ROTATION message, so is no longer authorized and is unable to fetch new data
Once the Raspberry Pi (connected to the smart meter) is paired, it starts listening to the consent management front-end's MAM channel (click here for the code). Every time an event of type AUTHORIZED
is published on this channel by the front end, the Raspberry Pi will communicate its current root and side key (encrypted with the service provider's public key) to the service provider in the message (via an IOTA transaction). And when an event of type AUTHORIZATION_REVOKED
is published on the MAM channel the Raspberry Pi will publish a message of type KEY_ROTATION
on the MAM channel. So the Raspberry Pi can handle authorizations via this MAM channel.
The front-end uses the same channel to obtain its state, but it creates another view (click here for a code example) from the events (for example show a consent policy when an event of type AUTHORIZED
has taken place).
In My Home's consent management wallet a paired device can be selected that the service provider can then access. The device is obtained from an event on the MAM channel (type of DEVICE_ADDED
). And when access is given an event of type AUTHORIZED
is published to which the paired Raspberry Pi will respond.
Using an immutable log of events as a backend is called event sourcing. Event sourcing works as a backend for both the consent management front-end and the Raspberry Pi.
The MAM channel root is communicated to an authorized service provider. This way all parties involved (Raspberry Pi, the consumer, and the service provider, see component diagram above) have access to the immutable audit trail and can show whom had consent and when to use the data.
Events that are published on the consent and devices wallet (My Home)'s MAM channel. A user has added a device, provided consent, revoked consent and deleted the device.
Very nice. But now we have an immutable audit log only accessible by parties involved. On permanodes, this will never be erased. The same goes for the published energy measurement data by the way, it is just like the policies, forever stored on permanodes in the IOTA Tangle.
Is this a problem? Although it is encrypted now, data might later be decryptable with new technologies or exploits. Other than that I don't see much difference between publicly storing encrypted data and handing out keys, or sending data in another way. For a malicious service provider it might be a bit more convenient to give someone else access when using keys. Instead of sending the raw received data they only have to send the keys. But raw data can also be easily send. It might be a problem in the future if the encryption is hacked, the rest of the argument against public storing of encrypted data seems based on emotion (although this needs to be addressed in the case of widespread adoption).
In relation to the GDPR's right to erasure, is it enough for a service provider to delete the root and side key? The GDPR does not address what erasure precisely means. I personally think it is fine to have publicly available encrypted data with removed keys in a cloud or on a distributed ledger. It's similar to the practice of crypto-shredding. But in a larger scale roll out of distributed ledger software for GDPR, will citizens feel the same? We will see what interpretation of the legislation will dominate.
What is a problem with MAM is that it is unsuited for high frequency smart meter measurements.
MAM's proof of work is a problem for publishing high frequency smart meter data on MAM. MAM is, with the current speed of proof of work on nodes, unsuited for P1 energy data. Even when offloading the proof of work from the Raspberry Pi to a node, it is too slow. On the main net one P1 energy data MAM message can be published roughly every 40 seconds. On the testnet it does work for smart meters that send data once every 10 seconds (click here for the P1 data publishing code). Newer Dutch smart meter models, however, send data every second!
In its current state IOTA is not suited for the IoT industry (see this IOTA Report Overview). At the moment, the energy required for the proof of work for data publishing, is higher than the estimated energy savings from usage of the data (back-of-the-envelope calculation: it takes 0.00005 kWh) per IOTA transaction, three transactions per MAM message is 0.00015 kWh per message, one message every 10 seconds for older smart meters is 473 kWh proof of work (PoW) per year per household. On average 3500 kWh and 16000 kWh gas energy usage per household, insight into energy usage leads to 2% energy savings by a conservative estimate, and 2% of the energy usage is 0.02 * (3500 + 16000) is roughly 390 kWh, so with current IOTA transaction speed for an average household more energy is used for the proof of work (473 kWh) than the expected savings (390 kWh)).
It is possible to move to an off-Tangle protocol like MQTT, but in that case the service provider is required to host an MQTT broker or similar. You lose the ease of access of an MAM.fetch
.
The PoW problem, however, can be solved. There are advancements where dedicated hardware can run proof of work much quicker. For example, an FPGA for the Raspberry Pi can run proof of work for one transaction in 18 milliseconds! This uses much less energy. This does mean that people wanting to share their energy data for the energy transition must buy such dedicated hardware, or it must be provided in smart meters.
Proof of work speed needs to be improved for IOTA to be suitable for the IoT industry. This will happen once more devices start using the IOTA Tangle and the IoT industry starts using hardware that is optimized for IOTA's proof of work.
Examples of the software connected to the IOTA test net are deployed. Below we go through the flow on a laptop.
Energy data on IOTA with consent
Check out this video on Streamable using your phone, tablet or desktop.
Here we see the pairing of a Raspberry Pi, requesting consent from a service provider to access its data via the consent wallet My IOTA Home, consent (key exchange) for two service providers (wattt.nl from localhost and wattt.nl from domain), viewing the data once consent is given, and revoking the consent for one of the two service providers (key rotation). Note that this video is sped up.
In the future IOTA's Qubic protocol can possibly be integrated. Its oracles might be useful for storing consent. Also the next version of MAM called MAM+ will probably contain a public key infrastructure with possibly a key exchange mechanism. And in the future identity management system like Sovrin or IRMA can be integrated to proof that you own a smart meter without revealing anything else about yourself, and for signing the consent.
The code is open source and available on GitHub. It's a proof of concept and it's frail, but the happy flow (publishing energy data, pairing a Raspberry Pi, authorizing a service provider, viewing the data, revoking consent) has been tested and works.
If you have a Dutch smart meter, a Raspberry Pi and a RJ11 P1 cable you can download and install the software and connect yourself! Those who want to create their own service provider can do so and interface with the My Home consent management wallet as well.
For more technical information check the documentation. The ideas are possibly applicable to other fields where personally identifiable information is used. For example in health care when a patient wants to share his medical records.
We hope this will be a step towards a privacy-preserving infrastructure that opens smart meter data to the world. Where energy data can be used by everyone who you trust. This way smart meter owners can be in control of their data, and everyone can create services that use it.
The infrastructure for sharing energy data while adhering to the GDPR, can be realized using a decentralized consent protocol on the IOTA Tangle. Although IOTA has some open issues like:
Thanks to my colleagues at Alliander and IOTA users for their help. And thank you for reading. Let me know what you think.
This blogpost was originally published at https://medium.com/@erwinrooijakkers/gdpr-compliant-smart-meter-data-on-the-iota-tangle-four-lessons-learned-while-putting-the-dea852a5b2aa