The IoT Files: The need for cryptography

One of the main arguments that should be touched by IoT discussion is cryptography. There is an undisputed consensus that cryptography is a mandatory requirement to preserve security and privacy in the IoT world, but we are far away for a general consensus on how to operate.

The need for cryptography in IoT comes from two main aspects:

Data security
Data privacy

The first need is clear; encryption is a mandatory requirement when we want to implement any form of authentication and non repudiation. Encryption is widely used even if we don’t know we are using it. PKI, sign in certificates are just some example.

Whenever we want to transmit something, encryption comes in hand to be sure what we transmit is not seen by 3rd party and not tampered.

Whenever we store something encryption comes handy when we need to preserve the access to those data, even at a local level.

Regarding Data privacy, it is a way more strong call for encryption, a wide use of it. As a system IoT allow a multitude of devices to exchange data that can become sensitive and private. Without a clear understanding of this point there can be misinterpretation. In IoT the amount of data and metadata will be way bigger than the already impressive amount of data we deliver on the wild nowadays. So basically a more cautious approach to data privacy will be needed and embedded into the very essence of IoT, therefore encryption will be a mandatory requirement.

But encryption is not an easy area, and I am not talking about implementation (which can e easily achieved) but for the need and use of this technology.

A little check on the actual status

Cryptography is not only a technical or business argument (cost vs performance vs security) but, mainly, a political issue.

The history of cryptography has been doomed by constant attempts to block, or control, the use of good secure cryptography tools in the civil environment. It is not a mystery nowadays we have a lot of discussion upon cryptography and backdoors (although the term “backdoors” is misleading and misused most of the time).

The USA has, as an example, a good and long history fighting against civil cryptographic tools both in the past, may be someone remember the PGP affair, and in nowadays events, think of apple case as a clear example.

Every time we lower the level of security for some reason, we have to expect sooner or later someone else will leverage and use it for purpose not intended by the regulator. Recent history is full of those examples; some of the actions performed against cryptographic tools are on the news every day. We tend to call them vulnerability (SSLTLS vulnerability like freak …) but let us be clear on what they actually are: the consequences of export grade restriction on cryptography.

There are a lot of laws and regulation related to the use, import and export of cryptography, here some examples:

This section gives a very brief description of the cryptographic policies in twelve countries. We emphasize that the laws and regulations are continuously changing, and the information given here is not necessarily complete or accurate. For example, export regulations in several countries are likely to change in the near future in accordance with the new U.S. policy. Moreover, some countries might have different policies for tangible and intangible products; intangible products are products that can be downloaded from the Internet. Please consult with export agencies or legal firms with multi-national experience in order to comply with all applicable regulations.

Australia

The Australian government has been criticized for its lack of coordination in establishing a policy concerning export, import, and domestic use of cryptographic products. Recent clarifications state that there are no restrictions on import and domestic use, but that export is controlled by the Department of Defense in accordance with the Wassenaar Arrangement.

Brazil

While there are no restrictions of any kind today, there are proposals for a new law requiring users to register their products. Brazil is not part of the Wassenaar Arrangement.

Canada

There are no restrictions on import and domestic use of encryption products in Canada today . The Canadian export policy is in accordance with the policies of countries such as United States, United Kingdom, and Australia in the sense that Canada’s Communications Security Establishment (CSE) cooperates with the corresponding authorities in the mentioned countries.

China

China is one of the countries with the strongest restrictions on cryptography; a license is required for export, import, or domestic use of any cryptography product. There are several restrictions on export regulations, and China is not participating in the Wassenaar Arrangement.

The European Union

The European Union strongly supports the legal use of cryptography and is at the forefront of counteracting restrictions on cryptography as well as key escrow and recovery schemes. While this policy is heavily encouraged by Germany, there are a variety of more restrictive policies among the other member states.

France

France used to have strong restrictions on import and domestic use of encryption products, but the most substantial restrictions were abolished in early 1999. Export regulations are pursuant to the Wassenaar Arrangement and controlled by Service Central de la Sécurité des Systèmes d’Information (SCSSI).

Germany

There are no restrictions on the import or use of any encryption software or hardware. Furthermore, the restrictions on export regulations were removed in June 1999.

Italy

While unhindered use of cryptography is supported by the Italian authorities, there have been proposals for cryptography controls. There are no import restrictions, but export is controlled in accordance with the Wassenaar Arrangement by the Ministry of Foreign Trade.

United Kingdom

The policy of United Kingdom is similar to that of Italy, but with even more outspoken proposals for new domestic cryptography controls. Export is controlled by the Department of Trade and Industry.

Israel

Domestic use, export, and import of cryptographic products are tightly controlled in Israel. There have been proposals for slight relaxations of the regulations, but only for cryptographic products used for authentication purposes.

