EU GDPR: General Data Protection Regulation

The upcoming EU privacy regulation is relevant not only for European organizations but any business looking at Europe because of its extended scope of applicability.

The new European General Data Protection Regulation (GDPR) is expected to lead to a revolution in the privacy world. It will come into force by mid-2018, but time is short and there’s a lot of changes that must be implemented.

What It Is

GDPR entered into force on the 5th of May 2016, and European Union member states must transpose it into their national law by 6th of May 2018.
The Regulation updates and modernizes the principles enshrined in the 1995 Data Protection Directive to guarantee privacy rights.

It focuses on:

  • reinforcing individuals’ rights
  • strengthening the EU internal market
  • ensuring stronger enforcement of the rules
  • streamlining international transfers of personal data
  • setting global data protection standards

The changes will give people more control over their personal data and make it easier to access it. They are designed to make sure that people’s personal information is protected – no matter where it is sent, processed or stored – even outside the EU, as may often be the case on the internet.

Most importantly, it aims at changing the way organizations that operate in the EU or that collect personal data from the Union’s citizens, approach data privacy.

The people, business, organization or other bodies that collect and manage personal data are collectively called “data controllers“. They must all respect EU law when handling the data entrusted to them.

What It Means For Individuals

Mandatory Consent

  • People will have to receive the consent form in an easily accessible and intelligible form, containing the purpose of data processing.
  • They will have the right to withdraw their consent as easily as they gave it, this being particularly relevant for subjects who have given their consent as a child, or were not fully aware of the risks involved by processing.

The Right To Be Forgotten

  • People will also have “The right to be forgotten”, or data erasure, which means that the company processing and holding his data will be obliged to delete it all, including copies.
  • This obligation is extended to third parties that have access to that data.
  • To strengthen the right to be forgotten in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform the controllers which are processing such personal data to erase any links to, or copies or replications of those personal data. In doing so, that controller should take reasonable steps.

Protect Private Data

  • Data protection by design’ and ‘Data protection by default’ are now essential elements in EU data protection rules.
  • Data protection safeguards will be built into products and services from the earliest stage of development, and privacy-friendly default settings will be the norm – for example on social networks or mobile apps.
  • Citizens will have the right to be informed about a data breach that affected their personal data in maximum 72 hours from the data holder becoming aware of the breach.


  • Individuals will have the right to access information that contains a list specifying which data is being processed and the purpose of the data collection and management.
  • People will have the right to data portability, which means transmitting their personal data to another data controller.

What It Means For Companies

Harmonized Rules

  • There will be a single set of rules throughout the European Union, which will cut costs of doing business in the EU. They will only have to report to one supervisory body.
  • Companies whose main activity consist of processing data systematically obtained by monitoring data subjects at a large scale or special types of data or data related to criminal activity, will need to have in place a Data Protection Officer (DPO). The DPO will have to respect the internal record keeping requirements.
  • GDPR will have to be respected by both companies that originate from Europe, but, also those offering services to EU citizens.

User Data

  • Online identifiers including IP address, cookies and so forth will now be regarded as personal data if they can be (or are capable of being) without undue effort linked back to the data subject.
  • There is no distinction between personal data about individuals in their private, public or work roles – the person is the person.
  • Companies will have the legal obligation to inform users in the event of a data breach in maximum 72 hours from the moment they found out.
  • Data controllers will have to provide an electronic copy of all personal data free of charge, at request.
  • At the request of the users, companies must erase all their personal data, stop collecting it and have third parties delete it as well.
  • Also at citizens’ request, data must be transmitted to another entity, at users’ choice.

Security And Privacy By Design

  • Companies will have to design their systems with privacy in mind, rather than adding them. This mean that they must do all efforts to protect the privacy of their users.
  • Data controllers will hold and process data only if it is absolutely necessary for the completion of their duties.
  • Companies should implement techniques such as anonymisation (removing personally identifiable information where it is not needed), pseudonymization (replacing personally identifiable material with artificial identifiers), and encryption (encoding messages so only those authorized can read it) to protect personal data.
  • “Big data” analytics requires anonymised or pseudonymised data.

