Security Levels the IoT Device and Server Landscape




Best practices, standards and a diverse ecosystem are essential for embedded developers to mitigate threats such as stack overflows and software backdoors.

What are the best practices when designing for device through server IoT security systems? This question was put to the experts at ARM, including Marc Canel, Vice President, Security Technologies; Jeff Underhill, Director of Server Programs; and Joakim Bech, Technical Lead for Security Working Group at Linaro. What follows is a portion of those interviews. – JB


Blyler: Security for the Internet of Things (IoT) spans everything from end-point sensors to connected devices, aggregated gateways, and middleware – all the way to servers. How can embedded designers deal with all the inherent complexity?

joakim_bechBech: I think it’s impossible to get a detailed understanding in all areas. It is simply too much to handle. But luckily, you normally don’t have to focus on all IoT devices at the same time. Under normal conditions, the embedded designers work with a limited set of products in a specific area. The tricky part is when these devices develop their own communication that result in an un-tested area where you could potentially have both bugs and security flaws to an even greater extent than standard protocols. Therefore, if possible, it’s almost always better and preferable to adhere to a predefined standard, instead of inventing new protocols.

marc_canelCanel: There is no one IoT that covers everything. Instead, you have multiple IoT silos. Software developers design applications for specific silos, e.g., health care, wearable devices, entertainment, or industrial manufacturing. Each application works for the specific use case in one of those silos and it’s unlikely to have portability between the silos. Within each of those silos you will use different security models due to the different requirements of each market.

jeff_underhillUnderhill: The IoT represents an explosion in the number of end point devices and related data that will be exchanged between devices and servers. Many of these devices – like the Nest thermostat system – can reveal when device consumers are home or not, which has raised privacy and security concerns among all involved. Securing the system will be critical as the data spreads from the end devices through the home gateway (where the data is aggregated) to the network and up to the cloud. This data flow will add volume and diversity to the entire security challenges.


Blyler: Isn’t there a base level of security requirements applies to all silo’ed markets and across both devices and servers?

Canel: Yes. Typically, there are sets of key security functions that apply across the board, e.g., the secure boot architecture that runs on the operating systems (OSs). A second key function is device identification or knowing that the device you think you are talking to is really the right one. That is why ARM® has joined the Fast Online Identity (FIDO) alliance. We are propagating the FIDO architecture across all of our platforms and IoT markets to support the development of standards-based protocols to authenticate devices, applications and users across all markets.

Underhill: From the perspective of the server, you already have a hierarchy of privilege levels to run appropriate pieces of software. Further, each user, OS kernel, hypervisor and other secure execution spaces can be part of the TrustZone® technology. [Editor’s Note: For further reading, see the technical report on TEE and ARM’s Trust Zone. The TrustZone technology secures a wide array of client and server computing platforms, including handsets, tablets, wearable devices and enterprise systems.

Servers have a secure container mechanism that is untouchable by the open (untrusted) environment. Multiple secure mission critical functions can reside in that container space, e.g., server administration, controlling access to keys, and the bulk encryption of data and content. A key benefit of the TrustZone is the extension of security from the server down through lower end CPUs. The IoT will require more intelligence moving down the network to handle more preprocessing of data closer to the edge of the network.


Blyler: That’s a good segue into the next question: What are the best tools and practices (heuristics) when designing long-term secure IoT systems? What standards apply?

Bech: This is a huge area to cover. When designing long-term security you must take security into account at the beginning of a design. It’s much better to have security already in the early design than trying to squeeze it in later to an existing (non-secure) product. In Linaro –an open source community, we are endeavoring to follow industry standards. For example, in the open source Trusted Execution Environment (TEE), we have followed the standards created by GlobalPlatform (see Figure 1). Another important thing is that the security solutions you design today could be used for a very long time, meaning that must have some sense of what is coming in the future. It’s not good if you have to re-design a solution, just because hardware has become more powerful and therefore potentially could weaken the security, e.g., key sizes and such).

fig1
Figure 1. Trusted Execution Environment (TEE) is a secure area that resides in the main processor of a smart phone (or any mobile device) and ensures that sensitive data is stored, processed and protected in a trusted environment.

Canel: When it comes to coding techniques and practices, there really isn’t a standard. Each company and each developer have their own way of developing good code. For example, most advanced companies will ensure that there are good coding techniques around the management of stacks to avoid stack overflows and things like that.

