
Michael Richardson is now on the 14th iteration of an Internet Research Task Force (IRTF) draft in the ‘thing to thing’ or t2trg research group. It’s called ‘A Taxonomy of operational security considerations for manufacturer-installed keys and Trust Anchors‘.
It’s well worth a read, because it helps clarify thinking about trust in the context of the devices you care about. Devices like the small ones you scatter around your personal network in ‘Internet of Things’ roles, like local filestores, handsets, TV control and other functions in the home. All of these depend on a model of trust provided to them. Michael has been developing more precise terminology for this and the kinds of questions that need to be asked.
Exploring ideas in advance of standards
As with all IRTF drafts, this work comes with a disclaimer that it’s not an ‘official position of the Internet Engineering Task Force (IETF), or the IRTF:
This document is an Internet-Draft (I-D) that has been submitted to the Internet Research Task Force (IRTF) stream. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.
The IRTF is where more speculative, forward-looking and ‘open question’ work gets done. It isn’t usually saying how things should be and often therefore avoids normative language. Instead, the IRTF is where ideas are explored in advance of protocol and standards work. It’s some of the most interesting content at IETF face-to-face meetings, and it awards the Applied Networking Research Prize (ANRP) to early-stage research and gives early-career researchers a chance to showcase their work.
Categorizing the security bootstrapping space
Michael’s draft is a taxonomy. He’s categorizing the security bootstrapping space to help guide thinking by others towards the security of their devices in the context of a global Internet.
It is regrettably common for IoT devices to depend on a central manager node, with service delivery secured through its website. This comes at the cost of exporting everything you do, measure, monitor, or control, out of the local context and into the cloud. If IoT devices were designed to have security bootstrapped locally from the first time they were turned on, it would improve trust in configuration and operation. Local security bootstrapping opens the door to using non-third-party coordination methods, grounded in strong cryptographic controls.
As Michael points out, bootstrapping trust into a device demands a lot of thought. The component of trust that ‘anchors’ all other beliefs about trusted communications and states is called — not surprisingly — a Trust Anchor (TA). Perhaps the most important part of understanding trust is to understand where your TA comes from. Who controls this? How did it arrive on your device, and how do you manage it?
Michael also reviews trusted zones, trusted auxiliary processors, trusted key stores and cold boot trusted execution environments, all of which influence how you derive a sense of trust in a device from the factory.
Limiting the exposure of device keys
A surprisingly large number of devices now come with an inherently secure sub-zone in the Central Processing Unit (CPU) chip die, baked into the Very Large Scale Integration (VLSI) circuitry. These sub-zones operate separately from the main processor and often have functions that limit exposure of the highly secure device keys.
Android and Apple devices, and laptops from many manufacturers, now have these units, and can protect the keying information ‘inside’ the secure zone from all but state-actor levels of intrusion. There are even designs of VLSI circuitry that discharge electricity on intrusion, and destroy the keys if somebody tries to use a probe to examine the state of the device.
This heads into the US Federal Information Processing Standards (FIPS) design guidelines, against which FIPS-certified hardware security modules (HSMs) are designed and tested. The Internet Assigned Numbers Authority (IANA) depends on these devices to operate the TA of the global DNS, enabling worldwide DNSSEC operation.
Secure protocol thinking
Michael’s draft is a great way to gain insight into secure devices and secure protocol thinking. You’ll begin to understand key concepts and terminology, as well as find pointers into the IETF documentation of security and functional standards in this important area. It’s a great read.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.