Substantial Fines

  • The maximum fines can go up to 4% of the company’s annual global turnover, or €20 Million, whichever is higher. These are applied in the cases when the data subjects’ rights have been infringed, such as the cases when data has been processed without a legal basis, or cross-border transfers have been performed.

  • Other infringement could attract fines of up to 2% of the annual worldwide turnover or €10 Million, whichever is greater. This is applied for example when companies cannot prove they have adequate security, haven’t appointed a DPO, or haven’t established a data processor agreement.

How To Prepare

  • Put in place an accountability framework that will prove you meet the required standards.
  • Design your product with security and privacy in mind, not add it later.
  • Establish clear policies and procedures in the event of a data breach, so you can notify people in time.
  • Verify your privacy policies and notices, so that it is easy to understand and accessible.
  • Be prepared for citizens to exercise their newly gained rights, often with unrealistic expectations.
  • If you are carrying out cross-border data transfers, including intra-group one, make sure you have a legitimate reason for transferring personal data to jurisdictions that don’t have adequate data protection regulations.

More Reading

Security Recommendations For IoT By BITAG

This is an extract of the excellent BITAG report “Internet of Things (IoT) Security and Privacy Recommendations”, published courtesy of BITAG, Broadband Internet Technical Advisory Group.

We highly recommend downloading and reading this report. And, even more importantly, to implement these recommendations, where the Apptimate platform can be a valuable part of your developer toolkit.

The full report can be found here.

BITAG believes the recommendations outlined in this report may help to dramatically improve the security and privacy of IoT devices and minimize the costs associated with collateral damage. In addition, unless the IoT device sector—the sector of the industry that manufactures and distributes these devices—improves device security and privacy, consumer backlash may impede the growth of the IoT marketplace and ultimately limit the promise that IoT holds.

BITAG recommended several security standards for IoT devices, including timely, automated software updates and password protection. The organization also said there should be more testing of customization options and an implementation of encryption best practices. BITAG also highly recommended allowing IoT devices to function if internet connectivity or the cloud fails, especially in the case of home alarm systems.

In the past few years, many devices now being connected to the Internet are not only personal computers but also a variety of devices embedded with Internet connectivity and functions. This class of devices has generally been described as the Internet of Things (IoT) and has brought with it new security and privacy risks.

Although consumers face general security and privacy threats as a result of any Internet-connected device, the nature of consumer IoT is unique because it can involve non-technical or uninterested consumers; challenging device discovery and inventory on consumer home networks as the number and variety of devices proliferate; negative effects on the Internet access service of both the consumer and others that run on shared network links; and effects on other Internet services when these devices are compromised by malware and become a platform for unwanted data traffic—such as spam and denial of service attacks—which can interfere with the provision of these other services. Importantly, the number and diversity of consumer IoT devices is growing rapidly, and these devices often function autonomously, without human intervention.

Several recent incidents have demonstrated that some devices do not abide by rudimentary privacy and security best practices. In some cases, devices have been compromised and allowed unauthorized users to perform Distributed Denial of Service (DDoS) attacks, perform surveillance and monitoring, gain unauthorized access or control, induce device or system failures, and disturb or harass authorized users or device owners.

Potential issues contributing to the lack of privacy and security best practices include: lack of IoT supply chain experience with security and privacy, lack of incentives to develop and deploy updates after the initial sale, lack of secure over-the-network software updates, devices with malware inserted during the manufacturing process, and more.


IoT Devices Should Ship With Reasonably Current Software

BITAG recommends that IoT devices should ship to customers or retail outlets with reasonably current software that does not contain severe, known vulnerabilities.

IoT Devices Should Have A Mechanism For Automated, Secure Software Updates

Software bugs should be minimized, but they are inevitable. Thus, it is critical for an IoT device to have a mechanism for automatic, secure software updates.  BITAG recommends that manufacturers of IoT devices or IoT service providers should, therefore, design their devices and systems based on the assumption that new bugs and vulnerabilities will be discovered over time. They should design systems and processes to ensure the automatic update of IoT device software, without requiring or expecting any type of user action or even user opt-in.

IoT Devices Should Use Strong Authentication By Default

BITAG recommends that IoT devices be secured by default (e.g. password protected) and not use common or easily guessable user names and passwords (e.g., “admin”, “password”).

IoT Device Configurations Should Be Tested And Hardened

Some IoT devices allow a user to customize the behavior of the device. BITAG recommends that manufacturers test the security of each device with a range of possible configurations, as opposed to simply the default configuration.

