The IoT Files: is a small OS good for security?

NOTE: I will update this article with images later.
One of the key aspects that should be addressed on IoT is the OS security.
Many people rules this fear out, when talking about IoT, telling that IoT require so small OS that security isn’t really a problem, or a minor issue.
It is a common idea that a smaller OS is less prone to security risks, and could not be more wrong. Security in IoT has in OS one of its Achilles’ heel, let me show why in a few point:

Nobody is perfect, developers are no perfect.

The first issue to e considered is that writing a code is prone to error because is a human activity, and we, human, make mistakes. If it is not a wakeup call the recent amount of vulnerability found in open sources code widely used (think of the SSL related Issues, or the encryption ones) I don’t know what else should convince you that there is no such thing as a secure code around.
If we look at statistics about cyber attacks we keep find in the first positions not holistic sophisticated attacks, but SQL injection ones, one of the oldest (and easiest to address) attack technique.

So the idea that can exist an IoT OS secure is doomed at the root, it does not take account of reality.

Since the importance of IoT we should carefully look at OS security features.

How Many IoT?

The first thing we should consider is that IoT is related to a multitude of devices, with a multitude of operations and sensors.

Now the market could address this in two way:

A multitude of different OSs
A few bunch of IoT OS that can load modules to be adapted to the various needs.

In the first case we should consider that an excessive number of OS would expand the attack surface: the more the easier someone makes mistakes.

Another risk related to a thousand different OS would be the compatibility between the different systems. In the absence of strong standards the risk of proprietary solution adoption is greater and so the risk of communication issues.

This is, indeed, also a security problem since where you can find so many version you can find so many vulnerabilities. On the other end vulnerability would affect a smaller number of targets. If this is a good or bad thing depend if you are or not the target.

A few bunches of IoT Oss would be easier to be managed, but at the same time they would be more “generalist” and therefore more complex and open to be cracked. Extensive use of library has been proved with the recent open sources security breaches, not to be invulnerable.

Moreover a vulnerability found could affect a larger number of devices.

Is an IoT OS really small?

One thing we should keeping in mind is that a IoT OS isn’t a one click software.

An IoT device has to perform a lot of complex tasks, even if running in a small memory space (compared to computers of course) and less powerful processors (may be).

Let’s name some constrains:

It has to deal with sensors, so needs drivers. And accordingly to the nature of the data collected by the sensors those drivers can be really complex.
It has to deal with commands, so it needs an interface to receive and understand commands, but this means also to be able to make authentication and authorization.
It has to offer a friendly User interface to allow configuration, since IoT should be used by normal people and not techie freak.
It has to deal with storage of potential sensitive data; therefore it needs to handle data accordingly. May be adding security levels as encryption and wipe data mechanisms.
It has to perform an output to the user and to other devices; therefore it has to handle different kind of communication.
It has to talk with other devices, so it needs to implement protocol stacks, and make somehow secure the communication (which is way more than simply protocol encryption)
It require to be update
…

Can all this considered small? Every of this point takes security implications.

Sensors my sensors

When we talk about sensors we start thinking about GPS or accelerometers, so common in our Smartphone’s. Those are good example but not the only ones. Temperature, altimeter, compass, pressure…..and so on

If we have GPS, Altimeter, pressure, time, temperature we can easily guess where you are with a great degree of precision.

But some sensors are able to do more: biometric is a classical area. Think of the new facial recognizing feature present in some devices. This technology is incredibly intrusive and delicate, and brings back many security and privacy concern.

Can it be useful? Yes great, when you play with your new Microsoft Surface Book it will amaze how good (and frightening) this technology is today.

But the same technology can track you on the streets; shops, from any security enable camera or internet camera….

We are talking about IoT, so means those technology will be widely used. So would be nice to have the fridge in your home that recognize you and offer you your preferred drink without you have to do anything. This is the IoT promise.

Tell me master

And would not be a good IoT environment if it would not have the ability to accept human language commands. But this means to be able to understand and process languages. Think as IoT as worlds of ears always listening to you to accept your order, but always listening all you say.

Sure at the beginning the interfaces will be not so fancy, may be just few words, but who knows the future. We have to consider what will be not what we have now; otherwise there will be no planning.

Other interface would be probably more common since most of the command will come from the IoT service provider and other devices, because in the IoT world a system need to communicate send and receive command.

Now commands are good things, but require understanding (at least):

Who is sending the command
Has the one sending the command the right to do so?
Which commands are allowed to this subject?
What channel is being used to send the command
Is this command allowed for this channel?
Is the requester allowed for this channel?
Can I provide the output though this channel?
…

