SexTech: Characteristics of Smart Sex Toys (ESET White Paper)

Did you know that sex toys could be connected to the Internet, to a smartphone or to another sex toy? Along with the technology that makes sex toys smart, vulnerabilities are introduced that could endanger the user’s data, privacy and even safety!

Architecture of a smart sex toy.

Architecture of a smart sex toy.

With the emergence of the IoT, many manufacturers have entered the sexual pleasure market by integrating the ability to control devices through mobile apps as well as adding web-based interconnectivity.

There are currently numerous different apps available, each of which offers the ability to control a wide range of models.

In terms of their architecture, most of these devices can be controlled via Bluetooth Low Energy (BLE) from an app installed on a smartphone.

The main advantages of this protocol are that it has very low power requirements, communications are within an acceptable range, there is interoperability among chipset manufacturers, and it all comes in a very compact size.

As a result, a lot of smart devices for the home, health, car, and even sex toy fields, use BLE between the device and the app that controls it.

Like Bluetooth, BLE operates on the 2.4 GHz ISM band.

However, unlike standard Bluetooth, BLE stays in sleep mode all the time, except when a connection is initiated.

Also, the actual connection times themselves are just a few milliseconds, unlike Bluetooth, which takes more than 100 milliseconds.

On BLE networks, devices are classed as either central or peripheral.

Central devices (smartphones, computers, etc.) have more processing capacity and are responsible for controlling peripheral devices.

Generally, central devices run software created specifically for interacting with these peripheral devices.

Peripheral devices act as sensors, which collect data and send the data to the central devices to be processed.

This is key to BLE peripherals’ low power use; they don’t process data—they only collect and transmit it.

The app is responsible for setting any options on the device and controlling the user’s authentication process.

To do so, it typically connects to a server in the cloud, which stores the person’s account information.

In some cases, the app also acts as an intermediary between various users seeking to use features like chat, videoconferencing, file transfers, or if device owners want to give control of their devices to remote users.

This architecture presents several weak spots that could be used to compromise the security of the data being processed: Intercepting the local communication between the controlling app and the device, between the app and the cloud, between the remote phone and the cloud, or directly attacking the cloud-based service.

Of course, not all attacks take place over network connections, and some malicious scenarios could be launched using malware previously installed on the phone or by exploiting bugs in the phone’s operating system.

The white paper looks only at vulnerabilities present in the app itself.

Tags: , , , , , , , ,

Leave a Reply