|Android Things 1.0 Released - Too Secure To Be Successful?|
|Written by Harry Fairhead|
|Thursday, 10 May 2018|
Whoever gets to control a large chunk of the IoT market will get a lot of power and presumably profit. Android Things 1.0 is Google's offering and it emphasizes security. But is it possible to have too much of a good thing?
Linux is the main OS for large IoT modules and even when it appears to be some other OS it is often Linux underneath. What we all know is that IoT devices aren't secure. The Things team has made security a main concern, but it might be missing some of the point when it comes to IoT devices.
Things is a cut down version of Android. You can use Android UI components, but only if the IoT device has a display, keyboard and/or mouse. To make it more suitable for the IoT, you also get a set of APIs to allow you to interact with the outside world. As long as the sort of outside world device you are planning to use is a high-level one, e.g. I2C, SPI or UART, then there should be no problem.
The problems start when you want to use the GPIO lines in raw mode. This is very slow and it more or less precludes writing any custom interfaces such as 1-wire or a custom serial protocols. It is even so slow that if you want to flash a number of LEDs you might find Things isn't up to it.
The reason for this is that the Things team refuses to allow user programs direct access to a memory-mapped peripherals. Instead everything has to go though SYSFS which is simple and reasonably safe, but hundreds of times slower than direct memory access.
Of course, it is obvious that for security reasons IoT programs should not be given the ability to access a memory map of the peripheral registers. However, this is only a security risk in an environment where new programs can be installed. As long as the IoT device is restricted to run just the program you wrote for it, there is no danger in accessing memory. In fact, given the discovery of the Meltdown and Spectre vulnerabilities, a program doesn't need memory-mapped access to read the system memory.
For an IoT device, what is needed is edge security, not restrictions on the IoT code, which has to have full access to the hardware to get its job done.
I tried to explain this to the Android Things team in a bug report, but I got the impression that they were all so security conscious that it was an unthinkable proposition.
So what all of this means is that if you want to use Android Things you have to make sure that it is fast enough to work with the devices you have in mind. Notice that going from Java to C provides only a minor improvement and it isn't a solution. The big problem is the use of SYSFS, which is slow in any language.
To emphasise security even more, the devices that Things run on are split into production and development. The production modules all have security facilities - key and ID attestation and verified boot. This allows secure OTA software updates. Google promises that security updates will be available for at least 3 years, which isn't anywhere near long enough in my opinion.
The production boards are:
The development boards are the NXP Pico and the Raspberry Pi 3 Model B. I wonder how many devices will end up using the Raspberry Pi in production because of cost/performance issues and so throwing away much of the work that has been done on security.
The Android Things Console, which controls the software updates, is limited to 100 active devices for non-commercial use. At the moment there is no mention of pricing, but after 100 and for commercial use you need to sign a distribution agreement. I'm not sure I want to hand the keys to my devices over to Google quite so quickly. Given the way Google has never been slow to pull the plug on any project that doesn't fit in with its plans, I would worry that Android Things is a little bit too locked down to pass as open source, even if it was open source - and it isn't.
The IoT isn't secure, but the way Android Things goes about the security problem isn't the right way. IoT programs need to run without restriction and the security we need is at the edge of the operating system. Restricting external interactions to data only seems like a better idea.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 10 May 2018 )|