Authentication is not as simple as it could seems, since we have to be sure that the requester identification is not prone to

Error
Hack

And authentication can be related to completely different sources and channels that require different approach.

A visual identification is different from a fingerprint one, or a voice one. As well as when we talk about machine to machine, certificates, addresses, protocols and other meanings are used.

And after authentication we should consider authorization, which is key since we work in a multi_connected environment. Not being able to separate correctly those two needs can expose the IoT OS to serious vulnerability.

Usability

No matter with whom or what the IoT device has to relate, sooner or later it will need a human interface (at least the most of them) and so the need of a User interface is another key aspect.

Configuration, command and outputs that need human touch need to be provided accordingly. UI design is not always considered a security issue, but indeed it is.

Think at the nowadays password interfaces.

Is it safe to show the password while you are writing it? In most of the cases t isn’t. So a lot of modern interface hide or make visible the password on demand.

But since the interface led also to error, how to handle password error is key. Now the rate of error and the interfaces are linked together, so if you have to digit a password in a small touch screen you will probably make more errors then in a big wide laptop keyboard. Using the same error metrics with a laptop or a Smartphone touch screen make no sense. A user interface is indeed embedded with security consideration.

Where I put my data?

Data are a delicate element. They have to be protected and managed.

From a developer point of view this is a nightmare, we have to protect the areas where we put data to be stored and as well we have to protect the data in the running memory.

Both need to be managed carefully, but this requires writing more code, using more processor time and running more cycles.

In IoT this is way more complex. If we just think about the storage of the data (without considering issues related to running memory or data transmission) this will require a certain amount of attention.

If we deal with sensitive data we should probably need to encrypt those data, and wipe the area when data are deleted. Both are necessary operation to give security.

Wipe data does not means to simply “delete” the data from storage, this operation usually means just to remove the pointers that signs physical data location, but means to operate at “physical and logical cluster” level to overwrite data in order to make them non readable anymore.

It is not just an IoT issues, virtualization technology and security breaches have already demonstrated that this is a requested security feature.

When I was younger (dinosaur age) I remember that due to a turbo pascal compiler defect, the records released from memory were not actually wiped so it was common to implement a routine to blank that memory space in order to make the release effective.

We are in the same order of need, when we move or delete a logical data we have to be sure the physical space has been wiped out accordingly or those data can be available.

If it is your fridge temperature may be you do not care (even if you should) but what if it is you facial or voice recognizing pattern data ….

The things become more complicated if we use an external device to store those data. We need to control data consistency somehow (hashing with elliptic encryption algorithm?) before during and after every call.

Just to name a few point of course.

But if data storage is a problem; what about data encryption? We knows that should be better to encrypt data, but this does not comes for free.

From a performance point of view the more you encrypt the more you have to work, this is clear. The stronger is the encryption the harder is the job.

But encryption comes with other issues: all the legal rumors done those days about FBIApple case is just an example, But since I am old I still remember the PGP affair. Encryption brings a lot of issues: who hold the key, which level of encryption is required, who can open the encrypted data, how the encrypted data should be managed by the OS (decrypt all data when running, decrypt just the live segment in use…) and so on.

Tell me again that IoT OS is a simple affair please.

To output or not to output?

A system that does do nothing, does not have users or interfaces and does not communicate is a good system form a security perspective.

Ok may be is useless but it minimize the attacking surface to the minimum (the best would be not to have the system at all, of course).

But since we keep insisting in IoT doing something we need to accept an IoT device and therefore its OS have o communicate outside providing outputs.

This is quite another complicated issue, since output are delicate things.

It is not only which kind of outputs are allowed for a specific interface and requester-receiver couple (problems that attain to the authentication and authorization stuffs mentioned before), but also how to be sure the output arrive safe at destination.

Mutual authentication, as an example, is a key issue, as well as authorization. But let us take as an example, our primary steps in the IoT, the smart meter example. Most of the controls nowadays are focusing on the not tampering the device (which is good) and the respect of technical specification (which is also good). But a few efforts are done in order to verify if the data sent are the data that arrive to destination.

Quality of data, here, is a big security issue and concern. A good IoT system should be able to provide and implement mechanisms that address, as an example, potential data injection. And this should be done at OS level, at least at some extent.

The unit transmitting the data should be responsible to its delivery till, at least, the first node of the path. This can be implemented in communication protocols or at higher levels, but have to be implemented somehow, somewhere.