That being said, code is developed by human beings who make mistakes. To protect mission critical data against individual mistakes you must have robust encryption technology within the devices and ensure that the data remains protected for a long time. We are doing work on cryptographic (“crypto”) engines – in either hardware or software – to ensure data security.

I don’t think that ARM will become a vendor of crypto technology because there is already an established ecosystem of such vendors. But we will come up with architecture recommendations so that the developers have a consistent level of crypto engine implementations within their products.


Blyler: How should hardware and software developers design security into their applications? Does ARM have a series of IP or tools to help the developer add security to their applications?

fig2
Figure 2. After some data fills the state, i.e., “hello” is the first command line argument. (Courtesy Wikipedia)

Bech: When working towards a long-term secure system, you should make use of all available test equipment. In addition to ensuring that the software APIs are behaving as they should, you must test to reduce your vulnerability to side channel attacks. A lot of security libraries have been shown to be vulnerable for timing attacks and power analysis attacks (Differential Power Analysis). Likewise, incorrect implementation and usage of cryptographic algorithms might also completely compromise a system, therefore it is also important to have audits where domain experts complete a thorough review of the complete solution.

Canel: There are various tools companies that have such products, for example, to prevent common security breech mechanisms like stack overflows (see Figure 2). [Editor’s Note: The stack overflows when a program attempts to use more space than is available on the call stack, e.g., when it attempts to access memory beyond the call stack’s set limit. This is essentially a buffer overflow. To learn more, see this reference: “How are Compilers detect stack overflows …”]

Underhill: On the server side, we look at best practices in a standardization approach so that our partners are presented with a standard software view to the OS, the hypervisors, etc. For example, we provide customers with a secure container space. OEM and end customers will have their specific use cases for these secure containers. We provide them with the secure building block to integrate throughout their products/solutions.


Blyler: Describe briefly overall trends in security, privacy and data collection/analysis technologies.

Bech: One trend we see at Linaro is toward open source security applications. In recent years, consumers and developers alike have heard about backdoors data breeches in both hardware and software, unauthorized data mining, sites losing complete databases containing credentials and such. This security awareness has led to people to request openness. People and companies want to have the possibility to look into the source code to make sure that it doesn’t contain backdoors and such. Secondly, we have also noticed the move away from pure software security solutions to also leveraging some hardware. It could be TrustZone in an ARM powered system or it could be a dedicated co-processor that runs part or all of the security solution. For example, companies today don’t completely trust the default OS as security flaws could make it possible to extract sensitive information. If a flaw makes it possible to gain root access, keys used for decryption could potentially be read out from the OS. Companies therefore instead prefer to manage sensitive assets in a secure environment that is protected with help from hardware.

Canel: From our point-of-view, the trend is toward using the Trust Zone ecosystem. This is especially true for connected devices that can upgrade themselves over the air. Another trend is using a secure boot system across all markets to assure the image of the code that is running on the devices is authenticated securely.

Over the next 2 to 4 years we will see innovative solutions to store keys securely at low cost within devices and make sure those keys are protected against side channel attacks. [Editor’s note: Side-Channel Attacks (SCAs) collects operational characteristics – execution time, power consumers, electromagnetic emanation – of the design to retrieve keys, learn how to insert faults or to gain other insights into the design. (Here’s an example of an ARM ecosystem vendor that deals with side-channel attacks – INVIA.)

Underhill: We are seeing the increased use of open source software on server systems. That trend is an important enabler to a new architecture entering the server space. Another trend is found in the changing boundaries of servers. Today’ servers have both a networking and a storage component. So having a partnership with providers of those other component areas is good. On the server side, ARM’s networking and storage partners like Applied Micro, AMD, Cavium, Broadcom, and others have announced server related plans. So the diversity we are seeing with the IoT and the exploding amount of devices is being paralleled by the increased diversity in the processing needs to handle that throughput on the network and also back in the data center.


Blyler: Thank you.


blyler_johnJohn Blyler covers today’s latest high-tech, R&D and even science fiction in blogs, magazine articles, books and videos. He is an experienced physicist, engineer, journalist, author and professor who continues to speak at major conferences and before the camera.

Jeff Underhill is the Director of Server Programs at ARM.

Joakim Bech is the Technical Lead for Security Working Group at Linaro.

Marc Canel is the Vice President of Security Technologies at ARM.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis