D4.6 One-pager: Privacy and IoT Security Report - Version 1

Link

Report (pdf)

This deliverable presents the first EDIAQI report on privacy and IoT security. It evaluates how indoor air quality monitoring data are collected, transmitted, stored, shared and protected in EDIAQI pilots and campaigns. The report also gives recommendations on how to improve data privacy and security when using IoT systems for indoor air quality monitoring.

The deliverable focuses on two closely connected topics: IoT security and data privacy. IoT security deals with the technical protection of sensors, gateways, cloud systems, APIs and user interfaces. Data privacy deals with protecting individuals, organisations and buildings from being identified or profiled through indoor climate data.

Why is this topic important?

Indoor air quality monitoring systems collect data from real buildings, rooms and occupied spaces. At first, indoor climate data may seem harmless because it usually contains environmental parameters such as temperature, relative humidity, CO₂, particulate matter or VOCs. However, these data can reveal much more.

Indoor climate data may show when a room is occupied, when people are active, when a building is used, how ventilation systems operate, or what routines exist in homes, schools, offices and other buildings. If such information is not properly protected, it could be misused for profiling, unethical business practices, surveillance, or even planning malicious activities.

For this reason, privacy and security are essential for trustworthy indoor air quality monitoring. Users are more likely to accept sensors and monitoring systems when they know that their data are protected, that only necessary data are collected, and that shared data cannot be traced back to specific people, rooms, buildings or organisations.

Key messages

Indoor air quality data can be sensitive: Even when data are environmental, they may reveal private information about people’s routines, building use and organisational activities.

Privacy must be built into the system design: Data privacy should not be added at the end. It should be considered from the beginning when deciding what data to collect, where sensors are placed, how data are transmitted and who can access the results.

Data minimisation is a core principle: Only data that are necessary for the monitoring objective should be collected. This includes selecting the right parameters, the right time resolution and the right monitoring locations.

Security is needed across the full IoT stack: Protection is needed at device level, gateway level, cloud level, API level and user-interface level. Encryption, authentication, authorisation and secure software updates are important at different layers.

Anonymisation is essential before wider data sharing: EDIAQI data should be anonymised so that research data cannot be traced back to specific individuals, buildings, organisations or exact addresses.

Sensor data should remain useful for research: The report notes that anonymising the actual sensor values or timestamps may reduce scientific value. Therefore, anonymisation should mainly focus on location and identifying metadata.

EDIAQI security measures are generally satisfactory: The report gives a positive overall assessment of the applied security measures, while noting that end-to-end security and long-term privacy must continue to be evaluated.

What did the EDIAQI project do?

The EDIAQI team reviewed privacy and IoT security principles relevant to indoor air quality monitoring. The report explains why indoor climate data can be sensitive and how privacy risks can arise even when no direct personal data are collected.

The report describes privacy principles for EDIAQI, including data minimisation, secure data transmission and management, anonymisation, user consent and transparency. It also explains security methods at device, gateway and cloud levels.

The deliverable then assesses the technical solutions used by EDIAQI technology providers and data platforms:

System / provider	Security approach described in the deliverable
Lab Service Analytica / NetPID™	Sensors send authenticated and authorised data through Amazon AWS services. Communication uses secured Wi-Fi, HTTPS and TLS encryption. Cloud access uses certificates and AWS security services such as Cognito. Data can also be accessed securely through dashboards and API gateway services.
WINGS / AIRWINGS	Security is described at device, communication and protocol levels. The system can use AES encryption, secure narrowband communication, Wi-Fi security such as WPA2, and several communication technologies including NB-IoT, LoRa, GPRS, 4G/5G and Wi-Fi. API access uses HTTPS requests and token validation.
Thinnect	The solution uses wireless sensor devices, an Edge gateway and a cloud platform. Mesh networking is used for sensor communication. Security includes Edge Public Key Infrastructure, TLS, SSH, VPN-style secure connections, certificates, token-based authentication and role-based access control.
FROST Server	EDIAQI uses FROST Server to collect data from individual platforms into a common SensorThings API environment. Standard role-based FROST security measures are used for confidentiality and privacy, including server-to-server security.

The report also maps which SensorThings API data elements may need anonymisation. For example, location names, building names, room names, verbose descriptions, exact coordinates, owner information, addresses and local building identifiers may require anonymisation before data are shared more widely.

What does this mean in practice?

For EDIAQI, privacy and IoT security are necessary for responsible monitoring. The project aims to collect useful indoor air quality data while protecting the people and organisations connected to the monitored buildings.