IoT Devices Should Follow Security & Cryptography Best Practices

Manufacturers should take care to avoid encryption methods, protocols, and key sizes with known weaknesses. Additional encryption best practices include:

  • Encrypt Configuration (Command & Control) Communications By Default
  • Secure Communications To and From IoT Controllers
  • Encrypt Local Storage of Sensitive Data
  • Authenticate Communications, Software Changes, and Requests for Data
  • Use Unique Credentials for Each Device
  • Use Credentials That Can Be Updated
  • Close Unnecessary Ports and Disable Unnecessary Services
  • Use Libraries That Are Actively Maintained and Supported

IoT Devices Should Communicate Securely

IoT Devices Should Be Restrictive Rather Than Permissive In Communicating

When possible, devices should not be reachable via inbound connections by default. IoT devices should not rely on the network firewall alone to restrict communication, as some communication between devices within the home may not traverse the firewall.

IoT Devices Should Continue To Function If Internet Connectivity Is Disrupted

BITAG recommends that an IoT device should be able to perform its primary function or functions (e.g., a light switch or a thermostat should continue to function with manual controls), even if it is not connected to the Internet because Internet connectivity may be disrupted due to causes ranging from accidental misconfiguration to intentional attack. IoT devices that have implications for user safety should continue to function under disconnected operation to protect the safety of consumers.

IoT Devices Should Continue To Function If The Cloud Back-End Fails

Many services that depend on or use a cloud back-end can continue to function, even if in a degraded or partially functional state, when connectivity to the cloud back-end is interrupted or the service itself fails.

Manufacturers should support an IoT device throughout the course of its lifespan, from design to the time when a device is retired, including transparency about the timespan over which they plan to provide continued support for a device, and what the consumer should expect from the device’s function at the end of the device’s lifespan.

More detailed recommendations can be found in the report here.

Object Security

This post is an adaptation from a blog post by HYKER Security Lead Joakim.


The Internet of Things (IoT) is coming.
With it comes new security challenges from the constrained and asynchronous nature of IoT.

IoT is a wide term used to describe anything from industrial control systems to smart homes. The devices are thought of ranging from powerful devices like Raspberry PIs to constrained NFC chips. Everybody has their own view. Much of the challenges associated with IoT devices springs from the nature of constrained nodes. These nodes, or devices, are constrained in the sense that they have low processing power, a small amount of RAM and often operate on battery power.


Channel Security

Channel security (“session”, “tunnel”, “VPN”) is a term used in communications security which describes a secure channel used by an application to transmit data. The channel is negotiated and managed by a protocol at the data, network or transport level in the protocol stack. The channel handles the data agnostically; it does not know anything about the payload.

Object Security

Object security is a term used in communications security describing secure communication with no need for a secure channel. Instead of relying on a communication protocol lower in the stack to handle the encryption, the application that created the message will handle encryption and decryption of its own communication.

The key difference between traditional channel security and object security is that in object security an application handles its own secure communication. This has the effect that when using object security an application does not need to trust a channel and the different relaying nodes between sender and receiver.

Consider the case of an email message. When it’s carried over an IPSEC or TLS secured connection, the message is protected during transmission. However, it is unprotected in the receiver’s mailbox, and in intermediate servers, hubs, etc., along the way.

By contrast, with object security, the entire message is encrypted and integrity protected until it is examined and decrypted by the recipient. It also provides strong authentication of the actual sender, as opposed to the machine the message came from.

HYKER Asynchronous Object Security implemented in the Payload Encryption Protocol (PEP) provides all necessary functionality, including encryption key distribution, for simple application development of full end-2-end security in just a few lines of code.

Characteristics Of IoT Networks

The characteristics of constrained devices call for a different set of solutions than the ones commonly used for non-constrained devices. The InfoSec community needs to explore how to provide information security on constrained devices communicating over insecure channels, i.e, how can message integrity, secrecy, replay protection, message freshness guarantee, and sequence ordering be provided for the Internet of Things.

There are some properties of constrained networks which have a significant impact on how communication works compared to how it works on traditional networks.

Firstly, communicating parties operating on battery power will naturally want to save battery. Therefore the network part of a constrained device will be turned off for as much time as possible. This means that the normal case will be asynchronous communication and because of this, caching nodes are the norm in IoT.

