Testing Internet of Toys Designs to Improve Privacy and Security

Abstract

Internet-connected toys (IoToys), embedded with microphones, cameras and other sensors, bring technology more than ever closer to children. This new generation of toys poses several questions, e.g. “What data can IoToys exchange? With whom? What are the possible threats?”, and raises concerns regarding the security and privacy of children. These issues are at the centre of this chapter. The authors describe the data flow of the IoToys architecture and highlight the threats that such architecture should tackle. They present the privacy and security test conditions under which different IoToys have been submitted. The results indicate that personal data are exposed, thus violating data confidentiality and consequently end-users’ privacy. The chapter concludes with recommendations to enhance the security and privacy of IoToys architecture.

Introduction

Internet-connected toys (IoToys), like any other Internet of Things (IoT) devices, contain embedded electronic and computing features, such as microphones, cameras, sensors of various kinds, that enable them to interact with users and adapt to their actions. By IoToys, we mean not only Internet-connected toys, but any Internet-connected device that interacts with children, such as puericulture and monitoring devices. They can record, store, analyse and share all sorts of data: sounds, images, movements, localities or even body parameters, depending on their configuration. IoToys can offer new, important opportunities to children for play, learning, health and educational support, to mention a few, thanks to their interactive and personalized features. However, they also raise questions about safety, security, privacy, trust and other fundamental rights of children. IoToys, as it is the case with any other connected devices, may gather personal information regarding our children’s lives, and then use and share those data.

In fact, IoToys, in contrast to their “traditional” counterparts, are able to communicate with other devices and services, e.g. mobile phones, proxies and entities¹ that collect data for management, data-sharing, data analysis and other activities depending on the service provided. As a consequence, these developments of IoToys not only increase the amount of data available to services and their value to business, but also raise new security and privacy issues, which can affect families’ and especially children’s privacy when interacting with such devices. Issues that neither users nor manufactures have faced previously.

In addition, an IoToy is a complex environment that unifies digital and physical worlds in a specific context and implies convergence of different types of technologies and services. This increases even more the possible ways that such an environment can be attacked. For example, most of the IoToys on today’s market have a corresponding mobile application that acts as a controller. So, the mobile application’s execution environment, or other communication services, could be used as an attack vector for an adversary (i.e. an entity that acts maliciously) to gain access to children’s private data, as already been demonstrated for a well-known IoToy (Cert.org, 2016).

In recent years, white hat hackers penetrated the data systems and networks of several organizations with the aim of exposing vulnerabilities and remediating them before they “can be taken advantage of by others” (Rouse, 2018), so far, news headlines that have reported security breaches, such as Mattel’s Hello Barbie (Gibbs, 2015), Genesis’ Cayla Doll (Moye, 2015), VTech Toys (Hunt, 2015; Sullivan, 2016) and Fisher-Price’s Smart Bear (Yadron, 2016), have, fortunately, originated from white hat hackers and found proper solutions or been removed from the market.

Until now, various research has studied security and privacy in the IoT, demonstrating different security and privacy issues (Geneiatakis et al., 2017; Ziegeldorf, Morchon, & Wehrle, 2015), while others (Chaudron et al., 2017) show that Internet-connected devices and objects pose challenges to ensuring the protection of children’s identities, rights, data, privacy and security. Nevertheless, to the best of our knowledge, the literature lacks research focusing on testing and challenging technically the designs of IoToys under a security and privacy perspective. To fill this gap, we set up a protocol to perform a security and privacy threat analysis of IoToys.

Our test protocol founds its inspiration in research work that proved to be efficient in testing Internet-connected objects in the context of a smart house scenario using products already available on the market (Geneiatakis et al., 2017). Our work brings together engineers and social scientists who take a closer look at each step of the journey of children’s data (recording, storing, analysing and sharing) through the analysis of several cases from technical and user-centred perspectives. The ultimate aim of our work is to identify key elements that need to be taken into account to ensure children’s rights, data, privacy and security while designing and using Internet-connected toys, as well as to provide concrete guidelines for protecting children’s privacy when using IoToys. Our contribution, in addition to a concrete threat analysis, is a practical feasibility evaluation of identified vulnerabilities showing how they can be exploited in practice.

The remaining of this chapter is structured as follows. After the introduction, in section “IoToys Data Flow” we overview a typical IoToys’ architecture with a focus on data flow, and in section “Threat Model” we analyse its threat model. In section “IoToys Security Analysis”, we study the realization of the threat model in test-bed architecture and analyse possible consequences to end-users in terms of security and privacy. In section “Discussion and Best Practice”, we suggest guidelines and protection measures to improve protection against threats. Finally, in section “Conclusions and Future Work”, we conclude this chapter and outline some directionsfor future work.