Japan

There are no restrictions on the import or use of encryption products. Export is controlled in accordance with the Wassenaar Arrangement by the Security Export Control Division of the Ministry of International Trade and Industry.

Russia

The Russian policy is similar to the policies of China and Israel with licenses required for import and domestic use of encryption products. Unlike those countries, however, Russia is a participant of the Wassenaar Arrangement. Export of cryptographic products from Russia generally requires a license.

South Africa

There are no restrictions on the domestic use of cryptography, but import of cryptographic products requires a valid permit from the Armaments Control Division. Export is controlled by the Department of Defense Armaments Development and Protection. South Africa does not participate in the Wassenaar Arrangement.

In the table below, 75 countries have been divided into five categories according to their cryptographic policies as of 1999. Category 1 includes countries with a policy allowing for unrestricted use of cryptography, while category 5 consists of countries where cryptography is tightly controlled. The table and most other facts in this answer are collected from [EPIC99], which includes extensive lists of references. Countries with their names in italics are participants in the Wassenaar Arrangement .

1	Canada, Chile, Croatia, Cyprus, Dominica, Estonia, Germany, Iceland, Indonesia, Ireland, Kuwait, Kyrgyzstan, Latvia, Lebanon, Lithuania, Mexico, Morocco, Papua New Guinea, Philippines, Slovenia, Sri Lanka, Switzerland, Tanzania, Tonga, Uganda, United Arab Emirates.
2	Argentina, Armenia, Australia, Austria, Belgium, Brazil, Bulgaria, Czech Republic, Denmark, Finland, France, Greece,Hungary, Italy, Japan, Kenya, South Korea, Luxembourg, Netherlands, New Zeeland, Norway, Poland, Portugal, Romania, South Africa, Sweden, Taiwan, Turkey, Ukraine, Uruguay.
3	Hong Kong, Malaysia, Slovakia, Spain, United Kingdom, United States.
4	India, Israel, Saudi Arabia.
5	Belarus, China, Kazakhstan, Mongolia, Pakistan, Russia, Singapore, Tunisia, Venezuela, Vietnam.

NOTE: WHAT IS THE WASSENAAR ARRANGEMENT?

The Wassenaar Arrangement (WA) was founded in 1996 by a group of 33 countries including United States, Russia, Japan, Australia, and the members of the European Union. Its purpose is to control exports of conventional weapons and sensitive dual-use technology, which includes cryptographic products; “dual-use” means that a product can be used for both commercial and military purposes. The Wassenaar Arrangement controls do not apply to so-called intangible products, which include downloads from the Internet.

WA is the successor of the former Coordinating Committee on Multilateral Export Controls (COCOM), which placed export restrictions to communist countries. It should be emphasized that WA is not a treaty or a law; the WA Control lists are merely guidelines and recommendations, and each participating state may adjust its export policy through new regulations. Indeed, there are substantial differences between the export regulation policies of the participating countries.

As of the latest revision in December 1999, WA controls encryption and key management products where the security is based on one or several of the following:

A symmetric algorithm with a key size exceeding 56 bits.

Factorization of an integer of size exceeding 512 bits.

Computation of discrete logarithms in a multiplicative group of a field of size is excess of 512 bits.

Computation of discrete logarithms in a group that is not part of a field, where the size of the group exceeds 112 bits.

Other products, including products based on single-DES, are decontrolled. For more information on the Wassenaar Arrangement, see https://www.wassenaar.org/.

Why IoT needs cryptography and where?

IoT, as a general concept, refers to a multitude of object that can access to the Internet.

The need to access the internet is related to several aspects: need to exchange data, receive command, and export outputs…

Of course there are different needs and different grade of privacy and security required accordingly to the nature of the object we are talking about: it is not the same thing to talk about an infotainment car system, an autonomous driving system or a GPS, as well is different when we talk about a refrigerator or a SCADA controller in a nuclear plant.

But, no matter what the device is and its role, some assumptions are common to all IoT objects:

They have to deal with sensors
They have to deal with data
They have security and privacy implications
They have to store data
They have to transmit data
They have to received data

The first point is important in the encryption discussion because sensors can retrieve information that can give indication to an expert eye to a lot of things outside the realm of the IoT object.

Data are of course the main reason to implement encryption.

Security and privacy implication are the obvious case study for encryption.

The last three points are where encryption should, at least, be implemented.

One of the common mistakes related to IoT security consideration is to focus on a specific aspectdevice and not see the big picture.

Looking at a specific device is good for implementation, but not good to understand security and data privacy issues. What can seems trivial in an object assume a different role in a context, and IoT is all about context.

So the idea is that even if some data can seem harmful, they can assume a different value if merged with other data.

