Warp 10 for IoT: GDPR compliant before GDPR even existed

For most systems, GDPR is a pain that needs lots of workarounds to fulfill very simple things:

Recent mishap of a big company: an Amazon customer made use of his right to personal data access. Amazon sent him back all his personal data + 1,700 Alexa voice files from another customer. (link to this news)

In a typical backend, there is no 'per customer' access to the database. At most, there is one user per application sharing the database, and of course, a dedicated table somewhere to list the customers.

To fulfill the GDPR, the backend must be updated to carefully extract or delete data for a single customer. It would be more simple to let the customer access the database directly with its own credentials, wouldn't it?

As soon as every customer has its own account in the database, you may simplify the design: connected devices could read and write directly into the database, each one with its own credential.

Crazy? Too hard to scale up? Not with Warp 10. Let me explain how you can do that with our token mechanism.

Data modeling

In the IoT word, keep things simple and safe: Every device has a unique identifier. It could be either:

• A serial number. Dangerous, because too easy to get or guess.
• A customer account name. Dangerous also.
• A UUID generated for each device. Safest.

In Warp 10, each time series will have a label 'deviceID' with this UUID. With this data modeling, complying with GDPR with Warp 10 is really easy.

One Token per user

What is a Warp 10 token? It is an encrypted object that contains multiple information. The token encryption key is the equivalent of your SQL root password. Keep it safe.

In this object, the required fields are application name, owner UUID, producer UUID, creation date, and expiry date. It can also contain other special attributes or labels.

• A write token will enforce the application name, owner, producer, and labels if any. In the labels, we can put deviceID=the device UUID.
• A write token can be used for delete only if owner=producer AND the .nodelete attribute is not in the token.
• A read token will enforce application name, owner, producer, and labels if any.

One token to read them all

Your data scientist, or your application, will need to read data from every existing systems. So, you need a super token to read data, whatever the deviceID value.

Such a super read token is easy to generate: just forget the deviceID label! In this case, as soon as you FETCH data, you can specify the deviceID your want, or a regexp wildcard. As the super read token does not contain any deviceID, the deviceID label selector won't be overridden by the token.

Automate token generation

The easiest way to generate token is to use a WarpScript with the TOKENGEN extension. You can easily generate thousands of tokens to feed your IoT production line. TOKENGEN takes a map as input :

{
  'id' 'nameoftoken'  // for bookkeeping purposes
  'type' 'READ'       // or 'WRITE'
  'application' 'app' // Name of applications for this token
  'owner' 'UUID'      // UUID of the data owner for WRITE tokens or the billed user for READ tokens
  'producer' 'UUID'   // only for WRITE tokens
  'issuance' NOW MSTU /  // Time of token issuance
  'expiry' NOW 30 d + MSTU /  // Time of token expiry 30d% days
  'labels' {}         // Map of token labels
  'attributes' {}     // Map of token attributes
  
  // The following are only for READ tokens
  // if omitted, the token is a WildCard token.
  'owners' [ /* List of UUIDs */ ]
  'producers' [ /* List of UUIDs */ ]
  'applications' [ /* List of application names or regexps*/ ]
} TOKENGEN

Real world example

BestFridge is building smart fridges. You are proud to work for this visionary company. BestFridge collects data such as the internal and external temperature, the time spent with the door opened, the amount of energy absorbed by the compressor, the duration of the outages if any. Every fridge is connected to the Internet. With this information, BestFridge can compute the efficiency of isolation, the efficiency loss of the compressor in time, and the maintenance period.

Leader of this project, you will generate a unique write token for each fridge:

• expiry: somewhere in year 2100. lifetime of the system.
• application: 'smartfridges'
• owner: a unique UUID per token
• producer: another UUID, same for every token
• labels: { 'deviceID': a UUID per token}
• attributes: { '.nodelete' " '.maxfuture' '60000' '.maxpast' '86400000' }

You will also generate a super token for its application:

• Expiry: somewhere in year 2100. Lifetime of the system.
• application: 'smartfridges'
• owner: a unique UUID per token
• producer: another UUID, same for every token
• owner: a UUID
• owners: []
• producers: []
• applications: [ 'smartfridges' ]
• labels: {}

Each fridge can directly push data to a Warp 10 server, using its own token. The super token can read all the data, whatever the owner or deviceID. You have to keep it safe.

If the fridge is reverse engineered, the smart hacker will find the write token. What can he do with it?

• With a write token, he cannot read the data stored remotely.
• He cannot delete data (because owner is different from producer, and we put a .nodelete special attribute).
• He may override its own device data (but not the others), and only in the specified time window: 1 minute in the future, 24 hours in the past.

Enter GDPR

A curious customer named Billy wants to recover all its data or erase them. You need to generate a read token for this deviceID (and not the other ones).

• Expiry: somewhere in year 2100. lifetime of the system.
• application: 'smartfridges'
• owner: a unique UUID per token
• producer: another UUID, same for every token
• owner: a UUID
• owners: []
• producers: []
• applications: [ 'smartfridges' ]
• labels: { 'deviceID' 'Billy device UUID' }

With this token, Billy can FETCH everything for this deviceID.

Next step, you need to generate a write token to delete only time series with Billy deviceID.

• expiry: somewhere in year 2100. lifetime of the system.
• application: 'smartfridges'
• owner: same as producer
• producer: another UUID, same for every token
• labels: { 'deviceID': 'Billy device UUID' }
• attributes: {}

If Billy owns several devices, you make an alternation in a regexp:

• labels: { 'deviceID' '~(BillyUUID01|BillyUUID2|BillyUUID3)' }

You are done. With these two tokens and a short HowTo, your customer can safely access the database to fetch data and delete data. To help him, you can prepare a GDPR web page where the customer enters both tokens, a download json button, and an erase all button.

Conclusion

Warp 10 time series database has been designed a long time ago to manage connected wearables. The concept of data owner and producer is here since the beginning. Using Warp 10 does not ensure you to comply to GDPR, it still depends on your data modeling choices. But for sure, token will help you!

For more information about token vs GTS, read this tutorial.

Pierre Papin

Electronics engineer, fond of computer science, embedded solution developer.