User group	Practical relevance
Homeowners and tenants	Monitoring data from homes may reveal routines, occupancy and daily habits. Privacy protection is essential before household IAQ data are stored, shared or analysed.
Schools and kindergartens	Data from classrooms can reveal room use, occupancy patterns and building operation. Security and anonymisation are important when monitoring spaces used by children and staff.
Commercial property owners	Indoor climate data may reveal business routines, operational patterns or building management practices. Data privacy helps protect organisational confidentiality.
Local municipalities	Municipalities responsible for public buildings need monitoring systems that protect building-level and user-level information while still enabling IAQ analysis across schools, kindergartens and offices.
EDIAQI pilot teams	Pilot teams should collect only necessary data, use secure data transmission, document access rules and ensure that sensitive location metadata are anonymised where needed.
EDIAQI technical partners	Technical partners should maintain end-to-end security across sensors, gateways, cloud platforms, APIs, dashboards and data-sharing services.
Researchers	Researchers need access to useful IAQ datasets, but these datasets should be prepared so that exact locations, organisations and people cannot be re-identified.

Privacy principles

Principle	Meaning for EDIAQI
Data minimisation	Collect only the data needed for the monitoring objective. Avoid unnecessary parameters, excessive time resolution and unnecessary monitoring locations.
Secure transmission and management	Use encryption, authentication and authorisation when data move between sensors, gateways, cloud systems, APIs and user interfaces.
Anonymisation	Remove or generalise information that could identify specific individuals, organisations, buildings, rooms or exact addresses.
Consent and transparency	Users should know what data are collected, why they are collected, how they are used, how long they are kept and who can access them.
Access control	Data access should be limited to authorised users and systems. Role-based access control should be used where appropriate.

IoT security layers

Layer	Security focus
Device level	Secure hardware, local communication, encrypted stored data where relevant, protection against unauthorised access, and secure firmware updates.
Gateway level	Secure upstream communication, protected management interfaces, secure credential storage, managed messaging and secure remote updates.
Cloud level	Secure cloud services, encrypted API and user access, authentication, authorisation, access logging, data backup and service continuity.
API and user-interface level	Secure HTTPS connections, token-based authentication, role-based access rights and restricted data access for external users or systems.
Shared data level	Anonymisation of identifying metadata before data are made available for research or wider analysis.

Recommendations

Collect only necessary IAQ data: Avoid collecting data that are not needed for the scientific or monitoring purpose.
Avoid unnecessary time resolution: Data should be frequent enough for analysis but not more detailed than needed.
Place sensors only where monitoring is justified: Sensor placement should follow the pilot objective and avoid unnecessary observation of spaces.
Encrypt data transmissions: Data should be protected between sensors, gateways, cloud platforms, APIs and user interfaces.
Use authentication and authorisation: Only authorised devices, users and systems should be able to send, receive or access data.
Keep software and firmware updated: Security updates are needed at device, gateway, server and cloud levels.
Protect cloud platforms and APIs: Cloud services should use established security practices, secure access control and encrypted communication.
Anonymise location metadata: Building names, room names, exact addresses, exact coordinates, owners and verbose descriptions should be anonymised where they could identify a person, organisation or building.
Preserve scientific usefulness: Do not anonymise sensor values in ways that make them unusable for research. Focus anonymisation on identifying metadata.
Be transparent with users: Users should understand what is collected, how it is used and how privacy is protected.
Continue end-to-end evaluation: Security should be evaluated throughout the project, especially where data move across systems and providers.

Limitations

This deliverable is Version 1 of the EDIAQI privacy and IoT security report. It provides an initial assessment and recommendations, but it does not represent the final security evaluation of all EDIAQI systems.

The report states that the current data security situation in EDIAQI is satisfactory after some improvements, but long-term data privacy cannot be guaranteed unless the recommendations are applied consistently. End-to-end data security and privacy still need continued evaluation.

The next report, D4.9, is expected to evaluate implemented improvements and address additional topics such as multi-factor authentication, API security, incident and intrusion detection, continuous monitoring, firewalls, security updates, backup and recovery, and possibly a small-scale cybersecurity exercise.

Related wiki pages

[+] View technical source and page metadata

Source deliverable

This one-pager is based on:

Deliverable: D4.6 – Privacy and IoT Security – Version 1
Work Package: WP4 – Pilots, data and campaigns
Lead / main contributing partner: THIN / Thinnect
Authors and contributors: LAS, WINGS, THIN
Original deliverable type: R – Document, report
Dissemination level: PU – Public
Official submission date: 31 May 2024
Actual submission date: 31 May 2024
Version: Final
Follow-up deliverable: D4.9 – next EDIAQI security report