Cryptography role, in this context, is to prevent those data to be used for not authorized and not wanted activities. But cryptography is also one of the basic tools needed to allow data integrity and non repudiation.

Cryptography, of course, is not the panacea of very problem, but it is one of the tools to be used when we transmit and store data in order to preserve and save information.

Data transmission

When we have to transmit or receive data, no matter if commands, processed outputs or raw data, we should be confident that our data:

Comes from a trusted and authorized source
The data has not been manipulated during the transport (Data injections, data forgering…)
Data are protected by unauthorized access (data sniffing…)
The data are consistent with the requests

Encryption can play its role mainly in the second point, although encryption is also used for authentication and authorization aspects.

Encrypting a transmission allow the data to pass from a point A to a point B without third party can read it preventing exfiltration of data. And since the key provide a basic level of authentication a data encryption can provide also some defense against injections of unwanted data.

The downside of encryption is related to two aspects: solidity of the encryption and key exchange.

Those aspects are not trivial, a 40 symmetrical encryption key can be easily forced by modern computer systems (see as an example the “Bar mitzvah attack” on ssltls protocols), therefore a 40 bit encryption (see freak lesson) is a clear security hole.

On the other end even a longer encryption key is useless if the key is discovered.

Processor time and resources

The longer the key the more the encryption will take in terms of time and resources. Encryption chipset are, usually, the answer to solve this aspect, while they can do a little on key exchange.

The argumentation against a wide use of long keys in encryption (256 bit) are, in reality, more related to political or costs constrain than to technical ones. And even costs are just partially a problem, scaling the production would make those chips inexpensive.

Of course software encryption is a more economic (but, may be, less secure) way to address the question on IoT.

All the point is to understand how much we can invest in this IoT device in terms of resources.

Another point to take care of is the overload that encryption gives on network package. Usually a encryption protocol brings some overload to the transmission due to bigger packets (although the use of compression can reduce it) and the key exchange process which can require several exchanges.

The key exchange issue

The other issue is the key exchange. To make encryption (symmetrical or asymmetrical) you need to exchange the key with your partner in communication.

The key can be

Static
Dynamic

A static key is easy to be implemented and can be hardened in the solution. The problem with static keys is that they can be good for storage issues but not good for data transmission. Once the key has been discovered all the security has gone

Dynamic keys are a more secure solution, a lot of protocols rely on dynamic keys for data exchange, take as an example, SSLTLS yet implementation needs to be careful in order to avoid the same level of problem discovered on the aforementioned protocols.

One problem is related on how to create your key, a weak protocol can create some predictable keys that can be easily guessed, and this is one of the typical requests of export grade encryption.

Also rely on PKI infrastructure is not, per se, a secure solution. PKI keys can be stolen andor forged.

Data storage

Data should be preserved when we are transmitting but also when we store them

It seems trivial but data storage is not as simple as it seems in IoT. We can have different kinds of data: permanent, semi permanent and volatile.

Let us assume that volatile data are those used at the moment and then destroyed, we should focus on the permanent or semi permanent ones.

Again this is a generalization, and specific implementation can differs, but generally speaking permanent data stored needs, as first instance, a storage area.

This area can be local or remote (the cloud), accordingly to the data needs.

Apparently the more secure solution would be storing data locally in the device. This is a simplistic approach since the security of the data stored in a devices are strictly related on how secure is the access to the device, which is not clear.

If the device is not able to set up a proper authentication and authorization mechanism to internal resources (this is way a more extensive need than locking the door from outside visitors) data stored locally need to be protected from external intrusion.

Encryption is, of course, one of the technology sounds to be implemented. As for data transfer here we can name the same arguments for key length we discussed before. Another important aspect here is the ability, of the system, to wipe out physical data moved from the storage area in order to prevent sophisticated data exfiltration techniques.

Again the problem here is how to deal with the Key to encrypt and decrypt data. This is the scenario we saw on the Apple vs St. Bernardino’s FBI case to refer to current episodes.

What IoT need

For a security standpoint it is no doubt that a strong encryption approach should be necessary for IoT, there are no real justification, from a technical and economical point of views, against this implementation.

The problem comes from the political approach related to encryption. Encryption lives in a dual identity status as a civil technology and a military one. Recent geo political issues (cyber terrorism and terrorism) have fueled the discussion against encryption potentially harms future implementation with “backdoors” style design (insecurity by design).

Without a common agreement on encryption we can face 2 different scenarios:

One scenario sees a short key length implementation, with practically no security advance beside marketing statements.

Another scenario sees an IoT divided into regions where encryption is or not allowed, making for you not possible to go in specific countries because of the technology implemented in your cardiac stimulator (I assume you can leave your phone and watch at home using an allowed device).

Of course both are not what IoT is claimed to be.