The Role of Standards in IoT Security
•Download as PPTX, PDF•
1 like•256 views
Working on standards can be slow and tedious but there are also rewards: interoperability, open source implementations and high-quality specifications. Based on two examples of ongoing standardization efforts that aim to improve IoT security in the Internet Engineering Task Force (IETF), namely "Authentication and Authorization for Constrained Environments" (ACE) and "Software Updates for Internet of Things" (SUIT), Hannes explains the process and how to get involved.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to The Role of Standards in IoT Security
Similar to The Role of Standards in IoT Security (20)
Recently uploaded
Recently uploaded (20)
The Role of Standards in IoT Security
- 1. Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect The role of standards in IoT security Hannes Tschofenig Senior Principal Engineer Arm
- 2. 2Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Ace Suit
- 3. Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Why should you care about ACE or SUIT?
- 4. 4Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect What is the problem? ACE: Authentication and Authorization for Constrained Environments (ace) Use case: technician in industrial facility Core Idea Users Obtain Token1 +Token Configuration, Software update, .. 2 Industrial Equipment Devices ACL
- 5. 5Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Arm TechCon 2015: Early ACE Prototype (Door Lock)
- 6. 6Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Problem Statement, cont. SUIT: Software Updates for Internet of Things (suit) Core IdeaYouBike service down in Taiwan Software update destroys $286 million Japanese satellite DEFCON 26 IoT device hack Boot loader Slot 1 (active) Slot 2 (staging) Memory Layout Verify signature / Decrypt firmware 2 Update Server Over IP/non-IP Manifest + Firmware1 Bootfirmware 3
- 7. 7Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Technologies Building blocks ACE Constrained Application Protocol (CoAP) (and other IoT protocols) Web Authorization (OAuth) Concise Binary Object Representation (CBOR) CBOR Object Signing and Encryption (COSE) CBOR Web Token (CWT) Proof-of-Possession Tokens (PoP Tokens) SUIT Concise Binary Object Representation (CBOR) CBOR Object Signing and Encryption (COSE)
- 8. Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Why did this work got started?
- 9. 9Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect History ACE SUIT Various companies saw the same use cases and needed a solution for fine-grained access control. • Industrial control • Home automation • Asset tracking (such as container monitoring) Use cases published in RFC 7744 I co-chaired the working group and lots of solution approaches have been proposed. Firmware updates are simple. Right? Many companies create their own, proprietary solution. We worked on LwM2M on the transport of firmware images to IoT devices but wanted a standardized solution protect meta-data and firmware end-to-end. Helped form a working group and submitted our solution as input.
- 10. Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon Where are we now?
- 11. 11Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Status ACE SUIT Re-using OAuth emerged as a good idea and framework for use with constrained devices got developed. Specs are available for download. Main spec is here and “working group last call” has just been started. Interoperability testing has been started. We have developed a product called “Secure Device Access (SDA)” Still work in progress. Architecture and information model specifications are working group items. Manifest specification under discussion. Several hackathons held on this topic and a custom board built ;-)
- 12. 12Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Hackathons Rough consensus and running code IETF Hackathon in Montreal, July 2018 SUIT Hackathon in Berlin, June 2018
- 13. Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon How can I use the specs?
- 14. 14Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Using the specs ACE Code Lots of OAuth / OpenID Connect code available (for the server-side). Product quality server code with PoP token support also available (for JWT) Native App libraries also available (Android, IOS/MacOS, Windows). Code for complete ACE implementation • ACE-Java for Authorization Server, • ACE client, and • CMU implementation consisting of ACE Client, ACE-AS, ACE-RS, and library of components. SUIT Code CBOR libraries for embedded devices: • cn-CBOR • TinyCBOR • QCBOR COSE libraries for embedded devices: • LibCOSE • COSE-C Manifest generator Manifest parser Use it in context of LwM2M. Our device management client implements the LwM2M client side and connects to Pelion as well as other LwM2M device management servers, including Leshan.
- 15. Copyright © 2018 Arm TechCon, All rights reserved. #ArmTechCon How can I contribute?
- 16. 16Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Your input matters • Join the mailing lists (ACE and SUIT) • Review specifications and provide your feedback • Play with the code and make it better • Write drafts and suggest alternatives • Attend a hackathon / IETF meeting (in person or remote) • Check out our Secure Device Access solution. IETF 103 Bangkok IETF 103 starts Saturday 3 November and runs through Friday afternoon, 9 November Bangkok, Thailand
- 17. 17Copyright © 2018 Arm TechCon, All rights reserved. #MbedConnect Trademark and copyright statement The trademarks featured in this presentation are registered and/or unregistered trademarks of Arm (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners. Copyright © 2018 Thank You! 17
Editor's Notes
- My name is Hannes Tschofenig and I will speak about the role of standards in IoT security. Standards are important for Arm since we want interoperable solutions between different players in the ecosystem and want those players to develop the technical solutions together. I have been doing standards for almost 20 years now and have contributed to many of the Internet security protocols.
- To make this talk more specific I would like to focus on standardization activities in the IETF – the Internet Engineering Task Force. The IETF is known for the development of core Internet protocols, like IP, TCP, HTTP, TLS and so on. The work in the IETF (and also in many other standards developing organizations) is done in groups. I picked two groups dealing with IoT security, namely ACE and Oauth. These are just two examples but illustrate how standardization activities work and why you should consider participating.
- Let me explain you a bit about what the standards developed in these two groups are about. Why should you actually care?
- Let me start with the ACE working group. ACE, which standards for Authentication and Authorization for Constrained Environments, tries to solve a fairly simple problem. Take a look at the figure on the left where a technician is trying to configure industrial equipment locally without having to communicate via the Internet. These configuration steps may including retrieving settings, updating them or even installing new software on these devices. Clearly this is a security sensitive task, which has to be subject to access control. Along with access control comes the need to authenticate the person seeking access. On the left you see the technical realization the working group has chosen to use: In our scenario the tablet used by the technician would obtain a token from a backend server, potentially ahead of time. Since that server needs to authenticate the technician, and to determine access rights to various industrial appliances different information sources (shown as databases here) have to be available. Once the authorization decision has been made a token is generated and provided to the tablet of the technician. This token is then used when the technician accesses the industrial equipment. For some of you this pattern may be familiar from Oauth, which is widely used on the web and with smart phone apps.
- The industrial sector is obviously not the only use case for this type of communication model. In 2015 I presented an early ACE prototype that showcased a doorlock. It used Oauth, rather than the optimizations describe later. It does, however, illustrate the point of other use cases where this technology can be applied. (FYI: the picture shows an enterprise door lock system, which I can be controlled via Bluetooth Low Energy. I used a Nordic chip for BLE. Since that chip was quite limited it connected it using SPI to a application processor, which was played by a K64F.)
- The second group I would like to talk about is the SUIT working group, which defines a standard for software updates for IoT devices. Needless to say that software updates are quite important. Many IoT devices lack a software update mechanism entirely and others fail to provide a good security solution, as these examples show. When I attended DefCon this year I learned about an IoT device hack where IoT devices from a Chinese manufacturer had a software update solution (which is good) but unfortunately the update mechanism wasn’t properly secured, which allowed a whitehat hacker to compromise the devices. More dramatic is the case of devices that used a device management solution called TR69, which was implemented incorrectly in many devices. This lead to a compromise in millions of routers and other higher-end IoT devices like Internet-connected printers. So, how does the standardized solution work? Look at the memory layout of a typical microcontroller where a bootloader is responsible for selecting which firmware image to boot. The firmware images on the device are placed in different memory regions, or slots. When an update server makes a new firmware image available it needs to be conveyed to the IoT device. Along with the firmware image there is manifest which contains meta-data about the firmware image and an end-to-end security wrapper, which protects the firmware image against modifications and is optionally encrypted. A device receiving a firmware update would start to verify the received manifest and decrypt the firmware image. If verified correctly it would be activated as the current version and the bootloader would start it.
- Work in the IETF tends to make use of building blocks and here is the list of building blocks used in the ACE and the SUIT working group. Two building blocks are common between the two working groups, namely the binary encoding format CBOR, which is a more efficient way of encoding information than JSON (or XML). Along with it comes a security wrapper providing digital signatures, MACs and encryption functionality called COSE. The ACE work additionally borrows from Oauth. For efficient encoding of the tokens the CBOR Web Token standard is used. Those tokens are, for security reasons, linked with a key. This turns them into proof-of-possession tokens, which are conceptually similar to Kerberos tickets or certificates, just with a more modern encoding and extra functionality. Re-using building blocks helps to lower the implementation effort and for IoT devices this also results in reduced flash memory usage. These building blocks may also be useful in your development activities.
- Let us talk a bit about why this work got started, which is similar to how other activities happen.
- In the ACE case various companies saw the need to come up with fine-grained access control solutions. I talked about the industrial control solution and also the home automation solution. There are, however, many more documented in RFC 7744. I co-chaired the group in the foundational days where lots of different solutions were proposed. In the end, the Oauth-based approach explained earlier was selected as the way forward. The SUIT case is different and more recent. With the security problems in the IoT sector companies realized that there has to be some work on firmware updates. Previously companies just created their own, proprietary solutions. This is time consuming and there is obviously little code to re-use. We worked on the IoT device management solution LwM2M, which allows the transport of the firmware image from the update server to the device. We wanted an enhanced solution that also offers e2e security. After we helped to form the working group we submitted our solution to the group. Of course, discussions led to many changes, including changes to the encoding format. In the end, we will have a solution that addresses a wider range of use cases.
- Where are we with the work now? This is an important question since the stage of development determines whether results are already readily available or whether input can be provided. A big benefit of standardization work is that interested parties can actually contribute their ideas as well.
- In ACE we have been optimizing Oauth and the specification are already in a later stage of development. The specs are freely available, which is not true for all SDOs. The so-called working group last call has been started. Interoperability test events have also taken place already and we have released a product, called SDA. For SUIT the work is still at an earlier stage but the architecture and the information model has been worked out. The manifest specification is still in discussion. For hackathons one of my co-worker has developed a custom board, which allows us to implement various scenarios in a convenient manner. It supports multiple MCUs, has BLE/WiFi/NFC support, and comes with a secure element.
- In the IETF we implement code alongside the specification work. A group of IETF participants have participated in various hackathons, which we all won. As you can see, we are not just doing boring specification work but also have a lot of fun at these events. I bring some hardware along and we get stuff working in a short period of time.
- You may be wondering how you could make use of this work yourself?
- This slide lists lots of pointers to open source specifications. Open source and open standardization is complementary. But in the IETF open source is often part of the specification development and we have contributed also a number of open source implementations. In this list, for example, you can find pointers to the COSE implementation we realized as well as code for manifest generation. With our Mbed TLS open source code we have also made implementations for cryptographic libraries available that can be used on embedded devices. Click through the links to see what code help you advance your product development along.
- You may want to also contribute and there are various ways.
- Of course, you can join the standardization work itself. The discussion lists are open and everyone can join. You can download and review the specifications. The open source projects also welcome your input. If you want to push it even further you could contribute your ideas as specifications. Attend a hackathon and the next one will take place in the upcoming IETF meeting in Bangkok. You can also join from remote. Finally, I encourage you to check out our Secure Device Access / SDA solution, which is part of Arm Pelion.
- I hope to see you in some of the standardization groups. With that I would like to thank you for your attention.