IoToys Data Flow

In this new IoToys era, users, especially children, can have (a) a two-way communication and (b) real-time interaction with toys. In such communication and interaction, data are exchanged in a bidirectional way between the user and IoToys, then between IoToys and a remote server. Remote content can be accessed by children while using their toys, which can either be interconnected directly to the Internet, e.g. via built-in Wi-Fi, or by assisting devices, e.g. mobile phones, that play a proxy role.

How are IoToys connected to the Internet? IoToys in order to function need Internet connectivity. Depending on the toy, they do not have to be necessarily always connected, but usually the Internet is essential for their proper functioning, especially during the initialization phase as they need to exchange data with a remote server. Since most IoToys lack a direct user interface, a mobile device, tablet or smartphone is most commonly used for set-up. Using a corresponding mobile app, the mobile phone connects with the toy via a wireless protocol, such as Wi-Fi or Bluetooth; then, the user sends the desired configuration directly to the toy when it is needed. Such configurations can be a password to access the house’s Wi-Fi connection, or personal preferences related to the IoToy, such as the child’s name, system language, notification settings, etc.

In some cases, the IoToy is not a stand-alone device but is rather accompanied by a hub. The hub acts as an intermediate interface between the IoToy and the Internet to facilitate their interconnection. This usually happens with IoToys, and many IoT devices in general, that have a small computational or network capacity but are unable to perform in a stand-alone mode. In such cases, the hub is the device with which the mobile phone connects to and which then handles communication with the IoToy. For the end-user, the use of a hub is completely “hidden” and makes no difference for controlling IoToys as it is achieved via the use of a mobile device.

Most IoToys, apart from being accessible by a mobile device that shares the same network, e.g. when connected to the same Wi-Fi, can also be accessed from outside their home network via the Internet. This is achieved through a dedicated server that provides such functionality. The server is connected to the IoToy, and the mobile phone accesses the server in order to get updates and send commands to the toy whenever they are needed. The data flow of IoToys in a typical smart home environment is illustrated in Fig. 11.1 and can be described as follow:

Fig. 11.1

IoToys data flow

• A. The user interacts with the IoToy. He/she provides inputs to the IoToy which transforms them into sharable data.

• B. IoToy sends and receives data from a remote server via the Internet. The router is the junction between the household Wi-Fi and the cabled network.

• C. IoToy communicates with a smartphone via a wireless protocol. The smartphone acts as an interface/controller for the IoToy.

• D. The smartphone connects to the Internet via a router.

• E. Data flow between router and remote server.

• F. Any device used by a remote user—providing the right credentials, i.e. passwords and user name, e.g. parents—that connects to the server and exchanges data directly, including data originated by IoToys.

During normal IoToys operation, the devices are neither constantly connected to the Internet nor constantly exchanging data. This of course varies from device to device, but the general principle is that communication happens only when needed. For example, a monitoring camera may broadcast live video only when it detects motion in a room, a toy may download new content only when it is not being used. Moreover, it may be the case that communication does not always occur via the Internet, it can also happen locally through a local area network. For example, when the mobile device is in the proximity of home, it can communicate with the IoToy without the need to contact the server.

Threat Model

What types of adversaries can we expect? In general, similar to any other interconnected system, a threat model in the context of IoToys should take into consideration two types of adversaries: external and internal entities that act maliciously in either a passive or/and an active way. External adversaries are entities located outside the system, meaning that they do not have direct access to IoToys, so they have to find a way to get through to the server. Internal adversaries are entities that may have the same level of access as any other legitimate entity of the system. For instance, consider a user that has an IoToy and would like to identify all other users of the same IoToy. Compared to the external adversary, the internal one has the advantage of already accessing the system, e.g. by having a legitimate account with a username and password, allowing interaction with the services the toy offers.

What types of attacks can we expect? The way adversaries interact with the system passively or actively depends on their final goal. An adversary who acts passively is able to eavesdrop on underlying communication in order to monitor children’s activities or gather information about how the IoToy works, which could be used in a later step, for a more sophisticated and active attack. To do so, an adversary will try to monitor communication at points (B), (C), (D), (E) and (F) of Fig. 11.1, to intercept data collected during interactions between user and IoToy (A).

