The focus of the presentation was on describing the process from a data consumer to an analytics provider from step to step.

1. Berner Fachhochschule | Wirtschaft, Gesundheit, Soziale Arbeit
Smart Cities of Self-Determined
Data Subjects (SDDS)
Graphic source: https://bam.files.bbci.co.uk
Jan Frecè &
Thomas Selzam
Bern University of
Applied Sciences,
E-Government-Institute
17 May 2017,
Danube University,
Krems, Austria

2. Bern University of Applied Sciences | Department of Business, Health & Social Work
1. The Problem and its Resolution
2. Layers of the SDDS Approach
3. Layers at Work
4. Case Aftermath & Feature Overview
Agenda
2

3. Bern University of Applied Sciences | Department of Business, Health & Social Work
The Smart City Data Problem
3
Graphic sources: http://www.eoi.es,
https://flaticon.com (Made by Freepik & Alfredo
Hernandez)
The more data  the better the city
modeling  the smarter the city
The more data  the better
the citizen modeling  the
smaller the individual privacy

4. Bern University of Applied Sciences | Department of Business, Health & Social Work
▶ All personal data is stored in decentralized data stores, where it
emerges.
▶ The functions for data storage, assembly, analysis and finally
consummation are logically separated.
▶ No unencrypted information and no personal information leave
the data store.
▶ The only one with access to analysis results is the data consumer.
Solving the Dilemma Using Self-Determined Data
Subjects (SDDS)
4

5. Bern University of Applied Sciences | Department of Business, Health & Social Work
The Layers of an SDDS approach
5
Data Layer
[containing all unencrypted personal data stored and managed in decentralized
data storages]
Assembly Layer
[containing combined, encrypted and de-personalized data sets from the data
layer]
Analysis Layer
[containing encrypted data from the assembly layer, the algorithms to analyze
this data and the encrypted results stemming from the analysis]
Consumer Layer
[containing encrypted analysis results from analysis layer, able to decrypt the
results]

6. Bern University of Applied Sciences | Department of Business, Health & Social Work
Peter wants to support the city by
providing his transportation data, but he
does not want to reveal information
younger than two weeks and no
information from Wednesdays.
Use Case Setup I
6Graphic source: Made by Freepik on https://flaticon.com
The City Department of
Transportation is interested to
know which means of
transportation people have used
at which times of day, for what
distances, in the last three
months.

7. Bern University of Applied Sciences | Department of Business, Health & Social Work
Use Case Setup II
7Graphic source: Made by Freepik on https://flaticon.com
A tracker in Peter’s car
saves its movements and
at home moves the data to
Peter’s decentralized data
store.
Peter Muster, 2017
Yearly Subscriber
City Department of
Public Transportation
All data from using public
transport is saved on
Peter’s subscription card
and at home moved to
Peter’s decentralized data
store.

8. Bern University of Applied Sciences | Department of Business, Health & Social Work
Data Announcement Overview
8Graphic source: https://www.omakpac.org
Step 1: The data subject (Peter) authorizes the data creators (Public
Transportation Card & Car GPS Sensor).
Step 2: The data creators announce the data to the local SDDS node.
Step 3: The local SDDS node creates an entry in the distributed ledger
(block chain), thereby announcing the data’s existence.
Step 4: Now the data subject can log into the SDDS platform and enter its
access conditions. Only then the data becomes available.

9. Bern University of Applied Sciences | Department of Business, Health & Social Work
Data Announcement Details Behind the Curtains
9Graphic source: https://www.omakpac.org
Data is announced
• in an SDDS block chain, as reference only,
• with an encrypted owner ID,
• with an encrypted location ID,
• with an unencrypted data type identifier,
• in connection with smart contracts,
enforcing the access conditions.
These smart contracts are the only gateway
to reach the decentralized stores.

10. Bern University of Applied Sciences | Department of Business, Health & Social Work
Data Analysis: A Few More Details
10
Step 1: The data consumer (Department of Transportation) creates a new
information request at the SDDS platform.
Step 2: The platform isolates the entries in the distributed ledger (block
chain) using the Type-ID and triggers the associated smart
contracts.
Step 3: If all access conditions (older than two weeks, no Wednesdays)
are met, the local SDDS node is contacted (through a
anonymization layer).
Step 4: The distributed data store extracts the demanded data, removes
personal information and forwards it to the local SDDS node.

11. Bern University of Applied Sciences | Department of Business, Health & Social Work
Data Analysis: A Few More Details
11
Step 5: The local SDDS node encrypts the data for analyzing and forwards
it to the SDDS platform.
Step 6: The SDDS platform assembles the data from all local nodes and
forwards it to the Analytics Provider.
Step 7: The Analytics Provider executes the selected analytic algorithm
upon the encrypted data, producing an encrypted result.
Step 8: The data consumer can download and decrypt the result.

12. Bern University of Applied Sciences | Department of Business, Health & Social Work
Data Analysis: The SDDS Layers at Work
12
Data Layer
Assembly Layer
Analysis Layer
Consumer Layer
Graphic source: Made by Freepik, Macrovector and
Plainicon on https://flaticon.com

13. Bern University of Applied Sciences | Department of Business, Health & Social Work
Use Case Scenario – Aftermath I
13Graphic source: Made by Freepik on https://flaticon.com
• Peter could put his private data source to use and
help his city. Possibly, he is even remunerated for his
service.
• No personal data has been revealed.
• No data has been revealed in general, only
information provided.
• SDDS Platform does not store any data, only IAM
information.
• No access to analysis results.
• Only anonymized, encrypted data is processed.
• The location and the creator of the data to be
analyzed remains unknown.
• Only references are saved in block chain  no
data exposure in the case of encryption withering
away.

14. Bern University of Applied Sciences | Department of Business, Health & Social Work
Use Case Scenario – Aftermath II
14Graphic source: Made by Freepik on https://flaticon.com
• As desired, the Department of Transportation has
information concerning which means of
transportation are used for what kind of distances
at which time of day.
• Only relevant data (of the last three months) was
processed.
• No raw data has been revealed, only agreed
information. Sample result:
14-15h: Distance < 1km  22.3% City Bus
• No location data or names have been revealed  no
risk of mishandling personal data.

15. Bern University of Applied Sciences | Department of Business, Health & Social Work
SDDS Main Features
15
• All data remains where it has been created. Outside of decentralized
data stores, only references are saved.
• Only encrypted, de-personalized excerpts leave the data store.
• Data subject decides what to share under which conditions.
• Information can be shared without revealing the actual data, nor the
data creator.
• Using Proxy Re-encryption, the SDDS platform prevents itself from
being able to decrypt data or results and still processes them.
• All roles are cryptographically isolated. Even double roles are
possible, e.g. data consumer can also be an analytics provider
without revealing more data.

16. Bern University of Applied Sciences | Department of Business, Health & Social Work
Thank you for your attention!
Do you have any
questions?
16
Jan Frecè & Thomas Selzam
Bern University of Applied Sciences
E-Government-Institute
jan.frece@bfh.ch
thomas.selzam@bfh.ch