Second, when sending data on the network, you want to send as little data as possible. This is of course always a good thing but it is extra important for constrained nodes; power consumption from network hardware is very high compared to cryptographic operations. Another aspect of minimizing transmitted data is that large data packages will require larger buffers on the recipient node, something that might not be available on constrained nodes.

Sending large packages also increases the re-transmission amount. If a fragment of a large message is dropped by the network, or there is an error somewhere in a packet, all of the message might need to be re-transmitted instead of just a small part. Packet fragmentation can be a considerable source of network overhead.

The Situation, And What We Should Do About It

Traditional Methods

Secure communication for constrained nodes can certainly be achieved using traditional methods such as channel security. A popular channel security protocol for constrained devices is DTLS.
The security in these traditional protocols protects the channel, not the data itself, hence the name. Since many devices operate on battery power it is important to use as little resources as possible, both in terms of power consumption and memory/CPU usage. The consequences of this is very often seen in devices designed so that they sleep for as much time as possible.

The core problems with security in IoT is that Application traffic is asynchronous, which makes caching a requirement for a well-functioning network. To achieve this, caching proxies are often used.

Consequences of using traditional methods

Herein lies the core problem of this post. If a proxy is to be used for caching data, and channel security is used, the security can follow two patterns. Hop-by-hop or end-to-end security.

Hop-By-Hop Security

The first pattern, hop-by-hop security, visualized in Figure 1, is to terminate the channel security session in the caching node, effectively dividing the security into two parts. One part from the sender to the caching node and one part from the caching node to the receiver.

Figure 1: Hop-by-hop security

Doing this forces the data to be decrypted at the caching node; the caching node needs to re-encrypt the plaintext for the receiver. The data integrity and confidentiality will therefore not be end-to-end between the client and server, but hop-by-hop from client to proxy and from proxy to server.

Hop-by-hop security can only be relied on if all partners are trusted. This is not a good assumption for a secure and robust system. The possibility of malicious nodes opens up for both passive eavesdropping attacks and active attacks such as man-in-the-middle attacks on the communication. These kind of attacks are a very real threat and there have been countless examples of them. Hop-by-hop security is sometimes also referred to as point-to-point security.

End-To-End Security

The second pattern, end-to-end security, visualized in Figure 2, is to not terminate the session at the proxy but instead keep the channel security enabled through the proxy. This thwarts the possibility for the proxy to attack the session in a meaningful way since it prevents it from reading the data or changing it without detection.

Figure 2: End-to-end security

True end-to-end security is thereby obtained but important functionality is also lost. With channel security used for end-to-end encryption, it is all or nothing; all data originating from above the session layer has to be secured. The inability for a proxy to change or read anything from the transport layer and higher layers is not without negative consequences. A proxy often carries a lot of functionality on higher layers that are broken by end-to-end channel security. For example, a CoAP caching proxy can not cache any data for connections that tunnel through the proxy using channel security. CoAP is a protocol designed to work closely with proxies; the protocol will be crippled without the proxying functionality.

Advantages Of Transitioning To Object Security

When the end-to-end security is based on object security instead, the protocol can pick and choose what part of the data that should be confidential or integrity protected. For example, it would be possible to encrypt the payload, integrity protect static parts of the header and leave variable header parts be.

Protecting certain parts of the header can be very important. A malicious intermediate tampering with the header can do considerate damage. For example, an attacker could change the method code from GET to DELETE, thereby deleting a resource instead of fetching the current value. This is one reason for why encryption of just the payload of the CoAP message is not sufficient.
In conclusion, object security enables end-to-end security without preventing proxy operations, if done correctly.

Network Overhead

Another important aspect when comparing object security and channel security for constrained devices is the network overhead produced by the different technologies. The overhead in a session based security protocol is composed of both the handshake and the overhead that the protocol produces when encrypting and integrity protecting data.

In an object-based security protocol the encryption parameters can be pre-established, in which case the overhead consists solely of the overhead produced when encrypting and integrity protecting, no handshake takes place.


Using channel security protocols, such as DTLS, for constrained nodes is often not the best solution. Protocols based on object security can often be a much better fit.

One of the most popular IoT protocols targeting constrained devices is CoAP. There is now an ongoing development of an OSCoAP protocol for securing constrained devices. This is an end-to-end object security protocol which aims at reducing the overhead and complexity by adding object security as an option in CoAP packets.