An adversary is active when instead of passively monitoring the underlying communication, he interacts with the different components of IoToys architecture, i.e. IoToys, mobile devices and supported services (e.g. Web access), in order to gain access to otherwise private information. For instance, an active adversary could try to identify the different components that comprise the IoToys architecture in order to launch an attack at a future time by generating appropriate requests towards different elements.

Furthermore, an active attacker could try to impersonate a user (child) in order to gain access to IoToys-related data. The types of information that can be accessed depend on the types of services provided. For example, the adversary might be capable of understanding the status of the toy, if it is online or not, or from which exact mobile phone the IoToy is accessed. An active adversary is, therefore, not only capable of violating service-data confidentiality but also users’ privacy, as well as affecting the integrity of data when a malicious user tries to insert or delete legitimate users’ data.

Ultimately, an adversary might try to affect IoToys’ availability by causing a denial of service against any of the components of an IoToy’s architecture.

IoToys Security Analysis

To study whether the different types of adversary, internal and external ones, described in the previous section can be a real threat to IoToys, we deployed a dedicated test-bed architecture similar to the one illustrated in Fig. 11.1. For our test scenarios, we relied on commercial IoToys. However, as our object is to identify IoToys’ robustness against cyber threats and not to criticize specific products and implementations, we do not, therefore, provide here any specific information about the products under test. We have, nonetheless, contacted IoToys companies for which the tests found security-related issues and have informed them of our findings. The contacted companies reacted rapidly, reviewed our findings and quickly implemented measures to overcome the issues raised. The minimization of personal data collection was among our counterstrategies.

In our analysis, we considered scenarios for both types of adversaries, external or internal. We considered external attacks that can only monitor underlying network communication by accessing one of the points (E) and (F) of IoToys architecture. We then considered attacks by an internal adversary who is assumed to be a “powerful” adversary, which not only has in his/her possession a legitimate entity that can interact with the provided service (e.g. by using his/her credentials), but also can monitor the underlying traffic at points (B), (C) and (D). In this way, we are able to simulate how a legitimate entity might try to behave maliciously.

How did we conduct the test? As the details of internal mechanisms and processes for the different IoToys that we used in our test campaign were not known, we deployed different scenarios for the IoToys in order to trigger all the functionalities that they support, and to understand the different protocols they employ for their interactions with Internet-based services. While doing so, our testing adversary was able to capture all underlying communications, clear or encrypted, between the IoToys and the Internet, at points (B), (C), (D), (E) and (F) in Fig. 11.1.

In order to capture the traffic that the tested IoToys generate, we set up our own infrastructure in the following way. We used a computer with a network card that provides hotspot functionalities, i.e. allowing other devices to connect to it over Wi-Fi and gain Internet access. As a result, the computer is able to connect to our router and have Internet access, while at the same time it serves as an access point for other devices. On the computer we ran Wireshark,² an open-source tool for capturing network traffic. Once the hotspot was operational, we connected the IoToys to it and started capturing the traffic generated while we were testing the IoToys in different scenarios.

Thanks to this set-up, we could identify if the IoToys exchanged some types of information with a remote service, which was the case for all the IoToys we used. Furthermore, the set-up was able to capture this exchange of information. By analysing the underlying traffic, an adversary can deduce the different types of protocols used by IoToys, as well as whether the IoToys exchange some types of information with their servers. This is an important step for our tests, as we seek to determine if and how IoToys communicate with their servers and what type of data should be analysed. Depending on the provided service, our analysis showed that the following communications ways were used for data exchange:

• a. HTTP;

• b. HTTPS;

• c. WebSockets.

HTTP (Reschke & Fielding, 2014) is a well-known protocol used for data exchange on the World Wide Web (WWW). It exchanges plaintext, while its counterpart HTTPS (Rescorla, 2000) is a similar protocol that functions over a secure connection and exchanges encrypted data. HTTP runs over a TCP connection that is unencrypted, whereas for HTTPS the underlying communication is capable of providing security services such as confidentiality and message integrity through a Secure Socket Layer (SSL) (Freier, Karlton, & Kocher, 2011) or Transport Layer Security (TLS) (Dierks, 2008).

