GDPR-compliant smart meter data on the IOTA Tangle — four lessons learned while putting the consumer in control
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 sustainable future.
Sharing smart meter data with service providers can help the energy transition. For example, in the UK energy usage reduced when citizens were provided with an energy usage insights app with data from 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 determine what television channel is being watched!
You can ponder if we should care about privacy in the face of the slow-moving climate change apocalypse. Of course we should not put fundamental human rights like privacy aside for other concerns. And it’s also 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:
- State the goal for data usage clearly (and only use the data for that goal).
- Have consent of the consumer to access the data.
- Stop collecting data when consent is revoked.
(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:
- Energy data goes directly from the smart meter to the service provider.
- Consent (authorizations to access energy data) are stored decentrally.
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?), susceptible to misuse and hacks. Central storage can also lead to a 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.
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 the IOTA Tangle see The Tangle: an Illustrated Introduction.
Now follow four lessons we learned implementing GDPR-compliant energy data streams on the IOTA Tangle
- The difficulty in providing access is handing out the keys.
- Asymmetric encryption is needed when sharing keys.
- MAM channels can be used as decentralized storage of consent with an encrypted immutable event log, but… you now have an encrypted immutable event log.
- Masked Authenticated Messaging on standard hardware is unsuited for frequent smart meter measurements.
1. The difficulty in providing access is handing out the keys
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…
An authorized service provider needs to receive the root and side key of restricted MAM channel (key exchange)
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), 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 energy 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.
In the IOTA transaction above the MAM root and side key in the IOTA transaction are encrypted. Why?
2. Asymmetric encryption is needed!
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 using hash-based signatures. 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 using JavaScript instead of C#. Using this method and an IOTA seed you can generate a public and private key.
Let’s look at our use case.
Encrypting the MAM root and side key
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.
Revoking access
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.
KEY_ROTATION message, so is no longer authorized and is unable to fetch new data.I think it would be helpful if quantum-proof asymmetric encryption is integrated in IOTA as an IOTA eXtensible Interface (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.
3. MAM channels can be used as decentralized storage of consent in an encrypted immutable event log, but… you now have an encrypted immutable event log
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 energy data channel. So the Raspberry Pi manages authorizations based on events on the consent wallet’s 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).
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 the component diagram above have access to the immutable audit trail and can show whom had consent and when to use the data.
Very nice. But now we have an immutable audit log only accessible by parties involved. On permanodes, this audit log 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 cracked. The rest of the arguments against publicly 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. 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.
4. MAM’s proof of work is too slow for smart meter measurements (on standard hardware)
MAM’s proof of work is a problem for publishing high frequency smart meter data via 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 devnet 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 (also 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 data message is 0.00015 kWh per message, one message every 10 seconds for older smart meters is roughly 500 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 400 kWh. So with current IOTA transaction speed for an average household more energy is used for the proof of work (500 kWh) than the expected energy savings (400 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 a 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, but means 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.
In practice
Examples of the software connected to the IOTA devnet are deployed or can be run locally. Below we go through the flow on a laptop.
Remarks
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 prove that you own a smart meter without revealing anything else about yourself, and possibly for (extra) signing of 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 sometimes 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.
Conclusion
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 using IOTA has open issues like:
- Improving the speed of proof of work for publishing MAM data messages (for example with dedicated hardware).
- Standardizing key exchange (and possibly key rotation).
- Legally clarifying if removal of keys of encrypted data on a distributed ledger adheres to the GDPR’s right to erasure.
Thanks to my colleagues at Alliander and IOTA users for their help. And thank you for reading. Let me know what you think.