The point is that IoT brings a lot of data, Big data. And big data are prone to be damaged by poor data quality because checking the error is way more difficult.

Try to find the wrong record into 10 or into 10 billion and tell me the difference.

How many languages you talk?

The previous notes make immediately clear that communication between devices is indeed a serious issues, and need a careful protocol design.

Some controls can be put on top of the protocol to serve specific issues, but the protocol should implement as much security as possible.

Theoretically this is something we all would like, but let us face the truth:

How many DNS systems have already implemented DNSSEC?
How much internet traffic is still in HTTP and not HTTPS?
How many use IPSec?
How much traffic is on IPv6 today (a more secure protocol than IPv4)
And with the implementation of IPv6 how many will systematically use IPsec embedded or possible rotating address function?

There is a big difference between the presence of a technology and its actual use.

A good security protocol implementation is a difficult affair because require larger data to be sent, more processor time to be processed.

But this is something that IoT have to deal with, the great quantity of sensitive and personal data that will flow on IoT infrastructure require a more careful approach then the naïve we seen till now.

I know it sound harsh but, did you know that Google implemented Site to site communication encryption (between data centers) only after Snowden revelation?

I talked before in “The IoT files” about protocol common issues, DNS is in my point of view one of the clearest example of how we have to seriously rethink our protocols approach.

Update this

Most of the features we talked are not specific for IoT, but IoT will bring them all in a smaller OS. All are strictly related, and fail to operate in one of them will demise security also for the other.

Another example is the Update systems.

It is out of doubt that patching and updating will be necessary even in the IoT world.

But as of now, update is prone to be a Single Point of Failure for quite all systems. Software distribution systems used nowadays are not invulnerable, and can be used as a vehicle of attack through a malicious software attack to obtain a total system compromise situation.

By “malicious software update,” I mean that someone tricks your device into installing an inauthentic version of some software which causes your device to do things you don’t want it to do.

A “targeted malicious software update” means that only the attacker’s intended target(s) will receive the update, which greatly decreases the likelihood of anyone ever noticing it. To perform a targeted malicious software update, an attacker needs two things:

to be in a position to supply the update and
to be able to convince the victim’s existing software that the malicious update is authentic.

Finally, by “total system compromise” I mean that the attacker obtains all of the authority held by the program they’re impersonating an update to. In the case of an operating system, this means that the attacker can subvert any application on that device and obtain any encryption keys or other unencrypted data that the application has access to.

A backdoored encryption system which allows attackers to decrypt arbitrary data that their targets have encrypted is a significantly different kind of capability than a backdoor which allows attackers to run arbitrary software on their targets’ computers.

From an attacker perspective, each capability has some advantages. The former allows for passively-collected encrypted communications and other surreptitiously obtained encrypted data to be decrypted.

The latter can only be used when the necessary conditions exist for an active attack to be executed, but when those conditions exist it allows for much more than mere access to already-obtained-but-encrypted data.

Any data on the device can be exfiltrated, including encryption keys and new data which can be collected from attached microphones, cameras, or other peripherals.

Many software projects have only begun attempting to verify the authenticity of their updates in recent years. But even among projects that have been trying to do it for decades, most still have single points of devastating failure.

In some systems there are a number of keys where if any one of them is compromised such an attack becomes possible. In other cases it might be that signatures from two or even three keys are necessary, but when those keys are all controlled by the same company (or perhaps even the same person) the system still has single points of failure.

The controversial “systemd” comes to an OS known for stability. This problem exists in almost every update system in wide use today

I hope that in the not-too-distant future, for many applications at least, attackers wishing to perform targeted malicious updates will be unable to do so without compromising a multitude of keys held by many people in many different legal jurisdictions. There are a number of promising projects which could help achieve that goal, including the DeDiS Cothority and the Docker project’s Notary.

Being free of single points of failure should be a basic requirement for any new software distribution mechanisms deployed today.

So I hardly think we can take security not so seriously in a light IoT device OS.

But are big OS worse?

Biggest multipurpose OS have, of course, a bigger surface area so are an easy target for attack, they need a serious hardening to be secures (which usually is not done at any level).

No matter if it is Linux, Unix, Mac OS or Windows they have all pro and Vs when talking about security but, generally speaking, a bigger OS need a bigger HW and so can rely on more complex security features.

Sometimes if the security can’t be provided it is used to wrap the code into smaller virtual container that can be protected. It can be implemented at Virtual machine level (think of docker implementation as an example, ok not strictly security related but fit somehow) but also at OS level.