So, an adversary that is capable of capturing HTTP messages can directly read them as real and clear data are provided in HTTP requests and responses. This is why, in most cases of the tested IoToys, HTTPS was used. However, even if the communication is completely secure, IoToys might send personal data without users’ consent either to the provided service or to other third-party services. To identify if this was in fact the case, we executed a specific attack on the underlying secure communications, called a Man-in-the-Middle attack (MitM), which enables an intermediate to impersonate a server under specific conditions, and consequently read the encrypted data exchanged between the IoToy and the provided service. A general overview of this type of attack is illustrated in Fig. 11.2. A detailed analysis of the different types of attacks that can be launched against secure connection is beyond the scope of this work but can be found in Benítez-Mejía, Zacatenco-Santos, Toscano-Medina, and Sánchez-Pérez (2017), Zhang et al. (2014), and Onwuzurike and De Cristofaro (2015).

Fig. 11.2

An example of a Man-in-the-Middle attack for capturing/extracting encrypted traffic

To perform the MitM attack, we used the community edition of Burp³ suite, a free powerful network tool that, among others, can perform a MitM attack. As IoToys are controlled by their corresponding mobile applications, our main target was to capture the traffic that the mobile phone was generating. We thus set up Burp by using the Proxy mode it supports. The computer on which Burp was running was connected to the same Wi-Fi network as the targeted mobile device. On the mobile device, we manually changed the Wi-Fi settings and added the computer on which Burp was running as a proxy. In this way, all traffic from the phone was redirected through the computer before reaching the Internet. The final step was to install Burp’s certificate on the mobile phone in order to have it recognized as a trusted entity and thus be trusted by any traffic and certificates that were signed by it. What actually happened in the background is that Burp intervened automatically when an encrypted connection was established. It caught all the data transmitted between the IoToy and the IoToy’s server without them realizing their traffic had been intercepted. By using Burp and by performing a MitM attack, we were able to read encrypted messages that were exchanged between the IoToys and their servers and thus could see if any personal and sensitive data were exchanged without the user being aware of it, without confronting them with the licence agreementof the product.

What are the key issues? First, in our test-bed architecture, we could get access to data exchanged over both insecure and secure connections. Particularly, we identified that over secure connections IoToys send various personal data to IoToys servers. Some of our most interesting findings include identifying data that were sent to IoToys servers, such as the following:

• Personal information, such as children’s dates of birth, names, etc.;

• Unique identifiers, e.g. product hardware address, mobile device model, operating system, time zone of the user, etc., which can be used for distinguishing products and consequently users;

• Users’ preferences, e.g. names given to IoToys by end-users;

• Information related to the status of an IoToy, e.g. if it is online or not.

Second, we found out that IoToys do not only send such information to their corresponding servers, as expected, but may also send it to third-party services. Even more, we observed cases where the data are not directly sent to the third party, but instead the third party is given special access to the IoToy’s server in order to fetch users’ data. This type of data flow is illustrated in Fig. 11.3.

Fig. 11.3

Vulnerable points, in dark grey, of IoToys architecture, as identified by using our test protocol

Another important finding is the fact that some IoToys do not only rely on the HTTP Basic Authorization scheme, which is vulnerable to eavesdropping and replay attacks, but they also use the same generic usernames and passwords for all their products. What we found in this case is that the username and password that are needed for user registration are coded in the corresponding mobile application. This means that all users who have downloaded the mobile application are registered on the website with the same credentials. With these credentials, it is possible to query the server and then, depending on which user ID you specify in your request, the server responds with related user information. For example, if we assume that the IoToy was contacting the server https://www.iotoy.com/getIoToy?userID=123456, an adversary could simply create a script whereby the user ID changes after every loop in order to gather information about all the users of the same product worldwide. Since the authentication is the same for all users, the adversary would be authorized to send all those requests and receive corresponding responses.

Finally, our last category of findings relates to the use of WebSockets (Fette, 2011). WebSockets is an alternative option for communication that is employed to enable data transfer in cases where a real-time response is required (i.e. video services to mobile devices). The main discovery of our analysis is the fact that IoToys exchange personal data related to the provided service in clear text, i.e. it is not encrypted. This means that any adversary can capture the underlying communication and get access to personal data. For instance, in one of the cases we experimented with, an IoToy captures video and sends it back to a parent’s mobile phone. In that case, we were able to demonstrate that any intermediate node between the IoToy and the mobile phone can get access to the broadcast video, without having direct access to the webcam.

Figure 11.3 overviews the different vulnerable points where an attacker could extract information according to our analysis on the basis of our test-bed architecture.

Discussion and Best Practice

IoToys can play an important role in children’s development as they provide enhanced interaction and personalized experiences, elements that their predecessors are not able to support. However, their connection to the Internet could make them vulnerable to well-known threats. As IoToys comprise different components, adversaries might try to compromise any or all of them in order to get access to otherwise personal data.

According to our analysis, we identified that IoToys rely on well-known Internet-based protocols, such as HTTP, HTTPS and WebSocket, to provide interaction between a toy and a child. IoToys deploy mainly HTTPS, instead of insecure HTTP, when (personal) data need to be exchanged on the server side, but not always. Some tested devices only use HTTP and therefore exchange clear and readable data and do not offer any additional protection to the data in case of interception. Similarly, when IoToys rely on WebSockets, data can also be sent in clear text, as demonstrated by our analysis. Furthermore, for user authentication, some devices rely on the username and password approach. In some cases, they use schemes such as basic authentication in which the username and password are in reality sent in clear text. So an attacker can impersonate a legitimate entity and get access to his/her personal data. Even worse, we identified that there are cases where some elements of IoToys use the exact same username and password for every available product IoToys and rely on unique identifiers to filter the provided data. This means that a malicious internal user can get access to any and all legitimate users’ data if he/she generates the appropriate request.

So, an important question that users and IoToys manufacturers should answer is: “What measures can or should be taken in order to enhance data protection for IoToys and eliminate data leakages?”

First of all, IoToy companies should introduce a data minimization approach, meaning that only those data necessary to implement the service should be provided by users. Second, users should be explicitly informed in a transparent way about the types of data that are exchanged between the IoToy and the server, and also if the IoToy server exchanges any of those data with third-party services. In order to enable such data flows, users should give their consent, otherwise the data should not be sent over the network, without affecting IoToys’ functionality at all. For instance, users should have the option, if they wish, to share specific data with third parties. Such an option is available through a mobile app that manages the IoToy.

So, in case (personal) data are required for the proper functionality of the IoToy, then the underlying network communication should be sufficiently secured. In this view, a good option is the use of SSL; however, IoToy companies should recognize that SSL can be vulnerable to MitM attacks and thus only specific types of data should be exchanged over it. For instance, it is not advisable to send any authentication data in clear text over SSL. This means that the use of mechanisms like HTTP Basic authentication should be replaced by other more robust solutions. For instance, an alternative more robust solution is the use of HTTP Digest (Fielding & Reschke, 2014) as it relies on a challenge-response protocol in which users’ credentials are exchanged in encrypted form.

Finally, IoToys should not use a predefined username and password in order to get access to the provided service. Instead, they should introduce an approach whereby users provide appropriate credentials. This is because, in the recent past, predefined passwords in IoT systems have been exploited by attackers in order to launch distributed attacks (Akamai, 2017) against other resources of the Internet.

Conclusions and Future Work

In the IoToys era, children and/or other actors, e.g. parents, can interact with toys physically or remotely based on their input, thanks to the technological developments of IoT and the enhancements to wireless network communications. Such interactions are technically supported by well-established protocols and mechanisms that have been successfully used on the Internet and rely on heterogeneous network architectures. Besides the advantages that an Internet-based service has, it may also open the door to various vulnerabilities that can be taken advantage of and turned into attacks. Consequently, like any Internet-connected device, IoToys cannot be excluded from this rule. Until now, it is questionable if IoToys exchange non-authorized personal data with related servers or third-party services. To answer this question, an IoToy test-bed architecture was deployed and different IoToys were tested in specific-use cases. It is important to highlight that the test bed that was set up did not require any special equipment or expensive software. On the contrary, all the software used was free and easily found on the Internet. Even more, the hardware was normal devices that anyone can find in a retail IT store.

Our analysis identifies that (1) IoToys exchange personal data with related servers and third-party services and (2) they may also provide “opportunities” for malicious actors to gain access to end-users’ personal data. The latter is either because IoToys exchange data in clear text or they use a predefined username and password which assumes that the deployment of a secure network connection is sufficient for the provided service. In the current analysis, the focus was mainly on protocols and network interfaces that an attacker might try exploit to gain access to personal data.

However, an important element that has not been considered in this work is the mobile applications used for managing IoToys. Thus, there is a need for further study focusing on the vulnerabilities and threats that mobile applications might introduce to IoToys. Finally, we can also foresee a need to extend our scheme to support a completely automated approach for testing the security of IoToys against well-defined specifications in the form of an IoToys security certification programme. Such complementary studies should be able to build on our analysis and help to identify new threats to data security and privacy and ways to mitigate them.

Notes

• 1. Entities could be persons, informal groups like hacktivists or formal groups like service providers, institutions, etc.

• 2. https://www.wireshark.org/.

• 3. https://portswigger.net/burp.