NIST SP 1800-36: Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Security

NIST SPECIAL PUBLICATION 1800-36

Trusted Internet of Things (IoT) Device NetworkLayer Onboarding and Lifecycle Management:

Enhancing Internet Protocol-Based IoT Device and Network Security

Includes Executive Summary (A); Approach, Architecture, and Security Characteristics (B); How-To Guides (C); Functional Demonstrations (D); and Risk and Compliance Management (E) Michael Fagan Jeffrey Marron Murugiah Souppaya* Paul Watrobski*

National Cybersecurity Center of Excellence Information Technology Laboratory

William Barker

Andy Dolan Kyle Haefner Craig Pratt Darshak Thakore CableLabs Louisville, Colorado

Peter Romness

Cisco San Jose, California

Stratvia LLC Largo, Maryland

Tyler Baker David Griego

Chelsea Deane Joshua Klosterman Blaine Mulugeta Charlie Rearick Susan Symington

Foundries.io London, United Kingdom

Brecht Wyseur

Kudelski IoT Cheseaux-sur-Lausanne, Switzerland

The MITRE Corporation McLean, Virginia

Dan Harkins Danny Jump

Aruba, a Hewlett Packard Enterprise Company San Jose, California

November 2025

Nick Allott Alexandru Mereacre Ashley Setter

NquiringMinds Southampton, United Kingdom

Julien Delplancke

NXP Semiconductors Mougins, France

Michael Richardson

Sandelman Software Works Ontario, Canada

Steve Clark

SEALSQ, a subsidiary of WISeKey Geneva, Switzerland

Mike Dow Steve Egerter Silicon Labs Austin, Texas

Karen Kent

Trusted Cyber Annex

Retired NIST Author* *Former NIST employee; all work for this publication was done while at NIST.

FINAL This publication is available free of charge from https://doi.org/10.6028/NIST.SP.1800-36

NIST SPECIAL PUBLICATION 1800-36

Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Security

Includes Executive Summary (A); Approach, Architecture, and Security Characteristics (B); How-To Guides (C); Functional Demonstrations (D); and Risk and Compliance Management (E)

Michael Fagan Jeffrey Marron Murugiah Souppaya* Paul Watrobski*

Andy Dolan Kyle Haefner Craig Pratt Darshak Thakore

William Barker

Peter Romness

Chelsea Deane Joshua Klosterman Blaine Mulugeta Charlie Rearick Susan Symington

Tyler Baker David Griego

National Cybersecurity Center of Excellence Information Technology Laboratory Stratvia LLC Largo, Maryland

CableLabs Louisville, Colorado

Cisco San Jose, California

The MITRE Corporation McLean, Virginia

Dan Harkins Danny Jump

Aruba, a Hewlett Packard Enterprise Company San Jose, California

Foundries.io London, United Kingdom

Brecht Wyseur

Kudelski IoT Cheseaux-sur-Lausanne, Switzerland

Nick Allott Alexandru Mereacre Ashley Setter

NquiringMinds Southampton, United Kingdom

Julien Delplancke NXP Semiconductors Mougins, France

Michael Richardson

Sandelman Software Works Ontario, Canada

Steve Clark

SEALSQ, a subsidiary of WISeKey Geneva, Switzerland

Mike Dow Steve Egerter Silicon Labs Austin, Texas

Karen Kent

Trusted Cyber Annex

Retired NIST Author*

*Former NIST employee; all work for this publication was done while at NIST.

FINAL November 2025

U.S. Department of Commerce Howard Lutnick, Secretary National Institute of Standards and Technology Craig Burkhardt, Acting Under Secretary of Commerce for Standards and Technology and Acting NIST Director

NIST SPECIAL PUBLICATION 1800-36A

Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management:

Enhancing Internet Protocol-Based IoT Device and Network Security Volume A: Executive Summary

Michael Fagan Jeffrey Marron Murugiah Souppaya* Paul Watrobski*

Dan Harkins

Aruba, a Hewlett Packard Enterprise company San Jose, California

National Cybersecurity Center of Excellence Information Technology Laboratory

Blaine Mulugeta Susan Symington

William Barker Stratvia LLC Largo, Maryland

Michael Richardson

Sandelman Software Works Ottawa, Ontario

The MITRE Corporation McLean, Virginia

Retired NIST Author*

*Former NIST employee; all work for this publication was done while at NIST.

November 2025 FINAL This publication is available free of charge from https://doi.org/10.6028/NIST.SP.1800-36

FINAL

Executive Summary Establishing trust between a network and an Internet of Things (IoT) device (as defined in NIST Internal Report 8425) prior to providing the device with the credentials it needs to join the network is crucial for mitigating the risk of potential attacks. There are two possibilities for attack. One happens when a device is convinced to join an unauthorized network, which would take control of the device. The other occurs when a malicious device infiltrates a network. Trust is achieved by attesting and verifying the identity and posture of the device and the network before providing the device with its network credentials—a process known as network-layer onboarding. In addition, scalable, automated mechanisms are needed to safely manage IoT devices throughout their lifecycles, such as safeguards that verify the security posture of a device before the device is permitted to execute certain operations. In this practice guide, the National Cybersecurity Center of Excellence (NCCoE) applies standards, best practices, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices in Internet Protocol-based environments. This guide shows how to provide network credentials to IoT devices in a trusted manner and maintain a secure device posture throughout the device lifecycle, thereby enhancing IoT security.

CHALLENGE With tens of billions of IoT devices connected worldwide and more being connected every day, it is unrealistic to onboard or manage a network of these devices manually. In addition, providing local network credentials at the time of manufacture requires the manufacturer to customize network-layer onboarding on a build-to-order basis, which prevents the manufacturer from taking full advantage of the economies of scale that could result from building identical devices for its customers. There is a need to have a scalable, automated mechanism to securely manage IoT devices throughout their lifecycles and, in particular, a trusted mechanism for providing IoT devices with their network credentials and access policy at the time of deployment on the network. It is easy for a network to falsely identify itself, yet many IoT devices onboard to networks without verifying the network’s identity and ensuring that it is their intended target network. Also, many IoT devices lack user interfaces, making it cumbersome to input network credentials manually. Wi-Fi is sometimes used to provide credentials over an open (i.e., unencrypted) network, but this onboarding method risks credential disclosure. Most home networks use a single password shared among all devices, so access is controlled only by the device’s possession of the password. This type of access does not consider a unique device identity or whether the device belongs on the network. This method also increases the risk of exposing credentials to unauthorized parties. Providing unique credentials to each device is more secure, but providing unique credentials manually would be resource-intensive and error-prone, risk credential disclosure, and cannot be performed at scale. Once a device is connected to the network, if it becomes compromised, it can pose a security risk to both the network and other connected devices. Not keeping such a device current with the most recent software and firmware updates may make it more susceptible to compromise. The device could also be attacked through the receipt of malicious payloads. Once compromised, it may be used to attack other devices on the network or become part of a larger botnet, potentially participating in distributed denialof-service (DDoS) attacks or other malicious activities across the internet.

NIST SP 1800-36A: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

1

FINAL

OUTCOME The outcome of this project is to enhance the security of systems by helping IoT device users, manufacturers, and vendors understand how to carry out trusted network layer onboarding. This project has developed examples of trusted onboarding solutions and demonstrated these solutions using sample technologies and various scenarios. The NCCoE has published the findings in this practice guide, a NIST Special Publication (SP) 1800 series composed of multiple volumes targeting different audiences. This practice guide can help IoT device users: Understand how to onboard their IoT devices in a trusted manner to: 

Ensure that their network is not put at risk as new IoT devices are added to it



Safeguard their IoT devices from being taken over by unauthorized networks



Provide IoT devices with unique credentials for network access



Provide, renew, and replace device network credentials in a secure manner



Support ongoing protection of IoT devices throughout their lifecycles

This practice guide can help manufacturers and vendors of semiconductors, secure storage components, IoT devices, and network onboarding equipment: Understand the desired security properties for supporting trusted network-layer onboarding and explore their options with respect to recommended practices for: 

Providing unique credentials into secure storage on IoT devices at the time of manufacture to mitigate supply chain risks (i.e., device credentials)



Installing onboarding software on IoT devices



Providing IoT device purchasers with information needed to onboard the IoT devices to their networks (i.e., device bootstrapping information)



Integrating support for network-layer onboarding with additional security capabilities to provide ongoing protection throughout the device lifecycle

SOLUTION The NCCoE recommends using trusted network-layer onboarding to provide scalable, automated, trusted ways to provide IoT devices with unique network credentials and manage devices throughout their lifecycles to ensure they remain secure. The NCCoE collaborated with technology providers and other stakeholders to implement example trusted network-layer onboarding solutions for IoT devices that: 

provide each device with unique network credentials,



enable the device and the network to mutually authenticate,

NIST SP 1800-36A: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

2

FINAL 

send devices their credentials over an encrypted channel,



do not provide any person with access to the credentials, and



can be performed repeatedly throughout the device lifecycle.

The capabilities demonstrated include: 

trusted network-layer onboarding of IoT devices,



repeated trusted network-layer onboarding of devices to the same or a different network,



trusted application-layer onboarding (i.e., automatic establishment of an encrypted connection between an IoT device and a trusted application service after the IoT device has performed trusted network-layer onboarding and used its credentials to connect to the network), and



software-based methods to provide device credentials in the factory and transfer device bootstrapping information from the device manufacturer to the device purchaser.

Future capabilities could build upon this project by demonstrating the integration of trusted networklayer onboarding with additional zero trust-inspired [Note: See NIST SP 800-207] mechanisms beyond those currently demonstrated. Additionally, the Connectivity Standards Alliance Matter protocol was released after the initiation of this project, and therefore, it was not incorporated into the current capabilities. However, future community efforts could involve exploring the integration of this standard to enhance security and interoperability. This demonstration followed an agile methodology of building implementations (i.e., builds) iteratively and incrementally, starting with network-layer onboarding and gradually integrating additional capabilities that improve device and network security throughout a managed device lifecycle. This demonstration includes factory builds that simulate activities performed to securely provide device credentials during manufacturing, and five network-layer onboarding builds that demonstrate the Wi-Fi Easy Connect, Bootstrapping Remote Secure Key Infrastructure (BRSKI), and Thread Commissioning protocols. These builds also demonstrate both streamlined and independent trusted application-layer onboarding approaches, along with policy-based continuous assurance and authorization. The example implementations use technologies and capabilities from our project collaborators (listed below). Collaborators Aruba, a Hewlett Packard Enterprise company CableLabs Cisco Foundries.io

Kudelski IoT NquiringMinds NXP Semiconductors Open Connectivity Foundation (OCF)

NIST SP 1800-36A: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

Sandelman Software Works SEALSQ, a subsidiary of WISeKey Silicon Labs

3

FINAL While the NCCoE uses a suite of commercial products, services, and proof-of-concept technologies to address this challenge, this guide does not endorse these particular products, services, and technologies, nor does it guarantee compliance with any regulatory initiatives. Your organization's information security experts should identify the products and services that will best integrate with your IoT products, existing tools, IT and IoT system infrastructure, and operations. Your organization can adopt these solutions or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a solution.

HOW TO USE THIS GUIDE Depending on your role in your organization, you might use this guide in different ways: Business decision makers, such as chief information security, product security, and technology officers, can use this part of the guide, NIST SP 1800-36A: Executive Summary, to understand the project’s challenges and outcomes, as well as our solution approach. Technology, security, and privacy program managers who are concerned with how to identify, understand, assess, and mitigate risk can use NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. This part of the guide describes the architecture and different implementations. Also, NIST SP 1800-36E: Risk and Compliance Management, maps components of the trusted onboarding reference architecture to security characteristics in broadly applicable, well-known cybersecurity guidelines and practices. IT professionals who want to implement an approach like this can make use of NIST SP 1800-36C: HowTo Guides. It provides product installation, configuration, and integration instructions for building example implementations, allowing them to be replicated in whole or in part. They can also use NIST SP 1800-36D: Functional Demonstrations, which provides the use cases defined to showcase trusted network-layer onboarding and lifecycle management security capabilities and the results of demonstrating these capabilities with each example implementation. These use cases may be helpful when developing requirements for systems being developed.

COLLABORATORS Collaborators participating in this project submitted their capabilities in response to an open call in the Federal Register for all sources of relevant security capabilities from academia and industry (vendors and integrators). Those respondents with relevant capabilities or product components signed a Cooperative Research and Development Agreement (CRADA) to collaborate with NIST in a consortium to build this example solution. Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or the NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.

NIST SP 1800-36A: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

NIST SPECIAL PUBLICATION 1800-36B

Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Security Volume B: Approach, Architecture, and Security Characteristics Michael Fagan Jeffrey Marron Murugiah Souppaya* Paul Watrobski*

Andy Dolan Kyle Haefner Craig Pratt Darshak Thakore

William Barker

Peter Romness

Chelsea Deane Joshua Klosterman Blaine Mulugeta Charlie Rearick Susan Symington

Tyler Baker David Griego

National Cybersecurity Center of Excellence Information Technology Laboratory Stratvia LLC Largo, Maryland

Cisco San Jose, California

Foundries.io London, United Kingdom

Brecht Wyseur

The MITRE Corporation McLean, Virginia

Dan Harkins Danny Jump

CableLabs Louisville, Colorado

Kudelski IoT Cheseaux-sur-Lausanne, Switzerland

Aruba, a Hewlett Packard Enterprise Company San Jose, California

November 2025

Nick Allott Alexandru Mereacre Ashley Setter

NquiringMinds Southampton, United Kingdom

Julien Delplancke

NXP Semiconductors Mougins, France

Michael Richardson

Sandelman Software Works Ontario, Canada

Steve Clark

SEALSQ, a subsidiary of WISeKey Geneva, Switzerland

Mike Dow Steve Egerter Silicon Labs Austin, Texas

Retired NIST Author*

*Former NIST employee; all work for this publication was done while at NIST.

FINAL This publication is available free of charge from https://doi.org/10.6028/NIST.SP.1800-36

FINAL

DISCLAIMER Certain commercial en��es, equipment, products, or materials may be iden�fied by name or company logo or other insignia in order to acknowledge their par�cipa�on in this collabora�on or to describe an experimental procedure or concept adequately. Such iden�fica�on is not intended to imply special status or rela�onship with NIST or recommenda�on or endorsement by NIST or NCCoE; neither is it intended to imply that the en��es, equipment, products, or materials are necessarily the best available for the purpose. Na�onal Ins�tute of Standards and Technology Special Publica�on 1800-36B, Natl. Inst. Stand. Technol. Spec. Publ. 1800-36B, 132 pages, November 2025, CODEN: NSPUE2

FEEDBACK The NCCoE is always seeking feedback on our prac�ce guides. We are par�cularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have ques�ons about applying it in your environment, please email us at iot-onboarding@nist.gov. All comments are subject to release under the Freedom of Informa�on Act.

Na�onal Cybersecurity Center of Excellence Na�onal Ins�tute of Standards and Technology 100 Bureau Drive Mailstop 2002 Gaithersburg, MD 20899 Email: nccoe@nist.gov

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

ii

FINAL

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE The Na�onal Cybersecurity Center of Excellence (NCCoE), a part of the Na�onal Ins�tute of Standards and Technology (NIST), is a collabora�ve hub where industry organiza�ons, government agencies, and academic ins�tu�ons work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the crea�on of prac�cal cybersecurity solu�ons for specific industries, as well as for broad, cross-sector technology challenges. Through consor�a under Coopera�ve Research and Development Agreements (CRADAs), including technology partners—from Fortune 50 market leaders to smaller companies specializing in informa�on technology security—the NCCoE applies standards and best prac�ces to develop modular, adaptable example cybersecurity solu�ons using commercially available technology. The NCCoE documents these example solu�ons in the NIST Special Publica�on 1800 series, which maps capabili�es to the NIST Cybersecurity Framework and details the steps needed for another en�ty to re-create the example solu�on. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland. To learn more about the NCCoE, visit htps://www.nccoe.nist.gov/. To learn more about NIST, visit htps://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES NIST Cybersecurity Prac�ce Guides (Special Publica�on 1800 series) target specific cybersecurity challenges in the public and private sectors. They are prac�cal, user-friendly guides that facilitate the adop�on of standards-based approaches to cybersecurity. They show members of the informa�on security community how to implement example solu�ons that help them align with relevant standards and best prac�ces, and provide users with the materials lists, configura�on files, and other informa�on they need to implement a similar approach. The documents in this series describe example implementa�ons of cybersecurity prac�ces that businesses and other organiza�ons may voluntarily adopt. These documents do not describe regula�ons or mandatory prac�ces, nor do they carry statutory authority.

KEYWORDS application-layer onboarding; bootstrapping; Internet of Things (IoT); Manufacturer Usage Description (MUD); network-layer onboarding; onboarding; Wi-Fi Easy Connect.

ACKNOWLEDGMENTS We are grateful to the following individuals for their generous contribu�ons of exper�se and �me.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iii

FINAL Name

Organization

Amogh Guruprasad Deshmukh

Aruba, a Hewlett Packard Enterprise company

Bart Brinkman

Cisco

Eliot Lear

Cisco

George Grey

Foundries.io

David Griego

Foundries.io

Fabien Gremaud

Kudelski IoT

Faith Ryan

The MITRE Corporation

Kevin Brady

NIST

Barbara Cuthill

NIST

Cherilyn Pascoe

NIST

Toby Ealden

NquiringMinds

John Manslow

NquiringMinds

Antony McCaigue

NquiringMinds

Alexandru Mereacre

NquiringMinds

Loic Cavaille

NXP Semiconductors

Mihai Chelalau

NXP Semiconductors

Julien Delplancke

NXP Semiconductors

Anda-Alexandra Dorneanu

NXP Semiconductors

Todd Nuzum

NXP Semiconductors

Nicusor Penisoara

NXP Semiconductors

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iv

FINAL Name

Organization

Laurentiu Tudor

NXP Semiconductors

Karen Scarfone

Scarfone Cybersecurity

Pedro Fuentes

SEALSQ, a subsidiary of WISeKey

Gweltas Radenac

SEALSQ, a subsidiary of WISeKey

Kalvin Yang

SEALSQ, a subsidiary of WISeKey

Heather Flanagan

Spherical Cow Consulting

The Technology Partners/Collaborators who par�cipated in this build submited their capabili�es in response to a no�ce in the Federal Register. Respondents with relevant capabili�es or product components were invited to sign a Coopera�ve Research and Development Agreement (CRADA) with NIST, allowing them to par�cipate in a consor�um to build this example solu�on. We worked with: Technology Collaborators Aruba, a Hewlet Packard Enterprise company CableLabs Cisco

Foundries.io Kudelski IoT NquiringMinds NXP Semiconductors

Open Connec�vity Founda�on (OCF) Sandelman So�ware Works SEALSQ, a subsidiary of WISeKey Silicon Labs

DOCUMENT CONVENTIONS The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the publica�on and from which no devia�on is permited. The terms “should” and “should not” indicate that among several possibili�es, one is recommended as par�cularly suitable without men�oning or excluding others, or that a certain course of ac�on is preferred but not necessarily required, or that (in the nega�ve form) a certain possibility or course of ac�on is discouraged but not prohibited. The terms “may” and “need not” indicate a course of ac�on permissible within the limits of the publica�on. The terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

v

FINAL

PATENT DISCLOSURE NOTICE NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication. As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL. No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vi

FINAL

Contents 1 Summary ............................................................................................ 1 1.1

Challenge .....................................................................................................................1

1.2

Solu�on ........................................................................................................................2

1.3

Benefits ........................................................................................................................3

2 How to Use This Guide ........................................................................ 5 2.1

Typographic Conven�ons .............................................................................................7

2.2

Publica�on Structure ...................................................................................................7

3 Approach ............................................................................................ 9 3.1

Audience ....................................................................................................................11

3.2

Scope .........................................................................................................................12

3.3

Assump�ons and Defini�ons .....................................................................................12 3.3.1 Creden�al Types .............................................................................................12 3.3.2 Integra�ng Security Enhancements................................................................14 3.3.3 Device Limita�ons ..........................................................................................16 3.3.4 Specifica�ons Are S�ll Improving ...................................................................17

3.4

Collaborators and Their Contribu�ons .......................................................................17 3.4.1 Aruba, a Hewlet Packard Enterprise Company ..............................................20 3.4.2 CableLabs .......................................................................................................23 3.4.3 Cisco ...............................................................................................................24 3.4.4 Foundries.io ...................................................................................................25 3.4.5 Kudelski IoT ....................................................................................................25 3.4.6 NquiringMinds ...............................................................................................26 3.4.7 NXP Semiconductors ......................................................................................28 3.4.8 Open Connec�vity Founda�on (OCF) .............................................................29 3.4.9 Sandelman So�ware Works ...........................................................................29 3.4.10 SEALSQ, a subsidiary of WISeKey ...................................................................31 3.4.11 VaultIC408 ......................................................................................................31 3.4.12 Silicon Labs .....................................................................................................31

4 Reference Architecture...................................................................... 34 4.1

Device Manufacture and Factory Provisioning Process ..............................................36

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vii

FINAL 4.2

Device Ownership and Bootstrapping Informa�on Transfer Process .........................38

4.3

Trusted Network-Layer Onboarding Process ..............................................................41

4.4

Trusted Applica�on-Layer Onboarding Process ..........................................................43

4.5

Con�nuous Verifica�on..............................................................................................46

5 Laboratory Physical Architecture ....................................................... 48 5.1

Shared Environment ..................................................................................................51 5.1.1 Domain Controller ..........................................................................................52 5.1.2 Jumpbox .........................................................................................................52

5.2

Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Physical Architecture .................................52 5.2.1 Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture .............53

5.3

Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) Physical Architecture ..........................54

5.4

Build 3 (BRSKI, Sandelman So�ware Works) Physical Architecture ............................55

5.5

Build 4 (Thread, Silicon Labs, Kudelski IoT) Physical Architecture ..............................57

5.6

Build 5 (BRSKI, NquiringMinds) Physical Architecture ................................................58 5.6.1 BRSKI Factory Provisioning Build Physical Architecture ..................................60

6 General Findings ............................................................................... 62 6.1

Wi-Fi Easy Connect.....................................................................................................62 6.1.1 Mutual Authen�ca�on ...................................................................................62 6.1.2 Mutual Authoriza�on .....................................................................................62 6.1.3 Secure Storage ...............................................................................................63

6.2

BRSKI ..........................................................................................................................63 6.2.1 Reliance on the Device Manufacturer ............................................................63 6.2.2 Mutual Authen�ca�on ...................................................................................63 6.2.3 Mutual Authoriza�on .....................................................................................64 6.2.4 Secure Storage ...............................................................................................64

6.3

Thread........................................................................................................................64

6.4

Applica�on-Layer Onboarding ...................................................................................65 6.4.1 Independent Applica�on-Layer Onboarding ..................................................65 6.4.2 Streamline Applica�on-Layer Onboarding .....................................................65

7 Addi�onal Build Considera�ons ........................................................ 66 7.1

Network Authen�ca�on ............................................................................................66

7.2

Device Communica�ons Intent ..................................................................................66

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

viii

FINAL 7.3

Network Segmenta�on ..............................................................................................67

7.4

Integra�on with a Lifecycle Management Service......................................................67

7.5

Network Creden�al Renewal .....................................................................................67

7.6

Integra�on with Supply Chain Management Tools.....................................................67

7.7

Atesta�on .................................................................................................................68

7.8

Mutual Atesta�on .....................................................................................................68

7.9

Behavioral Analysis ....................................................................................................68

7.10 Device Trustworthiness Scale .....................................................................................68 7.11 Resource Constrained Systems ..................................................................................68

8 References ........................................................................................ 70 Appendix A List of Acronyms ................................................................. 73 Appendix B Glossary ............................................................................. 76 Appendix C Build 1 (Wi-Fi Easy Connect, Aruba/HPE) ............................ 78 C.1 Technologies ..............................................................................................................78 C.2 Build 1 Architecture ...................................................................................................80 C.2.1 Build 1 Logical Architecture ............................................................................80 C.2.2 Build 1 Physical Architecture ..........................................................................82

Appendix D Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) ...................... 83 D.1 Technologies ..............................................................................................................83 D.2 Build 2 Architecture ...................................................................................................85 D.2.1 Build 2 Logical Architecture ............................................................................85 D.2.2 Build 2 Physical Architecture ..........................................................................88

Appendix E Build 3 (BRSKI, Sandelman So�ware Works) ....................... 89 E.1

Technologies ..............................................................................................................89

E.2

Build 3 Architecture ...................................................................................................91 E.2.1 Build 3 Logical Architecture ............................................................................91 E.2.2 Build 3 Physical Architecture ..........................................................................93

Appendix F Build 4 (Thread, Silicon Labs-Thread, Kudelski KeySTREAM) 94 F.1

Technologies ..............................................................................................................94

F.2

Build 4 Architecture ...................................................................................................96

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

ix

FINAL F.2.1

Build 4 Logical Architecture ............................................................................96

F.2.2

Build 4 Physical Architecture ........................................................................101

Appendix G Build 5 (BRSKI over Wi-Fi, NquiringMinds) ........................ 102 G.1 Technologies ............................................................................................................102 G.2 Build 5 Architecture .................................................................................................104 G.2.1 Build 5 Logical Architecture ..........................................................................104 G.2.2 Build 5 Physical Architecture ........................................................................107

Appendix H Factory Provisioning Process............................................. 108 H.1 Factory Provisioning Process ....................................................................................108 H.1.1 Device Birth Creden�al Provisioning Methods .............................................108 H.2 Factory Provisioning Builds – General Provisioning Process .....................................111 H.3 BRSKI Factory Provisioning Builds (NquiringMinds and SEALSQ)..............................111 H.3.1 BRSKI Factory Provisioning Build Technologies .............................................112 H.3.2 BRSKI Factory Provisioning Build Logical Architectures ................................114 H.3.3 BRSKI Factory Provisioning Build Physical Architectures ..............................117 H.4 Wi-Fi Easy Connect Factory Provisioning Build (SEALSQ and Aruba/HPE) ................117 H.4.1 Wi-Fi Easy Connect Factory Provisioning Build Technologies .......................117 H.4.2 Wi-Fi Easy Connect Factory Provisioning Build Logical Architecture.............118 H.4.3 Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture ...........120

List of Figures Figure 3-1 Aruba/HPE DPP Onboarding Components ............................................................. 23 Figure 3-2 Components for Onboarding an IoT Device that Communicates Using Thread to AWS IoT ................................................................................................................................. 33 Figure 4-1 Trusted IoT Device Network-Layer Onboarding and Lifecycle Management Logical Reference Architecture .......................................................................................................... 35 Figure 4-2 IoT Device Manufacture and Factory Provisioning Process .................................... 36 Figure 4-3 Device Ownership and Bootstrapping Informa�on Transfer Process ...................... 39 Figure 4-4 Trusted Network-Layer Onboarding Process .......................................................... 42 Figure 4-5 Trusted Streamlined Applica�on-Layer Onboarding Process .................................. 44

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

x

FINAL Figure 4-6 Con�nuous Verifica�on ......................................................................................... 46 Figure 5-1 NCCoE IoT Onboarding Laboratory Physical Architecture....................................... 49 Figure 5-2 Physical Architecture of Build 1 ............................................................................. 53 Figure 5-3 Physical Architecture of Wi-Fi Easy Connect Factory Provisioning Build ................. 54 Figure 5-4 Physical Architecture of Build 2 ............................................................................. 55 Figure 5-5 Physical Architecture of Build 3 ............................................................................. 57 Figure 5-6 Physical Architecture of Build 4 ............................................................................. 58 Figure 5-7 Physical Architecture of Build 5 ............................................................................. 60 Figure 5-8 Physical Architecture of BRSKI Factory Provisioning Build ..................................... 61 Figure C-1 Logical Architecture of Build 1……………………………………………………………………..………81 Figure D-1 Logical Architecture of Build 2…………………………………………………………………..………..86 Figure E-1 Logical Architecture of Build 3 ............................................................................... 91 Figure F-1 Logical Architecture of Build 4: Device Prepara�on………………………………………………98 Figure F-2 Logical Architecture of Build 4: Connec�on to the OpenThread Network……………..99 Figure F-3 Logical Architecture of Build 4: Applica�on-Layer Onboarding using the Kudelski keySTREAM Service………………………………………………………………………………100 Figure G-1 Logical Architecture of Build 5…………………………………………………………………………..105 Figure H-1 Logical Architecture of the First Version of the BRSKI Factory Provisioning Build.……………………………………………………………………………………………………………..116 Figure H-2 Logical Architecture of the Second Version of the BRSKI Factory Provisioning Build.…………………………………………………………………………………………..…………………117 Figure H-3 Logical Architecture of the Wi-Fi Easy Connect Factory Provisioning Build…………120

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

xi

FINAL

List of Tables Table 3-1 Capabili�es and Components Provided by Each Technology Partner/Collaborator . 19 Table 5-1 Build 1 Products and Technologies .......................................................................... 51 Table C-1 Build 1 Products and Technologies.......................................................................... 79 Table D-1 Build 2 Products and Technologies………………………………………………………………………..83 Table E-1 Build 3 Products and Technologies .......................................................................... 89 Table F-1 Build 4 Products and Technologies .......................................................................... 94 Table G-1 Build 5 Products and Technologies ....................................................................... 102 Table H-1 First Version of the BRSKI Factory Provisioning Build Products and Technologies………………………………………………………………………………………..112 Table H-2 Second Version of the BRSKI Factory Provisioning Build Products and Technologies………………………………………………………………………………………..114 Table H-3 Wi-Fi Easy Connect Factory Provisioning Build Products and Technologies………….118

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

xii

FINAL

1 Summary IoT devices are typically connected to a network. As with any other device needing to communicate on a network securely, an IoT device needs creden�als specific to that network to help ensure that only authorized devices can connect to and use the network. A typical commercially available, mass-produced IoT device cannot be pre-provisioned with local network creden�als by the manufacturer during the manufacturing process. Instead, the device will be provisioned with local network creden�als at the �me of its deployment. This prac�ce guide is focused on trusted methods of providing IoT devices with the network-layer creden�als and policy they need to join a network upon deployment, a process known as network-layer onboarding. Establishing trust between a network and an IoT device (as defined in NIST Internal Report 8425) prior to providing the device with the creden�als it needs to join the network is crucial for mi�ga�ng the risk of poten�al atacks. There are two possibili�es for atack. One is where a device is convinced to join an unauthorized network, which would take control of the device. The other is where a malicious device infiltrates a network. Trust is achieved by ates�ng and verifying the iden�ty and posture of the device and the network before providing the device with its network creden�als—a process known as network-layer onboarding. In addi�on, scalable, automated mechanisms are needed to safely manage IoT devices throughout their lifecycles, such as safeguards that verify the security posture of a device before the device is permited to execute certain opera�ons. In this prac�ce guide, the Na�onal Cybersecurity Center of Excellence (NCCoE) applies standards, best prac�ces, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices. This guide shows how to provide network creden�als to IoT devices in a trusted manner and maintain a secure device posture throughout the device lifecycle.

1.1 Challenge With tens of billions of IoT devices connected worldwide and more being connected every day, it is unrealis�c to onboard or manage these devices by visi�ng each one and performing a manual ac�on. A manufacturer can provide local network creden�als that are securely updated during the manufacturing process. However, this approach requires customizing network-layer onboarding for each order, limi�ng the manufacturer’s ability to benefit from the economies of scale achieved by producing iden�cal devices for all customers. The industry lacks scalable, automa�c mechanisms to manage IoT devices safely throughout their lifecycles. The industry also lacks a trusted mechanism for providing IoT devices with their

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

1

FINAL network creden�als and policy at the �me of deployment on the network. It is easy for a network to falsely iden�fy itself, yet many IoT devices onboard to networks without verifying the network’s iden�ty and ensuring that it is their intended target network. Also, many IoT devices lack user interfaces, making it cumbersome to input network creden�als manually. Wi-Fi is some�mes used to provide creden�als over an open (i.e., unencrypted) network, but this onboarding method risks creden�al disclosure. Most home networks use a single password shared among all devices, so access is controlled only by the device’s possession of the password. This method does not consider a unique device iden�ty or whether the device belongs on the network. It also increases the risk of exposing creden�als to unauthorized par�es. Providing unique creden�als to each device is more secure, but doing so manually would be resource-intensive and error-prone, risk creden�al disclosure, and cannot be performed at scale. Once a device is connected to the network, if it becomes compromised, it can pose a security risk to both the network and other connected devices. Not keeping such a device current with the most recent so�ware and firmware updates may make it more suscep�ble to compromise. The device could also be atacked through the receipt of malicious payloads. Once compromised, it may be used to atack other devices on the network or become part of a larger botnet, poten�ally par�cipa�ng in distributed denial-of-service (DDoS) atacks or other malicious ac�vi�es across the internet.

1.2 Solu�on We need scalable, automated, trusted mechanisms to safely manage IoT devices throughout their lifecycles to ensure they remain secure, star�ng with secure ways to provision devices with their network creden�als, i.e., beginning with network-layer onboarding. Onboarding is a par�cularly vulnerable point in the device lifecycle; if it is not performed securely, then both the device and the network are at risk. Networks are at risk of having unauthorized devices connect to them, and devices are at risk of being taken over by networks that are not authorized to onboard or control them. The NCCoE has adopted the trusted network-layer onboarding approach to promote safe, automated ways to provide IoT devices with unique network creden�als and securely manage devices throughout their lifecycles. The NCCoE is collabora�ng with CRADA consor�um technology providers in a phased approach to develop example implementa�ons of trusted network-layer onboarding solu�ons. We define a trusted network-layer onboarding solution to be a mechanism for provisioning network creden�als to a device that: 

provides each device with unique network creden�als;



enables the device and the network to mutually authen�cate;



sends devices their network creden�als over an encrypted channel;

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

2

FINAL 

does not provide any person with access to the network creden�als; and



can be performed repeatedly throughout the device lifecycle to enable: •

secure management and replacement of the device’s network creden�als as needed, and

•

secure onboarding of the device to other networks a�er being repurposed or resold.

The use cases designed to be demonstrated by this project’s implementa�ons include: 

a trusted network-layer onboarding of IoT devices;



repeated trusted network-layer onboarding of devices to the same or a different network;



automa�c establishment of an encrypted connec�on between an IoT device and a trusted applica�on service (i.e., trusted application-layer onboarding) a�er the IoT device has performed trusted network-layer onboarding and used its creden�als to connect to the network;



ongoing policy-based gran�ng of device network access permissions and privileges (i.e., authoriza�on);



so�ware-based methods to provision device birth creden�als in the factory; and



mechanisms for IoT device manufacturers to provide IoT device purchasers with informa�on needed to onboard the IoT devices to their networks (i.e., device bootstrapping information).

1.3 Benefits This prac�ce guide can benefit both IoT device users and manufacturers. The guide can help IoT device users understand how to onboard IoT devices to their networks in a trusted manner to: 

ensure that their network is not put at risk as IoT devices are added to it;



safeguard their IoT devices from being taken over by unauthorized networks;



provide IoT devices with unique creden�als for network access;



provide, renew, and securely replace device network creden�als;



ensure that IoT devices can automa�cally and securely perform applica�on-layer onboarding a�er performing trusted network-layer onboarding and connec�ng to a network; and



support ongoing protec�on of IoT devices throughout their lifecycles.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

3

FINAL This guide can help IoT device manufacturers, as well as manufacturers and vendors of semiconductors, secure storage components, and network onboarding equipment, understand the desired security proper�es for suppor�ng trusted network-layer onboarding and demonstrate mechanisms for: 

placing unique creden�als into secure storage on IoT devices at �me of manufacture (i.e., device birth credentials);



installing onboarding so�ware onto IoT devices;



providing IoT device purchasers with the informa�on needed to onboard the IoT devices to their networks (i.e., device bootstrapping information); and



integra�ng support for network-layer onboarding with addi�onal security capabili�es to provide ongoing protec�on throughout the device lifecycle.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

FINAL

2 How to Use This Guide This NIST Cybersecurity Prac�ce Guide demonstrates a standards-based reference design for implemen�ng trusted IoT device network-layer onboarding and lifecycle management and describes various example implementa�ons of this reference design. Each of these implementa�ons, which are known as builds, is standards-based and is designed to help provide assurance that networks are not put at risk as new IoT devices are added to them and help safeguard IoT devices from connec�ng to unauthorized networks. The reference design described in this prac�ce guide is modular; it can be deployed in whole or in part, enabling organiza�ons to incorporate trusted IoT device network-layer onboarding and lifecycle management into their legacy environments according to goals that they have priori�zed based on risk, cost, and resources. This guide contains five volumes: 

NIST Special Publica�on (SP) 1800-36A: Executive Summary – why we wrote this guide, the challenge we address, why it could be important to your organiza�on, and our approach to solving this challenge



NIST SP 1800-36B: Approach, Architecture, and Security Characteristics – what we built and why (you are here)



NIST SP 1800-36C: How-To Guides – instruc�ons for building the example implementa�ons, including all the security-relevant details that would allow you to replicate all or parts of this project



NIST SP 1800-36D: Functional Demonstrations – use cases that have been defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabili�es, and the results of demonstra�ng these use cases with each of the example implementa�ons



NIST SP 1800-36E: Risk and Compliance Management – risk analysis and mapping of trusted IoT device network-layer onboarding and lifecycle management security characteris�cs to cybersecurity standards and recommended prac�ces

Depending on your role in your organiza�on, you might use this guide in different ways: Business decision makers, including chief informa�on security, product security, and technology officers, will be interested in the Executive Summary, NIST SP 1800-36A, which describes the following topics: 

challenges that enterprises face in migra�ng to the use of trusted IoT device networklayer onboarding



example solu�ons built at the NCCoE



benefits of adop�ng the example solu�on

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

5

FINAL Technology, security, and privacy program managers who are concerned with how to iden�fy, understand, assess, and mi�gate risk will be interested in NIST SP 1800-36B, which describes what we did and why. Also, Sec�on 4 of NIST SP 1800-36E will be of par�cular interest. Sec�on 4, Mappings, maps logical components of the general trusted IoT device network-layer onboarding and lifecycle management reference design to security characteris�cs listed in various cybersecurity standards and recommended prac�ces documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity Framework) and Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53). You might share the Executive Summary, NIST SP 1800-36A, with your leadership team members to help them understand the importance of using standards-based implementa�ons for trusted IoT device network-layer onboarding and lifecycle management. IT professionals who want to implement similar solu�ons will find all volumes of the prac�ce guide useful. You can use the how-to por�on of the guide, NIST SP 1800-36C, to replicate all or parts of the builds created in our lab. The how-to por�on of the guide provides specific product installa�on, configura�on, and integra�on instruc�ons for implemen�ng the example solu�on. We do not re-create the product manufacturers’ documenta�on, which is generally widely available. Rather, we show how we incorporated the products together in our environment to create an example solu�on. For addi�onal guidance, please refer to the Functional Demonstrations, NIST SP 1800-36D, which provides the use cases defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabili�es and the results of demonstra�ng these use cases with each example implementa�on. Finally, NIST SP 1800-36E will help explain the security func�onality that the components of each build provide. This guide assumes that IT professionals have experience implemen�ng security products within the enterprise. While we have used a suite of commercial products to address this challenge, this guide does not endorse these par�cular products. Your organiza�on can adopt this solu�on or one that adheres to these guidelines in whole, or you can use this guide as a star�ng point for tailoring and implemen�ng parts of a trusted IoT device network-layer onboarding and lifecycle management solu�on. Your organiza�on’s security experts should iden�fy the products that will best integrate with your exis�ng tools and IT system infrastructure. We hope that you will seek products that are congruent with applicable standards and recommended prac�ces. A NIST Cybersecurity Prac�ce Guide does not describe “the” solu�on, but example solu�ons. We seek feedback on the publica�on’s contents and value your input. Please contribute your thoughts to iot-onboarding@nist.gov.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

6

FINAL

2.1 Typographic Conven�ons The following table presents typographic conven�ons used in this volume. Typeface/Symbol

Meaning

Example

Italics

file names and path names; references to documents that are not hyperlinks; new terms; and placeholders names of menus, op�ons, command butons, and fields command-line input, onscreen computer output, sample code examples, and status codes command-line user input contrasted with computer output link to other parts of the document, a web URL, or an email address

For language use and style guidance, see the NCCoE Style Guide.

Bold Monospace

Monospace Bold

blue text

Choose File > Edit. mkdir

service sshd start

All publica�ons from NIST’s NCCoE are available at htps://www.nccoe.nist.gov.

2.2 Publica�on Structure The remainder of this publica�on is organized into the following sec�ons and appendices: 

Sec�on 3: Approach Details the audience, scope, assump�ons, defini�ons, and contribu�ons from collaborators.



Sec�on 4: Reference Architecture Describes the logical and process architectures suppor�ng trusted onboarding and lifecycle management.



Sec�on 5: Laboratory Physical Architecture Outlines the physical implementa�on of the example builds in the NCCoE lab environment.



Sec�on 6: General Findings Summarizes key observa�ons and outcomes from the project.



Sec�on 7: Future Build Considera�ons Discusses poten�al areas for future work and enhancements.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

7

FINAL 

Appendix A: List of Acronyms Comprehensive list of all acronyms used throughout the publica�on for easy reference.



Appendix B: Glossary Defini�ons of key terms and concepts relevant to trusted IoT device onboarding and lifecycle management.



Appendix C: Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Details on the technologies and architectures for Build 1, which demonstrates onboarding using Aruba/HPE solu�ons.



Appendix D: Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) Details on the technologies and architectures for Build 2, which leverages CableLabs and Open Connec�vity Founda�on (OCF) solu�ons.



Appendix E: Build 3 (BRSKI, Sandelman So�ware Works) Details on the technologies and architectures for Build 3, which implements the BRSKI protocol using Sandelman So�ware Works components.



Appendix F: Build 4 (Thread, Silicon Labs, Kudelski IoT) Details on the technologies and architectures for Build 4, which demonstrates onboarding using the Thread protocol and Kudelski IoT keySTREAM.



Appendix G: Build 5 (BRSKI over Wi-Fi, NquiringMinds) Details on the technologies and architectures for Build 5, which implements BRSKI over Wi-Fi using NquiringMinds’ open-source stack.



Appendix H: Factory Provisioning Process Describes the overall factory provisioning process, including device birth creden�al provisioning methods, general process flows, and specific details for BRSKI and Wi-Fi Easy Connect factory builds.



Appendix I: References Complete list of cited works, standards, and suppor�ng materials referenced throughout the guide.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

8

FINAL

3 Approach This project builds on the document-based research presented in the NIST Dra� Cybersecurity White Paper 16, Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management [1]. That paper describes key security and other characteris�cs of a trusted network-layer onboarding solu�on as well as the integra�on of onboarding with related technologies such as device atesta�on, device communica�ons intent [2][3], and applica�on-layer onboarding. The security and other aspects of the onboarding process, as detailed in the paper, help ensure that adding new IoT devices does not endanger the network, while also protec�ng the devices from being accessed by unauthorized networks. To kick off this project, the NCCoE published a Federal Register No�ce [4] invi�ng technology providers to par�cipate in demonstra�ng approaches to deploying trusted IoT device networklayer onboarding and lifecycle management in home and enterprise networks, with the objec�ve of showing how trusted IoT device network-layer onboarding can prac�cally and effec�vely enhance the overall security of IoT devices and, by extension, the security of the networks to which they connect. The Federal Register No�ce invited technology providers to provide products and/or exper�se to compose prototypes. Components sought included network onboarding components and IoT devices that support trusted network-layer onboarding protocols; authoriza�on services; supply chain integra�on services; access points, routers, or switches; components that support device communica�ons intent management; atesta�on services; controllers or applica�on services; IoT device lifecycle management services; and asset management services. Coopera�ve Research and Development Agreements (CRADAs) were established with qualified respondents, and teams of collaborators were assembled to build a variety of implementa�ons. NIST followed an agile methodology of building implementa�ons itera�vely and incrementally, star�ng with network-layer onboarding and gradually integra�ng addi�onal capabili�es that improve device and network security throughout a managed device lifecycle. The project team began by designing a general, protocol-agnos�c reference architecture for trusted network-layer onboarding (see Sec�on 4) and establishing a laboratory infrastructure at the NCCoE to host implementa�ons (see Sec�on 5). Five teams were established to implement trusted network-layer onboarding prototypes (i.e., builds), and a sixth team was established to demonstrate mul�ple builds for factory provisioning ac�vi�es performed by an IoT device manufacturer to enable devices to support trusted network-layer onboarding. Each build team fleshed out the ini�al architectures of their example implementa�ons. They then used technologies, capabili�es, and components from project collaborators to begin crea�ng the builds:

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

9

FINAL 

Build 1 (Wi-Fi Easy Connect, Aruba/HPE) uses components from Aruba, a Hewlet Packard Enterprise company, to support trusted network-layer onboarding using the Wi-Fi Alliance’s Wi-Fi Easy Connect Specifica�on, Version 2.0 [5] and independent (see Sec�on 3.3.2) applica�on-layer onboarding to the Aruba User Experience Insight (UXI) cloud.



Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) uses components from CableLabs to support trusted network-layer onboarding using the Wi-Fi Easy Connect protocol that allows provisioning of per-device creden�als and policy management for each device. Build 2 also uses Open Connec�vity Founda�on (OCF) components to support streamlined (see Sec�on 3.3.2) trusted applica�on-layer onboarding to the OCF security domain.



Build 3 (BRSKI, Sandelman So�ware Works) uses components from Sandelman So�ware Works to support trusted network-layer onboarding using the Bootstrapping Remote Secure Key Infrastructure (BRSKI) [6] protocol and an independent, third-party Manufacturer Authorized Signing Authority (MASA).



Build 4 (Thread [7], Silicon Labs, Kudelski IoT) uses components from Silicon Labs to support connec�on to an OpenThread [8] network using pre-shared creden�als and components from Kudelski IoT to support trusted applica�on-layer onboarding to the Amazon Web Services (AWS) IoT core.



Build 5 (BRSKI over Wi-Fi, NquiringMinds) uses components from NquiringMinds to support trusted network-layer onboarding using the BRSKI protocol over 802.11 [9]. Addi�onal components from NquiringMinds support ongoing, policy-based, con�nuous assurance and authoriza�on, as well as device communica�ons intent enforcement.



Factory Provisioning Builds - ac�vi�es performed by an IoT device manufacturer to enable devices to support trusted network-layer onboarding: o The BRSKI Factory Provisioning Build uses components from NquiringMinds to implement the factory provisioning flows. The build is implemented on Raspberry Pi devices, where the IoT secure element is an integrated Infineon Op�ga SLB 9670 TPM 2.0. The device cer�ficate authority (CA) is externally hosted on NquiringMinds servers. This build demonstrates ac�vi�es for provisioning IoT devices with their ini�al (i.e., birth—see Sec�on 3.3) creden�als for use with the BRSKI protocol and for making device bootstrapping informa�on available to device owners. o The Wi-Fi Easy Connect Factory Provisioning Build uses Raspberry Pi devices, code from Aruba, and secure storage elements, code, and a CA from SEALSQ, a subsidiary of WISeKey. This build demonstrates ac�vi�es for provisioning IoT devices with their birth creden�als for use with the Wi-Fi Easy Connect protocol and for making device bootstrapping informa�on available to device owners.

Each build team documented the architecture and design of its build (see Appendix C, Appendix D, Appendix E, Appendix F, Appendix G, and Appendix H). As each build progressed, its team also documented the steps taken to install and configure each component of the build (see NIST SP 1800-36C).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

10

FINAL The project team then designed a set of use case scenarios to showcase the builds’ security capabili�es. Each build team conducted a func�onal demonstra�on of its build by running the build through the defined scenarios and documen�ng the results (see NIST SP 1800-36D). The project team also conducted a risk assessment and a security characteris�c analysis and documented the results, including mappings of the security capabili�es of the reference solu�on to both the Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity Framework 2.0) [10] and Security and Privacy Controls for Informa�on Systems and Organiza�ons (NIST SP 800-53 Rev. 5) (see NIST SP 1800-36E). Finally, the NCCoE worked with industry and standards-developing organiza�on collaborators to dis�ll their findings and consider poten�al enhancements to future support for trusted IoT device network-layer onboarding (see Sec�on 6 and Sec�on 7). During the course of this work, an industry protocol from the Connec�vity Standards Alliance, Mater, emerged as a relevant development. However, due to �me constraints, it was not possible to include it in this project. As such, it may be considered for follow-up efforts or future itera�ons.

3.1 Audience The intended audience for this prac�ce guide includes both public and private sector organiza�ons such as: 



Organiza�ons involved in building and suppor�ng IoT Devices and Infrastructure •

IoT device manufacturers, integrators, and vendors

•

Semiconductor manufacturers and vendors

•

Secure storage manufacturers

•

Network equipment manufacturers

•

Service providers (internet service providers/cable operators and applica�on pla�orm providers)

Owners and Administrators responsible for IoT Device Use and Management •

IoT device owners and users

•

Owners and administrators of networks (both home and enterprise) to which IoT devices connect

•

Installers and maintainers, technical support service companies working on behalf of IoT owners

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

11

FINAL

3.2 Scope This project focuses on the trusted network-layer onboarding of IoT devices in both home and enterprise environments. Enterprise, consumer, and industrial use cases for trusted IoT device network-layer onboarding are all considered to be in scope at this �me. The project encompasses trusted network-layer onboarding of IoT devices deployed across different Internet Protocol (IP) based environments using wired, Wi-Fi, and broadband networking technologies. The network-layer onboarding protocols demonstrated in this project are not an exhaus�ve list of network-layer onboarding protocols that exist to date. The project’s scope also includes security technologies that can integrate with and be enhanced by the trusted network-layer onboarding mechanism to protect the device and its network throughout the device’s lifecycle. Examples of these technologies include supply chain management, device atesta�on, trusted applica�on-layer onboarding, device communica�ons intent enforcement, device lifecycle management, asset management, the dynamic assignment of devices to various network segments, and ongoing device authoriza�on. Aspects of these technologies that are relevant to their integra�on with network-layer onboarding are within scope. Demonstra�on of the general capabili�es of these technologies independent of onboarding, however, is not within the project’s scope. For example, demonstra�ng a policy that requires device atesta�on to be performed before the device will be permited to be onboarded is within scope. The details and general opera�on of the device atesta�on mechanism would be out of scope.

3.3 Assump�ons and Defini�ons NIST’s prior guidelines on Cybersecurity Supply Chain Risk Management Prac�ces for Systems and Organiza�ons, NIST SP 800-161r1-upd1 [11] and Foundational Activities for IoT Product Manufacturers, NIST IR 8259 [12] define terms such as “supply chain” and “IoT device.” In addi�on to the concepts established in these and other NIST guidelines, this project is guided by a variety of specific assump�ons and defini�ons, which are categorized by subsec�on below.

3.3.1 Creden�al Types There are several different creden�als that may be related to any given IoT device, making it important to be clear about which creden�al is being referred to. Two types of IoT device creden�als are involved in the network-layer onboarding process: birth creden�als and network creden�als. Birth creden�als are installed onto the device before it is released into the supply chain; trusted network-layer onboarding solu�ons use birth creden�als to authen�cate devices and securely provision them with their network creden�als. If supported by the device and the applica�on service provider, applica�on-layer creden�als may be provisioned to the device a�er

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

12

FINAL the device performs network-layer onboarding and connects to the network, during the applica�on-layer onboarding process. These different types of IoT device creden�als are defined as follows: 

Birth Creden�al: In order to par�cipate in trusted network-layer onboarding, devices must be equipped with a birth creden�al, which is some�mes also referred to as a device birth identity or birth certificate. A birth creden�al is a unique, authorita�ve creden�al that is generated or installed into secure storage on the IoT device during the premarket phase of the device’s lifecycle, i.e., before the device is released for sale. A manufacturer, integrator, or vendor typically generates or installs a birth creden�al onto an IoT device in the form of an Ini�al Device Iden�fier (IDevID) [13] and/or a public/private key pair. Birth creden�als



•

are permanent, and their value is independent of context;

•

enable the trusted network-layer onboarding process while keeping the device manufacturing process efficient; and

•

include a unique iden�ty and a secret and can range from simple raw public and private keys to X.509 cer�ficates that are signed by a trusted authority.

Network Creden�al: A network creden�al is the creden�al that is provisioned to an IoT device during network-layer onboarding. The network creden�al enables the device to connect to the local network securely. A device’s network creden�al may be changed repeatedly, as needed, by subsequent invoca�on of the trusted network-layer onboarding process.

Addi�onal types of creden�als that may also be associated with an IoT device are: 

Applica�on-Layer Creden�al: An applica�on-layer creden�al is a creden�al that is provisioned to an IoT device during applica�on-layer onboarding. A�er an IoT device has performed network-layer onboarding and connected to a network, it may be provisioned with one or more applica�on-layer creden�als during the applica�on-layer onboarding process. Each applica�on-layer creden�al is specific to a given applica�on and is typically unique to the device, and it may be replaced repeatedly over the course of the device’s life�me.



User Creden�al: An IoT device that permits authorized users to access it—and restricts access only to authorized users—will have one or more user creden�als associated with it. These creden�als are what the users present to the IoT device in order to gain access to it. The user creden�al is not relevant during network-layer onboarding and is generally not of interest within the scope of this project. We include it in this list only for completeness. Many IoT devices may not even have user creden�als associated with them.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

13

FINAL In order to perform network- and applica�on-layer onboarding, the device must already have been provisioned with birth creden�als. A pre-provisioned, unique, authorita�ve birth creden�al is essen�al for enabling the IoT device to be iden�fied and authen�cated as part of the trusted network-layer onboarding process, no mater what network the device is being onboarded to or how many �mes it is onboarded. The value of the birth creden�al is independent of context, whereas the network creden�al that is provisioned during network-layer onboarding is significant only with respect to the network to which the IoT device will connect. Each applica�on-layer creden�al that is provisioned during applica�on-layer onboarding is specific to a given applica�on, and each user creden�al is specific to a given user.

3.3.2 Integra�ng Security Enhancements Integra�ng addi�onal security mechanisms and technologies in the trusted network-layer IoT device onboarding can help increase trust in both the IoT device and the network. Examples of such security mechanism integra�ons demonstrated in this project include: 

Trusted Applica�on-Layer Onboarding: When available, applica�on-layer onboarding can occur automa�cally once a device connects to its local network. This process securely provides the device with the creden�als needed to connect to a trusted applica�on service. Given the large number of IoT devices in many networks, manual onboarding is o�en imprac�cal and can expose devices to risks from accidental or malicious misconfigura�on. Therefore, automated applica�on-layer onboarding is essen�al for maintaining the overall security of each IoT device, similar to network-layer onboarding. As part of the applica�on-layer onboarding process, devices and the applica�on services they interact with perform mutual authen�ca�on and establish an encrypted channel over which the applica�on service can download applica�on-layer creden�als and so�ware to the device. The device can then provide informa�on back to the applica�on service as appropriate. This process is useful for ensuring that IoT devices are execu�ng the most up-to-date versions of their intended applica�ons. Applica�on-layer onboarding can also be used to establish a secure associa�on between a device and a trusted lifecycle management service. This associa�on ensures that the IoT device con�nues to be patched and updated with the latest firmware and so�ware, thereby enabling the device to remain trusted throughout its lifecycle. Just as network-layer onboarding cannot be performed un�l a�er network-layer bootstrapping informa�on has been introduced to the device and the network the same applies for applica�on-layer onboarding. The network-layer bootstrapping informa�on enables the device and the network to mutually authen�cate and establish a secure channel. Similarly, applica�on-layer onboarding requires the introduc�on of applica�on-layer bootstrapping informa�on to the device and applica�on servers, enabling the device and the applica�on server to mutually authen�cate and establish a secure channel.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

14

FINAL •

Streamlined Application-Layer Onboarding—One poten�al mechanism for introducing this applica�on-layer bootstrapping informa�on to the device and the applica�on server is to use the network-layer onboarding process. The secure channel established during network-layer onboarding serves as a conduit for exchanging this informa�on. By protec�ng the integrity and confiden�ality of the bootstrapping data, the trusted network-layer onboarding mechanism ensures that the creden�als used for mutual authen�ca�on between the device and the applica�on server remain secure. This process establishes a solid founda�on for their secure associa�on, enabling a streamlined and secure applica�on-layer onboarding. We call an applica�on-layer onboarding process that uses network-layer onboarding to exchange applica�on-layer bootstrapping informa�on streamlined applica�on-layer onboarding.

•

Independent Application-Layer Onboarding—An alterna�ve mechanism for introducing applica�on-layer bootstrapping informa�on to the device is to provide this informa�on during the manufacturing process. During manufacturing, the IoT device can be provisioned with so�ware and associated bootstrapping informa�on that enables the device to mutually authen�cate with an applica�onlayer service a�er it has connected to the network. This mechanism for performing applica�on-layer onboarding does not rely on the network-layer onboarding process to provide applica�on-layer bootstrapping. All that is required is that the device have connec�vity to the applica�on-layer onboarding service a�er it has connected to the network. We call an applica�on-layer onboarding process that does not rely on network-layer onboarding to exchange applica�on-layer bootstrapping informa�on independent applica�on-layer onboarding.



Segmenta�on: Upon connec�on to the network, a device may be assigned to a par�cular local network segment based on enterprise policy, preven�ng unauthorized communica�on with other network components. This ensures the device, as well as others on the network, is isolated from or protected against other devices that do or do not meet certain criteria. A trusted network-layer onboarding mechanism can convey the informa�on used to determine to which network segment the device should be assigned upon connec�on. By conveying this informa�on in a manner that protects its integrity and confiden�ality, the trusted network-layer onboarding mechanism helps to increase assurance that the device will be assigned to the appropriate network segment. Postonboarding, if a device later becomes untrustworthy, such as due to vulnerabili�es, misconfigura�on, or suspicious behavior, it can be dynamically reassigned to a different segment for quaran�ne or have its network creden�als revoked or deleted.



Ongoing Device Authoriza�on: Once a device has been network-layer onboarded in a trusted manner and has possibly performed applica�on-layer onboarding as well, it is important that the device maintains a secure posture on the network. Ensuring the ongoing security of the device is important for keeping the device from being corrupted and for protec�ng the network from a poten�ally harmful device. Even though a device is authen�cated and authorized prior to being onboarded, the device should be subject

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

15

FINAL to ongoing policy-based authen�ca�on and authoriza�on as it con�nues to operate on the network. This may include monitoring device behavior and constraining communica�ons to and from the device as needed in accordance with policy. An ongoing device authoriza�on service can ensure that the device and its opera�ons con�nue to be authorized throughout the device’s tenure on the network. 

Device Communica�ons Intent Enforcement: Network-layer onboarding protocols can be used to securely transmit device communica�ons intent informa�on (e.g., a MUD file). Device communica�on intent informa�on defines how a device is intended to communicate on a network. This informa�on is securely transmited to the network (i.e., to transmit this informa�on in encrypted form with integrity protec�ons), where it can be enforced. A�er the device has securely connected to the network, the network can use this device communica�ons intent informa�on to ensure that the device sends and receives traffic only from authorized loca�ons. Secure conveyance of device communica�ons intent informa�on, combined with enforcement of it, ensures that IoT devices are constrained to sending and receiving only those communica�ons that are explicitly required for each device to fulfill its purpose.



Addi�onal Security Mechanisms: Although not demonstrated in this project, addi�onal security mechanisms can be integrated with network-layer onboarding, beginning at device boot-up and extending through all phases of the device lifecycle. Examples of such mechanisms include integra�on with supply chain management tools, device atesta�on, automated lifecycle management, mutual atesta�on, and centralized asset management. Overall, the applica�on of these and other security protec�ons can create a dependency chain of protec�ons. This chain is based on a hardware root of trust as its founda�on and extends up to support the security of the trusted network-layer onboarding process. The trusted network-layer onboarding process, in turn, may enable addi�onal capabili�es and provide a founda�on that makes them more secure, thereby helping to ensure the ongoing security of the device and, by extension, the network.

3.3.3 Device Limita�ons The security capabili�es that any onboarding solu�on can support depend on various factors related to the IoT device itself. These include the hardware, processing power, cryptographic modules, secure storage capacity, batery life, and the presence or absence of a human interface. Addi�onal considera�ons include whether the device supports features such as firmware verifica�on at boot �me, atesta�on, applica�on-layer onboarding, and device communica�ons intent enforcement. Furthermore, the supported onboarding protocols, other compa�ble protocols, and integra�on with supply-chain tools also play a significant role in determining the security capabili�es of the solu�on.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

16

FINAL Devices with greater capabili�es are generally able to support more advanced security measures and implement them more robustly. However, the level of assurance provided will vary based on the combined capabili�es of both the device and the onboarding solu�on.

3.3.4 Specifica�ons Are S�ll Improving Ideally, trusted network-layer onboarding solu�ons selected for widespread implementa�on and use will be openly available and standards-based. Some poten�al solu�on specifica�ons are s�ll being improved or are in development. In the mean�me, the immaturity of these specifica�ons may be a limi�ng factor in deploying opera�onal implementa�ons of the proposed capabili�es. For example, the details of running BRSKI over Wi-Fi are not fully specified at this �me.

3.4 Collaborators and Their Contribu�ons Organiza�ons par�cipa�ng in this project submited their capabili�es in response to an open call in the Federal Register for all sources of relevant security capabili�es from academia and industry (vendors and integrators). Listed below are the respondents with relevant capabili�es or product components (iden�fied as “Technology Partners/Collaborators” herein) who signed a CRADA to collaborate with NIST in a consor�um to build an example trusted IoT device networklayer onboarding solu�on.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

17

FINAL Technology Collaborators Aruba, a Hewlet Packard Enterprise company CableLabs Cisco

Foundries.io Kudelski IoT NquiringMinds NXP Semiconductors

Open Connec�vity Founda�on (OCF) Sandelman So�ware Works SEALSQ, a subsidiary of WISeKey Silicon Labs

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

18

FINAL Table 3-1 summarizes the capabili�es and components provided, or planned to be provided, by each partner/collaborator. Table 3-1 Capabili�es and Components Provided by Each Technology Partner/Collaborator Collaborator

Security Capability or Component Provided

Aruba

Infrastructure for trusted network-layer onboarding using the Wi-Fi Easy Connect protocol and application-layer onboarding to the UXI cloud. IoT devices for use with both Wi-Fi Easy Connect network-layer onboarding and applicationlayer onboarding. The UXI Dashboard provides for an “always-on” remote technician with near real-time data insights into network and application performance.

CableLabs

Infrastructure for trusted network-layer onboarding using the Wi-Fi Easy Connect protocol. IoT devices for use with both Wi-Fi Easy Connect network-layer onboarding and application-layer onboarding to the OCF security domain.

Cisco

Components to support network connectivity and network segmentation capabilities for various builds.

Foundries.io

Factory software for providing birth credentials into secure storage on IoT devices and for transferring device bootstrapping information from device manufacturer to device purchaser.

Kudelski IoT

Infrastructure for trusted application-layer onboarding of a device to the AWS IoT core. The service comes with a cloud platform and a software agent that enables secure provisioning of AWS credentials into the secure storage of IoT devices.

NquiringMinds

Infrastructure for trusted network-layer onboarding using BRSKI over 802.11. Service that performs ongoing monitoring of connected devices to ensure their continued authorization (i.e., continuous authorization service), as well as device communications intent enforcement.

NXP Semiconductors

IoT devices with secure storage for use with both Wi-Fi Easy Connect and BRSKI network-layer onboarding. Service for provisioning credentials into secure storage of IoT devices.

Open Connectivity Foundation (OCF)

Infrastructure for trusted application-layer onboarding to the OCF security domain using IoTivity, an open-source software framework that implements the OCF specification.

Sandelman Software Works

Infrastructure for trusted network-layer onboarding using BRSKI. IoT devices for use with BRSKI network-layer onboarding.

SEALSQ, a subsidiary of WISeKey

Secure storage elements, code, and software that simulates factory provisioning of birth credentials to those secure elements on IoT devices in support of both Wi-Fi Easy Connect and BRSKI network-layer onboarding; certificate authority for signing device certificates.

Silicon Labs

Infrastructure for connection to a Thread network that has access to other networks for application-layer onboarding. IoT device with secure storage for use with Thread network connection and application-layer onboarding using Kudelski IoT.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

19

FINAL

Each of these technology partners and collaborators has described the relevant products and capabili�es it brings to this trusted onboarding effort in the following subsec�ons. The NCCoE does not cer�fy, endorse, or validate products or services. We demonstrate the capabili�es that can be achieved by using par�cipants’ contributed technology.

3.4.1 Aruba, a Hewlet Packard Enterprise Company Aruba, a Hewlet Packard Enterprise (HPE) company, provides secure, intelligent edge-to-cloud networking solu�ons that use ar�ficial intelligence (AI) to automate the network, while harnessing data to drive business outcomes. With Aruba ESP (Edge Services Pla�orm) and as-a-service op�ons as part of the HPE GreenLake family, Aruba takes a cloud-na�ve approach to helping customers meet their connec�vity, security, and financial requirements across campus, branch, data center, and remote worker environments, covering all aspects of wired, wireless local area networking (LAN), and wide area networking (WAN). Aruba ESP provides unified solu�ons for connec�vity, visibility, and control throughout the IT-IoT workflow, with the objec�ve of helping organiza�ons accelerate IoT-driven digital transforma�on with greater ease, efficiency, and security. To learn more, visit Aruba.

3.4.1.1 Device Provisioning Protocol Device Provisioning Protocol (DPP), cer�fied under the Wi-Fi Alliance (WFA) as “Easy Connect,” is a standard developed by Aruba that allows IoT devices to be easily provisioned onto a secure network. DPP improves security by leveraging Wi-Fi Protected Access 3 (WPA3) to provide device-specific creden�als, enhance cer�ficate handling, and support robust, secure, and scalable provisioning of IoT devices in any commercial, industrial, government, or consumer applica�on. Aruba implements DPP through a combina�on of on-premises hardware and cloud-based services, as shown in Table 3-1.

3.4.1.2 Aruba Access Point (AP) From their unique vantage as ceiling furniture, Aruba Wi-Fi 6 APs have an unobstructed overhead view of all nearby devices. Built-in Bluetooth Low Energy (BLE) and Zigbee 802.15.4 IoT radios, as well as a flexible USB port, provide IoT device connec�vity that allows organiza�ons to address a broad range of IoT applica�ons with infrastructure already in place, elimina�ng the cost of gateways and IoT overlay networks while enhancing IoT security. Aruba’s APs enable a DPP network through an exis�ng Service Set Iden�fier (SSID), enforcing DPP access control and adver�sing the Configurator Connec�vity Informa�on Element (IE) to atract unprovisioned clients (i.e., clients that have not yet been onboarded). Paired with

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

20

FINAL Aruba’s cloud management service “Central”, the APs implement the DPP protocol. The AP performs the DPP network introduc�on protocol (Connector exchange) with provisioned clients and assigns network roles.

3.4.1.3 Aruba Central Aruba Central is a cloud-based networking solu�on with AI-powered insights, workflow automa�on, and edge-to-cloud security that empowers IT teams to manage and op�mize campus, branch, remote, data center, and IoT networks from a single point of visibility and control. Built on a cloud-na�ve, microservices architecture, Aruba Central is designed to simplify IT and IoT opera�ons, improve agility, and reduce costs by unifying management of all network infrastructure. Aruba’s “Central” Cloud DPP service exposes and controls many centralized func�ons to enable a seamless integrated end-to-end solu�on and act as a DPP service orchestrator. The cloud based DPP service selects an AP to authen�cate unprovisioned enrollees (in the event that mul�ple APs receive the client chirps). The DPP cloud service holds the Configurator signing key and generates Connectors for enrollees authen�cated through an AP.

3.4.1.4 IoT Opera�ons Available within Aruba Central, the IoT Opera�ons service extends network administrators’ view into IoT devices and applica�ons connected to the network. Organiza�ons can gain cri�cal visibility into previously invisible IoT devices, as well as reduce costs and complexity associated with deploying IoT applica�ons. IoT Opera�ons comprises three core elements: 

IoT Dashboard, which provides a granular view of devices connected to Aruba APs, as well as IoT connectors and applica�ons in use.



IoT App Store, a repository of click-and-go IoT applica�ons that interface with IoT devices and their data.



IoT Connector, which provisions mul�ple applica�ons to be computed at the edge for agile IoT applica�on support.

3.4.1.5 Client Insights Part of Aruba Central, AI-powered Client Insights automa�cally iden�fies each endpoint connec�ng to the network with up to 99% accuracy. Client Insights discovers and classifies all connected endpoints—including IoT devices—using built-in machine learning and dynamic profiling techniques, helping organiza�ons beter understand what’s on their networks, automate access privileges, and monitor the behavior of each endpoint’s traffic flows to more rapidly spot atacks and act.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

21

FINAL

3.4.1.6 Cloud Auth Cloud-na�ve network access control (NAC) solu�on Cloud Auth delivers �me-saving workflows to configure and manage onboarding, authoriza�on, and authen�ca�on policies for wired and wireless networks. Cloud Auth integrates with an organiza�on’s exis�ng cloud iden�ty store, such as Google Workspace or Azure Ac�ve Directory, to authen�cate IoT device informa�on and assign the right level of network access. Cloud Auth operates as the DPP Authoriza�on server and is the repository for trusted DPP Uniform Resource Iden�fiers (URIs) of unprovisioned enrollees. It maintains role informa�on for each unprovisioned DPP URI and provisioned devices based on unique per-device creden�als (public key extracted from Connector). Representa�onal State Transfer (RESTful) applica�on programming interfaces (APIs) provide extensible capabili�es to support third par�es, making an easy path for integra�on and collabora�ve deployments.

3.4.1.7 UXI Sensor: DPP Enrollee User Experience Insight (UXI) sensors con�nuously monitor end-user experience on customer networks and provide a simple-to-use cloud-based dashboard to assess networks and applica�ons. The UXI sensor is onboarded in a zero-touch experience using DPP. Once network-layer onboarding is complete, the UXI sensor performs applica�on-layer onboarding to the Aruba cloud to download a customer-specific profile. This profile enables the UXI sensor to perform con�nuous network tes�ng and monitoring, and to troubleshoot network issues that it finds.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

22

FINAL

Figure 3-1 Aruba/HPE DPP Onboarding Components

3.4.2 CableLabs CableLabs is an innova�on lab for future-forward research and development (R&D)—a global mee�ng of minds dedicated to building and orchestra�ng emergent technologies. By convening peers and experts to share knowledge, CableLabs’ objec�ve is to energize the industry ecosystem for speed and scale. Its research facilitates solu�ons with the goal of making connec�vity faster, easier, and more secure, and its conferences and events offer neutral mee�ng points to gain consensus. As part of this project, CableLabs has provided the reference pla�orm for its Custom Connec�vity architecture for the purpose of demonstra�ng trusted network-layer onboarding of Wi-Fi devices using a variety of creden�als. The following components are part of the reference platform.

3.4.2.1 Pla�orm Controller The controller provides interfaces and messaging for managing service deployment groups, access points with the deployment groups, registra�on and management of user services, and the secure onboarding and lifecycle management of users’ Wi-Fi devices. The controller also exposes APIs for integra�on with third-party systems for the purpose of integra�ng various business flows (e.g., integra�on with manufacturing process for device management).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

23

FINAL

3.4.2.2 Custom Connec�vity Gateway Agent The Gateway Agent is a so�ware component that resides on the Wi-Fi AP and gateway. It connects with the controller to coordinate the Wi-Fi and rou�ng capabili�es on the gateway. Specifically, it enforces the policies and configura�on from the controller by managing the lifecycle of the Wi-Fi Extended Service Set/Basic Service Set (ESS/BSS) on the AP, authen�ca�on and creden�als of the client devices that connect to the AP, and service management and rou�ng rules for various devices. It also manages secure onboarding capabili�es like Easy Connect, simple onboarding using a per-device pre-shared key (PSK), etc. The Gateway agent is provided in the form of an opera�onal Raspberry Pi-based Gateway that also includes hostapd for Wi-Fi/DPP and open-vswitch for the crea�on of trust domains and rou�ng.

3.4.2.3 Reference Clients Three Raspberry Pi-based reference clients are provided. The reference clients have support for WFA Easy Connect-based onboarding as well as support for different Wi-Fi creden�als, including per-device PSK and 802.1x cer�ficates. One of the reference clients also has support for OCFbased streamlined applica�on-layer onboarding.

3.4.3 Cisco Cisco Systems, or Cisco, delivers collabora�on, enterprise, and industrial networking and security solu�ons. The company’s cybersecurity team, Cisco Secure, is one of the largest cloud and network security providers in the world. Cisco’s Talos Intelligence Group, the largest commercial threat intelligence team in the world, is comprised of world-class threat researchers, analysts, and engineers, and supported by unrivaled telemetry and sophis�cated systems. The group feeds rapid and ac�onable threat intelligence to Cisco customers, products, and services to help iden�fy new threats quickly and defend against them. Cisco solu�ons are built to work together and integrate into environments, using the “network as a sensor” and “network as an enforcer” approach to both make teams more efficient and keep enterprises secure. To learn more, visit Cisco.

3.4.3.1 Cisco Catalyst Switch A Cisco Catalyst 3850-S is an enterprise-grade, stackable network switch that provides highspeed wired connec�vity, supports Power over Ethernet (PoE) for powering devices, and enables network segmenta�on through Virtual Local Area Networks (VLANs). It offers reliable performance, redundancy features, and can integrate both wired and wireless devices. For this project the switch provides wired connec�vity and network segmenta�on, however it is not used for advanced or proprietary Cisco features beyond these standard capabili�es.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

24

FINAL

3.4.4 Foundries.io Foundries.io helps organiza�ons bring secure IoT and edge devices to market faster. The FoundriesFactory cloud pla�orm offers DevOps teams a secure Linux-based firmware/opera�ng system (OS) pla�orm with device and fleet management services for connected devices, based on a fixed no-royalty subscrip�on model. Product development teams gain enhanced security from boot to cloud while reducing the cost of developing, deploying, and upda�ng devices across their installed life�me. The open-source pla�orm interfaces to any cloud and offers Foundries.io customers maximum flexibility for hardware configura�on, so organiza�ons can focus on their intellectual property, applica�ons, and value add. For more informa�on, visit Foundries.

3.4.4.1 FoundriesFactory FoundriesFactory is a cloud-based so�ware pla�orm provided by Foundries.io that offers a complete development and deployment environment for crea�ng secure IoT devices. It provides a set of tools and services that enable developers to create, test, and deploy custom firmware images, as well as manage the lifecycle of their IoT devices. Customizable components include open-source secure boot so�ware, the open-source Linux microPla�orm (LmP) distribu�on built with Yocto and designed for secure managed IoT and edge products, secure Over the Air (OTA) update facili�es, and a Docker run�me for managing containerized applica�ons and services. The pla�orm is cross-architecture (x86, Arm, and RISCV) and enables secure connec�ons to public and private cloud services. Leveraging open standards and open so�ware, FoundriesFactory is designed to simplify and accelerate the process of developing, deploying, and managing IoT and edge devices at scale, while also helping ensure that they are secure and up to date over the product life�me.

3.4.5 Kudelski IoT Kudelski IoT is the Internet of Things division of Kudelski Group and provides end-to-end IoT solu�ons, IoT product design, and full-lifecycle services to IoT semiconductor and device manufacturers, ecosystem creators, and end-user companies. These solu�ons and services leverage the group’s 30+ years of innova�on in digital business model crea�on; hardware, so�ware, and ecosystem design and tes�ng; state-of-the-art security lifecycle management technologies and services; and managed opera�on of complex systems.

3.4.5.1 Kudelski IoT keySTREAM™ Kudelski IoT keySTREAM is a device-to-cloud, end-to-end solu�on for securing all the key assets of an IoT ecosystem during its en�re lifecycle. The system provides each device with a unique, immutable, unclonable iden�ty that forms the founda�on for cri�cal IoT security func�ons like

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

25

FINAL in-factory or in-field provisioning, data encryp�on, authen�ca�on, and secure firmware updates, as well as allowing companies to revoke network access for vulnerable devices if necessary. This ensures that the en�re lifecycle of the device and its data can be managed. In this project, keySTREAM is used to enable trusted applica�on-layer onboarding. It manages the atesta�on of devices, ownership, and provisioning of applica�on creden�als.

3.4.6 NquiringMinds NquiringMinds provides intelligent, trusted systems, combining AI-powered analy�cs with cybersecurity fundamentals. tdx Volt is the NquiringMinds general-purpose zero-trust services infrastructure pla�orm, upon which it has built Cyber tdx, a cogni�vely enhanced cyber defense service designed for IoT. Both products are the latest itera�on of the TDX product family. NquiringMinds is a UK company. Since 2010, it has been deploying its solu�ons into smart ci�es, health care, industrial, agricultural, financial technology, defense, and security sectors. NquiringMinds collaborates within the open-standards and open-source community. It focuses on the principle of con�nuous assurance: the ability to con�nually reassess security risk by intelligently reasoning across the hard and so� informa�on sources available. NquiringMinds’ primary contribu�ons to this project, described in the subsec�ons below, are being made available as open source.

3.4.6.1 NquiringMinds’ BRSKI Protocol Implementa�on NquiringMinds has open sourced their so�ware implementa�on of IETF’s Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, which provides a solu�on for secure zero-touch (automated) bootstrap of new (unconfigured) devices. This implementa�on includes the necessary adapta�ons for BRKSI to work with Wi-Fi networks. The open source BRSKI implementa�on is available under an Apache 2.0 license on GitHub.

3.4.6.2 TrustNetZ NquiringMinds has open sourced the TrustNetZ (Zero Trust Networking) so�ware stack which sits on top of their BRSKI implementa�on. TrustNetZ embodies the network onboarding and lifecycle management concepts into an easy to replicate demonstrator which includes the IoT device, the router, the router onboarding, the registrar, the manufacturer, the manufacturer provisioning, policy enforcement and con�nuous assurance servers. This so�ware also encapsulates NquiringMinds’ con�nuous assurance capability, enhancing the security of the network by con�nually assessing whether connected IoT devices meet the policy requirements of the network. The so�ware also includes a flexible, verifiable creden�al-based

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

26

FINAL policy framework aligning with World Wide Web Consor�um (W3C) verifiable creden�als specifica�on, which can rapidly be adapted to model different security and business model scenarios. The implementa�on models networking onboarding flows with EAP-TLS Wi-Fi cer�ficates. The open source TrustNetZ implementa�on is available under an Apache 2.0 license on GitHub.

3.4.6.3 edgeSEC edgeSEC is an open-source, OpenWrt-based implementa�on of an intelligent secure router. It implements, on an open stack, the key components needed to implement both trusted onboarding and con�nuous assurance of devices. It contains an implementa�on of the Internet Engineering Task Force (IETF) BRSKI protocols, with the necessary adapta�ons for wireless onboarding, fully integrated into an open opera�onal router. It addi�onally implements device communica�ons intent constraints (IETF Manufacturer Usage Descrip�on [MUD]) and behavior monitoring (IoTSF ManySecured) that support some of the more enhanced trusted onboarding use cases. EdgeSEC addi�onally provides the pla�orm for an asynchronous control plane for the con�nuous management of mul�ple routers and a general-purpose policy evalua�on point, which can be used to demonstrate the breadth of onboarding and monitoring use cases that can be supported. EdgeSEC is not directly used in the build that was demonstrated for this project, but it contains cri�cal pieces of code that have been adapted in a simplified manner for the TrustNetZ implementa�on. The open source edgeSEC implementa�on is available under an Apache 2.0 license on GitHub.

3.4.6.4 tdx Volt tdx Volt is NquiringMinds’ zero-trust infrastructure pla�orm. It encapsulates iden�ty management, creden�al management, service discovery, and smart policy evalua�on. This pla�orm is designed to simplify the end-to-end demonstra�on of the trusted onboarding process and provides tools for use on the IoT device, the router, applica�ons, and clouds. Tdx Volt is used by the TrustNetZ demonstrator as a verifiable creden�al issuer and verifier. Tdx Volt is an NquiringMinds’ product, documented working implementa�ons are available online at tdx Volt.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

27

FINAL

3.4.6.5 Reference Hardware For demonstra�on purposes, the NquiringMinds components can be deployed using the following hardware: Compute hosts: Raspberry Pi 4 The Raspberry Pis host the IoT client device, the router, and all addi�onal compute services. Other Raspberry Pi models are likely to work but have not been tested. Addi�onal details for the product used for this build can be found at Raspberry Pi. TPM/Secure Element The secure storage for the IoT device (used in network-layer onboarding and factory provisioning) is provided by an Infineon Op�ga SLB 9670 TPM 2.0, integrated through a GeeekPi TPM hat. Addi�onal details for the product used in this build can be found at Infineon. A working version of the code is also available u�lizing the SEALSQ Secure element found at SEALSQ.

3.4.7 NXP Semiconductors NXP Semiconductors focuses on secure connec�vity solu�ons for embedded applica�ons, NXP is impac�ng the automo�ve, industrial, and IoT, mobile, and communica�on infrastructure markets. Find out more at NXP.

3.4.7.1 EdgeLock SE050 secure element The EdgeLock SE050 secure element (SE) product family offers strong protec�on against the latest atack scenarios and an extended feature set for a broad range of IoT use cases. This readyto-use secure element for IoT devices provides a root of trust at the silicon level and delivers real end-to-end security—from edge to cloud—with a comprehensive so�ware package for integra�on into any type of device.

3.4.7.2 EdgeLock 2GO EdgeLock 2GO is the NXP service pla�orm designed for easy and secure deployment and management of IoT devices. This flexible IoT service pla�orm lets device manufacturers and service providers choose the appropriate op�ons to op�mize costs while benefi�ng from an advanced level of device security. The EdgeLock 2GO service provisions the cryptographic keys and cer�ficates into the hardware root of trust of the IoT devices and simplifies the onboarding of the devices to the cloud.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

28

FINAL

3.4.7.3 i.MX 8M family The i.MX 8M family of applica�ons processors based on Arm® Cortex®-A53 and Cortex-M4 cores provide advanced audio, voice, and video processing for applica�ons that scale from consumer home audio to industrial building automa�on and mobile computers. It includes support for secure boot, secure debug, and lifecycle management, as well as integrated cryptographic accelerators. The development boards and Linux Board Support Package enablement provide out-ofthe-box integra�on with an external SE050 secure element.

3.4.8 Open Connec�vity Founda�on (OCF) OCF is a standards-developing organiza�on that has had contribu�ons and par�cipa�on from over 450+ member organiza�ons represen�ng the full spectrum of the IoT ecosystem, from chip makers to consumer electronics manufacturers, silicon enablement so�ware pla�orm and service providers, and network operators. The OCF specifica�on is an Interna�onal Organiza�on for Standardiza�on/Interna�onal Electrotechnical Commission (ISO/IEC) interna�onally recognized standard that was built in tandem with an open-source reference implementa�on called IoTivity. Addi�onally, OCF provides an in-depth tes�ng and cer�fica�on program.

3.4.8.1 IoTivity OCF has contributed open-source code from IoTivity that demonstrates the advantage of secure network-layer onboarding and implements the WFA’s Easy Connect to power a seamless bootstrapping of secure and trusted applica�on-layer onboarding of IoT devices with minimal user interac�on. This code includes the interac�on layer, called the OCF Diplomat, which handles secure communica�on between the DPP-enabled access point and the OCF applica�on layer. The OCF onboarding tool (OBT) is used to configure and provision devices with opera�onal creden�als. The OCF reference implementa�on of a basic lamp is used to demonstrate both network- and applica�on-layer onboarding and to show that once onboarded and provisioned, the OBT can securely interact with the lamp.

3.4.9 Sandelman So�ware Works Sandelman So�ware Works (SSW) provides consul�ng and so�ware design services in the areas of systems and network security. A complete stack company, SSW provides consul�ng and design services from the hardware driver level up to Internet Protocol Security (IPsec), Transport Layer Security (TLS), and cloud database op�miza�on. SSW has been involved with the IETF since the 1990s, now dealing with the difficult problem of providing security for IoT systems. SSW leads standardiza�on efforts through a combina�on of running code and rough consensus.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

29

FINAL

3.4.9.1 Minerva Highway IoT Network-Layer Onboarding and Lifecycle Management System The Highway component is a cloud-na�ve component operated by the device manufacturer (or its authorized designate). It provides the Request for Comments (RFC) 8995 [6] specified Manufacturer Authorized Signing Authority (MASA) for the BRSKI onboarding mechanism. Highway is an asset manager for IoT devices. In its asset database, it maintains an inventory of devices that have been manufactured, what type they are, and who the current owner of the device is (if it has been sold). Highway does this by taking control of the complete iden�ty lifecycle of the device. It can aid in provisioning new device iden�ty cer�ficates (IDevIDs) by collecting Cer�ficate Signing Requests and returning cer�ficates, or by genera�ng the new iden��es itself. This is consistent with the sec�ons describing on-device private key genera�on and offdevice private key genera�on of IRTF “A Taxonomy of opera�onal security considera�ons for manufacturer installed keys and Trust Anchors.” Highway can act as a standalone three-level private-public key infrastructure (PKI). Integra�ons with Automa�c Cer�ficate Management Environment (RFC 8555) allow it to provision cer�ficates from an external PKI using the DNS-01 challenge in Sec�on 8.4 of RFC 8555. Hardware integra�ons allow for the private key opera�ons to be moved out of the main central processing unit (CPU). However, the needs of a busy produc�on line in a factory would require con�nuous access to the hardware offload. In prac�ce, customers put the subordinate CA into Highway, which it needs to sign new IDevIDs, and put the trust anchor private CA into a hardware security module (HSM). Highway provides a BRSKI-MASA interface running on a public TCP/HTTPS port (usually 443 or 9443). This service requires access to the private key associated with the anchor that has been “baked into” the IoT device (i.e., ‘Pledge’ in RFC 8995) during manufacturing. The Highway instance that speaks to the world in this way does not have to be the same instance that signs IDevID cer�ficates, and there are significant security advantages to separa�ng them. Both instances do need access to the same database servers, and there are a variety of database replica�on techniques that can be used to improve resilience and security. As IDevIDs do not expire, Highway does not presently include any mechanism to revoke IDevIDs, nor does it provide Cer�ficate Revoca�on Lists (CRLs) or Online Cer�ficate Status Protocol (OCSP). It is unclear how those mechanisms can work in prac�ce. Highway supports two models. In the Sales Integra�on model, the intended owner is known in advance. This model requires customer-specific integra�ons, which o�en occur at the database level through views or other SQL tools. In the trust on first use (TOFU) model, the first customer to claim a product becomes its owner. NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

30

FINAL

3.4.10 SEALSQ, a subsidiary of WISeKey WISeKey Interna�onal Holding Ltd. (WISeKey) is a cybersecurity company that deploys digital iden�ty ecosystems and secures IoT solu�on pla�orms. SEALSQ is a subsidiary of WISeKey that designs and sells secure microcontrollers, PKI, and iden�ty provisioning services while developing post-quantum technology hardware and so�ware products. SEALSQ products and solu�ons are used across a variety of applica�ons today, from mul�-factor authen�ca�on devices, home automa�on systems, and network infrastructure, to automo�ve, industrial automa�on, and control systems.

3.4.11 VaultIC408 The VaultIC408 secure element combines hardware-based key storage with cryptographic accelerators to provide a wide array of cryptographic features, including iden�ty, authen�ca�on, encryp�on, key agreement, and data integrity. It protects against hardware atacks such as microprobing and side channels. The fundamental cryptography of the VaultIC family includes NIST-recommended algorithms and key lengths. Each of these algorithms, Ellip�c Curve Cryptography (ECC), Rivest-ShamirAdleman (RSA), and Advanced Encryp�on Standard (AES), is implemented on-chip and uses onchip storage of the secret key material so the secrets are always protected in the secure hardware. The secure storage and cryptographic accelera�on support use cases like network and IoT end node security, pla�orm security, secure boot, secure firmware download, secure communica�on or TLS, data confiden�ality, encryp�on key storage, and data integrity.

3.4.11.1 INeS Cer�ficate Management System (CMS) SEALSQ’s por�olio includes INeS, a managed PKI-as-a-service solu�on. INeS leverages the WISeKey Webtrust-accredited trust services pla�orm, a Mater-approved Product Atesta�on Authority (PAA), and custom CAs. These PKI technologies support large-scale IoT deployments, where IoT endpoints will require cer�ficates to establish their iden��es. The INeS CMS pla�orm provides a secure, scalable, and manageable trust model. INeS CMS provides cer�ficate management, CA management, public cloud integra�on and automa�on, role-based access control (RBAC), and APIs for custom implementa�ons.

3.4.12 Silicon Labs Silicon Labs provides products in the area of secure, intelligent wireless technology for a more connected world. Securing IoT is challenging. It’s also mission-cri�cal. The challenge of protecting connected devices against frequently surfacing IoT security vulnerabili�es follows device NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

31

FINAL makers throughout the en�re product lifecycle. Protec�ng products in a connected world is a necessity as customer data and modern online business models are increasingly targets for costly hacks and corporate brand damage. To stay secure, device makers need an underlying security pla�orm in the hardware, so�ware, network, and cloud. Silicon Labs offers security products with features that address escala�ng IoT threats, with the goal of reducing the risk of IoT ecosystem security breaches and the compromise of intellectual property and revenue loss from counterfei�ng. For this project, Silicon Labs has provided a host pla�orm for the OpenThread border router (OTBR), a Thread radio transceiver, and an IoT device to be onboarded to the AWS cloud service, which communicates using the Thread wireless protocol.

3.4.12.1 OpenThread Border Router Pla�orm A Raspberry Pi serves as the host pla�orm for the OTBR. The OTBR forms a Thread network and acts as a bridge between the Thread network and the public internet, allowing the IoT device that communicates using the Thread wireless protocol and that is to be onboarded to communicate with cloud services. The OTBR’s connec�on to the internet can be made through either WiFi or ethernet. Connec�on to the SLWSTK6023A (see Sec�on 3.4.12.2) is made through a USB serial port.

3.4.12.2 SLWSTK6023A Thread Radio Transceiver The SLWSTK6023A (Wireless starter kit) acts as a Thread radio transceiver or radio coprocessor (RCP). This allows the OTBR host pla�orm to form and communicate with a Thread network.

3.4.12.3 xG24-DK2601B Thread “End” Device The xG24-DK2601B is the IoT device that is to be onboarded to the cloud service (AWS). It communicates using the Thread wireless protocol. Communica�on is bridged between the Thread network and the internet by the OTBR.

3.4.12.4 Kudelski IoT keySTREAM™ The Kudelski IoT keySTREAM solu�on is described more fully in Sec�on 3.4.5.1. It is a cloud service capable of verifying the hardware-based secure iden�ty cer�ficate chain associated with the xG24-DK2601B component described in Sec�on 3.4.12.3 and delivering a new cer�ficate chain that can be refreshed or revoked as needed to assist with lifecycle management. The cer�ficate chain is used to authen�cate the xG24-DK2601B device to the cloud service (AWS). Figure 3-2 shows the rela�onships among the components provided by Silicon Labs and Kudelski IoT that support the trusted applica�on-layer onboarding of an IoT device that communicates via the Thread protocol to AWS IoT.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

32

FINAL

Figure 3-2 Components for Onboarding an IoT Device that Communicates Using Thread to AWS IoT

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

33

FINAL

4 Reference Architecture Figure 4-1 depicts the reference architecture to demonstrate trusted IoT device network-layer onboarding and lifecycle management used throughout this Prac�ce Guide. This architecture shows a high-level, protocol-agnos�c, and generic approach to trusted network-layer onboarding. It represents the basic components and processes, regardless of the network-layer onboarding protocol used and the par�cular device lifecycle management ac�vi�es supported. When implemen�ng this architecture, an organiza�on can follow different steps and use different components. The exact steps that are performed may not be in the same order as the steps in the logical reference architecture, and they may use components that do not have a one-toone correspondence with the logical components in the logical reference architecture. In Appendix C, Appendix D, Appendix E, Appendix F, and Appendix G, we present the architectures for builds 1, 2, 3, 4, and 5, respec�vely, each of which is an instan�a�on of this logical reference architecture. Those build-specific architectures are more detailed and are described in terms of specific collaborator components and trusted network-layer onboarding protocols. Some steps or components of this architecture are intended primarily for an IoT device’s manufacturer, while others are intended for the IoT device’s customers. For more informa�on about how a customer can consider IoT device cybersecurity and help determine if and how they should implement trusted network-layer onboarding on their network, see IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements, SP 800-213 [14]. When customers desire to use trusted network-layer onboarding, implementa�on of this solu�on by IoT manufacturers will par�ally support the Interface Access Control capabilities as defined in IoT Device Cybersecurity Capability Core Baseline, NISTIR 8259A [15] and the Documentation capabilities as defined in IoT Non-Technical Supporting Capability Core Baseline, NISTIR 8259B [16], and would also par�ally support those same capabili�es as defined in IoT Device Cybersecurity Guidance for the Federal Government: IoT Device Cybersecurity Requirement Catalog, SP 800-213A [17]. For more informa�on about general cybersecurity considera�ons in the development of IoT devices for manufacturers, see Foundational Cybersecurity Activities for IoT Product Manufacturers, NISTIR 8259 Rev. 1 [17].

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

34

FINAL

Figure 4-1 Trusted IoT Device Network-Layer Onboarding and Lifecycle Management Logical Reference Architecture There are five high-level processes to carry out this architecture, as labeled in Figure 4-1. These five processes are as follows: 1. Device manufacture and factory provisioning – the activities that the IoT device manufacturer performs to prepare the IoT device so that it is capable of network- and application-layer onboarding (Figure 4-2, Section 4.1). 2. Device ownership and bootstrapping information transfer – the transfer of IoT device ownership and bootstrapping information from the manufacturer to the device and/or the device’s owner that enables the owner or an entity authorized by the owner to onboard the device securely. The component in Figure 4-1 labeled “Supply Chain Integration Service” represents the mechanism used to accomplish this information transfer (Figure 4-3, Section 4.2). 3. Trusted network-layer onboarding – the interactions that occur between the network-layer onboarding component and the IoT device to mutually authenticate, confirm authorization, establish a secure channel, and provision the device with its network credentials (Figure 4-4, Section 4.3). 4. Trusted application-layer onboarding – the interactions that occur between a trusted application server and the IoT device to mutually authenticate, establish a secure channel, and provision the device with application-layer credentials (Figure 4-5, Section 4.4). 5. Continuous verification – ongoing, policy-based verification and authorization checks on the IoT device to support device lifecycle monitoring and control (Figure 4-6, Section 4.5).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

35

FINAL Figure 4-1 uses two colors. The dark blue components are central to suppor�ng trusted network-layer onboarding itself, while the light blue components support the other aspects of the architecture. The subsec�ons below explain each of the five processes in more detail.

4.1 Device Manufacture and Factory Provisioning Process Figure 4-2 depicts the device manufacture and factory provisioning process in more detail. As shown in Figure 4-2, the manufacturer is responsible for crea�ng the IoT device and provisioning it with the necessary hardware, so�ware, and birth creden�als so that it is capable of network-layer onboarding. The IoT device should be manufactured with a secure root of trust as a best prac�ce, possibly as part of a secure manufacturing process, par�cularly when outsourced. Visibility and control over the provisioning process and manufacturing supply chain, par�cularly for outsourced manufacturing, is cri�cal in order to mi�gate the risk of compromise in the supply chain, which could lead to the introduc�on of compromised devices. The CA component is shown in light blue in Figure 4-2 because its use is op�onal and depends on the type of creden�al that is being provisioned to the device (i.e., whether it is an 802.1AR cer�ficate).

Figure 4-2 IoT Device Manufacture and Factory Provisioning Process At a high level, the steps that the manufacturer or an integrator performs as part of this prepara�on process, as shown in Figure 4-2, are as follows: 1. Create the IoT device and assign it a unique identifier (e.g., a serial number). Equip the device with secure storage. 2. Equip the device to run a specific network-layer onboarding protocol (e.g., Wi-Fi Easy Connect, BRSKI, Thread Mesh Commissioning Protocol (MeshCoP) [7]). This step includes ensuring that the device has the software/firmware needed to run the onboarding protocol as well as any additional information that may be required. 3. Generate or install the device’s unique birth credential into the device’s secure storage. [Note: using a secure element that has the ability to autonomously generate private/public root key

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

36

FINAL pairs is inherently more secure than performing credential injection, which has the potential to expose the private key.] The birth credential includes information that must be kept secret (i.e., the device’s private key) because it is what enables the device’s identity to be authenticated. The contents of the birth credential will depend on what network-layer onboarding protocol the device supports. For example: a. If the device runs the Wi-Fi Easy Connect protocol, its birth credential will take the form of a unique private key, which has an associated DPP URI that includes the corresponding public key and possibly additional information such as Wi-Fi channel and serial number. b. If the device runs the BRSKI protocol, its birth credential takes the form of an 802.1AR certificate that gets installed as the device’s IDevID and corresponding private key. The IDevID includes the device’s public key, the location of the MASA, and trust anchors that can be used to verify vouchers signed by the MASA. The 802.1AR certificate needs to be signed by a trusted signing authority prior to installation, as shown in Figure 4-2. 4. Install any additional information that may be required to support related capabilities that are enabled by network-layer onboarding. The specific contents of the information that gets installed on the device will vary according to what capabilities it is intended to support. For example, if the device supports: a. streamlined application-layer onboarding (see Section 3.3.2), then the bootstrapping information that is required to enable the device and a trusted application server to find and mutually authenticate each other and establish a secure association will be stored on the device. This is so it can be sent to the network during network-layer onboarding and used to automatically perform application-layer onboarding after the device has securely connected to the network. The Wi-Fi Easy Connect protocol, for example, can include such application-layer bootstrapping information as third-party information in its protocol exchange with the network, and Build 2 (i.e., the Wi-Fi Easy Connect, CableLabs, OCF build) demonstrates use of this mechanism to support streamlined application-layer onboarding. Note, however, that a device may still be capable of performing independent [see Section 3.3.2] application-layer onboarding even if the application-layer onboarding information is not exchanged as part of the network-layer onboarding protocol. The application that is installed on the device, i.e., the application that the device executes to fulfill its purpose, may include application-layer bootstrapping information that enables it to perform application-layer onboarding when it begins executing. Build 1 (i.e., the Wi-Fi Easy Connect, Aruba/HPE build) demonstrates independent application-layer onboarding. b. device communications intent, then the URI required to enable the network to locate the device’s intent information may be stored on the device so that it can be sent to the network during network-layer onboarding. After the device has securely connected to the network, the network can use this device’s communications intent information to ensure that the device sends and receives traffic only from authorized locations. The URI

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

37

FINAL and device communications intent information itself should be protected from unauthorized modification. 5. Maintain a record of the device’s serial number (or other uniquely identifying information) and the device’s bootstrapping information. The manufacturer will take note of the device’s ID and its bootstrapping information and store these. Eventually, when the device is sold, the manufacturer will need to provide the device’s owner with its bootstrapping information. The contents of the device’s bootstrapping information will depend on what network-layer onboarding protocol the device supports. For example: a. If the device runs the Wi-Fi Easy Connect protocol, its bootstrapping information is the DPP URI that is associated with its private key. b. If the device runs the BRSKI protocol, its bootstrapping information is its 802.1AR certificate.

4.2 Device Ownership and Bootstrapping Informa�on Transfer Process Figure 4-3 depicts the ac�vi�es that are performed to transfer device bootstrapping informa�on from the device manufacturer to the device owner, as well as to transfer device ownership informa�on to the device itself, if appropriate. A high-level summary of these ac�vi�es is described in the steps labeled 1, 2, and 3. The figure uses two colors. The dark-blue components are those used in the network-layer onboarding process. They are the same components as those depicted in the trusted networklayer onboarding process diagram provided in Figure 4-4. The light-blue components and their accompanying steps depict the por�on of the diagram that is specific to device ownership and bootstrapping informa�on transfer ac�vi�es.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

38

FINAL

Figure 4-3 Device Ownership and Bootstrapping Informa�on Transfer Process These steps are as follows: 1. The device manufacturer makes the device serial number, bootstrapping information, and ownership information available so that the organization or individual who has purchased the device will have the device’s serial number and bootstrapping information, and the device itself can be informed of who its owner is. In Figure 4-3, the manufacturer is shown sending this information to the supply chain integration service, which ensures that the necessary information ultimately reaches the device owner’s authorization service as well as the device itself, if appropriate. (This description of the process is deliberately simple in order to enable it to be general enough that it applies to a variety of network-layer onboarding protocols.) In reality, the supply chain integration service mechanism for forwarding this bootstrapping information from the manufacturer to the owner may take many forms. For example, when BRSKI is used, the manufacturer sends the device serial number and bootstrapping information to a MASA that both the device and its owner trust. When other network-layer onboarding protocols are used, the device manufacturer may provide the device owner with this bootstrapping information directly by uploading this information to the owner’s portion of a trusted cloud. Such a mechanism is useful for the case in which the owner is a large enterprise that has made a bulk purchase of many IoT devices. In this case, the manufacturer can upload the information for hundreds or thousands of IoT devices to the supply chain integration service at once. We call this the enterprise use case. Alternatively, the device manufacturer may provide this information to the device owner indirectly by including it on or in the packaging of an IoT device that is sold at retail. We call this the consumer use case.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

39

FINAL The contents of the device bootstrapping information will also vary according to the networklayer onboarding protocol that the device supports. For example, if the device supports the WiFi Easy Connect network-layer onboarding protocol, the bootstrapping information will consist of the device’s DPP URI. If the device supports the BRSKI network-layer onboarding protocol, bootstrapping information will consist of the device’s IDevID (i.e., its 802.1AR certificate). 2. The supply chain integration service forwards the device serial number and bootstrapping information to an authorization service that has connectivity to the network-layer onboarding component that will onboard the device (i.e., to a network-layer onboarding component that belongs either to the device owner or to an entity that the device owner has authorized to onboard the device). The network-layer onboarding component will use the device’s bootstrapping information to authenticate the device and verify that it is expected and authorized to be onboarded to the network. This forwarding process can vary widely depending on whether it involves an enterprise or consumer use case. Within each use case type, different mechanisms may be employed. For example: a. Information may be moved within the device owner’s portion of a trusted cloud. b. Data might be transferred via a standardized protocol operating between the MASA (Manufacturer Authorized Signing Authority) and the onboarding network’s domain registrar. c. Alternatively, a mobile app might scan information from a QR code on the device packaging. In the case in which BRSKI is used, a certificate authority is consulted to help validate the signature of the 802.1AR certificate that comprises the device bootstrapping information. 3. The supply chain integration service may also provide the device with information about who its owner is. Knowing who its owner is enables the device to ensure that the network that is trying to onboard it is authorized to do so, because it is assumed that if a network owns a device, it is authorized to onboard it. The mechanisms for providing the device with assurance that the network that is trying to onboard it is authorized to do so can take a variety of forms, depending on the network-layer onboarding protocol being used. For example, if the Wi-Fi Easy Connect protocol is being used, then if an entity is in possession of the device’s public key, that entity is assumed to be authorized to onboard the device. If BRSKI is being used, the device will be provided with a signed voucher verifying that the network that is trying to onboard the device is authorized to do so. The voucher is signed by the MASA. Because the device manufacturer has installed trust anchors for the MASA onto the device, the device trusts the MASA. It is also able to verify the MASA’s signature. In this document, for the sake of simplicity, we often refer to the network that is authorized to onboard a device as the device owner’s network. In reality, it may not always be the case that the device’s owner also owns the network to which the device is being onboarded. While it is assumed that a network that owns a device is authorized to onboard it, and the device and the onboarding network are often owned by the same entity, common ownership is not a requirement. The network that is onboarding a device does not have to be the owner of that device.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

40

FINAL The network owner may permit devices that it does not own to be onboarded to the network. In order for such a device to be onboarded, the network owner must be in possession of the device’s bootstrapping information. By accepting the bootstrapping information, the network owner is implicitly authorizing the device to be onboarded to its network. Conversely, a device may permit itself to be onboarded to a network that is not owned by the device’s owner. A device owner that wants to authorize a network to onboard the device needs to ensure that the device trusts the onboarding network. The specific mechanism for accomplishing this will vary according to the network-layer onboarding protocol being used. When the Wi-Fi Easy Connect protocol is being used, simply providing the network with the device’s public key is sufficient to authorize the network to onboard the device. When BRSKI is being used, the voucher that the MASA provides to the device must authorize the network to onboard it. Authentication of the network by the device may also take a variety of forms. These may range from simply trusting the person who is onboarding the device to onboard it to the correct network, to providing the IoT device with the network’s public key.

4.3 Trusted Network-Layer Onboarding Process Figure 4-4 depicts the trusted network-layer onboarding process in more detail. It shows the interac�ons that occur between the network-layer onboarding component and the IoT device to mutually authen�cate, confirm that the device is authorized to be onboarded to the network, confirm that the network is authorized to onboard the device, establish a secure channel, and provision the device with its network creden�als.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

41

FINAL

IoT Devices (1)Device enters onboarding mode

(8) Use network credentials to connect to the network securely

(2)Trusted introduction of device and network bootstrapping information (3) Device and network authentication (4) Verify that the network is authorized to onboard the device

Secure storage

Access Point, Router, or Switch (7) Provision network credentials to the device

(6) Establish a secure channel (denoted by ) Network Onboarding Component

(5) Verify that device is authorized to be onboarded to the network

NetworkLayer Onboarding Authorization Service

Figure 4-4 Trusted Network-Layer Onboarding Process The numbered arrows in the diagram are intended to provide a high-level summary of the network-layer onboarding steps. These steps are assumed to occur a�er any device bootstrapping informa�on and ownership transfer ac�vi�es (as described in the previous sec�on) that may need to be performed. The steps of the trusted network-layer onboarding process are as follows: 1. Device enters into onboarding mode - the IoT device to be onboarded is placed in onboarding mode, i.e., it is put into a state such that it is actively listening for and/or sending initial onboarding protocol messages. 2. Trusted introduction of device and network bootstrapping information - any required device bootstrapping information that has not already been provided to the network and any required network bootstrapping information that has not already been provided to the device are introduced in a trusted manner. 3. Device and network authentication - using the device and network bootstrapping information that has been provided, the network authenticates the identity of the IoT device (e.g., by ensuring that the IoT device is in possession of the private key that corresponds with the public key for the device that was provided as part of the device’s bootstrapping information), and the IoT device authenticates the identity of the network (e.g., by ensuring that the network is in possession of the private key that corresponds with the public key for the network that was provided as part of the network’s bootstrapping information).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

42

FINAL 4. Verify that the network is authorized to onboard the device - the device verifies that the network is authorized to onboard it. For example, the device may verify that it and the network are owned by the same entity, and therefore, assume that the network is authorized to onboard it. 5. Verify that device is authorized to onboard to the network - the network onboarding component consults the network-layer onboarding authorization service to verify that the device is authorized to be onboarded to the network. For example, the network-layer authorization service can confirm that the device is owned by the network and is on the list of devices authorized to be onboarded. 6. Establish a secure channel - a secure (i.e., encrypted) channel is established between the network onboarding component and the device. 7. Provision network credentials to the device - the network onboarding component uses the secure channel that it has established with the device to confidentially send the device its unique network credentials. 8. Use network credentials to securely connect to the network - the device uses its newly provisioned network credentials to establish secure connectivity to the network. The access point, router, or switch validates the device’s credentials in this step. The mechanism it uses to do so varies depending on the implementation and is not depicted in Figure 4-4.

4.4 Trusted Applica�on-Layer Onboarding Process Figure 4-5 depicts the trusted applica�on-layer onboarding process as enabled by the streamlined applica�on-layer onboarding mechanism. As defined in Sec�on 3.3.2, streamlined applica�on-layer onboarding occurs a�er network-layer onboarding and depends upon and is enabled by it. The figure uses two colors. The dark-blue components are those used in the network-layer onboarding process. They and their accompanying steps (writen in black font) are iden�cal to those found in the trusted network-layer onboarding process diagram provided in Figure 4-4. The light-blue component and its accompanying steps (writen in light-blue font) depict the por�on of the diagram that is specific to streamlined applica�on-layer onboarding.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

43

FINAL

IoT Devices (1)Device enters onboarding mode

(10) Use network credentials to connect to the network securely

(2)Trusted introduction of device and network bootstrapping information (3) Device and network authentication (4) Verify that network is authorized to onboard the device (6) Establish a secure channel (denoted by )

Secure storage

(11) Device and application server mutually authenticate and establish a secure channel (12) Application server may, for example, perform updates and ongoing lifecycle management of device

Access Point, Router, or Switch (9) Provision network credentials to the device, including the application server’s application-layer bootstrapping information

(7) Device sends its applicationlayer bootstrapping information Network Onboarding Component

(5) Verify that device is authorized to be onboarded to the network (8) Exchange device’s and application server’s applicationlayer bootstrapping information

NetworkLayer Onboarding Authorization Service Application Server

Figure 4-5 Trusted Streamlined Applica�on-Layer Onboarding Process As is the case with Figure 4-4, the steps in this diagram are assumed to occur a�er any device ownership and bootstrapping informa�on transfer ac�vi�es that may need to be performed. Steps 1 through 6 in this figure are iden�cal to Steps 1 through 6 in the trusted network-layer onboarding diagram of Figure 4-4, but Steps 7 and 8 are different. With the comple�on of Steps 1 through 6 in Figure 4-5, a secure channel has been established between the IoT device and the network-layer onboarding component. However, the device is not provisioned with its network-layer creden�als un�l Step 9. To support streamlined applica�on-layer onboarding, addi�onal steps are required. Steps 1 through 12 are as follows: 1. The IoT device to be onboarded is placed in onboarding mode, i.e., it is put into a state such that it is actively listening for and/or sending initial onboarding protocol messages. 2. Any required device bootstrapping information that has not already been provided to the network and any required network bootstrapping information that has not already been provided to the device are introduced in a trusted manner. 3. Using the device and network bootstrapping information that has been provided, the network authenticates the identity of the IoT device (e.g., by ensuring that the IoT device is in possession of the private key that corresponds with the public key for the device that was provided as part of the device’s bootstrapping information), and the IoT device authenticates the identity of the network (e.g., by ensuring that the network is in possession of the private key that corresponds

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

44

FINAL with the public key for the network that was provided as part of the network’s bootstrapping information). 4. The device verifies that the network is authorized to onboard it. For example, the device may verify that it and the network are owned by the same entity, and therefore, assume that the network is authorized to onboard it. 5. The network onboarding component consults the network-layer onboarding authorization service to verify that the device is authorized to be onboarded to the network. For example, the network-layer authorization service can confirm that the device is owned by the network and is on the list of devices authorized to be onboarded. 6. A secure (i.e., encrypted) channel is established between the network onboarding component and the device. 7. The device sends its application-layer bootstrapping information to the network onboarding component. Just as the network requires the trusted introduction of device network-layer bootstrapping information – so it can authenticate the device and ensure the device is authorized for network-layer onboarding – the application server similarly requires the trusted introduction of device application-layer bootstrapping information. This enables the application server to authenticate the device at the application layer and ensure it is authorized for application-layer onboarding.. Because this application-layer bootstrapping information is being sent over a secure channel, its integrity and confidentiality are ensured. 8. The network onboarding component forwards the device’s application-layer bootstrapping information to the application server. In response, the application server provides its applicationlayer bootstrapping information to the network-layer onboarding component for eventual forwarding to the IoT device. The IoT device needs the application server’s bootstrapping information to enable the device to authenticate the application server and ensure that it is authorized to application-layer onboard the device. 9. The network onboarding component uses the secure channel that it has established with the IoT device to confidentially send the device its unique network credentials. Along with these network credentials, the network onboarding component also sends the IoT device the application server’s bootstrapping information. Because the application server’s bootstrapping information is being sent over a secure channel, its integrity and confidentiality are ensured. 10. The device uses its newly provisioned network credentials to establish secure connectivity to the network. 11. Using the device and application server application-layer bootstrapping information that has already been exchanged in a trusted manner, the application server authenticates the identity of the IoT device, and the IoT device authenticates the identity of the application server. Then they establish a secure (i.e., encrypted) channel. 12. The application server application layer onboards the IoT device. This application-layer onboarding process may take various forms. For example, the application server may download an application to the device for the device to execute. It may also associate the device with a trusted

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

45

FINAL lifecycle management service that performs ongoing updates to patch the device as needed to ensure that it remains compliant with policy.

4.5 Con�nuous Verifica�on Figure 4-6 depicts the steps that are performed to support con�nuous verifica�on. The figure uses two colors. The light-blue component and its accompanying steps (writen in light-blue font) depict the por�on of the diagram that is specific to con�nuous authoriza�on. The darkblue components are those used in the network-layer onboarding process. They and their accompanying steps (writen in black font) are iden�cal to those found in the trusted networklayer onboarding process diagram provided in Figure 4-4, except for Step 5, Verify that device is authorized to be onboarded to the network. IoT Devices (1)Device enters onboarding mode

(8) Use network credentials to connect to the network securely

(2)Trusted introduction of device and network bootstrapping information (3) Device and network authentication (4) Verify that network is authorized to onboard the device (6) Establish a secure channel (denoted by )

Secure storage

Access Point, Router, or Switch (7) Provision network credentials to the device

Network Onboarding Component

(5a) Verify that device is authorized to be onboarded to the network

(9) Monitor and control the router according to policy on an ongoing basis to verify that the device and its operations continue to be authorized

Continuous Authorization Service

(5b) Verify that device is authorized to be onboarded to the network

NetworkLayer Onboarding Authorization Service

Figure 4-6 Con�nuous Verifica�on When con�nuous verifica�on is being supported, Step 5 is broken into two separate steps, as shown in Figure 4-6. Instead of the network onboarding component directly contac�ng the network-layer onboarding authoriza�on service to see if the device is owned by the network and on the list of devices authorized to be onboarded (as shown in the trusted network-layer onboarding architecture depicted in Figure 4-4), a set of other enterprise policies may also be applied to determine if the device is authorized to be onboarded. The applica�on of these policies is represented by the inser�on of the Con�nuous Authoriza�on Service (CAS) component in the middle of the exchange between the network onboarding component and the networklayer onboarding authoriza�on service.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

46

FINAL For example, the CAS may have received external threat informa�on indica�ng that certain device types have a vulnerability. If so, when the CAS receives a request from the network-layer onboarding component to verify that a device of this type is authorized to be onboarded to the network (Step 5a), it would immediately respond to the network-layer onboarding component that the device is not authorized to be onboarded to the network. If the CAS has not received any such threat informa�on about the device and it checks all its policies and determines that the device should be permited to be onboarded, it will forward the request to the networklayer onboarding authoriza�on service (Step 5b) and receive a response (Step 5b) that it will forward to the network onboarding component (Step 5a). As depicted by Step 9, the CAS also con�nues to operate a�er the device connects to the network and executes its applica�on. The CAS performs asynchronous calls to the network router to monitor the device on an ongoing basis, providing policy-based verifica�on and authoriza�on checks on the device throughout its lifecycle.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

47

FINAL

5 Laboratory Physical Architecture Figure 5-1 depicts the high-level physical architecture of the NCCoE IoT Onboarding laboratory environment in which the five trusted IoT device network-layer onboarding project builds, and the factory provisioning builds have been implemented. The NCCoE provides virtual machine (VM) resources and physical infrastructure for the IoT Onboarding lab. As depicted, the NCCoE IoT Onboarding laboratory hosts collaborator hardware and so�ware for the builds. The NCCoE also provides connec�vity from the IoT Onboarding lab to the NIST Data Center, which provides connec�vity to the internet and public IP spaces (both IPv4 and IPv6). Access to and from the NCCoE network is protected by a firewall. Access to and from the IoT Onboarding lab is protected by a pfSense firewall, represented by the brick box icon in Figure 5-1. This firewall has both IPv4 and IPv6 (dual stack) configured. The IoT Onboarding lab network infrastructure includes a shared virtual environment that houses a domain controller and a vendor jumpbox. These components are used across builds where applicable. It also contains five independent virtual LANs, each of which houses a different trusted network-layer onboarding build. The IoT Onboarding laboratory network has access to cloud components and services provided by the collaborators, all of which are available via the internet. These components and services include Aruba Central and the UXI Cloud (Build 1), SEALSQ INeS (Build 1), Pla�orm Controller (Build 2), a MASA server (Build 3), Kudelski IoT keySTREAM applica�on-layer onboarding service and AWS IoT (Build 4), and a Manufacturer Provisioning Root (Build 5).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

48

FINAL

Figure 5-1 NCCoE IoT Onboarding Laboratory Physical Architecture

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

49

FINAL All five network-layer onboarding laboratory environments, as depicted in the diagram, have been installed: 

The Build 1 (i.e., the Wi-Fi Easy Connect, Aruba/HPE build) network infrastructure within the NCCoE lab consists of two components: the Aruba Access Point and the Cisco Switch. Build 1 also requires support from Aruba Central for network-layer onboarding and the UXI Cloud for applica�on-layer onboarding. These components are in the cloud and accessed via the internet. The IoT devices that are onboarded using Build 1 include the UXI Sensor and the Raspberry Pi.



The Build 2 (i.e., the Wi-Fi Easy Connect, CableLabs, OCF build) network infrastructure within the NCCoE lab consists of a single component: the Gateway Access Point. Build 2 requires support from the Pla�orm Controller, which also hosts the IoTivity Cloud Service. The IoT devices that are onboarded using Build 2 include three Raspberry Pis.



The Build 3 (i.e., the BRSKI, Sandelman So�ware Works build) network infrastructure components within the NCCoE lab include a Wi-Fi capable home router (including Join Proxy), a demilitarized zone (DMZ) switch (for management), and an ESP32A Xtensa board ac�ng as a Wi-Fi IoT device, as well as an nRF52840 board ac�ng as an IEEE 802.15.4 device. A management system on a BeagleBone Green serves as a serial console. A registrar server has been deployed as a virtual appliance on the NCCoE private cloud system. Build 3 also requires support from a MASA server, which is accessed via the internet. In addi�on, a Raspberry Pi 3 provides an ethernet/802.15.4 gateway, as well as a test pla�orm.



The Build 4 (i.e., the Thread, Silicon Labs, Kudelski IoT build) network infrastructure components within the NCCoE lab include an Open Thread Border Router, which is implemented using a Raspberry Pi, and a Silicon Labs Gecko Wireless Starter Kit, which acts as an 802.15.4 antenna. Build 4 also requires support from the Kudelski IoT keySTREAM service, which is in the cloud and accessed via the internet. The IoT device that is onboarded in Build 4 is the Silicon Labs Dev Kit (BRD2601A) with an EFR32MG24 Systemon-Chip (SoC). The applica�on service to which it onboards is AWS IoT.



The Build 5 (i.e., the BRSKI over Wi-Fi, NquiringMinds build) includes 2 Raspberry Pi 4Bs running a Linux opera�ng system. One Raspberry Pi acts as the pledge (or IoT Device) with an Infineon TPM connected. The other acts as the router, registrar, and MASA all in one device. This build uses the open source TrustNetZ distribu�on, from which the en�re build can be replicated easily. The TrustNetZ distribu�on includes source code for the IoT device, the router, the access point, the network onboarding component, the policy engine, the manufacturer services, the registrar, and a demo applica�on server. TrustNetZ makes use of NquiringMinds tdx Volt to issue and validate verifiable creden�als.



Factory Provisioning Builds: o The BRSKI factory provisioning build is deployed in the Build 5 environment. The IoT device in this build is a Raspberry Pi equipped with an Infineon Op�ga SLB

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

50

FINAL 9670 TPM 2.0, which gets provisioned with birth creden�als (i.e., a public/private key pair and an IDevID). The BRSKI factory provisioning build also uses an external cer�ficate authority hosted on the premises of NquiringMinds to provide the device cer�ficate signing service. o The Wi-Fi Easy Connect factory provisioning build is deployed in the Build 1 environment. Its IoT devices are Raspberry Pis equipped with a SEALSQ VaultIC Secure Element, which gets provisioned with a DPP URI. The Secure Element can also be provisioned with an IDevID cer�ficate signed by the SEALSQ INeS cer�fica�on authority, which is independent of the DPP URI. Code for performing the factory provisioning is stored on an SD card. The subsec�ons below describe informa�on regarding the physical architecture of all builds, their related collaborators’ cloud components, and the shared environment, as well as the baseline so�ware running on these physical architectures. Table 5-1 summarizes the builds that were implemented and provides links to the appendices where each is described in detail. Table 5-1 Build 1 Products and Technologies Build

Network-Layer Protocols

Build Champions

Link to Details

Build 1

Wi-Fi Easy Connect

Aruba/HPE

Appendix C

Build 2

Wi-Fi Easy Connect

CableLabs and OCF

Appendix D

Build 3

BRSKI

Sandelman Software Works

Appendix E

Build 4

Thread

Silicon Labs and Kudelski IoT

Appendix F

Build 5

BRSKI over Wi-Fi

NquiringMinds

Appendix G

Onboarding Builds

Factory Provisioning Builds BRSKI with Build 5

BRSKI over WIFI

SEALSQ and NquiringMinds

Appendix H.3

Wi-Fi Easy Connect with Build 1

Wi-Fi Easy Connect

SEALSQ and Aruba/HPE

Appendix H.4

5.1 Shared Environment The NCCoE IoT Onboarding laboratory contains a shared environment to host several baseline services in support of the builds. These baseline services supported configura�on and integra�on work in each of the builds and allowed collaborators to work together throughout the build process. This shared environment is contained in its own network segment, with access to and

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

51

FINAL from the rest of the lab environment closely controlled. In addi�on, each of the systems in the shared environment is hardened with baseline configura�ons. The Registrar Server is a BRSKI component that is only used by Build 3 and is described in Sec�on 5.4.

5.1.1 Domain Controller The Domain Controller, which runs on Windows Server 2019, provides Ac�ve Directory and Domain Name System (DNS) services to support network access and access control in the lab.

5.1.2 Jumpbox The jumpbox, which runs on Windows Server 2019, provides secure remote access and management to authorized collaborators on each of the builds.

5.2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Physical Architecture Figure 5-2 is a view of the high-level physical architecture of Build 1 in the NCCoE IoT Onboarding laboratory. Most of these components are described in Sec�on 3.4.1 and Sec�on 3.4.3. The build components include: 

The Aruba Access Point acts as the DPP Configurator and relies on the Aruba Central cloud service for authen�ca�on and management purposes.



Aruba Central �es together the IoT Opera�ons, Client Insights, and Cloud Auth services to support the build's network-layer onboarding opera�ons. It also provides an API to support device ownership and the bootstrapping informa�on transfer process.



The Cisco Catalyst Switch provides PoE and network connec�vity to the Aruba Access Point.



The UXI Sensor acts as an IoT device and onboards to the network via Wi-Fi Easy Connect. A�er network-layer onboarding, it performs independent (see Sec�on 3.3.2) applica�on-layer onboarding. Once it has applica�on-layer onboarded and is opera�onal on the network, it does passive and ac�ve monitoring of applica�ons and services and will report outages, disrup�ons, and quality of service issues.



UXI Cloud is an HPE cloud service that the UXI sensor contacts as part of the applica�onlayer onboarding process. The UXI sensor downloads a customer-specific configura�on from the UXI Cloud so that the UXI sensor can learn about the customer networks and services it needs to monitor.



The Raspberry Pi acts as an IoT device and onboards to the network via Wi-Fi Easy Connect.



SEALSQ Cer�ficate Authority has been integrated with Build 1 to sign network creden�als that are issued to IoT devices.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

52

FINAL

Figure 5-2 Physical Architecture of Build 1

5.2.1 Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture Figure 5-3 is a view of the high-level physical architecture of the Wi-Fi Easy Connect Factory Provisioning Build in the NCCoE IoT Onboarding laboratory. See Appendix H.4 for addi�onal details on the Wi-Fi Easy Connect Factory Provisioning Build. The build components include: 

A UXI sensor.



The IoT Device is a Raspberry Pi.



The Secure Element is a SEALSQ VaultIC Secure Element and is interfaced with the Raspberry Pi. The Secure Element both generates and stores the key material necessary to support the DPP URI during the Factory Provisioning Process.



An SD card with factory provisioning code.



Aruba Central provides an API to ingest the DPP URI in support of the device ownership and bootstrapping informa�on transfer process.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

53

FINAL

Figure 5-3 Physical Architecture of Wi-Fi Easy Connect Factory Provisioning Build

5.3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) Physical Architecture Figure 5-4 is a view of the high-level physical architecture of Build 2 in the NCCoE IoT Onboarding laboratory. The build components include: 

The Gateway Access Point acts as the Custom Connec�vity Gateway Agent described in Sec�on 3.4.2.2 and controls all network-layer onboarding ac�vity within the network. It also hosts OCF IoTivity func�ons, such as the OCF OBT and the OCF Diplomat.



The Pla�orm Controller described in Sec�on 3.4.2.1 provides management capabili�es for the Custom Connec�vity Gateway Agent. It also hosts the applica�on-layer IoTivity service for the IoT devices as described in Sec�on 3.4.8.1.



The IoT devices serve as reference clients, as described in Sec�on 3.4.2.3. They run OCF reference implementa�ons. The IoT devices are onboarded to the network and complete both applica�on-layer and network-layer onboarding.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

54

FINAL

Figure 5-4 Physical Architecture of Build 2

5.4 Build 3 (BRSKI, Sandelman So�ware Works) Physical Architecture Figure 5-5 is a view of the high-level physical architecture of Build 3 in the NCCoE IoT Onboarding laboratory. The build components include: 

The onboarding router is a Turris MOX router running OpenWRT. The onboarding router quaran�nes the IoT devices un�l they complete the BRSKI onboarding process.



The owner’s Registrar Server hosts the Minerva Fountain Join Registrar Coordinator applica�on running in a virtual machine. The Registrar Server determines whether or not a device meets the criteria to join the network.



The MASA server for this build is a Minerva Highway MASA server as outlined in Sec�on 3.4.9.1. The MASA server’s role is to receive the voucher-request from the Registrar Server and confirm that the Registrar Server has the right to own the device.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

55

FINAL 

The DMZ switch is a basic Netgear switch that segments the build from the rest of the lab.



The IoT devices include an ESP32 Xtensa device with Wi-Fi that will be tested with FreeRTOS and RIOT-OS, a Raspberry Pi 3 running Raspbian 11, and an nRF52840 with an 802.15.4 radio that is running RIOT-OS. The IoT devices are currently not used in the build but will serve as clients to be onboarded onto the network in a future implementa�on of the build.



The Sandelman So�ware Works Reach Pledge Simulator is the device that is onboarded to the network in the current build.



The serial console is a BeagleBone Green with an atached USB hub. The serial console is used to access the IoT devices for diagnos�c purposes. It also provides power and power control for USB-powered devices.



The 802.15.4 gateway is integrated into the Raspberry Pi 3 via an OpenMote daughter card.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

56

FINAL

Figure 5-5 Physical Architecture of Build 3

5.5 Build 4 (Thread, Silicon Labs, Kudelski IoT) Physical Architecture Figure 5-6 is a view of the high-level physical architecture of Build 4 in the NCCoE IoT Onboarding laboratory. The build components include: 

The keySTREAM server described in Sec�on 3.4.5.1 is the applica�on layer onboarding service provided by Kudelski IoT. The IoT device will authen�cate to keySTREAM using a Silicon Labs chip birth cer�ficate and private key and leveraging Silicon Labs’ Secure Engine in the EFR32MG24 chipset (“Secure Vault(TM) High” which is security cer�fied Platform Security Architecture (PSA)/Security Evalua�on Standard for IoT Pla�orms (SESIP) Level 3 to protect that birth iden�ty with Secure Boot, Secure Debug, and physically unclonable func�on (PUF) wrapped key storage and hardware tamper protec�on).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

57

FINAL 

The AWS IoT server provides the Message Queuing Telemetry Transport (MQTT) test client for the trusted applica�on-layer onboarding. The Proof of Possession Cer�ficate is provisioned for the device using a registra�on code from the AWS server.



The OpenThread Border Router is run on a Raspberry Pi 3B and serves as the Thread Commissioner and Leader. It communicates with the IoT device by means of a Silicon Labs Gecko Wireless Devkit, which serves as the 802.15.4 antenna for the build.



The IoT Device in this build is a Silicon Labs Thunderboard (BRD2601A) containing the EFR32MG24Bx 15.4 SoC with Secure Vault (TM) High running the Thread protocol. It serves as the child node on the Thread network and is onboarded onto AWS IoT Core using creden�als provisioned from the Kudelski keySTREAM service.

Figure 5-6 Physical Architecture of Build 4

5.6 Build 5 (BRSKI, NquiringMinds) Physical Architecture Figure 5-7 is a view of the high-level physical architecture of Build 5 in the NCCoE IoT Onboarding laboratory. The build components include:

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

58

FINAL 

A Raspberry Pi 4B serves as the MASA, Registrar, and Router Access Point for the local network. The role of the MASA is to receive the voucher-request from the Registrar and confirm that the Registrar has the right to own the device. The registrar self-signs creden�als, namely the Local Device Iden�fier (LDevID), issued to the IoT devices. The IoT device (pledge) gets its IDevID cer�ficate for device iden�ty from the Manufacturer Provisioning Root (MPR) server during the factory provisioning process; it can be assumed to be present on the device at the point of onboarding. The Registrar determines whether or not a device meets the criteria to join the network. The router access point runs an open and closed BRSKI network; the closed BRSKI network may only be accessed through secure onboarding, which is performed via the open network. The registrar leverages a local tdx Volt instance to sign and verify verifiable creden�als.



Raspberry Pi 4Bs act as IoT Devices (pledges) for this build.



The Secure Element is an Infineon Op�ga SLB 9670 TPM 2.0 Secure Element, and both generates and stores the key material necessary to support the IDevID cer�ficate during the Factory Provisioning Process, as well as the onboarding process to request the voucher from the MASA via the registrar and the request to the registrar to sign the LDevID. The system can also be configured to use a SEALSQ VaultIC408 secure element. See H.3 for addi�onal details on the BRSKI factory provisioning builds.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

59

FINAL

Figure 5-7 Physical Architecture of Build 5

5.6.1 BRSKI Factory Provisioning Build Physical Architecture Figure 5-8 is a view of the high-level physical architecture of the BRSKI Factory Provisioning Build in the NCCoE IoT Onboarding laboratory. This build uses the same IoT device as Build 5: a Raspberry Pi integrated with an Infineon Op�ga SLB 9670 TPM 2.0 Secure Element. The factory provisioning code is hosted on an SD card. When a provisioning event is triggered, the IoT device will atempt a connec�on to an MPR server that sits in the cloud and acts as the cer�fica�on authority. It signs the IDevID (X.509) cer�ficate, which is then passed back to the IoT device for installa�on. As in Build 5, the Router + Services hosts a MASA, which is given device iden�ty informa�on in order to verify voucher requests during the BRKSI process. See H.3 for addi�onal details on the BRSKI factory provisioning builds.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

60

FINAL

Figure 5-8 Physical Architecture of BRSKI Factory Provisioning Build

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

61

FINAL

6 General Findings 6.1 Wi-Fi Easy Connect The Wi-Fi Easy Connect protocol that was demonstrated in Build 1 and Build 2 supports trusted network-layer onboarding in a manner that is secure, efficient, flexible enough to meet the needs of various use cases, and does not require specialized technical knowledge. In addi�on, to meet the needs of enterprises, it may be used to onboard a large number of devices quickly. Builds 1 and 2 are implementa�ons of this protocol, and they are interoperable: IoT devices that were provisioned for use with Build 1 were able to be onboarded onto the network using Build 2, and IoT devices that were provisioned for use with Build 2 were able to be onboarded onto the network using Build 1.

6.1.1 Mutual Authen�ca�on Although DPP is designed to support authen�ca�on of the network by the IoT device as well as authen�ca�on of the device by the network, the Wi-Fi Easy Connect solu�ons that were demonstrated in Builds 1 and 2 do not demonstrate mutual authen�ca�on at the network layer. They only support authen�ca�on of the device. In order to authen�cate the network, the device needs to be provided with the DPP URI for the network configurator, which means that the device has to have a func�onal user interface so that the DPP URI can be input into it. The devices being used in Builds 1 and 2 do not have user interfaces.

6.1.2 Mutual Authoriza�on When using DPP, device authoriza�on is based on possession of the device’s DPP URI. When the device is acquired, its DPP URI is provided to the device owner. A trusted administrator of the owner’s network is assumed to approve the addi�on of the device’s DPP URI to the database or cloud service where the DPP URIs of authorized devices are stored. During the onboarding process, the fact that the owning network is in possession of the device’s DPP URI indicates to the network that the device is authorized to join it. DPP supports network authoriza�on using the Resurrec�ng Duckling security model [18]. Although the device cannot cryptographically verify that the network is authorized to onboard it, the fact that the network possesses the device’s public key is understood by the device to implicitly authorize the network to onboard the device. The assump�on is that an unauthorized network would not have possession of the device and so would not be able to obtain the device’s public key. While this assurance of authoriza�on is not cryptographic, it does provide some level of assurance that the “wrong” network will not onboard it.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

62

FINAL

6.1.3 Secure Storage The UXI sensor used in Build 1 has a TPM where the device’s birth creden�al and private key are stored, providing a secure root of trust. However, the lack of secure storage on some of the other IoT devices (e.g., the Raspberry Pis) used to demonstrate onboarding in Build 2 is a current weakness. Ensuring that the confiden�ality of a device’s birth, network, and other creden�als is protected while stored on the device is an essen�al aspect of ensuring the security of the network-layer onboarding process, the device, and the network itself. To fully demonstrate trusted network-layer onboarding, devices with secure storage should be used in the future whenever possible.

6.2 BRSKI The BRSKI solu�on that is demonstrated in Build 3 supports trusted network-layer onboarding in a manner that is secure, efficient, and able to meet the needs of enterprises. It may be used to onboard a large number of devices quickly onto a wired network. This BRSKI build is based on IETF RFC 8995 [6]. The build has a reliance on the manufacturer to provision keys for the onboarding device and has a reliance on a cloud-based service for the MASA server. The BRSKI solu�on that is demonstrated in Build 5 provides similar trusted func�onality for onboarding devices onto a Wi-Fi network. This BRSKI build is based on an IETF individual dra� describing how to run BRSKI over IEEE 802.11 [9].

6.2.1 Reliance on the Device Manufacturer Organiza�ons implemen�ng BRSKI (whether wired or over Wi-Fi) should be aware of the reliance that they will have on the IoT device manufacturer in properly and securely provisioning their devices. If keys become compromised, atackers may be able to onboard their own devices to the network, revoke cer�ficates to prevent legi�mate devices from being onboarded, or onboard devices belonging to others onto the atacker’s network using the atacker’s MASA. These concerns are addressed in depth in RFC 8995 Sec�on 11.6. If a device manufacturer goes out of business or otherwise shuts down their MASA servers, the onboarding services for its devices will no longer func�on. Onboarding services may become temporarily unavailable during opera�on for a number of reasons. For example, a DoS atack on the MASA, server maintenance, or other manufacturer outage will prevent an organiza�on from accessing the MASA. These concerns are addressed in depth in RFC 8995 Sec�on 11.1.

6.2.2 Mutual Authen�ca�on BRSKI supports authen�ca�on of the IoT device by the network as well as authen�ca�on of the network by the IoT device. The Registrar authen�cates the device when it receives the IDevID NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

63

FINAL from the device. The MASA confirms that the Registrar is the legi�mate owner or authorized onboarder of the device and issues a voucher. The device is able to authen�cate the network using the voucher that it receives back from the MASA. This process is explained in depth in RFC 8995 Sec�on 11.5.

6.2.3 Mutual Authoriza�on BRSKI authoriza�on for the IoT device is done via the voucher that is returned to the Registrar from the MASA. The voucher states which network the IoT device is authorized to join. The Registrar determines the level of access the IoT device has to the network.

6.2.4 Secure Storage Build 5 uses a Secure Element atached to the IoT devices (e.g., Raspberry Pi devices) to store the IDevID a�er it is generated during the factory provisioning process (see H.3 for more details); however, the LDevID is not stored on the Secure Element a�er network-layer onboarding is completed. The lack of secure storage on the IoT devices (e.g., the Raspberry Pi devices) used to demonstrate onboarding in Build 3 is a current weakness. Ensuring that the confiden�ality of a device’s birth, network, and other creden�als is protected while stored on the device is an essen�al aspect of ensuring the security of the network-layer onboarding process, the device, and the network itself. To fully demonstrate trusted network-layer onboarding, devices with secure storage should be used in the future whenever possible.

6.3 Thread We do not have any findings with respect to trusted network-layer onboarding using the Thread commissioning protocol. Build 4 demonstrated the connec�on of an IoT device to a Thread network, but did not include the trusted onboarding of the Thread network creden�als to the device. In Build 4, a passphrase is generated on the IoT device and then a person is required to enter this passphrase into the OpenThread Border Router’s (OTBR) web interface. This passphrase serves as a pre-shared key that the device uses to join the Thread network. Due to the fact that a person must be privy to this passphrase in order to provide it to the OTBR, this network-layer onboarding process is not considered to be trusted, according to the defini�on of trusted network-layer onboarding that we provided in Sec�on 1.2. A�er connec�ng to the Thread network using the passphrase, the Build 4 device was successfully able to gain access to the public IP network via a border router. This enabled the IoT device that was communica�ng using the Thread wireless protocol to communicate with cloud services and use them to successfully perform trusted applica�on-layer onboarding to the AWS IoT Core.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

64

FINAL

6.4 Applica�on-Layer Onboarding We successfully demonstrated both: 

streamlined applica�on-layer onboarding (to the OCF security domain in Build 2) and



independent applica�on-layer onboarding (to the UXI cloud in Build 1 and to the AWS IoT Core using the Kudelski keySTREAM service in Build 4).

6.4.1 Independent Applica�on-Layer Onboarding Support for independent applica�on-layer onboarding requires the device manufacturer to preprovision the device with so�ware to support applica�on-layer onboarding to the specific applica�on service (e.g., the UXI cloud or the AWS IoT Core) desired. The Kudelski keySTREAM service supports the applica�on-layer onboarding provided in Build 4. KeySTREAM is a device security management service that runs as a so�ware-as-a-service (SaaS) pla�orm on the Amazon cloud. Build 4 relies on an integra�on that has been performed between Silicon Labs and Kudelski keySTREAM. KeySTREAM has integrated so�ware libraries with the Silicon Lab EFR32MG24 (MG24) IoT device’s secure vault to enable the private signing key that is associated with an applica�on-layer cer�ficate to be stored in the secure vault using security controls that are available on the MG24. This integra�on ensures that applica�on-layer creden�als can be provisioned into the vault securely such that no key material is misused or exposed. Because the device is prepared for applica�on-layer onboarding on behalf of a specific, pre-defined customer in Build 4 and this ownership informa�on is sealed into device firmware, the device is permanently iden�fied as being owned by that customer.

6.4.2 Streamline Applica�on-Layer Onboarding Support for streamlined applica�on-layer onboarding does not necessarily present such a burden on the device manufacturer to provision applica�on-layer onboarding so�ware and creden�als to the device at manufacturing �me. If desired, the manufacturer could pre-install applica�on-layer bootstrapping informa�on onto the device at manufacturing �me, as must be done in the independent applica�on-layer onboarding case. Alterna�vely, the device manufacturer may simply ensure that the device has the capability to generate one-�me applica�on-layer bootstrapping informa�on at run�me and use the secure exchanges inherent in trusted networklayer onboarding to support applica�on-layer onboarding.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

65

FINAL

7 Addi�onal Build Considera�ons The Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management project is now complete, so no addi�ons or changes to the exis�ng builds are planned as part of this project effort. As trusted network-layer onboarding is increasingly adopted, however, others may wish to con�nue implementa�on efforts to develop new build capabili�es or enhance exis�ng ones, so it is worth no�ng poten�al areas of further work. Various ways in which individual builds could be enhanced are noted in the appendices that detail each build’s technologies and architectures. For example, some builds could be enhanced by the addi�on of architectural components that have not yet been implemented, such as secure device storage; the use of an independent, third-party cer�ficate signing authority; support for network-layer onboarding using Thread MeshCoP; support for applica�on-layer onboarding; and support (or enhanced support) for ongoing device authoriza�on. In addi�on to adding components to support these capabili�es, future work could poten�ally involve demonstra�on of applica�on-layer onboarding using the FIDO Alliance’s FIDO Device Onboard (FDO) specifica�on and/or the Connec�vity Standards Alliance (CSA) Mater specifica�on. Other future work could involve integrating addi�onal security mechanisms with network-layer onboarding, beginning at device boot-up and extending through all phases of the device lifecycle, to further protect the device and, by extension, the network. For example, future builds could include the capability to demonstrate the integra�on of trusted network-layer onboarding with zero trust-inspired capabili�es, such as those described in the following subsec�ons. In addi�on, the scope of implementa�on efforts could poten�ally be expanded beyond the current focus on IP-based networks. While this project’s goal has been to tackle what is currently implementable, the subsec�ons that follow briefly discuss areas that could poten�ally be addressed by others in the future.

7.1 Network Authen�ca�on Future builds could be designed to demonstrate network authen�ca�on in addi�on to device authen�ca�on as part of the network-layer onboarding process. Network authen�ca�on enables the device to verify the iden�ty of the network that will be taking control of it prior to permi�ng itself to be onboarded.

7.2 Device Communica�ons Intent Future builds could be designed to demonstrate the use of network-layer onboarding protocols to securely transmit device communica�ons intent informa�on from the device to the network (i.e., to transmit this informa�on in encrypted form with integrity protec�ons). Secure conveyance of device communica�ons intent informa�on, combined with enforcement of it, would enable the build to ensure that IoT devices are constrained to sending and receiving only those

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

66

FINAL communica�ons that are explicitly required for each device to fulfill its purpose. Build 5 currently enforces device communica�ons intent as part of its con�nuous assurance process. Build 5 determines device communica�ons intent informa�on (e.g., the device’s MUD file URL) based on device type rather than conveying this informa�on from the device to the network during onboarding.

7.3 Network Segmenta�on Future builds could demonstrate the ability of the onboarding network to dynamically assign each new device that is permited to join the network to a specific subnetwork. The router may have mul�ple network segments configured to which an onboarded device may be dynamically assigned. The decision regarding which segment (subnetwork) to which to assign the device could poten�ally be based on the device’s Dynamic Host Configura�on Protocol (DHCP) fingerprint, other markers of the device’s type, or some indica�on of the device’s trustworthiness, subject to organiza�onal policy.

7.4 Integra�on with a Lifecycle Management Service Future builds could demonstrate trusted network-layer onboarding of a device, followed by streamlined trusted applica�on-layer onboarding of that device to a lifecycle management applica�on service. Such a capability would ensure that, once connected to the local network, the IoT device would automa�cally and securely establish an associa�on with a trusted lifecycle management service that is designed to keep the device updated and patched on an ongoing basis.

7.5 Network Creden�al Renewal Some devices may be provisioned with network creden�als that are X.509 cer�ficates and that will, therefore, eventually expire. Future build efforts could explore and demonstrate poten�al ways of renewing such creden�als without having to reprovision the creden�als to the devices.

7.6 Integra�on with Supply Chain Management Tools Future work could include defining an open, scalable supply chain integra�on service that can automa�cally provide addi�onal assurance of device provenance and trustworthiness as part of the onboarding process. The supply chain integra�on service could be integrated with the authoriza�on service to ensure that only devices whose provenance meets specific criteria and reaches a threshold level of trustworthiness will be onboarded or authorized.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

67

FINAL

7.7 Atesta�on Future builds could integrate device atesta�on capabili�es with network-layer onboarding to ensure that only IoT devices that meet specific network-owner-defined atesta�on criteria are permited to be onboarded. In addi�on to considering the atesta�on of each device as a whole, future atesta�on work could also focus on atesta�on of individual device components, so that detailed atesta�on could be performed for each board, integrated circuit, and so�ware program that comprises a device.

7.8 Mutual Atesta�on Future builds could implement mutual atesta�on of the device and its applica�on services. In one direc�on, device atesta�on could be used to enable a high-value applica�on service to determine whether a device should be given permission to access it. In the other direc�on, atesta�on of the applica�on service could be used to enable the device to determine whether it should give the applica�on service permission to access and update the device.

7.9 Behavioral Analysis Future builds could integrate ar�ficial intelligence (AI) and machine learning (ML)-based tools that are designed to analyze device behavior to spot anomalies or other poten�al signs of compromise. Any device that is flagged as a poten�al threat by these tools could have its network creden�als invalidated to effec�vely evict it from the network, be quaran�ned, or have its interac�on with other devices restricted in some way.

7.10 Device Trustworthiness Scale Future efforts could incorporate the concept of a device trustworthiness scale in which informa�on regarding device capabili�es, secure firmware updates, the existence (or not) of a secure element for private key protec�on, type and version of each of the so�ware components that comprise the device, etc., would be used as input parameters to calculate each device’s trustworthiness value. Calcula�ng such a value would essen�ally provide the equivalent of a background check. A history for the device could be maintained, including informa�on about whether it has ever been compromised, if it has a known vulnerability, etc. Such a trustworthiness value could be provided as an onboarding token or integrated into the authoriza�on service so permission to onboard to the network, or to access certain resources once joined, could be granted or denied based on historical data and trustworthiness measures.

7.11 Resource Constrained Systems At present, onboarding solu�ons for technologies such as Zigbee, Z-Wave, and BLE use their own proprietary mechanisms or depend on gateways. In the future, efforts could be expanded NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

68

FINAL to include onboarding in highly resource-constrained systems and non-IP systems without using gateways. Future work could include trying to perform trusted onboarding in these smaller microcontroller-constrained spaces in a standardized way with the goal of bringing more commonality across various solu�ons without having to rely on IP gateways.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

69

FINAL

8 References [1]

S. Symington, W. Polk, and M. Souppaya, Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management (Dra�), Na�onal Ins�tute of Standards and Technology (NIST) Dra� Cybersecurity White Paper, Gaithersburg, MD, Sept. 2020, 88 pp. htps://doi.org/10.6028/NIST.CSWP.09082020-dra�.

[2]

E. Lear, R. Droms, and D. Romascanu, Manufacturer Usage Descrip�on Specifica�on, IETF Request for Comments (RFC) 8520, March 2019. Available: htps://tools.ie�.org/html/rfc8520.

[3]

M. Souppaya et al, Securing Small-Business and Home Internet of Things (IoT) Devices: Mi�ga�ng Network-Based Atacks Using Manufacturer Usage Descrip�on (MUD), Na�onal Ins�tute of Standards and Technology (NIST) Special Publica�on (SP) 1800-15, Gaithersburg, Md., May 2021, 438 pp. Available: htps://nvlpubs.nist.gov/nistpubs/SpecialPublica�ons/NIST.SP.1800-15.pdf.

[4]

“Na�onal Cybersecurity Center of Excellence (NCCoE) Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management,” Federal Register Vol. 86, No. 204, October 26, 2021, pp. 59149-59152. Available: htps://www.federalregister.gov/documents/2021/10/26/2021-23293/na�onal-cybersecurity-center-of-excellence-nccoe-trusted-internet-of-things-iot-device.

[5]

Wi-Fi Alliance, Wi-Fi Easy Connect™ Specifica�on Version 3.0, 2022. Available: htps://www.wi-fi.org/system/files/Wi-Fi_Easy_Connect_Specifica�on_v3.0.pdf.

[6]

M. Pri�kin, M. Richardson, T.T.E. Eckert, M.H. Behringer, and K.W. Watsen, Bootstrapping Remote Secure Key Infrastructure (BRSKI), IETF Request for Comments (RFC) 8995, October 2021. Available: htps://datatracker.ie�.org/doc/rfc8995/.

[7]

Thread 1.1.1 Specifica�on, February 13, 2017.

[8]

OpenThread Released by Google. Available: htps://openthread.io/.

[9]

O. Friel, E. Lear, M. Pri�kin, and M. Richardson, BRSKI over IEEE 802.11, IETF InternetDra� (Individual), July 2018. Available: htps://datatracker.ie�.org/doc/dra�-friel-brski-over-802dot11/01/.

[10]

NIST. The NIST Cybersecurity Framework (CSF) 2.0. Available: htps://doi.org/10.6028/NIST.CSWP.29.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

70

FINAL [11]

J. Boyens, A. Smith, N. Bartol, K. Winkler, A. Holbrook, M. Fallon, Cybersecurity Supply Chain Risk Management Prac�ces for Systems and Organiza�ons, NIST Special Publica�on (SP) 800-161 Rev. 1, November 2024, htps://doi.org/10.6028/nist.sp.800-161r1upd1.

[12]

M. Fagan, K. Megas, B. Cuthill, J. Marron, B. Hoehn, Founda�onal Cybersecurity Ac�vi�es for IoT Product Manufacturers, NIST IR 8259 Rev. 1, May 2025, htps://doi.org/10.6028/nist.ir.8259r1.ipd.

[13]

IEEE Standard for Local and Metropolitan Area Networks - Secure Device Iden�ty, IEEE Std 802.1AR-2018 (Revision of IEEE Std 802.1AR-2009), 2 Aug. 2018, 73 pp. Available: htps://ieeexplore.ieee.org/document/8423794.

[14]

M. Fagan, J. Marron, K. Brady, B. Cuthill, K. Megas, R. Herold, IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements, NIST Special Publica�on (SP) 800-213, November 2021, htps://doi.org/10.6028/nist.sp.800-213.

[15]

M. Fagan, K. Megas, K. Scarfone, M. Smith, IoT Device Cybersecurity Capability Core Baseline, NISTIR 8259A, May 2020, htps://doi.org/10.6028/nist.ir.8259a.

[16]

M. Fagan, J. Marron, K. Brady Jr, B. Cuthill, K. Megas, and R. Herold, IoT Non-technical Suppor�ng Capability Core Baseline, NIST IR 8259B, August 2021, htps://doi.org/10.6028/nist.ir.8259b.

[17]

M. Fagan, K. Megas, J. Marron, E. Link, K. Brady, B. Cuthill, R. Herold, D. Lemire, B. Hoehn, IoT Device Cybersecurity Guidance for the Federal Government : IoT Device Cybersecurity Requirement Catalog, November 2021, htps://doi.org/10.6028/nist.sp.800-213a.

[18]

F. Stajano and R. Anderson, The Resurrec�ng Duckling: Security Issues for Ad-hoc Wireless Networks, B. Chris�anson, B. Crispo and M. Roe (Eds.). Security Protocols, 7th Interna�onal Workshop Proceedings, Lecture Notes in Computer Science, 1999. Springer-Verlag Berlin Heidelberg 1999. Available: htps://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf.

[19]

M. Richardson, A Taxonomy of opera�onal security considera�ons for manufacturer installed keys and Trust Anchors, IETF Internet-Dra� (Individual), November 2022. Available: htps://datatracker.ie�.org/doc/dra�-richardson-t2trg-idevid-considera�ons/.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

71

FINAL [20]

Cer�ficate #4302, Cryptographic Module Valida�on Program, NIST Computer Security Resource Center. Available: htps://csrc.nist.gov/projects/cryptographic-module-valida�on-program/cer�ficate/4302.

[21]

Cer�ficate #4303, Cryptographic Module Valida�on Program, NIST Computer Security Resource Center. Available: htps://csrc.nist.gov/projects/cryptographic-module-valida�on-program/cer�ficate/4303.

[22]

Entropy Cer�ficate #E2, Cryptographic Module Valida�on Program, NIST Computer Security Resource Center. Available: htps://csrc.nist.gov/projects/cryptographic-modulevalida�on-program/entropy-valida�ons/cer�ficate/2.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

72

FINAL

Appendix A

List of Acronyms

AAA

Authen�ca�on, Authoriza�on, and Accoun�ng

ACL

Access Control List

AES

Advanced Encryp�on Standard

AI

Ar�ficial Intelligence

AP

Access Point

API

Applica�on Programming Interface

AWS

Amazon Web Services

BLE

Bluetooth Low Energy

BRSKI

Bootstrapping Remote Secure Key Infrastructure

BSS

Basic Service Set

CA

Cer�ficate Authority

CAS

Con�nuous Authoriza�on Service

CMS

Cer�ficate Management System

CPMS

(Silicon Labs) Custom Parts Manufacturer Service

CPU

Central Processing Unit

CRADA

Coopera�ve Research and Development Agreement

CRL

Cer�ficate Revoca�on List

DHCP

Dynamic Host Configura�on Protocol

DMZ

Demilitarized Zone

DNS

Domain Name System

DPP

Device Provisioning Protocol

DTLS

Datagram Transport Layer Security

ECC

Ellip�c Curve Cryptography

ESP

(Aruba) Edge Services Pla�orm

ESS

Extended Service Set

EST

Enrollment over Secure Transport

HPE

Hewlet Packard Enterprise

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

73

FINAL HSM

Hardware Security Module

HTTPS

Hypertext Transfer Protocol Secure

IDevID

Ini�al Device Iden�fier

IE

Informa�on Element

IEC

Interna�onal Electrotechnical Commission

IETF

Internet Engineering Task Force

IoT

Internet of Things

IP

Internet Protocol

IPsec

Internet Protocol Security

ISO

Interna�onal Organiza�on for Standardiza�on

LAN

Local Area Network, Local Area Networking

LDevID

Local Device Iden�fier

LmP

Linux microPla�orm

MASA

Manufacturer Authorized Signing Authority

MeshCoP

Thread Mesh Commissioning Protocol

ML

Machine Learning

mPKI

Managed Public Key Infrastructure

MPR

Manufacturer Provisioning Root

MUD

Manufacturer Usage Descrip�on

NAC

Network Access Control

NCCoE

Na�onal Cybersecurity Center of Excellence

NIST

Na�onal Ins�tute of Standards and Technology

OBT

Onboarding Tool

OCF

Open Connec�vity Founda�on

OCSP

Online Cer�ficate Status Protocol

OS

Opera�ng System

OTA

Over the Air

OTBR

OpenThread Border Router

PKI

Public Key Infrastructure

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

74

FINAL PSK

Pre-Shared Key

PUF

Physically Unclonable Func�on

R&D

Research & Development

RBAC

Role-Based Access Control

RCP

Radio Coprocessor

RESTful

Representa�onal State Transfer

RFC

Request for Comments

RSA

Rivest-Shamir-Adleman (public-key cryptosystem)

SaaS

So�ware as a Service

SE

Secure Element

SEF

Secure Element Factory

SoC

System-on-Chip

SP

Special Publica�on

SSID

Service Set Iden�fier

SSW

Sandelman So�ware Works

TCP

Transmission Control Protocol

TLS

Transport Layer Security

TOFU

Trust On First Use

TPM

Trusted Pla�orm Module

URI

Uniform Resource Iden�fier

UXI

(Aruba) User Experience Insight

VM

Virtual Machine

WAN

Wide Area Network, Wide Area Networking

W3C

World Wide Web Consor�um

WFA

Wi-Fi Alliance

WPA2

Wi-Fi Protected Access 2

WPA3

Wi-Fi Protected Access 3

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

75

FINAL

Appendix B

Glossary

Applica�onInforma�on that the device and an applica�on-layer service must have in Layer Bootstrap- order for them to mutually authen�cate and use a trusted applica�onping Informa�on layer onboarding protocol to onboard a device at the applica�on layer. There is applica�on-layer bootstrapping informa�on about the device that the network must be in possession of, and applica�on-layer bootstrapping informa�on about the applica�on service that the device must be in possession of. A typical example of applica�on-layer bootstrapping informa�on that the device must have is the public key that corresponds to the trusted applica�on service’s private key. Applica�onThe process of providing IoT devices with the applica�on-layer credenLayer Onboard- �als they need to establish a secure (i.e., encrypted) associa�on with a ing trusted applica�on service. This document defines two types of applica�on-layer onboarding: independent and streamlined. Independent An applica�on-layer onboarding process that does not rely on use of the Applica�onnetwork-layer onboarding process to transfer applica�on-layer bootstrapLayer Onboard- ping informa�on between the device and the applica�on service. ing Network-Layer Bootstrapping Informa�on

Network-Layer Onboarding

Informa�on that the device and the network must have in order for them to use a trusted network-layer onboarding protocol to onboard a device. There is network-layer bootstrapping informa�on about the device that the network must be in possession of, and network-layer bootstrapping informa�on about the network that the device must be in possession of. A typical example of device bootstrapping informa�on that the network must have is the public key that corresponds with the device’s private key. The process of providing IoT devices with the network-layer creden�als and policy they need to join a network upon deployment.

Ongoing Device Authoriza�on

The ongoing policy-based gran�ng of device network access permissions and privileges.

Streamlined Applica�on-Layer Onboarding

An applica�on-layer onboarding process that uses the network-layer onboarding protocol to securely transfer applica�on-layer bootstrapping informa�on between the device and the applica�on service.

Trusted Network-Layer Onboarding

A network-layer onboarding process that meets the following criteria: • provides each device with unique network creden�als, • enables the device and the network to mutually authen�cate, • sends devices their network creden�als over an encrypted channel, • does not provide any person with access to the network creden�als, and

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

76

FINAL •

can be performed repeatedly throughout the device lifecycle to enable: • the device’s network creden�als to be securely managed and replaced as needed, and • the device to be securely onboarded to other networks a�er being repurposed or resold.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

77

FINAL

Appendix C

Build 1 (Wi-Fi Easy Connect, Aruba/HPE)

C.1 Technologies Build 1 is an implementa�on of network-layer onboarding that uses the Wi-Fi Easy Connect protocol. The onboarding infrastructure and related technology components for Build 1 have been provided by Aruba/HPE. IoT devices that were onboarded using Build 1 were provided by Aruba/HPE and CableLabs. The CA used for signing creden�als issued to IoT devices was provided by SEALSQ, a subsidiary of WISeKey. For more informa�on on these collaborators and the products and technologies that they contributed to this project overall, see Sec�on 3.4. Build 1 network onboarding infrastructure components within the NCCoE lab consist of the Aruba Access Point. Build 1 also requires support from Aruba Central and the UXI Cloud, which are accessed via the internet. IoT devices that can be network-layer onboarded using Build 1 include the Aruba/HPE UXI sensor and CableLabs Raspberry Pi. The UXI sensor also includes the Aruba UXI Applica�on, which enables it to use independent (see Sec�on 3.3.2) applica�on-layer onboarding to be onboarded at the applica�on layer as well, providing that the network to which the UXI sensor is onboarded has connec�vity to the UXI Cloud via the internet. The Build 1 implementa�on supports the provisioning of all three types of network creden�als defined in DPP: 

Connector for DPP-based network access



Password/passphrase/PSK for WPA3/WPA2 network access



X.509 cer�ficates for 802.1X network access

Build 1 has been integrated with the SEALSQ CA on SEALSQ INeS CMS to enable Build 1 to obtain signed cer�ficates from this CA when Build 1 is onboarding devices and issuing creden�als for 802.1X network access. When issuing creden�als for DPP and WPA3/WPA2-based network access, the configurator does not need to use a CA. Table C-1 lists the technologies used in Build 1. It lists the products used to instan�ate each component of the reference architecture and describes the security func�on that the component provides. The components listed are logical. They may be combined in physical form, e.g., a single piece of hardware may house a network onboarding component, a router, and a wireless access point.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

78

FINAL Table C-1 Build 1 Products and Technologies Component

Product

Function

Network-Layer Onboarding Component (Wi-Fi Easy Connect Configurator)

Aruba Access Point with support from Aruba Central

Runs the Wi-Fi Easy Connect network-layer onboarding protocol to interact with the IoT device to perform oneway or mutual authentication, establish a secure channel, and securely provide local network credentials to the device. If the network credential that is being provided to the device is a certificate, the onboarding component will interact with a certificate authority to sign the certificate. The configurator deployed in Build 1 supports DPP 2.0, but it is also backward compatible with DPP 1.0.

Access Point, Router, or Switch

Aruba Access Point

Wireless access point that also serves as a router. It may get configured with per-device access control lists (ACLs) and policy when devices are onboarded.

Supply Chain Integration Service

Aruba Central

The device manufacturer provides device bootstrapping information to the HPE Cloud via the REST API that is documented in the DPP specification. Once the device is transferred to an owner, the HPE Cloud provides the device bootstrapping information (i.e., the device’s DPP URI) to the device owner’s private tenancy within the HPE Cloud.

Authorization Service

Cloud Auth (on Aruba Central)

The authorization service provides the configurator and router with the information needed to determine if the device is authorized to be onboarded to the network and, if so, whether it should be assigned any special roles or be subject to any specific access controls. It provides device authorization, role-based access control, and policy enforcement.

Build-Specific IoT Device

Aruba UXI Sensor

The IoT device that is used to demonstrate both trusted network-layer onboarding and trusted application-layer onboarding. It runs the Wi-Fi Easy Connect network-layer onboarding protocol supported by the build to securely receive its network credentials. It also has an application that enables it to perform independent (see Section 3.3.2) application-layer onboarding.

Generic IoT Device

Raspberry Pi

The IoT device that is used to demonstrate only trusted network-layer onboarding.

Secure Storage

Aruba UXI Sensor Trusted Platform Module (TPM)

Storage on the IoT device that is designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to store and process private keys, credentials, and other information that must be kept confidential.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

79

FINAL Component

Product

Function

Certificate Authority (CA)

SEALSQ INeS CMS CA

Issues and signs certificates as needed. These certificates can be used by the device to connect to any 802.1abased network.

Application-Layer Onboarding Service

UXI Application and UXI Cloud

After connecting to the network, the device downloads its application-layer credentials from the UXI cloud and uses them to authenticate to the UXI application, with which it interacts.

Ongoing Device Authorization

N/A – Not intended for inclusion in this build

Performs activities designed to provide an ongoing assessment of the device’s trustworthiness and authorization to access network resources. For example, it may perform behavioral analysis or device attestation and use the results to determine whether the device should be granted access to certain high-value resources, assigned to a particular network segment, or other action taken.

Manufacturer Factory Provisioning Process

N/A (Not implemented at the time of publication)

Manufactures the IoT device. Creates, signs, and installs the device’s unique identity and other birth credentials into secure storage. Installs information the device requires for application-layer onboarding (if applicable). May populate a manufacturer database with information regarding devices that are created and, when the devices are sold, may record what entity owns them.

C.2 Build 1 Architecture C.2.1 Build 1 Logical Architecture Figure C-1 depicts the network-layer onboarding steps that are performed in Build 1. These steps are divided into two main parts: those required to transfer device bootstrapping informa�on from the device manufacturer to the device owner’s authoriza�on service (labeled with leters) and those required to perform network-layer onboarding of the device (labeled with numbers). The device manufacturer: 1. Creates the device and installs a unique birth credential into secure storage on the device. Then the manufacturer sends the device’s bootstrapping information, which takes the form of a DPP URI, to Aruba Central in the HPE cloud. The device manufacturer interfaces with the HPE cloud via a REST API. 2. When the device is purchased, the device’s DPP URI is sent to the HPE cloud account of the device’s owner. The device owner’s cloud account contains the DPP URIs for all devices that it owns.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

80

FINAL IoT Device Manufacturing and Ownership Transfer Activities

Device Manufacturer

(A) Create the IoT Device Install the device’s unique birth credential into the device’s secure storage Send the device’s DPP URI to the HPE Cloud (via the REST API)

(B) Provide the device’s DPP URI to the device owner’s account in the cloud

Network-Layer Onboarding Steps IoT Devices (1) Device enters onboarding mode and waits for DPP exchange to begin (3) Configurator and device perform the authentication phase of DPP—a 3-way handshake that authenticates the device and establishes a secure channel with it

HPE Cloud

(6) Acquire an IP address via DHCP and use the network credentials to connect to the network securely

Access Point, Router, or Switch

(5) Assign any special roles or ACLs pertaining to the device

(4) Configurator and device perform the configuration phase of DPP—a 3-way handshake that provisions network credentials to the device (e.g., SSID, unique PSK)

Configurator

(2) Configurator verifies that the device is authorized to be onboarded to the network by obtaining its public key from the list of owned device DPP URIs

Authorization Service

Figure C-1 Logical Architecture of Build 1 A�er obtaining the device, the device owner provisions the device with its network creden�als by performing the following network-layer onboarding steps: 1. The owner puts the device into onboarding mode. The device waits for the DPP exchange to begin. This exchange includes the device issuing a discovery message, which the owner’s configurator hears. The discovery message is secured such that it can only be decoded by an entity that possesses the device’s DPP URI. 2. The configurator consults the list of DPP URIs of all owned devices to decode the discovery message and verify that the device is owned by the network owner and is therefore assumed to be authorized to be onboarded to the network. 3. Assuming the configurator finds the device’s DPP URI, the configurator and the device perform the authentication phase of DPP, which is a three-way handshake that authenticates the device and establishes a secure (encrypted) channel with it. 4. The configurator and the device use this secure channel to perform the configuration phase of DPP, which is a three-way handshake that provisions network credentials to the device, along with any other information that may be needed, such as the network SSID. 5. The router or switch consults the owner’s authentication, authorization, and accounting (AAA) service to determine if the device should be assigned any special roles or if any special ACL entries should be made for the device. If so, these are configured on the router or switch. NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

81

FINAL 6. The device uses Dynamic Host Configuration Protocol (DHCP) to acquire an IP address and then uses its newly provisioned network credentials to connect to the network securely.

This completes the network-layer onboarding process. A�er the device is network-layer onboarded and connects to the network, it automa�cally performs independent (see Sec�on 3.3.2) applica�on-layer onboarding. The applica�on-layer onboarding steps are not depicted in Figure C-1. During the applica�on-layer onboarding process, the IoT device, which is a UXI sensor, authen�cates itself to the UXI cloud using its manufacturing cer�ficate and pulls its applica�on-layer creden�als from the UXI cloud. In addi�on, if a firmware update is relevant, this also happens. The UXI sensor contacts the UXI cloud service to download a customer-specific configura�on that tells it what to monitor on the customer’s network. The UXI sensor then conducts the network performance monitoring func�ons it is designed to perform and uploads the data it collects to the UXI applica�on dashboard.

C.2.2 Build 1 Physical Architecture Sec�on 5.2 describes the physical architecture of Build 1.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

82

FINAL

Appendix D

Build 2 (Wi-Fi Easy Connect, CableLabs, OCF)

D.1 Technologies Build 2 is an implementa�on of network-layer onboarding that uses the Wi-Fi Easy Connect protocol. Build 2 also supports streamlined (see Sec�on 3.3.2) applica�on-layer onboarding to the OCF security domain. The network-layer onboarding infrastructure for Build 2 is provided by CableLabs and the applica�on-layer onboarding infrastructure is provided by OCF. IoT devices that were network-layer onboarded using Build 2 were provided by Aruba/HPE and OCF. Only the IoT devices provided by OCF were capable of being both network-layer onboarded and streamlined applica�on-layer onboarded. For more informa�on on these collaborators and the products and technologies that they contributed to this project overall, see Sec�on 3.4. Build 2 onboarding infrastructure components consist of the CableLabs Custom Connec�vity Gateway Agent, which runs on the Gateway Access Point, and the Pla�orm Controller. IoT devices onboarded by Build 2 include the Aruba UXI Sensor and CableLabs Raspberry Pi. Table D-1 lists the technologies used in Build 2. It lists the products used to instan�ate each logical build component and the security func�on that the component provides. The components listed are logical. They may be combined in physical form, e.g., a single piece of hardware may house a network onboarding component, a router, and a wireless access point. Table D-1 Build 2 Products and Technologies Component

Product

Function

Network-Layer Onboarding Component (Configurator)

CableLabs Custom Connectivity Gateway Agent with support from CableLabs Platform Controller

Runs the Wi-Fi Easy Connect network-layer onboarding protocol to interact with the IoT device to perform oneway or mutual authentication, establish a secure channel, and securely provide local network credentials to the device. It also securely conveys application-layer bootstrapping information to the device as part of the WiFi Easy Connect protocol to support application-layer onboarding. The network-layer onboarding component deployed in Build 2 supports DPP 2.0, but it is also backward compatible with DPP 1.0.

Access Point, Router, or Switch

Raspberry Pi (running Custom Connectivity Gateway Agent)

The access point includes a configurator that runs the WiFi Easy Connect Protocol. It also serves as a router that: 1) routes all traffic exchanged between IoT devices and the rest of the network, and 2) assigns each IoT device to a local network segment appropriate to the device’s trust level (optional).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

83

FINAL Component

Product

Function

Supply Chain Integration Service

CableLabs Platform Controller/IoTivity Cloud Service

The device manufacturer provides device bootstrapping information (i.e., the DPP URI) to the CableLabs Web Server. There are several potential mechanisms for sending the DPP URI to the CableLabs Web Server. The manufacturer can send the device’s DPP URI to the Web Server directly, via an API. The API used is not the REST API that is documented in the DPP specification. However, the API is published and was made available to manufacturers wanting to onboard their IoT devices using Build 2. Once the device is transferred to an owner, the CableLabs Web Server provides the device’s DPP URI to the device owner’s authorization service, which is part of the owner’s configurator.

Authorization Service

CableLabs Platform Controller

The authorization service provides the configurator and router with the information needed to determine if the device is authorized to be onboarded to the network and, if so, whether it should be assigned any special roles, assigned to any specific network segments, or be subject to any specific access controls.

Build-Specific IoT Device

Raspberry Pi (Bulb) Raspberry Pi (switch)

The IoT devices that are used to demonstrate both trusted network-layer onboarding and trusted application-layer onboarding. They run the Wi-Fi Easy Connect networklayer onboarding protocol to securely receive their network credentials. They also support application-layer onboarding of the device to the OCF environment by conveying the device’s application-layer bootstrapping information as part of the network-layer onboarding protocol.

Generic IoT Device

Aruba UXI Sensor

The IoT device that is used to demonstrate only trusted network-layer onboarding.

Secure Storage

N/A (IoT device is not equipped with secure storage)

Storage designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to store and process private keys and other information that must be kept confidential.

Certificate Authority

N/A (Not implemented at the time of publication)

Issues and signs certificates as needed.

Application-Layer Onboarding Service

OCF Diplomat and OCF OBT within IoTivity

After connecting to the network, the OCF Diplomat authenticates the devices, establishes secure channels with them, and sends them access control lists that control which bulbs each switch is authorized to turn on and off.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

84

FINAL Component

Product

Function

Ongoing Device Authorization

N/A – Not intended for inclusion in this build

Performs activities designed to provide ongoing assessment of the device’s trustworthiness and authorization to access network resources. For example, it may perform behavioral analysis or device attestation and use the results to determine whether the device should be granted access to certain high-value resources, assigned to a particular network segment, or other action taken.

Manufacturer Factory Provisioning Process

N/A (Not yet implemented)

Manufactures the IoT device. Creates, signs, and installs the device’s unique identity and other birth credentials into secure storage. Installs information the device requires for application-layer onboarding (if applicable). May populate a manufacturer database with information regarding devices that are created and, when the devices are sold, may record what entity owns them.

D.2 Build 2 Architecture D.2.1 Build 2 Logical Architecture The network-layer onboarding steps that are performed in Build 2 are depicted in Figure D-1. These steps are broken into two main parts: those required to transfer device bootstrapping informa�on from the device manufacturer to the device owner’s authoriza�on service (labeled with leters) and those required to perform network-layer onboarding of the device (labeled with numbers). 1. The device manufacturer creates the device and installs a unique birth credential into secure storage on the device. Because the device created for use in Build 2 will also perform application-layer onboarding into the OCF security domain, as part of the manufacturing process the manufacturer also either installs application-layer bootstrapping information onto the device or ensures that the device has the capability to generate one-time application-layer bootstrapping information at runtime. Then the manufacturer makes the device’s network-layer bootstrapping information, which takes the form of a DPP URI, available to the device’s owner.

Build 2 supports several mechanisms whereby the manufacturer can make the device’s network-layer bootstrapping informa�on (i.e., its DPP URI) available to the device owner. The device’s DPP URI can be uploaded directly to a device owner’s cloud account or web server via API (as might come in handy when onboarding many enterprise devices at one �me). Alterna�vely, the DPP URI can be manually entered into a local web portal that runs a configura�on webpage that a device on the same Wi-Fi network can connect to for purposes of scanning a QR code or typing in the DPP URI. A DPP URI that is to be entered manually could, for example, be emailed to the owner or encoded into a QR code

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

85

FINAL and printed on the device chassis, in device documenta�on, or on device packaging. Table D-1 depicts the case in which the manufacturer provides the device’s DPP URI to the owner for manual entry. When the owner receives the device’s DPP URI, the owner may op�onally add the device’s DPP URI to a list of DPP URIs for devices that it owns that is maintained as part of the owner’s authoriza�on service. Such a list would enable the owner’s network to determine if a device is authorized to be onboarded to it. 2. The person onboarding the device opens a web application and enters the device’s DPP URI. The web application then sends the DPP URI to the Wi-Fi Easy Connect configurator, e.g., through a web request. (Note: Although the laboratory implementation of Build 2 requires the user to enter the DPP URI via a web page, an implementation designed for operational use would typically require the user to provide the DPP URI by scanning a QR code into a network operator-provided app that is logged into the user’s account.) IoT Device Manufacturing and Ownership Transfer Activities

Device Manufacturer

(A) Create the IoT Device, install the device’s unique birth credential, and either install its application-layer bootstrapping information or ensure that it can generate one-time application-layer bootstrapping information at runtime. Provide the device’s DPP URI to the device’s owner either via the CableLabs web server or via QR code

Network- and Application-Layer Onboarding (B) Person opens a web app and inputs the device’s DPP URI, which is sent to the configurator, thereby performing the trusted introduction of the device’s bootstrapping information

IoT Devices

(6) The device uses its newly-provisioned network credentials to connect to the network securely and then acquires an IP address via DHCP

(1) The device enters onboarding mode and waits for the DPP exchange to begin (3) The configurator and the device perform the authentication phase of DPP—a three-way handshake that authenticates the device and establishes a secure channel with it (4) The configurator and the device perform the configuration phase of DPP. During this three-way handshake, the device sends its application-layer bootstrapping information as part of the DPP configuration crequest object and the configurator provisions network credentials to the device

Secure storage

(7) The OCF OBT discovers the device and prompts the user for confirmation. Assuming user confirmation is received, the OBT authenticates the device and establishes a secure channel with it

Access Point and Router

Wi-Fi Easy Connect Configurator OCF Diplomat

(2) The configurator verifies that the device is authorized to be onboarded to the network (5) The configurator sends the device’s application-layer bootstrapping information to the OCF OBT via the OCF Diplomat

NetworkLayer Onboarding Authorization Service

OCF OBT

(8) The OBT installs operational trust anchors on the device and sends it an access control list that dictates which bulbs each light switch is authorized to turn on and off.

Figure D-1 Logical Architecture of Build 2 A�er ensuring that the device’s network-layer bootstrapping informa�on (i.e., its DPP URI) has been uploaded to the configurator, the device owner performs both trusted network-layer onboarding and streamlined applica�on-layer onboarding to the OCF security domain by performing the steps depicted in Figure D-1. In this diagram, the components that relate to network-layer onboarding are depicted in dark blue and their associated steps are writen in black

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

86

FINAL font. The components and steps related to applica�on-layer onboarding are depicted in light blue. The steps are as follows: 1. The owner puts the device into onboarding mode. The device waits for the DPP exchange to begin. This exchange includes the device issuing a discovery message, which the owner’s configurator hears. The discovery message is secured such that it can only be decoded by an entity that possesses the device’s DPP URI. 2. Optionally, if such a list is being maintained, the configurator consults the list of DPP URIs of all owned devices to verify that the device is owned by the network owner and is, therefore, assumed to be authorized to be onboarded to the network. (If the device is being onboarded by an enterprise, the enterprise would likely maintain such a list; however, if the device is being onboarded to a home network or small business, this step might be omitted.) 3. Assuming the configurator finds the device’s DPP URI, the configurator and the device perform the authentication phase of DPP, which is a three-way handshake that authenticates the device and establishes a secure (encrypted) channel with it. 4. The configurator and the device use this secure channel to perform the configuration phase of DPP, which is a three-way handshake that provisions network credentials to the device, along with any other information that may be needed, such as the network SSID. In particular, as part of the three-way handshake in the Build 2 demonstration, the device sends its application-layer bootstrapping information to the configurator as part of the DPP configuration request object. 5. The configurator receives the device’s application-layer bootstrapping information and forwards it to the OCF Diplomat. The purpose of the OCF Diplomat is to provide a bridge between the network and application layers. It accomplishes this by parsing the org.openconnectivity fields of the DPP request object, which contains the UUID of the device and the application-layer bootstrapping credentials, and sending these to the OCF OBT as part of a notification that the OBT has a new device to onboard. The Diplomat and the OBT use a subscribe and notify mechanism to ensure that the OBT will receive the onboarding request even if the OBT is unreachable for a period of time (e.g., the OBT is out of the home). 6. The device uses its newly provisioned network credentials to connect to the network securely and then uses DHCP to acquire an IP address. This completes the network-layer onboarding process. 7. The OBT implements a filtered discovery mechanism using the UUID provided from the OCF Diplomat to discover the new device on the network. Once it discovers the device, before proceeding, the OBT may optionally prompt the user for confirmation that they want to perform application-layer onboarding to the OCF security domain. This prompting may be accomplished, for example, by sending a confirmation request to an OCF app on the user’s mobile device. Assuming the user responds affirmatively, the OBT uses the application-layer bootstrapping information to authenticate the device and take ownership of it by setting up a Datagram Transport Layer Security (DTLS) connection with the device. 8. The OBT then installs operational trust anchors and access control lists onto the device. For example, in the access control list, each light bulb may have an access control entry dictating NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

87

FINAL which light switches are authorized to turn it on and off. This completes the application-layer onboarding process.

Note that, at this �me, the applica�on-layer bootstrapping informa�on is provided unilaterally in the Build 2 applica�on-layer onboarding demonstra�on. The applica�on-layer bootstrapping informa�on of the device is provided to the OCF Diplomat, enabling the OBT to authen�cate the device. In a future version of this process, the applica�on-layer bootstrapping informa�on could be provided bi-direc�onally, meaning that the OCF Diplomat could also send the OCF opera�onal root of trust to the IoT device as part of the DPP configura�on response frame. Exchanging applica�on-layer bootstrapping informa�on bilaterally in this way would enable the secure channel set up as part of the network-layer onboarding process to support the establishment of a mutually authen�cated session between the device and the OBT. In the Build 2 demonstra�on, two IoT devices, a switch and a light bulb, are onboarded at both the network and applica�on layers. Each device sends the OCF Diplomat its applica�on-layer bootstrapping informa�on over the secure network-layer onboarding channel during the network-layer onboarding process. Immediately a�er they complete the network-layer onboarding process and connect to the network, the OCF Diplomat provides their applica�on-layer bootstrapping informa�on to the OBT. The OBT then uses the provided applica�on-layer bootstrapping informa�on to discover, authen�cate, and onboard each device. Because the devices have no way to authen�cate the iden�ty of the OBT in the current implementa�on, the devices are configured to trust the OBT upon first use. A�er the OBT authen�cates the devices, it establishes secure channels with them and provisions them with access control lists that control which bulbs each switch is authorized to turn on and off. To demonstrate that the applica�on onboarding was successful, Build 2 demonstrates that the switch is able to control only those bulbs that the OCF OBT has authorized it to.

D.2.2 Build 2 Physical Architecture Sec�on 5.2.1 describes the physical architecture of Build 2.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

88

FINAL

Appendix E

Build 3 (BRSKI, Sandelman So�ware Works)

E.1 Technologies Build 3 is an implementa�on of network-layer onboarding that uses the BRSKI protocol. Build 3 does not support applica�on-layer onboarding. The network-layer onboarding infrastructure and related technology components for Build 3 were provided by Sandelman So�ware Works. The Raspberry Pi, ESP32, and Nordic NRF IoT devices that will be onboarded in a future implementa�on of Build 3 were also provided by Sandelman So�ware Works, as was the Sandelman So�ware Works Reach Pledge Simulator, which is the device that is onboarded in the current build. The IoT devices do not have secure storage, but future plans are to integrate them with secure storage elements. Build 3 issues private PKI cer�ficates as network creden�als at this �me, but future plans are to integrate Build 3 with a third-party private CA from which it can obtain signed cer�ficates. For more informa�on on Sandelman So�ware Works and the products and technologies that it contributed to this project overall, see Sec�on 3.4. Onboarding Build 3 infrastructure components consist of Raspberry Pi, Nordic NRF, ESP32, Sandelman So�ware Works Minerva Fountain Join Registrar/Coordinator, Sandelman So�ware Works Minerva. Highway, Sandelman So�ware Works Reach Pledge Simulator, and a Minerva Fountain internal CA. Table E-1 lists the technologies used in Build 3. It lists the products used to instan�ate each logical build component and the security func�on that the component provides. The components are logical. They may be combined in physical form, e.g., a single piece of hardware may house both a network onboarding component and a router and/or wireless access point. Table E-1 Build 3 Products and Technologies Component

Product

Function

Network-Layer Onboarding Component (BRSKI Domain Registrar)

Sandelman Software Works Minerva Fountain Registrar

Runs the BRSKI protocol. It authenticates the IoT device, receives a voucher-request from the IoT device, and passes the request to the MASA. It also receives a voucher from the MASA, verifies it, and passes it to the IoT device. Assuming the IoT device finds the voucher to be valid and determines that the network is authorized to onboard it, the Domain Registrar provisions network credentials to the IoT device using EST.

Access Point, Router, or Switch

Turris MOX router running OpenWRT

The Onboarding Router segments the onboarding device from the rest of the network until the BRSKI onboarding is complete

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

89

FINAL Component

Product

Function

Supply Chain Integration Service (Manufacturer Authorized Signing Authority—MASA)

Minerva Highway, which is a MASA provided by Sandelman Software Works

The device manufacturer provides device bootstrapping information (e.g., the device’s X.509 certificate) and device ownership information to the MASA. The MASA creates and signs a voucher saying who the owner of the device is and provides this voucher to the IoT device via the Domain Registrar so that the device can verify that the network that is trying to onboard it is authorized to do so.

Authorization Service

Minerva Highway, which is a MASA provided by Sandelman Software Works

As described in the previous row.

Build-Specific IoT Device

Sandelman Software Works Reach Pledge Simulator

The device that is used to demonstrate trusted network-layer onboarding by joining the network.

Secure Storage

N/A (The IoT devices and the Sandelman Software Works Reach Pledge Simulator do not include secure storage)

Storage on the IoT device that is designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to store and process private keys, credentials, and other information that must be kept confidential.

Certificate Authority

N/A (self-signed certificates were used)

Issues and signs certificates as needed.

Application-Layer Onboarding Service

None. Not supported in this build.

After connecting to the network, the device mutually authenticates with a trusted application service and interacts with it at the application layer.

Ongoing Device Authorization

N/A – Not intended for inclusion in this build

Performs activities designed to provide an ongoing assessment of the device’s trustworthiness and authorization to access network resources. For example, it may perform behavioral analysis or device attestation and use the results to determine whether the device should be granted access to certain highvalue resources, assigned to a particular network segment, or other action taken.

Manufacturer Factory Provisioning Process

N/A (Not implemented at the time of publication)

Manufactures the IoT device. Creates, signs, and installs the device’s unique identity and other birth credentials into secure storage. Installs information the device requires for application-layer onboarding (if applicable). May populate a manufacturer database with information regarding devices that are created and, when the devices are sold, may record what entity owns them.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

90

FINAL

E.2 Build 3 Architecture E.2.1 Build 3 Logical Architecture The network-layer onboarding steps that are performed in Build 3 are depicted in Figure E-1. These steps are broken into two main parts: those required to transfer device bootstrapping informa�on from the device manufacturer to the device owner’s authoriza�on service (labeled with leters) and those required to perform network-layer onboarding of the device (labeled with numbers). These steps are described in greater detail in IETF RFC 8995. The device manufacturer: 1. Creates the device and installs a unique serial number and birth credential into secure storage on the device. This unique birth credential takes the form of a private key and its associated 802.1AR certificate, e.g., the device’s IDevID. As part of this factory-installed certificate process, the location of the device’s MASA is provided in an extension to the IDevID. The device is also provided with trust anchors for the MASA entity that will sign the returned vouchers. 2. Stores information about the device, such as its serial number and its IDevID, in the MASA’s database. 3. Eventually, when the device is sold, the MASA may also record the device ownership information in its database. IoT Device Manufacturing and Ownership Transfer Activities

Device Manufacturer

(A) Create the IoT Device and give it a serial number Install the device’s unique birth credential into the device’s secure storage (IDevID) Provide the location of the device's MASA and a trust anchor for the MASA

Supply Chain Integration Service

Network-Layer Onboarding (1) Device establishes/discovers an https connection to the local Domain Registrar

IoT Devices (Pledges)

(5) Registrar examines the new voucher and other info. Based on this info, the Registrar makes the decision to continue bootstrapping and passes the voucher to the device (6) Device verifies the voucher signature by using pre-provisioned trust anchors associated with the MASA (7) Device uses EST to requests new credentials

C) Eventually, when the device is purchased, the manufacturer may also record the device owner information in the MASA

(9) Device uses network credentials to connect to the network securely

(2) Device creates a pledge voucher request, signs it using its IDevID certificate, and sends the request to the Registrar

Access Point, Router, or Switch (8) Registrar provisions network credentials to the device using EST (e.g. LDevID)

Domain Registrar

(3) Registrar determines if the device was expected. If so, it creates, signs, and sends to the device’s MASA a registrar voucher-request containing the info from the pledge voucherrequest and info about the registrar/owner.

B) Store the device serial # and IDevID in the MASA database.

Manufacturer Authorized Signing Authority (MASA)

4) MASA verifies that the Registrar owns the device (or trusts on first use), creates a new voucher indicating this, and passes the new voucher back to the Registrar.

Figure E-1 Logical Architecture of Build 3

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

91

FINAL A�er obtaining the device, the device owner provisions the device with its network creden�als by performing the following network-layer onboarding steps: 4. The owner puts the device into onboarding mode. The device establishes an HTTPS connection to the local Domain Registrar. Trust in the Domain Registrar is provisional. (In a standard implementation, the device would use link-local network connectivity to locate a join proxy, and the join proxy would provide the device with HTTPS connectivity to the local Domain Registrar. The Build 3 implementation, however, does not support discovery at this time. To overcome this code limitation, the IoT device has been pre-provided with the address of the local Domain Registrar, to which it connects directly.) 5. The device creates a pledge voucher-request that includes the device serial number, signs this request with its IDevID certificate (i.e., its birth credential), and sends this signed request to the Registrar. 6. The Registrar receives the pledge voucher-request and considers whether the manufacturer is known to it and whether devices of that type are welcome. If so, the Registrar forms a registrar voucher-request that includes all the information from the pledge voucher-request, along with information about the registrar/owner. The Registrar signs this registrar voucher-request. It locates the MASA that the IoT device is known to trust (e.g., the MASA that is identified in the device’s IDevID extension) and sends the registrar voucher-request to the MASA. 7. The MASA consults the information that it has stored and applies policy to determine whether or not to approve the Registrar’s claim that it owns and/or is authorized to onboard the device. (For example, the MASA may consult sales records for the device to verify device ownership, or it may be configured to trust that the first registrar that contacts it on behalf of a given device is in fact the device owner.) Assuming the MASA decides to approve the Registrar’s claim to own and/or be authorized to onboard the device, the MASA creates a voucher that directs the device to accept its new owner/authorized network, signs this voucher, and sends it back to the Registrar. 8. The Registrar receives this voucher, examines it along with other related information (such as security posture, remote attestation results, and/or expected device serial numbers), and determines whether it trusts the voucher. Assuming it trusts the voucher, the Registrar passes the voucher to the device. 9. The device uses its factory-provisioned MASA trust anchors to verify the voucher signature, thereby ensuring that the voucher can be trusted. The voucher also validates the Registrar and represents the intended owner, ending the provisional aspect of the EST connection. 10. The device uses Enrollment over Secure Transport (EST) to request new credentials. 11. The Registrar provisions network credentials to the device using EST. These network credentials get stored in secure storage on the device, e.g., as an LDevID. 12. The device uses its newly provisioned network credentials to connect to the network securely.

This completes the trusted network-layer onboarding process for Build 3.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

92

FINAL

E.2.2 Build 3 Physical Architecture Sec�on 5.4 describes the physical architecture of Build 3.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

93

FINAL

Appendix F

Build 4 (Thread, Silicon Labs-Thread, Kudelski KeySTREAM)

F.1 Technologies Build 4 is an implementa�on of network-layer connec�on to an OpenThread network, followed by use of the Kudelski IoT keySTREAM Service to perform independent (see Sec�on 3.3.2) applica�on-layer onboarding of the device to a par�cular customer’s tenancy in the AWS IoT Core. To join the network, the joining device generates and displays a pre-shared key that the owner enters on the commissioner, through a web interface, for authen�ca�on. The network-layer infrastructure for Build 4 was provided by Silicon Labs. The applica�on-layer onboarding infrastructure for Build 4 was provided by Kudelski IoT. IoT devices that were onboarded using Build 4 were provided by Silicon Labs. For more informa�on on these collaborators and the products and technologies that they contributed to this project overall, see Sec�on 3.4. Build 4 network infrastructure components within the NCCoE lab consist of a Thread border router (which is implemented using a Raspberry Pi) and a Silicon Labs Gecko Wireless Starter Kit. Build 4 also requires support from the Kudelski IoT keySTREAM service to perform applica�on-layer onboarding. The keySTREAM service comes as a SaaS pla�orm that is running in the cloud (accessible via the internet), and a so�ware library (KTA – Kudelski Trusted Agent) that is integrated in the IoT device so�ware stack. The KTA integrates with the Silicon Labs’ Hardware Root of Trust (Secure Vault). The IoT device that is connected to the network and applica�onlayer onboarded using Build 4 is the Silicon Labs Thunderboard (BRD2601A) with EFR32MG24x with Secure Vault(TM) High which is security cer�fied to PSA/SESIP Level 3. Table F-1 lists the technologies used in Build 4. It lists the products used to instan�ate each logical build component and the security func�on that the component provides. The components are logical. They may be combined in physical form, e.g., a single piece of hardware may house a network onboarding component, a router, and a wireless access point. Table F-1 Build 4 Products and Technologies Component

Product

Function

Network-Layer Onboarding Component (Thread Protocol Component)

SLWSTK6023A Thread Radio Transceiver (Wireless starter kit);

The SLWSTK6023A acts as a Thread radio transceiver or radio coprocessor (RCP), allowing the open thread boarder router host platform to form and communicate with a Thread network. If the Thread MeshCoP were running on this device, it would provision the IoT device with credentials for the Thread network.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

94

FINAL Component

Product

Function

Access Point, Router, or Switch

OpenThread Border Router (OTBR) hosted on a Raspberry Pi

Router that has interfaces both on the Thread network and on the IP network to act as a bridge between the Thread network and the public internet. This allows the IoT device that communicates using the Thread wireless protocol to communicate with cloud services.

Supply Chain Integration Service

Silicon Labs Custom Parts Manufacturer Service (CPMS)

To support network-layer onboarding, the device manufacturer provides device bootstrapping information to the to the device owner.

Authorization Service

Not implemented

Enables the network to verify that the device that is trying to onboard to it is authorized to do so.

Build-Specific IoT Device

Silicon Labs Thunderboard (BRD2601A)

The IoT device that is used to demonstrate trusted network- and application-layer onboarding.

Secure Storage

Secure Vault ™ High on Silicon Labs IoT device

Storage designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to store and process private keys and other information that must be kept confidential.

Certificate Authority (CA)

Each tenant in the Kudelski keySTREAM service cloud has its own certificate signing authority

Issues and signs certificates as needed. For applicationlayer onboarding, the device owner has its own certificate signing authority in its portion of the Kudelski keySTREAM service cloud.

Application-Layer Onboarding Service

Kudelski keySTREAM Service

After connecting to the Thread network, the device performs application-layer onboarding by accessing the Kudelski keySTREAM service. The device and the keySTREAM service mutually authenticate; the keySTREAM service verifies the device’s owner, generates an application-layer credential (i.e., an AWS certificate that is based on the device’s chipset identity and owner) for the device, and provisions the device with this X.509 credential that will enable the device to access the owner’s tenancy in the AWS IoT Core cloud.

Ongoing Device Au- N/A – Not inthorization tended for inclusion in this build

Performs activities designed to provide an ongoing assessment of the device’s trustworthiness and authorization to access network resources. For example, it may perform behavioral analysis or device attestation and use the results to determine whether the device should be granted access to certain high-value resources, assign the device to a particular network segment, or take other action.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

95

FINAL Component

Product

Function

Manufacturer Factory Provisioning Process

Silicon Labs Custom Parts Manufacturing Service (CPMS)

Manufactures the IoT device. Creates, signs, and installs the device’s unique identity and other birth credentials into secure storage. Installs software and information the device requires for application-layer onboarding. May populate a manufacturer database with information regarding devices that are created and, when the devices are sold, may record what entity owns them. The MG24 “B” version comes pre-loaded with a Silicon Labs Birth certificate. The “A” or “B” version birth certificate can be modified via their Custom Part Manufacturing Service (CPMS) to be unique per end device manufacturer and signed into their Root CA if desired.

F.2 Build 4 Architecture F.2.1 Build 4 Logical Architecture Build 4 demonstrates a device connec�ng to an OpenThread network. IoT devices generate and use a pre-shared key to connect to the OpenThread network of Build 4 using the Thread MeshCoP service. Once a device is connected to the OpenThread network of Build 4, it gets access to an IP network via a border router, and then performs applica�on-layer onboarding using the Kudelski keySTREAM Service. Kudelski keySTREAM is a device security management service that runs as a SaaS pla�orm on the Amazon cloud. Build 4 relies on an integra�on that has been performed between Silicon Labs and Kudelski keySTREAM. KeySTREAM has integrated so�ware libraries with the Silicon Lab EFR32MG24 (MG24) IoT device’s secure vault to enable the private signing key that is associated with an applica�on-layer cer�ficate to be stored into the secure vault using security controls that are available on the MG24. This integra�on ensures that applica�on-layer creden�als can be provisioned into the vault securely such that no key material is misused or exposed. At a high level, the steps required to enable demonstra�on of Build 4’s network connec�on and applica�on-layer onboarding capabili�es can be broken into the following three main parts: 

Device Prepara�on: The IoT device is prepared for network connec�on and applica�onlayer onboarding by the device manufacturer. •

The device comes from the manufacturer ready to be provisioned onto a Thread network. No addi�onal prepara�on is required.

•

The device is prepared for applica�on-layer onboarding on behalf of a specific, pre-defined customer who will become its owner. The device is assigned ownership to this customer (e.g., customer A) and this ownership informa�on is sealed

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

96

FINAL into device firmware, permanently iden�fying the device as being owned by customer A. The device owner, customer A, has a tenancy on the Kudelski keySTREAM Service and is also an Amazon Web Services (AWS) customer. A�er the device has been prepared, the device is provided to its owner (customer A). 

Network Connec�on: Customer A connects the device to Customer A’s OpenThread network by entering the pre-shared key displayed on the device’s serial terminal in the OpenThread Border Router’s (OTBR) web interface. This allows the network‘s radio channel, PAN ID, extended PAN ID and network name to be discovered, avoiding the need to preconfigure any of these parameters. Once on customer A’s OpenThread network, the device has access to the public IP network via the border router.



Applica�on-Layer Onboarding: The device and the keySTREAM service mutually authen�cate, keySTREAM confirms that customer A owns the device, and keySTREAM provisions the device with an AWS cer�ficate that is specific to the device and to customer A, enabling the device to authen�cate to customer A’s tenancy in the AWS IoT Core.

Each of these three aspects of the demonstra�on are illustrated in its own figure and described in more detail in the three subsec�ons below.

F.2.1.1 Device Prepara�on Figure F-1 depicts the steps that are performed by the device manufacturer, which in this case is Silicon Labs, to prepare the device for network- and applica�on-layer onboarding by a par�cular customer, Customer A. Each step is described in more detail below. Because these steps are performed to prepare the device for onboarding rather than as part of onboarding itself, they are labeled with leters instead of numbers in keeping with the conven�ons used in other build descrip�ons.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

97

FINAL

Figure F-4 Logical Architecture of Build 4: Device Prepara�on The following steps are performed to prepare the device for network connec�on and applica�on-layer onboarding: 1. The manufacturer creates the device, which in this case is a Silicon Labs MG24, and prepares it for network connection by installing the device’s unique birth credential into the device’s chipset. This chipset identity is a hardware root of trust. The MG24 “B” version comes pre-loaded with a Silicon Labs Birth certificate. The “A” or “B” version birth certificate can be modified via their Custom Part Manufacturing Service (CPMS) to be unique per end device manufacturer and signed into their Root CA if desired. 2. The manufacturer provides information about the device to customer A (perhaps via the supply chain service, as depicted in Figure F-1) so customer A can be aware that the device is expected on its network. 3. The manufacturer prepares the device for application-layer onboarding by installing the Kudelski keySTREAM Trusted Agent (KTA) software onto the device. 4. The manufacturer connects the device to the manufacturer’s local OpenThread network. (See Figure F-2 for details of the network connection steps.) Note that in this case, which is the first time that the device is being connected to a network, the device is being connected to the manufacturer’s network rather than to the network of the device’s eventual owner. 5. After the device connects to the manufacturer’s OpenThread network, the device has access to the public IP network via the border router. 6. The device and the Kudelski keySTREAM service mutually authenticate and establish an encrypted connection.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

98

FINAL 7. The KTA installs a configuration into the keySTREAM service platform that builds up a group of devices that belong to a certain end user and associates the group with a device ownership profile. This device ownership profile is associated with a particular customer (e.g., customer A). The same device profile is used by all devices in a group of devices that are owned by this owner. The profile is not specific to individual devices. The owner of these devices (customer A) has a keySTREAM tenancy, which includes a dedicated certificate signing CA. Customer A is also an AWS customer. 8. The device manufacturer installs and seals this device ownership profile into the device firmware. This profile permanently identifies the device as being owned by customer A.

F.2.1.2 Network-Layer Connec�on Figure F-2 depicts the steps of an IoT device connec�ng to that thread network using a preshared key that the device generates and shares with the OpenThread border router. Each step is described in more detail below. IoT Device Manufacturing Activities Supply Chain Integration Service

(A) Prepare the device for network connection and application-layer onboarding (See the previous figure for detailed device preparation steps.) Device Manufacturer

(B) One aspect of this preparation involves providing device information to the device owner (perhaps via the supply chain integration service, as depicted here)

(C) Provide the device info to the device owner’s authorization service

Network-Layer Connection Steps IoT Devices

(1) Device generates a pre-shared key. (2) Owner shares this key with the OpenThread border router using the router’s web interface

(3) Device requests to join the network and provides the pre-shared key as its network credential (4) Router authenticates the device based on the pre-shared key and grants the join request Border Router

Thread Network Onboarding Component

(5) Verify that the device is authorized to connect to the network (6) Assign the device network permissions

(7) The device is able to access the IP network via the border router.

Authorization Service for Device Owner

Figure F-5 Logical Architecture of Build 4: Connec�on to the OpenThread Network The device connects to the OpenThread network using the following steps: 1. The device generates a pre-shared key. 2. The owner starts the commissioning process by entering this pre-shared key on the OpenThread border router. 3. The device requests to join the network and provides the pre-shared key as its network credential.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

99

FINAL 4. The network authenticates the device based on the pre-shared key and grants the join request. 5. The network verifies that the device is authorized to connect to the network. 6. The network assigns the device network permissions and configures these as policies on the border router. 7. The device is able to access the IP network (and the internet) via the border router.

This completes the network-layer connec�on process.

F.2.1.3 Applica�on-Layer Onboarding Figure F-3 depicts the steps of the applica�on-layer onboarding process using the Kudelski keySTREAM service. Each step is described in more detail below. IoT Device Manufacturing Activities

Device Manufacturer

Prepare the device for application-layer onboarding by sealing a device ownership profile that permanently associates the device with KeySTREAM customer A into the device’s firmware. (See Figure 1-1 for the detailed device preparation steps.)

Application-Layer Onboarding (1) The device has already connected to the Thread network and now has access to the public (IP) network via the border router.

KTA

IoT Devices

(2) The device and the KeySTREAM Service mutually authenticate. (4) The KeySTREAM Service generates an AWS certificate for the device based on the device’s chipset identity and owner. (5) The KeySTREAM Service uses the dedicated CA that is running in customer A’s KeySTREAM tenancy to sign the certificate.

profile

(7) The device uses its newlyprovisioned AWS certificate to authenticate to the AWS IoT Core using the MQTT-TLS protocol.

AWS IoT Core

Border Router (6) The KeySTREAM Service securely provisions the AWS certificate to the device’s secure storage using the software library that KeySTREAM has integrated with the device’s secure vault chipset security controls to ensure that no key material is misused or exposed. Kudelski KeySTREAM Provisioning Service CA

(3) The KeySTREAM Service examines the device’s firmware profile to determine which of KeySTREAM’s customers owns the device and associates the device with the KeySTREAM tenancy of that customer (e.g., customer A).

Kudelski KeySTREAM Device Management Interface

Figure F-6 Logical Architecture of Build 4: Applica�on-Layer Onboarding using the Kudelski keySTREAM Service The applica�on-layer onboarding steps performed to provision the device with its applica�onlayer creden�als (e.g., its AWS cer�ficate) are as follows: 1. The device, which is already connected to the OpenThread network, accesses the IP network via the border router. 2. The device and the keySTREAM service mutually authenticate.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

100

FINAL 3. The keySTREAM Service examines the device’s firmware profile to determine which of keySTREAM’s customers owns the device. In this case, customer A is identified as the device owner. The keySTREAM service associates the device with customer A’s keySTREAM tenancy. 4. The keySTREAM Service generates an AWS IoT Core certificate for the device based on both the device’s ownership information and the secure hardware root of trust that is in the device’s chipset. 5. The keySTREAM Service uses the dedicated CA that is running in customer A’s keySTREAM tenancy to sign the AWS certificate. 6. The keySTREAM Service securely provisions the AWS certificate to the device’s secure storage using the software library that keySTREAM has integrated with the device’s secure vault chipset security controls to ensure that no key material is misused or exposed. 7. The device uses its newly provisioned application-layer credentials (i.e., the AWS certificate) to authenticate to customer A’s tenancy in the AWS IoT Core using the MQTT-TLS protocol.

F.2.2 Build 4 Physical Architecture Sec�on 5.5 describes the physical architecture of Build 4.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

101

FINAL

Appendix G Build 5 (BRSKI over Wi-Fi, NquiringMinds) G.1 Technologies Build 5 is an implementa�on of network-layer onboarding that uses a version of the BRSKI Protocol that has been modified to work over Wi-Fi. A�er the IoT device has joined the network, Build 5 also demonstrates a number of mechanisms that are performed on an ongoing basis to provide con�nuous, policy-based authoriza�on and assurance. Both the network-layer onboarding infrastructure and the con�nuous assurance service for Build 5 were provided by NquiringMinds. This en�re build can be replicated using the open sourced TrustNetZ code base. For more informa�on on NquiringMinds and the products and technologies that they contributed to this project overall, see Sec�on 3.4. Build 5 network onboarding infrastructure components within the NCCoE lab consist of a Linux based Raspberry Pi 4B router (which also runs the registrar service and MASA service), and a USB hub. The Build 5 components used to support the con�nuous assurance service include TrustNetZ Authoriza�on interfaces, TrustNetZ informa�on provider, and TrustNetZ policy engine. The IoT devices that are onboarded using Build 5 are a Raspberry Pi device. These IoT devices do not have secure storage but use the Infineon Op�ga SLB 9670 TPM 2.0 as an external secure element. Build 5 depends on an IDevID (X.509 Cer�ficate) having been provisioned to the secure element of the IoT device (pledge) prior to onboarding, as part of the factory provisioning process (see Sec�on H.1). For Build 5, this factory provisioning process was accomplished by the BRSKI Factory Provisioning Build, which is described in Sec�on H.3. Table G-1 lists the technologies used in Build 5. It lists the products used to instan�ate each logical build component and the security func�on that the component provides. The components are logical. They may be combined in physical form, e.g., a single piece of hardware may house a network onboarding component, a router, and a wireless access point. Table G-1 Build 5 Products and Technologies Component

Product

Function

Network-Layer Onboarding Component (BRSKI Domain Registrar)

Stateful, non-persistent Linux app that has two functional interfaces for both BRSKI and for the Authentication Service. (TrustNetZ onboarding)

Runs the BRSKI protocol modified to work over Wi-Fi and acts as a BRSKI Domain Registrar. It authenticates the IoT device, receives a voucher request from the IoT device, and passes the request to the MASA. It also receives a voucher from the MASA, verifies it, and passes it to the IoT device. Assuming the IoT device finds the voucher to be valid and determines that the network is authorized to onboard it, the Domain Registrar provisions network credentials to the IoT device using EST.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

102

FINAL Component

Product

Function

Access Point, Router, or Switch

Raspberry Pi 4B equipped with USB Wi-Fi dongle, running TrustNetZ AP code.

Router, providing an open Wi-Fi network and closed Wi-Fi network. Physical access control is mediated through the RADUIS interface (which is part of the TrustNetZ AP configura�on) The AP also receives network commands from the con�nuous assurance service.

Supply Chain Integration Service (Manufacturer Authorized Signing Authority—MASA)

TrustNetZ MASA

The MASA creates and signs a voucher and provides this voucher to the IoT device via the Registrar so that the device can verify that the network that is trying to onboard it is authorized to do so.

Authorization Service

Linux application which contains an encapsulated policy engine (TrustNetZ policy engine)

Determines whether the device is authorized to be onboarded to the network. The application features a REST API which accepts verifiable credential claims to feed data on entities and their relationships into its SQL database. The policy engine itself is based on verifiable credentials presentation, (persisted to SQL database), making it easily configurable and extensible.

Build-Specific IoT Device

Raspberry Pi devices (running TrustNetZ pledge agent)

The IoT device that is used to demonstrate trusted network- and application-layer onboarding. Handles the client side BRSKI protocols, the integration with the secure storage, with factory provisioning and TLS connections.

Secure Storage

Infineon Optiga SLB 9670 TPM 2.0

Storage on the IoT device that is designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to store and process private keys and other information that must be kept confidential.

Certificate Authority

TrustNetZ demo manufacturer CA (MPR – manufacture provisioning root)

Two CA are used in Build 5

TrustNetZ Domain CA

Domain CA issues certificates and provides signing and attestation functions that model network owner relationships (e.g. sign the LDevID certificate) Manufacturer CA issues the IDevID certificates; proving the device has been created by the manufacturer.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

103

FINAL Component

Product

Function

Application-Layer Onboarding Service

TrustNetZ Demo application server

After connecting to the network, the device mutually authenticates with a trusted application service and interacts with it at the application layer. The IDevID and TPM private key are used to establish a TLS session with the demonstration application server and send data to it from the device. This demonstrates the concept of secure connection to a third-party application server using the cryptographic artifacts from the onboarding process.

Ongoing Device Au- Continuous Authorization thorization Service, which calls into the in the TrustNetZ policy engine

Designed to perform a set of ongoing, policy-based continuous assurance and authorization checks on the device after it has connected to the network. As of this publication, the following ongoing checks have been implemented:



The manufacturer of the device must be trusted by the network owner



The device must be trusted by a user with appropriate privileges



The device must have an associated device type



The vulnerability score of the so�ware bill of materials (SBOM) for the device type must be lower than a set threshold



The device must not have contacted an IP address that is on a deny list

If it fails any of these periodic checks, its voucher is revoked, which removes the device from the network. Manufacturer Factory Provisioning Process

BRSKI Factory Provisioning Process used to provision the Infineon TPM with its private key and IDevID (See Section H.3)

Manufactures the IoT device. Creates, signs, and installs the device’s unique identity (i.e., its IDevID, which is an X.509 certificate) into secure storage. Installs information the device requires for application-layer onboarding. Populates the MASA with information regarding devices that are created and, when the devices are sold, may record what entity owns them.

G.2 Build 5 Architecture G.2.1 Build 5 Logical Architecture The network-layer onboarding steps that are performed in Build 5 are depicted in Figure G-1. These steps are broken into two main parts: those required to transfer device bootstrapping informa�on from the device manufacturer to the MASA (labeled with leters) and those required NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

104

FINAL to perform network-layer onboarding of the device and establish the opera�on of the con�nuous authoriza�on service (labeled with numbers).

Figure G-2 Logical Architecture of Build 5 The device manufacturer: 1. Creates the device and installs a unique serial number and birth credential into secure storage on the device. This unique birth credential takes the form of a private key and its associated 802.1AR certificate, e.g., the device’s IDevID. As part of this factory-installed certificate process, the location of the device’s manufacturer authorized signing authority (MASA) is provided in an extension to the IDevID. The device is also provided with trust anchors for the MASA entity that will sign the returned vouchers. 2. Stores information about the device, such as its serial number and its IDevID, in the MASA’s database. 3. Eventually, when the device is sold, the MASA may also record the device ownership information in its database.

A�er obtaining the device, the device owner provisions the device with its network creden�als by performing the following network-layer onboarding steps:

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

105

FINAL 1. The owner puts the device (i.e., the pledge) into onboarding mode. The device establishes an https connection to the local Domain Registrar. (In a standard BRSKI implementation, the device would have wired network connectivity. The device would use its link-local network connectivity to locate a join proxy, and the join proxy would provide the device with https connectivity to the local Domain Registrar.) The Build 5 implementation, however, relies on wireless connectivity and initially uses the unauthenticated EAP-TLS protocol. The pledge discovers potential onboarding networks by searching for public Wi-Fi networks that either match a particular SSID wildcard name or that advertise a particular realm. When the device finds a potential onboarding network, it connects to it and attempts to discover the registrar. The pledge will connect to the open Wi-Fi network and will receive either an IPv4 or IPv6 address. Subsequently, the pledge will listen to mDNS packets and will obtain the list of join proxies (IP addresses). Finally, the pledge will subsequently connect to each join proxy using the BRSKI-EST protocol. 2. The device creates a pledge voucher-request that includes the device serial number, signs this request with its IDevID certificate (i.e., its birth credential), and sends this signed request to the Registrar. 3. The Registrar receives the pledge voucher-request and considers whether the manufacturer is known to it and whether devices of that type are welcome. If so, the Registrar forms a registrar voucher-request that includes all the information from the pledge voucher request along with information about the registrar/owner. The Registrar sends this registrar voucher-request to the Continuous Authorization Service. 4. The Continuous Authorization Service consults policy to determine if this device should be permitted to be onboarded and what other conditions should be enforced. An example of policy that might be used is that the network owner wants to disable MASA validation. Assuming the device is permitted to be onboarded, the Continuous Authorization Service locates the MASA that the IoT device is known to trust (i.e., the MASA that is identified in the device’s IDevID extension) and sends the registrar voucher-request to the MASA. 5. The MASA consults the information that it has stored and applies policy to determine whether to approve the Registrar’s claim that it owns the device. (For example, the MASA may consult sales records for the device to verify device ownership, or it may be configured to trust that the first registrar that contacts it on behalf of a given device is in fact the device owner). Assuming the MASA decides to approve the Registrar’s claim to own the device, the MASA creates a new voucher that directs the device to accept its new owner, signs this voucher, and sends it back to the Continuous Authorization Service. 6. The Continuous Authorization Service receives this new voucher and examines it in consultation with policy to determine whether to continue onboarding. Some examples of policies that might be used include: permit onboarding only if no current critical vulnerabilities have been disclosed against the declared device type, the device instance has successfully passed a site-specific test process, or a test compliance certificate has been found for the declared device type. Assuming the device is permitted to be onboarded, the Continuous Authorization Service sends the new voucher to the Domain Registrar.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

106

FINAL 7. The Domain Registrar receives and examines the new voucher along with other related information and determines whether it trusts the voucher. Assuming it trusts the voucher, the Registrar passes the voucher to the device. 8. The device uses its factory-provisioned MASA trust anchors to verify the voucher signature, thereby ensuring that the voucher can be trusted. 9. The device uses Enrollment over Secure Transport (EST) to request new credentials. 10. The Registrar provisions network credentials to the device using EST. These network credentials get stored into secure storage on the device, e.g., as an LDevID. 11. The device uses its newly provisioned network credentials to connect to the network securely. 12. After the device is connected and begins operating on the network, the Continuous Authorization Service and the router make periodic asynchronous calls to each other that enable the Continuous Authorization Service to monitor device behavior and constrain communications to and from the device as needed in accordance with policy. In this manner, the Continuous Authorization Service interacts with the router on an ongoing basis to verify that the device and its operations continue to be authorized throughout the device’s tenure on the network.

This completes the network-layer onboarding process for Build 5 as well as the ini�aliza�on of the Build 5 con�nuous authoriza�on service. More details regarding the Build 5 implementa�on can be found at htps://trustnetz.org/docs/.

G.2.2 Build 5 Physical Architecture Sec�on 5.6 describes the physical architecture of Build 5.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

107

FINAL

Appendix H Factory Provisioning Process H.1 Factory Provisioning Process The Factory Provisioning Process creates and provisions a private key into the device’s secure storage; generates and signs the device’s cer�ficate (when BRSKI is supported), generates the device’s DPP URI (when Wi-Fi Easy Connect is supported), or generates other bootstrapping informa�on (when other trusted network-layer onboarding protocols are supported); provisions the device’s cer�ficate, DPP URI, or other bootstrapping informa�on onto the device; and sends the device’s cer�ficate, DPP URI, or other bootstrapping informa�on to the manufacturer’s database, which will eventually make this informa�on available to the device owner to use during network-layer onboarding.

H.1.1 Device Birth Creden�al Provisioning Methods There are various methods by which a device can be provisioned with its private key and bootstrapping informa�on (e.g., its cer�ficate, DPP URI, etc.), depending on how, where, and by what en�ty the public/private key pairs are generated [19]. Addi�onal methods are also possible depending on how the device’s cer�ficate is provided to the manufacturer’s database. The following are high-level descrip�ons of five poten�al methods for provisioning device birth creden�als during various points in the device lifecycle. These methods are not intended to be exhaus�ve: 1. Method 1: Key Pair Generated on IoT Device Summary: Generate the private key on the device; device sends the device’s bootstrapping informa�on (e.g., the device’s cer�ficate or DPP URI) to the manufacturer’s database. The steps for Method 1 are: a. The public/private key pair is generated on the device and stored in secure storage. b. The device generates and signs a CSR structure and sends the CSR to the manufacturer’s IDevID CA, which sends a signed cer�ficate (IDevID) back to the device. c. If BRSKI is being supported, the device loads the cer�ficate (IDevID) into its secure storage; if Wi-Fi Easy Connect is being supported, the device creates a DPP URI and loads that into secure storage. d. The device sends the cer�ficate or DPP URI to the manufacturer’s database. One disadvantage of this method is that the device’s random number generator is being relied upon to generate the key pair, and it is possible that a device’s random number generator will not be as robust as the random number generator that would be included in an NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

108

FINAL SE, for example. An advantage of this method is that the device’s private key is not vulnerable to disclosure, assuming the device is equipped with a strong random number generator that is used for key genera�on and the private key is put into secure storage immediately upon genera�on. 2. Method 2: Key Pair Generated in Secure Element Summary: Generate the private key in a secure element on the device; IDevID CA provides the device cer�ficate to the manufacturer’s database. The steps for Method 2 are: a. The public/private key pair is generated within the device’s SE. b. The device generates a CSR structure, the SE signs it, and the device sends the CSR to the manufacturer’s IDevID CA, which sends a signed cer�ficate (IDevID) back to the device. c. If BRSKI is being supported, the device loads the cer�ficate (IDevID) into its secure storage; if Wi-Fi Easy Connect is being supported, the device creates a DPP URI and loads that into secure storage. d. The IDevID CA provides the cer�ficate to the manufacturer’s database. The manufacturer stores either the cer�ficate (i.e., if BRSKI is being supported), or creates and stores a DPP URI (i.e., if Wi-Fi Easy Connect is being supported). Method 2 is similar to Method 1 except that in Method 2, the key pair is generated and stored in a secure element and the manufacturer’s database receives the signed cer�ficate directly from the CA (either via a push or a pull) rather than via the device. An advantage of Method 2 is that the device’s private key is not vulnerable to disclosure because secure elements are normally equipped with a strong random number generator and tamper-proof storage. 3. Method 3: Key Pair Loaded into IoT Device Summary: Generate the private key in the device factory and load it onto the device. The steps for Method 3 are: a. The public/private key pairs and cer�ficates are generated in advance at the device factory and recorded in the manufacturer’s database. b. The public/private key pair and cer�ficate are loaded onto the device at the device factory. One advantage of this method is that there is no need to trust the random number generator on the device to generate strong public/private key pairs. However, the private keys may be vulnerable to disclosure during the period of �me before they are provisioned into secure storage on the devices (and a�erwards if they are not deleted once they have been copied into secure storage).

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

109

FINAL 4. Method 4: Key Pair Pre-Provisioned onto Secure Element Summary: Generate the private key in the SE and load the cer�ficate on the device at the SE factory (SEF). The steps for Method 4 are: a. The public/private key pair and cer�ficate are generated in advance in the SE at the SEF and the public key is recorded. b. The cer�ficate is loaded onto the devices at the SEF. c. The cer�ficates and the serial numbers of their corresponding devices are provided to the device manufacturer, and the device manufacturer can put them into the manufacturer’s database. d. The CA that signs the cer�ficates that are generated and loaded onto the SEs may come from either the SEF or the device manufacturer. (Note: the CA is likely not located at the factory, which may be offshore.) Addi�onal trust anchors can also be loaded into the SE at the SEF (e.g., code signing keys, server public keys for TLS connec�ons, etc.) As with Methods 2 and 3, one advantage of this method (Method 4) is that there is no need to trust the random number generator on the device to generate strong public/private key pairs because the random number generator on the SE is used instead. With this method, the security level of the manufacturer’s factory does not need to be as high as that of the SEF because all key genera�on and cer�ficate signing is performed at the SEF; the manufacturer can rely on the security of the SEF, which can be advantageous to the device manufacturer, assuming that the SEF is in fact secure. 5. Method 5: Private Key Derived from Shared Seed Summary: The device’s private key is derived from a shared seed. The steps for Method 5 are: a. The chip vendor embeds a random number into each IoT device (e.g., this may be burned into fuses on the IoT device, inside the Trusted Execu�on Environment (TEE)). b. The IoT device manufacturer gets a copy of this seed securely (e.g., on a USB device transported via trusted courier). c. On first boot, the IoT device generates a private key from this seed. d. The manufacturer uses the same seed to generate a public key and signs a cer�ficate. As with Method 4, with this op�on (Method 5), there is no need for the IoT device manufacturer to have a secure factory because the IoT device manufacturer may rely on the security of the chip manufacturer. However, the IoT device manufacturer must also rely on the security of

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

110

FINAL the courier or other mechanism that is delivering the seed, and the IoT device manufacturer must ensure that the value of this seed is not disclosed.

H.2 Factory Provisioning Builds – General Provisioning Process The Factory Provisioning Builds implemented as part of this project simulate ac�vi�es performed during the IoT device manufacturing process to securely provision the device’s birth creden�als (i.e., its private key) into secure storage on the device and make the device’s networklayer bootstrapping informa�on available by enrolling the device’s public key into a database that will make this public key accessible to the device owner in a form such as a cer�ficate or DPP URI. The method used in the factory provisioning builds most closely resembles Method 2: Key Pair Generated on IoT Device, as described in Sec�on H.1.1. There are several different poten�al versions of the factory provisioning build architecture depending on whether the creden�als being generated are designed to support BRSKI, Wi-Fi Easy Connect, Thread, or some other trusted network-layer onboarding protocol. For example, when BRSKI is being supported, the device bootstrapping informa�on that is created takes the form of an 802.1AR cer�ficate (IDevID); if DPP is supported, it takes the form of a DPP URI. Because this project does not have access to a real factory or the tools necessary to provision birth creden�als directly into device firmware, the factory builds simulate the firmware loading process by loading factory provisioning code into the IoT device (e.g., a Raspberry Pi device). This code plays the role of the factory in the builds by instruc�ng the SE that is atached to the IoT device to generate the device’s private key and bootstrapping informa�on. Once the IoT device has been provisioned with its birth creden�als in this manner, it can, in theory, be networklayer onboarded to one of the project build networks.

H.3 BRSKI Factory Provisioning Builds (NquiringMinds and SEALSQ) Two variants of the BRSKI Factory Provisioning Build were implemented: 

NquiringMinds and SEALSQ implementa�on (first version): SEALSQ, a subsidiary of WISeKey, and NquiringMinds collaborated to implement one version of the BRSKI Factory Provisioning Build. This build is designed to provision birth creden�als to a Raspberry Pi device that has an atached secure element provided by SEALSQ.



NquiringMinds and Infineon implementa�on (second version): NquiringMinds implemented a second version of the BRSKI Factory Provisioning Build using an Infineon SE. This build is designed to provision birth creden�als to a Raspberry Pi device that has an atached Infineon Op�ga SLB 9670 TPM 2.0.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

111

FINAL

H.3.1 BRSKI Factory Provisioning Build Technologies The general infrastructure for the first version of the BRSKI Factory Provisioning Build (i.e., the NquiringMinds and SEALSQ implementa�on) is provided by SEALSQ. The first version of the BRSKI Factory Provisioning Build infrastructure consists of: 

A SEALSQ VaultIC SE that is atached to the Raspberry Pi;



SEALSQ Factory Provisioning Code that is located on an SD card and that communicates with the chip in the SE to



•

create a P-256 Ellip�c Curve public/private key pair within the SE,

•

construct a cer�ficate signing request, and

•

store the cer�ficate in the SE as well as send it to the manufacturer’s database;

SEALSQ INeS CMS CA, a cer�ficate authority for signing the device’s birth cer�ficate.

As men�oned earlier, separate factory provisioning builds are required for each network-layer onboarding protocol being supported. A small amount of factory provisioning code is required to be customized for each build, depending on the onboarding protocol that is supported and how the bootstrapping informa�on will be provided to the manufacturer. In this build, NquiringMinds provided this code and made it available to the Raspberry Pi IoT device by placing it on an SD card. (This could be either in a par��on of the SD card that holds the device’s BRSKI onboarding so�ware or on a separate SD card altogether). Table H-1 lists the technologies used in the first version of the BRSKI Factory Provisioning Build. It lists the products used to instan�ate each logical build component and the security func�on that the component provides. The components listed are logical. They may be combined in physical form, e.g., a single piece of hardware may both generate key pairs and provide secure storage. Table H-1 First Version of the BRSKI Factory Provisioning Build Products and Technologies Component

Product

Function

Key Pair Generation Component

SEALSQ VaultIC and associated provisioning code

Generates and installs the public/private key pair into secure storage. The VaultIC has a SP800-90B certified random number generator for key pair generation. [20][21][22] Signs the certificate signing request that is sent to the CA.

Secure Storage

SEALSQ VaultIC

Storage on the IoT device that is designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to generate, store, and process private keys, credentials, and other information that must be kept confidential.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

112

FINAL Component

Product

Function

General Factory Provisioning Instructions

SEALSQ Factory Provisioning Code

Creates a CSR associated with the key pair, installs the signed certificate into secure storage. Creates a record of devices that it has created and their certificates.

Build-specific Factory Provisioning Instructions

NquiringMinds Factory Provisioning Code

Sends device ownership information and the certificate received by the General Factory Provisioning code to the MASA.

Manufacturer Database

MASA

When devices are manufactured, device identity and bootstrapping information is stored here by the manufacturer. Eventually, this database makes the device’s bootstrapping information available to the device owner. Device bootstrapping information is information that the device owner requires to perform trusted network-layer onboarding; for BRSKI, the bootstrapping information is a signed certificate that is sent to the MASA, along with information regarding the device’s owner.

Certificate Authority (CA)

SEALSQ INeS CMS CA

Issues and signs certificates as needed.

The second version of the BRSKI Factory Provisioning Build (i.e., the NquiringMinds implementa�on with an Infineon SE) infrastructure consists of: 

An Infineon Op�ga SLB 9670 TPM 2.0 atached to the Raspberry Pi



Factory Provisioning Code writen by NquiringMinds that is located on an SD card and that communicates with the chip in SE to



•

create a P-256 Ellip�c Curve public/private key pair within the SE,

•

construct a cer�ficate signing request, and

•

store the cer�ficate in the SE as well as send it to the manufacturer’s database

NquiringMinds Manufacturer Provisioning Root (MPR) server, which signs the device’s IDevID birth cer�ficate. It sits in the cloud and is securely contacted using the keys in the Infineon Op�ga secure element.

In this build, NquiringMinds provided all of the factory provisioning code and made it available to the Raspberry Pi IoT device by placing it on an SD card. (This could be either in a par��on of the SD card that holds the device’s BRSKI onboarding so�ware or on a separate SD card altogether). Table H-2 lists the technologies used in the second version of the BRSKI Factory Provisioning Build. It lists the products used to instan�ate each logical build component and the security

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

113

FINAL func�on that the component provides. The components listed are logical. They may be combined in physical form, e.g., a single piece of hardware may both generate key pairs and provide secure storage. Table H-2 Second Version of the BRSKI Factory Provisioning Build Products and Technologies Component

Product

Function

Key Pair Generation Component

Infineon TPM and associated provisioning code

Generates and installs the public/private key pair into secure storage. Signs the certificate signing request that is sent to the CA.

Secure Storage

Infineon TPM

Storage on the IoT device that is designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to generate, store, and process private keys, credentials, and other information that must be kept confidential.

General Factory Provisioning Instructions

Infineon TPM-specific Factory Provisioning Code

Creates a CSR associated with the key pair, installs the signed certificate into secure storage. Creates a record of devices that it has created and their certificates.

Build-specific Factory Provisioning Instructions

Build-specific Factory Provisioning Code

Sends device ownership information and the signed certificate to the MASA.

Manufacturer Database

MASA

When devices are manufactured, device identity and bootstrapping information is stored here by the manufacturer. Eventually, this database makes the device’s bootstrapping information available to the device owner. Device bootstrapping information is information that the device owner requires to perform trusted network-layer onboarding; for BRSKI, the bootstrapping information is a signed certificate that is sent to the MASA, along with information regarding the device’s owner.

Certificate Authority (CA)

SEALSQ INeS CMS CA NquiringMinds Onpremises CA

Issues and signs certificates as needed.

H.3.2 BRSKI Factory Provisioning Build Logical Architectures Figure H-1 depicts the logical architecture of the first version of the BRSKI factory provisioning build (i.e., the NquiringMinds and SEALSQ implementa�on) and is annotated with the steps that are performed in this build to prepare IoT devices for network-layer onboarding using the BRSKI protocol. Figure H-1 shows a Raspberry Pi device with a SEALSQ VaultIC SE atached. An SD card that contains factory provisioning code provided by SEALSQ and NquiringMinds is also required.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

114

FINAL The SEALSQ so�ware will boot up and perform the following steps to simulate the ac�vi�es of a factory: 1. Instruct the SE to generate and store a private/public key pair. 2. Create a certificate signing request for this key pair and have the SE sign it. 3. Send the signed CSR to the IDevID CA (i.e., to the INeS CA that is operated by SEALSQ). 4. Receive back the signed certificate from the CA. 5. Load the certificate into the SE. 6. Send the certificate (along with device ownership information) to the manufacturer’s database, which in this case is the MASA that is trusted by the owner.

This completes the steps performed as part of the first version of the BRSKI Factory Provisioning Build. Once complete, shipment of the device to its owner can be simulated by walking the device across the room in the NCCoE laboratory to the Build 5 (NquiringMinds) implementa�on and replacing the SD card that has the factory provisioning code on it with an SD card that has the BRSKI onboarding code on it. (Alterna�vely, if the factory provisioning code and the BRSKI onboarding code are stored in separate par��ons of the same SD card, shipment of the device to its owner can be simulated by boo�ng up the code in the onboarding par��on.) Build 5 is designed to execute this BRSKI onboarding so�ware, which onboards the device to the device owner’s network by provisioning the device with an LDevID that will serve as its networklayer creden�al. Such successful network-layer onboarding of the newly provisioned device using the BRSKI protocol by Build 5 would serve to confirm that the first version of the BRSKI factory provisioning process successfully provisioned the device with its birth creden�als. At the �me of this wri�ng, however, this confirma�on process was not able to be performed. In order to securely network-layer onboard the newly provisioned Raspberry Pi using the BRSKI protocol, the Raspberry Pi’s onboarding so�ware would need to be writen to use the private key stored in the SEALSQ secure element when running the BRSKI protocol. Such so�ware was not yet available at the �me of this publica�on. The BRSKI onboarding code on the Raspberry Pi does not currently use the private key stored in the SEALSQ SE. As a result, Build 5 was not able to onboard this factory Pi as a way of confirming that the first version of the BRSKI factory build process completed successfully. The repository that hosts the code for this implementa�on can be found here at the trustnetz-se GitHub repository.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

115

FINAL

SEALSQ INeS CA

MASA

The Provisioning Code performs the following steps: IoT Device 1. Instruct the SE to generate and store a public/private (Raspberry Pi) key pair 2. Create a CSR and have the SE sign it WISeKey VaultIC Secure Element (SE) 3. Send the signed CSR to the CA SD Card Key Pair Secure Generation Storage Provisioning 4. Receive certificate Component Code from the CA 5. Load the certificate into the SE 6. Send the certificate and ownership information to the manufacturer’s database (i.e., the MASA)

Operations performed in the SE: • Generate private/public key pair • Sign the certificate signing request (CSR) • Receive and store the signed certificate

Figure H-1 Logical Architecture of the First Version of the BRSKI Factory Provisioning Build Figure H-2 depicts the logical architecture of the second version of the BRSKI factory provisioning build and is annotated with the steps that are performed in this build to prepare IoT devices for network-layer onboarding using the BRSKI protocol. Figure H-2 shows a Raspberry Pi device with an Infineon Op�ga SLB 9670 TPM 2.0 SE atached. An SD card that contains factory provisioning code provided by NquiringMinds is also required. The factory provisioning code so�ware will boot up and perform the following steps to simulate the ac�vi�es of a factory: 1. Instruct the Infineon SE to generate and store a private/public key pair. 2. Create a certificate signing request for this key pair and have the SE sign it. 3. Send the signed CSR to the IDevID CA (i.e., to the NquiringMinds on-premises CA/Manufacturer Provisioning Root). 4. Receive back the signed certificate from the CA. 5. Load the certificate into the SE. 6. Send the certificate (along with device ownership information) to the manufacturer’s database, which in this case is the MASA that is trusted by the owner.

This completes the steps performed as part of the second version of the BRSKI Factory Provisioning Build. Once complete, shipment of the device to its owner can be simulated by walking the device across the room in the NCCoE laboratory to the Build 5 (NquiringMinds) implementa�on and replacing the SD card that has the factory provisioning code on it with an SD card that has the BRSKI onboarding code on it. (Alterna�vely, if the factory provisioning code and the BRSKI onboarding code are stored in separate par��ons of the same SD card, shipment of the NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

116

FINAL device to its owner can be simulated by boo�ng up the code in the onboarding par��on.) Build 5 executes a modifica�on of the BRSKI onboarding so�ware that has been modified to use the IDevID resident on the Infineon TPM throughout the protocol flow, ensuring the device’s IDevID’s private key is never made public and never leaves the secure element. Specifically, the cri�cal signing opera�ons and the TLS nego�a�on steps are fully secured by the SE. The full BRSKI onboarding flow provisions a new LDevID onto the device. This LDevID provides a secure method for the device to connect to the domain owner’s network. This successful network-layer onboarding of the IoT device by Build 5 serves as confirma�on that the second version of the BRSKI factory provisioning process successfully provisioned the device with its birth creden�als.

Nquiring Minds OnPremises CA

MASA

The Provisioning Code performs the following steps: IoT Device 1. Instruct the SE to generate and store a public/private (Raspberry Pi) key pair 2. Create a CSR and have the SE sign it Infineon Optiga SLB 9670 TPM 2.0 (SE) 3. Send the signed CSR to the CA SD Card Key Pair Secure Generation Storage Provisioning 4. Receive certificate Component Code from the CA 5. Load the certificate into the SE 6. Send the certificate and ownership information to the manufacturer’s database (i.e., the MASA)

Operations performed in the SE: • Generate private/public key pair • Sign the certificate signing request (CSR) • Receive and store the signed certificate

Figure H-2 Logical Architecture of the Second Version of the BRSKI Factory Provisioning Build

H.3.3 BRSKI Factory Provisioning Build Physical Architectures Sec�on 5.6.1 describes the physical architecture of the BRSKI Factory Provisioning Builds.

H.4 Wi-Fi Easy Connect Factory Provisioning Build (SEALSQ and Aruba/HPE) SEALSQ, a subsidiary of WISeKey, and Aruba/HPE implemented a Wi-Fi Easy Connect Factory Provisioning Build. This build is designed to provision birth creden�als to a Raspberry Pi device that has an atached secure element provided by SEALSQ.

H.4.1 Wi-Fi Easy Connect Factory Provisioning Build Technologies The general infrastructure for the Wi-Fi Easy Connect Factory Provisioning Build is provided by SEALSQ. The Wi-Fi Easy Connect Factory Provisioning Build infrastructure consists of: NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

117

FINAL 

A SEALSQ VaultIC SE that is atached to the Raspberry Pi



SEALSQ Factory Provisioning Code that is located on an SD card and that communicates with the chip in the SE to: •

create a P-256 Ellip�c Curve public/private key pair within the SE,

•

use the public key to construct a DPP URI, and

•

export the DPP URI and convert it into a QR code.

Table H-3 lists the technologies used in the Wi-Fi Easy Connect Factory Provisioning Build. It lists the products used to instan�ate each logical build component and the security func�on that the component provides. The components listed are logical. They may be combined in physical form, e.g., a single piece of hardware may both generate key pairs and provide secure storage. Table H-3 Wi-Fi Easy Connect Factory Provisioning Build Products and Technologies Component

Product

Function

Key Pair Generation Component

SEALSQ VaultIC and associated provisioning code

Generates and installs the public/private key pair into secure storage. The VaultIC has a SP800-90B certified random number generator for key pair generation. [22]

Secure Storage

SEALSQ VaultIC

Storage on the IoT device that is designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to generate, store, and process private keys, credentials, and other information that must be kept confidential.

General Factory Provisioning Instructions

SEALSQ Factory Provisioning Code

Creates a public/private key pair.

Build-specific Factory Provisioning Instructions

Aruba/HPE Factory Provisioning Code

Uses the public key to create a DPP URI. Exports the DPP URI and converts it into a QR code.

Manufacturer Database

Manufacturer cloud or imprint on device

The DPP URI information is stored in the QR code and is the mechanism for conveying the device’s bootstrapping information to the device owner.

H.4.2 Wi-Fi Easy Connect Factory Provisioning Build Logical Architecture Figure H-3 depicts the logical architecture of the Wi-Fi Easy Connect factory provisioning build and is annotated with the steps that are performed in this build to prepare Raspberry Pi IoT devices for network-layer onboarding using the Wi-Fi Easy Connect protocol. Figure H-3 shows a Raspberry Pi device with a SEALSQ VaultIC SE atached. Factory provisioning code provided by SEALSQ and Aruba/HPE must also be loaded. In Figure H-3, this code is shown as being on an SD card. The factory provisioning so�ware will boot up and perform the following steps to simulate the ac�vi�es of a factory:

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

118

FINAL 1. Instruct the SE to generate and store a private/public key pair. 2. Use the public key to create a DPP URI. 3. Export the DPP URI and convert it into a QR code.

This completes the steps performed as part of the Wi-Fi Easy Connect Factory Provisioning Build. Once complete, shipment of the device to its owner can be simulated by walking the device across the room in the NCCoE laboratory to the Build 1 (Aruba/HPE) implementa�on. Build 1 uses the Wi-Fi Easy Connect protocol to network-layer onboard the device to the device owner’s network by provisioning the device with a connector that will serve as its network-layer creden�al. Successful network-layer onboarding of the newly provisioned device using the Wi-Fi Easy Connect protocol by Build 1 would serve to confirm that the Wi-Fi Easy Connect factory provisioning process correctly provisioned the device with its birth creden�als. At the �me of this wri�ng, however, this confirma�on process was not able to be performed. In order to securely network-layer onboard the newly provisioned Raspberry Pi using the Wi-Fi Easy Connect protocol, the Raspberry Pi would need to be equipped with a firmware image that uses the private key stored in the secure element when running the Wi-Fi Easy Connect protocol. Such firmware was not yet available at the �me of this publica�on. The Wi-Fi Easy Connect code on the Raspberry Pi does not use the private key stored in the SE at this �me. Confirma�on that the factory build process completed successfully is limited to inspec�on of the .PNG file and .URI file that were created to display the QR Code and the device’s DPP URI, respec�vely.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

119

FINAL The Provisioning Code performs the following steps: 1. Instruct the SE to generate and store a public/private key pair 2. Use the public key to create a DPP URI

IoT Device (Raspberry Pi) WISeKey VaultIC Secure Element (SE)

3. Export the DPP URI and convert it to a QR code QR Code

DPP URI

SD Card Provisioning Code

Key Pair Generation Component

Secure Storage

Operations performed in the SE: • Generate private/public key pair • Create the DPP URI

Figure H-3 Logical Architecture of the Wi-Fi Easy Connect Factory Provisioning Build

H.4.3 Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture Sec�on 5.2.1 describes the physical architecture of the Factory Provisioning Build.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

120

NIST SPECIAL PUBLICATION 1800-36C

Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management:

Enhancing Internet Protocol-Based IoT Device and Network Security Volume C: How-To Guides Murugiah Souppaya* Paul Watrobski* National Institute of Standards and Technology Gaithersburg, Maryland Chelsea Deane Joshua Klosterman Blaine Mulugeta Charlie Rearick Susan Symington The MITRE Corporation McLean, Virginia Dan Harkins Danny Jump Aruba, a Hewlett Packard Enterprise Company San Jose, California

November 2025 FINAL This publication is available free of charge from https://doi.org/10.6028/NIST.SP.1800-36

Andy Dolan Kyle Haefner Craig Pratt Darshak Thakore CableLabs Louisville, Colorado Nick Allot Ashley Setter NquiringMinds Southampton, United Kingdom

Retired NIST Author*

*Former NIST employee; all work for this publication was done while at NIST.

FINAL

DISCLAIMER Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose. While NIST and the NCCoE address goals of improving management of cybersecurity and privacy risk through outreach and application of standards and best practices, it is the stakeholder’s responsibility to fully perform a risk assessment to include the current threat, vulnerabilities, likelihood of a compromise, and the impact should the threat be realized before adopting cybersecurity measures such as this recommendation.

National Institute of Standards and Technology Special Publication 1800-36C, Natl. Inst. Stand. Technol. Spec. Publ. 1800-36C, 57 pages, November 2025, CODEN: NSPUE2

FEEDBACK As a private-public partnership, we are always seeking feedback on our practice guides. We are particularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us at iot-onboarding@nist.gov. All comments are subject to release under the Freedom of Information Act.

National Cybersecurity Center of Excellence National Institute of Standards and Technology 100 Bureau Drive Mailstop 2002 Gaithersburg, MD 20899 Email: nccoe@nist.gov

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

ii

FINAL

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the creation of practical cybersecurity solutions for specific industries, as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners—from Fortune 50 market leaders to smaller companies specializing in information technology security—the NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the steps needed for another entity to re-create the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland. To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align with relevant standards and best practices, and provide users with the materials lists, configuration files, and other information they need to implement a similar approach. The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.

KEYWORDS application-layer onboarding; bootstrapping; Internet of Things (IoT); Manufacturer Usage Description (MUD); network-layer onboarding; onboarding; Wi-Fi Easy Connect.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iii

FINAL

ACKNOWLEDGMENTS We are grateful to the following individuals for their generous contributions of expertise and time. Name

Organization

Amogh Guruprasad Deshmukh

Aruba, a Hewlett Packard Enterprise company

Bart Brinkman

Cisco

Eliot Lear

Cisco

Peter Romness

Cisco

Tyler Baker

Foundries.io

George Grey

Foundries.io

David Griego

Foundries.io

Fabien Gremaud

Kudelski IoT

Brecht Wyseur

Kudelski IoT

Faith Ryan

The MITRE Corporation

Toby Ealden

NquiringMinds

John Manslow

NquiringMinds

Antony McCaigue

NquiringMinds

Alexandru Mereacre

NquiringMinds

Loic Cavaille

NXP Semiconductors

Mihai Chelalau

NXP Semiconductors

Julien Delplancke

NXP Semiconductors

Anda-Alexandra Dorneanu

NXP Semiconductors

Todd Nuzum

NXP Semiconductors

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iv

FINAL

Name

Organization

Nicusor Penisoara

NXP Semiconductors

Laurentiu Tudor

NXP Semiconductors

Michael Richardson

Sandelman Software Works

Karen Scarfone

Scarfone Cybersecurity

Steve Clark

SEALSQ, a subsidiary of WISeKey

Pedro Fuentes

SEALSQ, a subsidiary of WISeKey

Gweltas Radenac

SEALSQ, a subsidiary of WISeKey

Kalvin Yang

SEALSQ, a subsidiary of WISeKey

Mike Dow

Silicon Labs

Steve Egerter

Silicon Labs

Heather Flanagan

Spherical Cow Consulting

The Technology Partners/Collaborators who participated in this build submitted their capabilities in response to a notice in the Federal Register. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build this example solution. We worked with: Technology Collaborators Aruba, a Hewlett Packard Enterprise company CableLabs Cisco

Foundries.io Kudelski IoT NquiringMinds NXP Semiconductors

Open Connectivity Foundation (OCF) Sandelman Software Works SEALSQ, a subsidiary of WISeKey Silicon Labs

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

v

FINAL

DOCUMENT CONVENTIONS The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the publication and from which no deviation is permitted. The terms “should” and “should not” indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. The terms “may” and “need not” indicate a course of action permissible within the limits of the publication. The terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

PATENT DISCLOSURE NOTICE NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication. As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL. No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vi

FINAL

Contents

1.2.1

Reference Architecture Summary ................................................................................3

1.2.2

Physical Architecture Summary ....................................................................................3

2.2.1

Wi-Fi Network Setup and Configuration .......................................................................9

2.2.2

Wi-Fi Easy Connect Configuration ............................................................................. 10

2.3.1

Configuration ............................................................................................................. 10

2.4.1

Configuration ............................................................................................................. 11

2.5.1

Configuration ............................................................................................................. 11

2.5.2

DPP Onboarding ......................................................................................................... 12

2.6.1

Private Certificate Authority ...................................................................................... 14

2.6.2

SEALSQ INeS ............................................................................................................... 18

2.8.1

SEALSQ VaultIC Secure Element ................................................................................ 19

3.1.1

Operation and Demonstration................................................................................... 21

3.2.1

Installation and Configuration ................................................................................... 21

3.2.2

Integration with CableLabs Platform Controller ........................................................ 21

3.2.3

Operation and Demonstration................................................................................... 22

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vii

FINAL

3.3.1

Installation and Configuration ................................................................................... 22

3.3.2

Operation and Demonstration................................................................................... 22

4.1.1

Setup and Configuration ............................................................................................ 23

4.2.1

Setup and Configuration ............................................................................................ 23

4.3.1

Setup and Configuration ............................................................................................ 24

4.5.1

Setup and Configuration ............................................................................................ 25

5.1.1

Installation and Configuration ................................................................................... 26

5.1.2

Operation and Demonstration................................................................................... 26

5.2.1

Setup and Configuration ............................................................................................ 27

5.3.1

Setup and Configuration ............................................................................................ 30

5.4.1

Setup and Configuration ............................................................................................ 32

5.4.2

Testing ........................................................................................................................ 37

6.1.1

Installation and Configuration ................................................................................... 39

6.1.2

Operation and Demonstration................................................................................... 39

6.2.1

Installation and Configuration ................................................................................... 40

6.2.2

Logical services........................................................................................................... 40

6.3.1

Prerequisites .............................................................................................................. 44

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

viii

FINAL 6.3.2

Onboarding Demonstration ....................................................................................... 45

6.3.3

Continuous Assurance Demonstration ...................................................................... 45

6.4.1

Pledge ........................................................................................................................ 45

6.4.2

Installation and Configuration ................................................................................... 45

6.4.3

Operation and Demonstration................................................................................... 45

List of Figures Figure 1-1 NCCoE IoT Onboarding Laboratory Physical Architecture ..................................................... 5 Figure 6-1 Logical Services for Build 5 ................................................................................................. 41 Figure 6-2 Diagram of Physical/Logical Components Used to Demonstrate BRSKI Flow ...................... 44

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

ix

FINAL

1 Introduction Volumes C, D, and E show information technology (IT) professionals and security engineers how we implemented these example solutions. We cover all of the products employed in this reference design. We do not re-create the product manufacturers’ documentation, which is presumed to be widely available. Instead, these three volumes show how we incorporated the products together in our environment. Note: These are not comprehensive tutorials. There are many possible service and security configurations for these products that are out of scope for this reference design.

1.1 How to Use This Guide This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design for implementing trusted IoT device network-layer onboarding and lifecycle management. It describes various example implementations of this reference design. Each of these implementations, which are known as builds, is standards-based and is designed to help provide assurance that networks are not put at risk as new IoT devices are added to them and to help safeguard IoT devices from connecting to unauthorized networks. The reference design described in this practice guide is modular and can be deployed in whole or in part, enabling organizations to incorporate trusted IoT device network-layer onboarding and lifecycle management into their legacy environments according to goals that they have prioritized based on risk, cost, and resources. This guide contains five volumes: 

NIST Special Publication (SP) 1800-36A: Executive Summary – why we wrote this guide, the challenge we address, why it could be important to your organization, and our approach to solving this challenge



NIST SP 1800-36B: Approach, Architecture, and Security Characteristics – what we built and why



NIST SP 1800-36C: How-To Guides – instructions for building the example implementations, including all the security-relevant details that would allow you to replicate all or parts of this project (you are here)



NIST SP 1800-36D: Functional Demonstrations – use cases that have been defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabilities, and the results of demonstrating these use cases with each of the example implementations



NIST SP 1800-36E: Risk and Compliance Management – risk analysis and mapping of trusted IoT device network-layer onboarding and lifecycle management security characteristics to cybersecurity standards and recommended practices

Depending on your role in your organization, you might use this guide in different ways: Business decision makers, including chief information security, product security, and technology officers, will be interested in the Executive Summary, NIST SP 1800-36A, which describes the following topics: 

challenges that enterprises face in migrating to the use of trusted IoT device network-layer onboarding

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

1

FINAL 

example solutions built at the NCCoE



benefits of adopting the example solution

Technology, security, and privacy program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in NIST SP 1800-36B, which describes what we did and why. Also, Section 4 of NIST SP 1800-36E will be of particular interest. Section 4, Mappings, maps logical components of the general trusted IoT device network-layer onboarding and lifecycle management reference design to security characteristics listed in various cybersecurity standards and recommended practices documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity Framework) and Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53). You might share the Executive Summary, NIST SP 1800-36A, with your leadership team members to help them understand the importance of using standards-based trusted IoT device network-layer onboarding and lifecycle management implementations. IT professionals who want to implement similar solutions will find the whole practice guide useful. You can use the how-to portion of the guide, NIST SP 1800-36C, to replicate all or parts of the builds created in our lab. The how-to portion of the guide provides specific product installation, configuration, and integration instructions for implementing the example solution. We do not re-create the product manufacturers’ documentation, which is generally widely available. Rather, we show how we incorporated the products together in our environment to create an example solution. Also, you can use Functional Demonstrations, NIST SP 1800-36D, which provides the use cases defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabilities and the results of demonstrating these use cases with each of the example implementations. Finally, NIST SP 1800-36E will help explain the security functionality that the components of each build provide. This guide assumes that IT professionals have experience implementing security products within the enterprise. While we have used a suite of commercial products to address this challenge, this guide does not endorse these particular products. Your organization can adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a trusted IoT device network-layer onboarding and lifecycle management solution. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. We hope you will seek products that are congruent with applicable standards and recommended practices. A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. We seek feedback on the publication’s contents and value your input. Comments, suggestions, and success stories are welcome. Please contribute your thoughts to iot-onboarding@nist.gov.

1.2 Build Overview This NIST Cybersecurity Practice Guide addresses the challenge of network-layer onboarding using standards-based protocols to perform trusted network-layer onboarding of an IoT device. Each build demonstrates one or more of these capabilities:

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

2

FINAL 

Trusted Network-Layer Onboarding: providing the device with its unique network credentials over an encrypted channel



Network Re-Onboarding: performing trusted network-layer onboarding of the device again after a device reset



Network Segmentation: assigning a device to a particular local network segment to prevent it from communicating with other network components, as determined by enterprise policy



Trusted Application-Layer Onboarding: providing the device with application-layer credentials over an encrypted channel after completing network-layer onboarding



Ongoing Device Authorization: continuously monitoring the device on an ongoing basis, providing policy-based assurance and authorization checks on the device throughout its lifecycle



Device Communications Intent Enforcement: Secure conveyance of device communications intent information, combined with enforcement of it, to ensure that IoT devices are constrained to sending and receiving only those communications that are explicitly required for each device to fulfill its purpose

Five builds, including the factory provisioning builds, have been implemented and demonstrated as part of this project. They serve as examples of how to onboard IoT devices using the protocols described in NIST SP 1800-36B. The remainder of this practice guide provides step-by-step instructions on how to reproduce all builds.

1.2.1 Reference Architecture Summary The builds described in this document are instantiations of the trusted network-layer onboarding and lifecycle management logical reference architecture described in NIST SP 1800-36B. This architecture is organized according to five high-level processes: Device Manufacture and Factory Provisioning, Device Ownership and Bootstrapping Information Transfer, Trusted Network-Layer Onboarding, Trusted Application-Layer Onboarding, and Continuous Verification. For a full explanation of the architecture, please see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics.

1.2.2 Physical Architecture Summary Figure 1-1 depicts the high-level physical architecture of the NCCoE IoT Onboarding laboratory environment in which the five trusted IoT device network-layer onboarding project builds and the two factory provisioning builds have been implemented. The NCCoE provides virtual machine (VM) resources and physical infrastructure for the IoT Onboarding lab. As depicted, the NCCoE IoT Onboarding laboratory hosts collaborator hardware and software for the builds. The NCCoE also provides connectivity from the IoT Onboarding lab to the NIST Data Center, which provides connectivity to the internet and public IP spaces (both IPv4 and IPv6). Access to and from the NCCoE network is protected by a firewall. Additionally, access to and from the IoT Onboarding lab is protected by a pfSense firewall, represented by the brick box icon in Figure 1-1. This firewall has both IPv4 and IPv6 (dual stack) configured. The IoT Onboarding lab network infrastructure includes a shared virtual environment that houses a domain controller and a vendor jumpbox. These components are used across builds where applicable. It also

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

3

FINAL contains five independent virtual local area networks (VLANs), each of which houses a different trusted network-layer onboarding build. The IoT Onboarding laboratory network has access to cloud components and services provided by the collaborators, all of which are available via the internet. These components and services include Aruba Central and the UXI Cloud (Build 1), SEALSQ INeS (Build 1), Platform Controller (Build 2), a Manufacturer Authorized Signing Authority (MASA) server (Build 3), Kudelski IoT keySTREAM application-layer onboarding service and Amazon Web Services (AWS) IoT (Build 4), and a Manufacturer Provisioning Root (Build 5).

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

FINAL

Figure 1-1 NCCoE IoT Onboarding Laboratory Physical Architecture

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

5

FINAL All five network-layer onboarding laboratory environments, as depicted in the diagram, have been installed: 

Build 1 (i.e., the Wi-Fi Easy Connect, Aruba/HPE build) network infrastructure within the NCCoE lab consists of two components: the Aruba Access Point and the Cisco Switch. Build 1 also requires support from Aruba Central for network-layer onboarding and the UXI Cloud for application-layer onboarding. These components are in the cloud and accessed via the internet. The IoT devices onboarded using Build 1 include the UXI Sensor and the Raspberry Pi.



Build 2 (i.e., the Wi-Fi Easy Connect, CableLabs, OCF build) network infrastructure within the NCCoE lab consists of a single component: the Gateway Access Point. Build 2 requires support from the Platform Controller, which also hosts the IoTivity Cloud Service. The IoT devices that are onboarded using Build 2 include three Raspberry Pis.



Build 3 (i.e., the BRSKI, Sandelman Software Works build) network infrastructure components within the NCCoE lab include a Wi-Fi capable home router (including Join Proxy), a DMZ switch (for management), and an ESP32A Xtensa board acting as a Wi-Fi IoT device, as well as an nRF52840 board acting as an IEEE 802.15.4 device. A management system on a BeagleBone Green serves as a serial console. A registrar server has been deployed as a virtual appliance on the NCCoE private cloud system. Build 3 also requires support from a MASA server that is accessed via the internet. In addition, a Raspberry Pi 3 provides an Ethernet/802.15.4 gateway, as well as a test platform.



Build 4 (i.e., the Thread, Silicon Labs, Kudelski IoT build) network infrastructure components within the NCCoE lab include an Open Thread Border Router (OBTR), which is implemented using a Raspberry Pi, and a Silicon Labs Gecko Wireless Starter Kit, which acts as an 802.15.4 antenna. Build 4 also requires support from the Kudelski IoT keySTREAM service, which is in the cloud and accessed via the internet. The IoT device onboarded in Build 4 is the Silicon Labs Dev Kit (BRD2601A) with an EFR32MG24 System-on-Chip (SoC). The application service to which it onboards is AWS IoT.



Build 5 (i.e., the BRSKI over Wi-Fi, NquiringMinds build) includes 2 Raspberry Pi 4Bs running a Linux operating system. One Raspberry Pi acts as the pledge (or IoT Device) with an Infineon Trusted Platform Module (TPM) connected. The other acts as the router, registrar, and MASA, all in one device. This build uses the open-source TrustNetZ distribution, from which the entire build can be replicated easily. The TrustNetZ distribution includes source code for the IoT device, the router, the access point, the network onboarding component, the policy engine, the manufacturer services, the registrar, and a demo application server. TrustNetZ makes use of NquiringMinds tdx Volt to issue and validate verifiable credentials.



The BRSKI factory provisioning build is deployed in the Build 5 environment. The IoT device in this build is a Raspberry Pi equipped with an Infineon Optiga SLB 9670 TPM 2.0, which gets provisioned with birth credentials (i.e., a public/private key pair and an Initial Device Identifier (IDevID)). The BRSKI factory provisioning build also uses an external certificate authority hosted on the premises of NquiringMinds to provide the device certificate signing service.



The Wi-Fi Easy Connect factory provisioning build is deployed in the Build 1 environment. Its IoT devices are Raspberry Pis equipped with a SEALSQ VaultIC Secure Element, which gets provisioned with a DPP uniform resource identifier (URI). The Secure Element can also be provisioned with an IDevID certificate signed by the SEALSQ INeS certification authority, which is

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

6

FINAL independent of the DPP URI. Code for performing the factory provisioning is stored on an SD card.

1.3 Typographic Conventions The following table presents typographic conventions used in this volume. Typeface/Symbol

Meaning

Example

Italics

file names and path names; references to documents that are not hyperlinks; new terms; and placeholders names of menus, options, command buttons, and fields command-line input, onscreen computer output, sample code examples, and status codes command-line user input contrasted with computer output link to other parts of the document, a web URL, or an email address

For language use and style guidance, see the NCCoE Style Guide.

Bold Monospace

Monospace Bold

blue text

Choose File > Edit. mkdir

service sshd start

All publications from NIST’s NCCoE are available at https://www.nccoe.nist.gov.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

7

FINAL

2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) This section of the practice guide contains detailed instructions for installing and configuring all the products used to build an instance of the example solution. For additional details on Build 1’s logical and physical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. The network-layer onboarding component of Build 1 utilizes Wi-Fi Easy Connect, also known as the Device Provisioning Protocol (DPP). The Wi-Fi Easy Connect standard is maintained by the Wi-Fi Alliance [1]. The term “DPP” is used when referring to the network-layer onboarding protocol, and “Wi-Fi Easy Connect” is used when referring to the overall implementation of the network onboarding process.

2.1 Aruba Central/Hewlett Packard Enterprise (HPE) Cloud This build utilized Aruba Central as a cloud management service that provided management and support for the Aruba Wireless Access Point (AP) and provided authorization and DPP onboarding capabilities for the wireless network. A cloud-based application programming interface (API) endpoint provided the ability to import the DPP Uniform Resource Identifiers (URIs) in the manner of a Supply Chain Integration Service. Due to this capability and Build 1’s support for Wi-Fi Easy Connect, Build 1’s infrastructure fully supported interoperable network-layer onboarding with Build 2’s Reference Clients (“IoT devices”) provided by CableLabs.

2.2 Aruba Wireless Access Point Use of DPP is implicitly dependent on the Aruba Central cloud service. Aruba Central provides a cloud Infrastructure-as-a-Service (IaaS) enabled architecture that includes initial support for DPP in Central 2.5.6/ArubaOS (AOS) 10.4.0. Central and AOS support multiple deployment formats: 1. Underlay deployment: In this mode, the APs function as access points only, bridging traffic locally without additional processing. 2. Overlay deployment: All data is securely tunneled to an on-prem gateway, where advanced services can route, inspect, and analyze it. After processing, the data is either bridged locally or routed to its next hop. 3. Mixed-mode deployment: This combines underlay and overlay approaches. A returned “role/label” determines how the data is processed and forwarded, offering flexibility in handling traffic. 4. At the time of this publication, a user can leverage any 3xx, 5xx, or 6xx-series APs to support a DPP deployment, with the view that all future series APs will implicitly include support. For an existing or new user, creating a Service Set Identifier (SSID) is a prerequisite. In the 2H of 2025, support will be added for the new range of AP7xx, which also adds support for WiFi7. Additionally, this release will include support for DPP in the 6GHz range and WPA3. Assuming an SSID exists or a new one is created based on the above security restrictions, the next step is to enable DPP (as detailed below in Section 2.2.1) so that the SSID can support multiple authentication and key management (AKM) processes on a Basic Service Set (BSS). If the chosen security type is DPP, only a single AKM will exist for that BSS.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

8

FINAL A standards-compliant 802.3at port is the easiest method for providing the AP with power. An external power supply can also be used. This document does not cover the specifics of radio frequency (RF) design and placement of APs. Guidance and assistance are available on the Aruba community site, https://community.arubanetworks.com, or the Aruba Support Portal, https://asp.arubanetworks.com. Additionally, we do not cover the onboarding and licensing of Aruba Central hardware. Documentation can be found here: https://www.arubanetworks.com/techdocs/ArubaDocPortal/content/docportal.htm.

2.2.1 Wi-Fi Network Setup and Configuration The following instructions detail the initial setup and configuration of the Wi-Fi network upon powering on and connecting the AP to an existing network. 1. Navigate to the Aruba Central cloud management interface. 2. On the sidebar, navigate under Global and choose the AP-Group you want to configure/modify. (This assumes you have already grouped your APs by location/functions.) 3. Under Devices, click Config in the top right side. 4. You will now be in the Access Points tab and WLANs tab. Do one of the following: a. If creating a new SSID, click on + Add SSID. After entering the Name (SSID) in Step 1 and configuring options as necessary in Step 2, when you get to Step 3 (Security), the slidebar defaults to the Personal Security Level; the alternative is the Enterprise Security Level. i. If you choose the Personal Security Level, under Key-Management, ensure you select either DPP or WPA2-Personal. If you choose WPA2-Personal, expand the Advanced Settings section and enable the toggle button for DPP so that the SSID can broadcast the AKM. Note that this option is not available if choosing DPP for Key-Management. ii. If you choose the Enterprise Security Level, only WPA2-Enterprise Key-Management currently supports DPP. Expand the Advanced Settings section and enable the toggle button for DPP so that the SSID can broadcast the AKM. b. If you plan to enable DPP on a previously created SSID: i. Ensure you are running version 10.4+ on your devices. You also need an SSID that is configured for WPA2-Personal or WPA2-Enterprise. ii. When ready, float your cursor over the previously created SSID name you wish to configure and click on the edit icon. iii. Edit the SSID, click on Security, expand the Advanced Settings section, and enable the toggle button for DPP. iv. Click Save Settings.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

9

FINAL For SSIDs that have been modified to add DPP AKM, it’s also necessary to enable DPP within the radio profile. 1. Under the Access Point Tab, click Radios. 2. Expect to see a default radio-profile. If a custom one has been created, you will need to review your configuration before proceeding. 3. Assuming a default radio-profile, click on the Edit icon, expand Show advanced settings, and scroll down to DPP Provisioning. You can selectively enable this for 2.4 GHz or 5.0 GHz. In the 2H of 2025, support will be added for the new range of AP7xx, which adds support for WiFi7. Additionally, this release will include support for DPP in the 6GHz range and WPA3.

2.2.2 Wi-Fi Easy Connect Configuration Configuration of the Access Point occurred through the Aruba Central cloud management interface. Standard configurations were used to stand up the Build 1 wireless network. The instructions for enabling DPP capabilities for the overall wireless network are listed below: 1. Navigate to the Aruba Central cloud management interface. 2. On the sidebar, navigate to Security > Authentication and Policy > Config. 3. In the Client Access Policy section, click Edit. 4. Under the Wi-Fi Easy Connect™ Service heading, ensure that the name of your wireless network is selected. 5. Click Save.

2.3 Cisco Catalyst 3850-S Switch This build utilized a Cisco Catalyst 3850-S switch minimally configured with two separate VLANs to allow for IoT device network segmentation and access control. The switch also provided Power-over-Ethernet support for the Aruba Wireless AP.

2.3.1 Configuration The switch was configured with two VLANs and a trunk port dedicated to the Aruba Wireless AP. You can find the relevant portions of the Cisco iOS configuration below: interface Vlan1 no ip address interface Vlan2 no ip address interface GigabitEthernet1/0/1 switchport mode trunk interface GigabitEthernet1/0/2

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

10

FINAL switchport mode access switchport access vlan 1 interface GigabitEthernet1/0/3 switchport mode access switchport access vlan 2

2.4 Aruba User Experience Insight (UXI) Sensor This build utilized an Aruba UXI Sensor as a Wi-Fi Easy Connect-capable IoT device. Models G6 and G6C support Wi-Fi Easy Connect, and all available G6 and G6C models support Wi-Fi Easy Connect within their software image. This sensor successfully utilized the network-layer onboarding mechanism provided by the wireless network and completed onboarding to the application-layer UXI cloud service. The device automatically initiates the network-layer onboarding process on boot.

2.4.1 Configuration All of Aruba’s available G6 and G6C UXI sensors support the ability to complete network-layer and application-layer onboarding. No specific configuration of the physical sensor is required. As part of the supply-chain process, the cryptographic public key for your sensor(s) will be available within the cloud tenant. Each device's public/private key pair is created as part of the manufacturing process. The public key effectively identifies the sensor to the network and is part of the Wi-Fi Easy Connect/DPP onboarding process. This allows unprovisioned devices straight from the factory to be onboarded and subsequently connect to the UXI sensor cloud to obtain their network-layer configuration. An administrator will have to define the ‘tasks’ the UXI sensor is going to perform, such as monitoring SSIDs, performing reachability tests to on-prem or cloud services, and making the results of these tests available within the UXI user/administrator portal.

2.5 Raspberry Pi In this build, the Raspberry Pi 3B+ acts as a DPP enrollee. In setting up the device for this build, a DPPcapable wireless adapter, the Alfa AWUS036NHA network dongle, was connected to enable the Pi to send and receive DPP frames. Once fully configured, the Pi can be onboarded with the Aruba AP.

2.5.1 Configuration The following steps were completed for the Raspberry Pi to complete DPP onboarding: 1. Set the Raspberry Pi's management IP to an IP address in the Build 1 network. To do this, add the following lines to the file dhcpcd.conf located at /etc/dhcpcd.conf. For this build, the IP address was set to 192.168.10.3.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

11

FINAL 2. Install Linux Libraries using the apt package manager. The following packages were installed: a. autotools-dev b. automake c. libcurl4-openssl-dev d. libnl-genl-3-dev e. libavahi-client-dev f.

libavahi-core-dev

g. aircrack-ng h. openssl-1.1.1q 3. Install the DPP utilities. These utilities were installed from the GitHub repository https://github.com/HewlettPackard/dpp using the following command: git clone https://github.com/HewlettPackard/dpp

2.5.2 DPP Onboarding This section describes the steps for using the Raspberry Pi as a DPP enrollee. The Pi uses a DPP utility to send out chirps to make its presence known to available DPP configurators. Once the Pi is discovered, the DPP configurator (Aruba Wireless AP) initiates the DPP authentication protocol. During this phase, DPP connectors are created to onboard the device to the network. As soon as the Pi is fully authenticated, it is fully enrolled and can begin normal network communication. 1. Navigate to the DPP utilities directory that was installed during setup: cd dpp/linux

2. From the DPP utilities directory, run the following command to initiate a DPP connection: sudo ./sss -I wlan1 -r -e sta -k respp256.pem -B respbkeys.txt -a -t -d 255

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

12

FINAL

3. Once the enrollee has found a DPP configurator, the DPP authentication protocol is initiated.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

13

FINAL

2.6 Certificate Authority The function of the certificate authority (CA) in this build is to issue network credentials for use in the network-layer onboarding process.

2.6.1 Private Certificate Authority A private CA was provided as a part of the DPP demonstration utilities in the HPE GitHub repository. For demonstration purposes, the Raspberry Pi is used as the configurator and the enrollee.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

14

FINAL

2.6.1.1 Installation and Configuration The following instructions detail the initial setup and configuration of the private CA using the DPP demonstration utilities and certificates located at https://github.com/HewlettPackard/dpp. 1. Navigate to the DPP utilities directory on the Raspberry Pi: ~dpp/linux cd dpp/linux/

2. The README in the GitHub repository (https://github.com/HewlettPackard/dpp/blob/master/README) references a text file called configakm, which contains information about the network policies for a configurator to provision on an enrollee. The format is: <akm> <EAP server> <ssid>. Current AKMs that are supported are DPP, dot1x, sae, and psk. For this build, DPP is used. For DPP, an Extensible Authentication Protocol (EAP) server is not used. 3. Configure the file configakm located in ~/dpp/linux/. This file instructs the configurator on how to deploy a DPP connector (network credential) from the configurator to the enrollee. As shown below, the configakm file is filled with the following fields: dpp unused Build1-IoTOnboarding.

4. The file csrattrs.conf contains attributes to construct an Abstract Syntax Notation One (ASN.1) string. This string allows the configurator to tell the enrollee how to generate a certificate signing request (CSR). The following fields were used for this demonstration: asn1 = SEQUENCE: seq_section [seq_section] field1 = OID:challengePassword field2 = SEQUENCE:ecattrs field3 = SEQUENCE:extnd field4 = OID:ecdsa-with-SHA256

[ecattrs] field1 = OID:id-ecPublicKey field2 = SET:curve

[curve] field1 = OID:prime256v1

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

15

FINAL [extnd] field1 = OID:extReq field2 = SET:extattrs

[extattrs] field1 = OID:serialNumber field2 = OID:favouriteDrink

2.6.1.2 Operation and Demonstration Once setup and configuration have been completed, the following steps can be used to demonstrate utilizing the private CA to issue credentials to a requesting device. 1. Open three terminals on the Raspberry Pi: one to start the certificate program, one to show the configurator’s point of view, and one to show the enrollee’s point of view. 2. The demonstration uses an OpenSSL certificate. To run the program from the first terminal, navigate to the following directory: ~/dpp/ecca/, and run the command: ./ecca

3. On the second terminal, start the configurator using the following command: sudo ./sss -I lo -r -c signp256.pem -k respp256.pem -B resppbkeys.txt -d 255

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

16

FINAL

As shown in the terminal where the ecca program is running, the configurator contacts the CA and asks for the certificate.

4. On the third terminal, start the enrollee using the following command: sudo ./sss -I lo -r -e sta -k initp256.pem -B initbkeys.txt -t -a -q -d 255

From the enrollee’s perspective, it will send chirps on different channels until it finds the configurator. Once found, it sends its certificate to the CA for signing. The snippet below is of the enrollee generating the CSR.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

17

FINAL

5. In the ecca terminal, the certificate from the enrollee is shown.

2.6.2 SEALSQ INeS The SEALSQ INeS Certificate Management System provides CA and certificate management capabilities for Build 1. Implementation of this system provides Build 1 with a trusted, public CA to support issuing network credentials.

2.6.2.1 Setup and Configuration To support this build, a custom software agent was deployed on a Raspberry Pi in the Build 1 network. This agent interacted with the cloud-based CA in SEALSQ INeS via API to sign network credentials. Network-level onboarding of IoT devices was completed via DPP, with network credentials being successfully requested from and issued by SEALSQ INeS.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

18

FINAL Additional information on interacting with the SEALSQ INeS API can be found at https://inesdev.certifyiddemo.com/. Access can be requested directly from SEALSQ via their contact form: https://www.sealsq.com/contact.

2.7 UXI Cloud The UXI Cloud is a web-based application that serves as a monitoring hub for the UXI sensor. It provides visibility into the data captured by the sensor's performance monitoring. For the purposes of this build, the dashboard was used to demonstrate application-layer onboarding, which occurs once the UXI sensor has completed network-layer onboarding. Once the application-layer onboarding was completed and the application configuration was applied to the device, our demonstration concluded.

2.8 Wi-Fi Easy Connect Factory Provisioning Build This Factory Provisioning Build included many of the components listed above, including Aruba Central, SEALSQ INeS, the Aruba Access Point, and Raspberry Pi IoT devices. A SEALSQ VaultIC Secure Element was also included in the build and provided secure generation and storage of the key material and certificates provisioned to the device.

2.8.1 SEALSQ VaultIC Secure Element The SEALSQ VaultIC Secure Element was connected to a Raspberry Pi via the built-in GPIO pins present on the Pi. SEALSQ provided demonstration code that generates a public/private key pair within the secure element, creates a Certificate Signing Request, and uses that CSR to obtain an IDevID certificate from SEALSQ INeS. This code supports the Raspberry Pi OS Bullseye. The demonstration code can be found in the official GitHub repository. HPE also provided a custom DPP-based implementation of the SEALSQ code, which generates supporting material within the secure element and then generates a DPP URI. This DPP URI is available in a string format, PNG (QR Code), and ASCII (QR Code). The DPP URI can then be used for network onboarding, as described in the rest of the Build 1 section. This code is included in the demonstration code located at the repository linked above.

2.8.1.1 Installation and Configuration Full instructions for installation and configuration can be found in the INSTALL.txt file from the SEALSQ demonstration code mentioned above. A general set of steps for preparing to run the demonstration code is included below. 1. Install prerequisites on Raspberry Pi a. cmake b. git c. gcc 2. On the Raspberry Pi, run the sudo raspi-update command to update drivers

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

19

FINAL 3. Before plugging the VaultIC Secure Element into the Raspberry Pi connector, configure the jumpers: a. Set _VCC_ jumper i. CTRL = VaultIC power controlled by GPIO25 (default) ii. 3V3 = VaultIC power always on b. Set J1&J2 to select I2C or SPI i. If using SPI, set J1 to SS and J2 to SEL (default) ii. If using I2C, set J1 to SCL and J2 to SDA 4. Using the raspi-config command, enable the SPI or I2C interface on the Raspberry Pi 5. Run git clone https://github.com/sclark-wisekey/NCCoE.factory.pub to pull down the demonstration code.

2.8.1.2 Running the demonstration code 1. Navigate to the folder containing the demonstration code. Inside that folder, navigate to the VaultIC/demos folder. 2. Edit the file config.cfg and change the value of VAULTIC_COMM to match the jumpers configured during setup. 3. The demonstrations are available with wolfSSL stacks and organized in dedicated folders. The README.TXT file in each demonstration subfolder explains how to run the demonstrations.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

20

FINAL

3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) This section of the practice guide contains detailed instructions for installing and configuring all of the products used to build an instance of the example solution. For additional details on Build 2’s logical and physical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. The network-layer onboarding component of Build 2 utilizes Wi-Fi Easy Connect, also known as the Device Provisioning Protocol (DPP). The Wi-Fi Alliance maintains the Wi-Fi Easy Connect standard [1]. The term “DPP” refers to the network-layer onboarding protocol, and “Wi-Fi Easy Connect” refers to the overall implementation of the network onboarding process.

3.1 CableLabs Platform Controller The CableLabs Platform Controller provides an architecture and reference implementation of a cloudbased service that provides management capability for service deployment groups, access points with the deployment groups, registration and lifecycle of user services, and the secure onboarding and lifecycle management of users’ Wi-Fi devices. The controller also exposes APIs for the purpose of integrating various business flows with third-party systems (e.g., integration with the manufacturing process for device management). The Platform Controller would typically be hosted by the network operator or a third-party service provider. It can be accessed via a web interface. Additional information for this deployment can be accessed at the official CableLabs repository.

3.1.1 Operation and Demonstration Full operation can commence once the Platform Controller, Gateway, and Reference Client configurations have been completed. Instructions for this are located at the official CableLabs repository.

3.2 CableLabs Custom Connectivity Gateway In this deployment, the gateway software runs on a Raspberry Pi 3B+, which acts as a router, firewall, wireless access point, Open Connectivity Foundation (OCF) Diplomat, and OCF Onboarding Tool. The gateway is also connected to the CableLabs Platform Controller, which manages much of the gateway's configuration and functions. Due to Build 2’s infrastructure and support of Wi-Fi Easy Connect, Build 2 fully supported interoperable network-layer onboarding with Build 1’s IoT devices.

3.2.1 Installation and Configuration Hardware requirements, pre-installation steps, installation steps, and configuration instructions for the gateway can be found at the official CableLabs repository.

3.2.2 Integration with CableLabs Platform Controller Once the initial configuration has occurred, the gateway can be integrated with the CableLabs Platform Controller. Instructions are available at the official CableLabs repository.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

21

FINAL

3.2.3 Operation and Demonstration Full operation can commence once the Platform Controller, Gateway, and Reference Client configurations have been completed. Instructions for this are located at the official CableLabs repository.

3.3 Reference Clients/IoT Devices Three reference clients were deployed in this build, each on a Raspberry Pi 3B+. They were each configured to emulate either a smart light switch or a smart lamp. The software deployed also included the capability to perform network-layer onboarding via Wi-Fi Easy Connect (or DPP) and applicationlayer onboarding using the OCF onboarding method. These reference clients were fully interoperable with network-layer onboarding to Build 1.

3.3.1 Installation and Configuration Hardware requirements, pre-installation, installation, and configuration steps for the reference clients are detailed in the official CableLabs repository.

3.3.2 Operation and Demonstration Full operation can commence once the Platform Controller, Gateway, and Reference Client configurations have been completed. Instructions for this are located at the official CableLabs repository. For interoperability with Build 1, the IoT device’s DPP URI was provided to Aruba Central, which allowed Build 1 to successfully complete network-layer onboarding with the Build 2 IoT devices.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

22

FINAL

4 Build 3 (BRSKI, Sandelman Software Works) This section of the practice guide contains detailed instructions for installing and configuring all of the products used to build an instance of the example solution. For additional details on Build 3’s logical and physical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. The network-layer onboarding component of Build 3 utilizes the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Build 3 is representative of a typical home or small office network.

4.1 Onboarding Router/Join Proxy The onboarding router quarantines the IoT device attempting to join the network until the BRSKI onboarding process is complete. The router in this build is a Turris MOX device, which is based on the Linux OpenWrt version 4 operating system (OS). The Raspberry Pi 3 contains software that functions as the Join Proxy for pledges to the network. If another brand of device is used, a different source of compiled Join Proxy might be required.

4.1.1 Setup and Configuration The router needs to be IPv6-enabled. In the current implementation, the join package operates on an unencrypted network.

4.2 Minerva Join Registrar Coordinator The Join Registrar determines whether a new device is allowed to join the network. The Join Registrar is located on a virtual machine running Devuan Linux 4 within the network.

4.2.1 Setup and Configuration The Minerva Fountain Join Registrar/Coordinator is available as a Docker container and as a VM in OVA format on the Minerva Fountain page. Further setup and configuration instructions are available on the configuration page of the Sandelman website. For the Build 3 demonstration, the VM deployment was installed onto a VMware vSphere system. A freshly booted VM image will do the following on its own: 

Configure a database



Configure a local certificate authority (fountain:s0\_setup\_jrc)



Configure certificates for the database connection



Configure certificates for the registrar Hypertext Transfer Protocol Secure (HTTPS) interface



Configure certificates for use with the Bucardo database replication system



Configure certificates for the Locally Significant Device Identifier (LDevID) certification authority (fountain:s2\_create\_registrar)



Start the JRC

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

23

FINAL The root user is permitted to log in on the console ("tty0") using the password “root” but is immediately forced to set a new password. The new registrar will announce itself with the name minerva-fountain.local in mDNS. The logs for this are put into /var/log/configure-fountain-12345.log (where 12345 is a new number based on the script's PID).

4.3 Reach Pledge Simulator The Reach Pledge Simulator acts as an IoT device in Build 3 that is joining the network and is hosted on a Raspberry Pi 3. More information is available on the Sandelman website on the Reach page.

4.3.1 Setup and Configuration While this device functions as an IoT device, it runs on the same software as the Join Registrar Coordinator. This software is available in VM and Docker container formats. Please see Section 4.2.1 for installation instructions. When setting up the Reach Pledge Simulator, the pledge automatically determines the address of the Join Registrar Coordinator. Currently, the Reach Pledge Simulator obtains its IDevID using the following steps: 1. View the available packages by visiting the Sandelman website.

2. Open a terminal on the Raspberry Pi device and navigate to the Reach directory by entering: cd reach

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

24

FINAL 3. Enter the following command while substituting the URL for one of the available zip files containing the IDevID of choice on the Sandelman website. wget https://honeydukes.sandelman.ca/product_00-D0-E5-02-00-42.zip

4. Unzip the file by entering the following command, substituting the name of your zip file (the IDevID is the device.crt file): unzip product_00-D0-E5-02-00-42.zip

Typically, this would be accomplished through a provisioning process involving a Certificate Authority, as demonstrated in the Factory Provisioning builds.

4.4 Serial Console Server The serial console server does not participate in the onboarding process but provides direct console access to the IoT devices. The serial console server has been attached to a multi-port USB hub, and USB connectors and/or USB2TTL adapters have been connected to each device. The ESP32 and the nRF52840 are both connected to the serial console and receive power from the USB hub. Power to the console and IoT devices is also provided via the USB hub. A BeagleBone Green device was used as the serial console, using the "screen" program as the telecom device.

4.5 Minerva Highway MASA Server In the current build implementation, the MASA server provides the Reach Pledge Simulator with an IDevID Certificate and a public/private key pair for demonstration purposes. Typically, this would be accomplished through a factory provisioning process involving a Certificate Authority, as demonstrated in the Factory Provisioning builds.

4.5.1 Setup and Configuration Installation of the Minerva Highway MASA is described on the Highway configuration page. Additional configuration details are available on the Highway development page. The availability of VMs and containers is described on the Minerva page.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

25

FINAL

5 Build 4 (Thread, Silicon Labs, Kudelski IoT) This section of the practice guide contains detailed instructions for installing and configuring all of the products used to build an instance of the example solution. For additional details on Build 4’s logical and physical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. This build utilizes the Thread protocol and performs application-layer onboarding using the Kudelski keySTREAM service to provision a device to the AWS IoT Core.

5.1 Open Thread Border Router (OTBR) The OTBR forms the Thread network and acts as the router on this build. The OTBR is run as software on a Raspberry Pi 3B. The Silicon Labs Gecko Wireless Devkit is attached to the Raspberry Pi via USB and acts as the 802.15.4 antenna for this build.

5.1.1 Installation and Configuration On the Raspberry Pi, run the following commands from a terminal to install and configure the OTBR software: git clone https://github.com/openthread/ot-br-posix sudo NAT64=1 DNS64=1 WEB_GUI=1 ./script/bootstrap sudo NAT64=1 DNS64=1 WEB_GUI=1 ./script/setup

5.1.2 Operation and Demonstration Once the initial configuration has occurred, the OTBR should be functional and operated through the web GUI. 1. To open the OTBR GUI, enter the following IP in a web browser: 127.0.0.1

2. In the Form tab, enter the details for the Thread network being formed. For demonstration purposes, we only updated the credentials field.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

26

FINAL

5.2 Silicon Labs Dev Kit (BRD2601A) The Silicon Labs Dev Kit acts as the IoT device for this build. It is controlled using the Simplicity Studio v5 Software available at the official Simplicity Studio page and connected to a computer running Windows or Linux via USB. Our implementation leveraged a Linux machine running Simplicity Studio. The custom firmware for the Dev Kit leveraged in this use case was made by Silicon Labs.

5.2.1 Setup and Configuration The Dev Kit custom firmware image works in conjunction with the Kudelski keySTREAM service. More information is available by contacting Silicon Labs through their contact form. Once the custom firmware has been acquired, the Dev Kit can be configured using the following steps. 1. Connect the Dev Kit via USB to the machine running Simplicity Studio. 2. The firmware is installed onto the Dev Kit using the Simplicity Commander tool within Simplicity Studio.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

27

FINAL

After selecting the firmware file, click Flash to flash the firmware of the Dev Kit. 3. Open the device console in the Tools tab and select the Serial 1 tab.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

28

FINAL

4. Enter the following command to create a new join passphrase in the Serial 1 command line: new-join-passphrase

5. Enter the output of the previous command in the Commission tab in the OTBR GUI and click Start Commission.

6. In the Simplicity Commander Device Console, enter the following command to begin the joining process from the Thunderboard:

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

29

FINAL join-with-curr-phrase

7. Press the Reset button on the Dev Kit and the device will join the thread network and reach out to the Kudelski keySTREAM service. You should see the following output in the Simplicity Commander Device Console:

5.3 Kudelski keySTREAM Service This section describes the Kudelski keySTREAM service that this build utilizes to provision certificates for connecting to the AWS IoT core. More information on keySTREAM is available on the keySTREAM page.

5.3.1 Setup and Configuration The Kudelski keySTREAM service provides two certificates for the device: a CA certificate and a Proof of Possession (POP) certificate generated using a code from the AWS server. This section describes the steps to download these certificates. 1. Locate the Chip unique identifier (UID) for the Silicon Labs Dev Kit in Simplicity Studio by rightclicking on the Device Adapters tab at the bottom and selecting Device Configuration.

2. On the Security Settings tab, take the last 16 characters of the serial number and remove the ‘FFFE’ characters from the 7th – 11th positions. NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

30

FINAL

3.

In the Kudelski keySTREAM service, claim your device by entering the chip UID from Simplicity Studio and clicking Commit.

4. The device will now be visible in the My Devices tab. A device can be removed from the keySTREAM service by scrolling to the right and clicking the Refurbish button.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

31

FINAL

5. Click the cloud icon to download the CA Certificate and the POP certificate. The POP certificate will require a code obtained from the AWS IoT Core, which will be generated in Section 5.4.1.

5.4 AWS IoT Core The Silicon Labs Dev Kit will connect to the AWS MQ Telemetry Transport (MQTT) test client using the certificates provisioned from the Kudelski keySTREAM service.

5.4.1 Setup and Configuration Application-layer onboarding for this build is performed using the AWS MQTT test client. Certificates provisioned from the Kudelski keySTREAM service are uploaded to an AWS instance, allowing the device to demonstrate its ability to successfully send a message to AWS. 1. Within the AWS IoT Core, open the Security drop-down menu, click on Certificate authorities, and click the Register CA certificate button on the right.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

32

FINAL

2. Select the radio button for Register CA in Single-account mode, copy the registration code to use as the Proof of Possession Code in the Kudelski keySTREAM service, and download the POP certificate.

3. After downloading the POP certificate, upload the CA certificate and the POP (verification) certificate, and select the radio buttons for Active under CA Status and On under Automatic Certificate Registration. Then click Register.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

33

FINAL

4. In the Security drop-down menu, click on Policies and add the policies shown below. Then, click Create.

5. In the All devices drop-down menu, click on Things and click Create things.

6. Click the Create single thing radio button and click Next.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

34

FINAL

7. Enter a Thing name and click Next.

8. Select the Skip creating a certificate at this time radio button and click Create thing.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

35

FINAL

9. In the Security drop-down menu, click on Certificates and click the Certificate ID of the certificate that you created. 10. In the Policies tab at the bottom, click Attach policies and add the policy that you created.

11. In the Things tab, click Attach to things and add the thing that you created.

12. Click the MQTT test client on the left side of the page and click the Publish to a topic tab.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

36

FINAL 13. Create a message of your choosing and click Publish. On the Subscribe to a topic tab, make sure that you are subscribed to the topic that you just created.

5.4.2 Testing Information sent and received by the Silicon Labs Dev Kit to the MQTT test client will be displayed in the device console in Simplicity Commander. This section describes testing the communication between the MQTT test client and the device. 1. On the Thunderboard, press Button 0. This will begin the connection to the MQTT test client.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

37

FINAL

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

38

FINAL

6 Build 5 (BRSKI over Wi-Fi, NquiringMinds) This section of the practice guide contains detailed instructions for installing and configuring all of the products used to build an instance of the example solution. For additional details on Build 5’s logical and physical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics. The network-layer onboarding component of Build 5 utilizes the BRSKI protocol.

6.1 Pledge The pledge acts as the IoT device attempting to onboard onto the secure network. It implements the pledge functionality as per the IETF BRSKI specification. It consists of software provided by NquiringMinds running on a Raspberry Pi Model 4B.

6.1.1 Installation and Configuration Hardware requirements, pre-installation steps, installation steps, and configuration instructions for the pledge device can be found at the official NquiringMinds repository.

6.1.2 Operation and Demonstration To demonstrate the onboarding and offboarding functionality, NquiringMinds has provided a web application that runs on the pledge device. It features a button to manually run the onboarding script and display the output of the onboarding process, as well as a button for offboarding. It also features a button to ping an IP address via the wireless network interface.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

39

FINAL

Figure 6-1 NQM BRSKI Demo App Web Interface

6.2 Router and Logical Services The router and logical services were hosted on a Raspberry Pi Model 4B equipped with two external WiFi adapters. These additional Wi-Fi adapters are needed to support VLAN tagging, which is a hardwaredependent feature. The details of the physical setup and all connections are provided in the official NquiringMinds documentation.

6.2.1 Installation and Configuration All of the services described in the next section can be installed on a Raspberry Pi using the installer provided by NquiringMinds. The demonstration services can also be built from source code if needed. The following links provide the instructions for building each of those services: 

BRSKI Demo Setup



EAP Config



MDNS publishing services

6.2.2 Logical Services The following logical services are installed on the registrar and services device. Their implementations can be found at the following repository links: NIST BRSKI implementation and BRSKI.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

40

FINAL Figure 6-2 below describes how these entities and logical services fit together to perform the BRSKI flow and a top-level view of how information is transmitted throughout the services to onboard the pledge.

Figure 6-2 Logical Services for Build 5

6.2.2.1 MASA The MASA currently resides as a local service on the registrar. In practice, this service would be located on an external server managed by the manufacturer. The MASA verifies that the IDevID is authentic and that the manufacturer’s MPR produced the IDevID.

6.2.2.2 Manufacturer Provisioning Root (MPR) The MPR sits on an external server and provides the IDevID (X.509 Certificate) for the device to initialize after production and notarize with a unique identity. The address of the MPR is built into the device's firmware at build time.

6.2.2.3 Registrar Build 5’s BRSKI Domain Registrar runs the BRSKI protocol modified to work over Wi-Fi and functions as the Domain Registrar to authenticate the IoT devices, receive and transfer voucher requests and

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

41

FINAL responses to and from the MASA, and ultimately determines whether network-layer onboarding of the device is authorized to take place on the respective network. NquiringMinds has developed a stateful, non-persistent Linux app for Android that serves this purpose. The registrar is responsible for verifying if the IDevID certificate provided by the pledge is authentic by verifying it with the MASA and verifying that the policy for a pledge to be allowed onto the closed, secure network has been met. It also runs continuous assurance periodically to ensure that the device still meets the policy requirements, revoking the pledge’s access if, at a later time, it doesn’t meet the policy requirements. Signed verifiable credential claims may be submitted to the registrar to communicate information about entities, which it uses to update the database used to determine if the policy is met. The tdx Volt facilitates the signing and verification of verifiable credentials. The MASA and router are integrated into the same physical device in the demonstrator system. 6.2.2.3.1 Radius server (Continuous Assurance Client) The registrar includes a Radius server that integrates with the Continuous Assurance Server to provide continuous assurance capabilities for connected IoT devices. The continuous assurance policy is enforced by a script that periodically runs to ensure the policy conditions are met. It accomplishes this by querying the Registrar's SQLite database. For the demonstration, the defined policy is: 

The manufacturer and device must be trusted by a user with appropriate privileges.



The device must have a device type associated with it.



The vulnerability score of the Software Bill of Materials (SBOM) for the device type must be lower than six.



The device must not have contacted a denylisted IP address within the last two minutes.

If the device fails any of these checks, the device will be offboarded.

6.2.2.4 Continuous Assurance Server The registrar runs several services used to power the continuous assurance flow. 6.2.2.4.1 Verifiable Credential Server The verifiable credential server is used to sign credentials submitted through the Demo web app and verify the credentials submitted to the registrar. The web app is powered by a local instance of the tdx Volt running on the registrar. The code for the Verifiable Credential Server is hosted at the GitHub repository. 6.2.2.4.2 Registrar Continuous Assurance Server The registrar hosts a REST API that is used to interface with the registrar’s SQLite database; the database stores information about the entities the registrar knows of. This server utilizes the verifiable credential server to validate the verifiable credential claims submitted. The code for the Registrar Continuous Assurance Server is hosted at the GitHub repository.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

42

FINAL 6.2.2.4.3 Demo Web Application The demo web application is used as an interactive, user-friendly way to administer the registrar. Users can view the list of verifiable credentials submitted to the registrar. The application also displays the state of the manufacturers, devices, device types, and Manufacturer Usage Description (MUD). There are buttons provided that allow you to trust or distrust a manufacturer, trust or distrust a device, set the device type for a device, set if a device type is vulnerable, and set the MUD file associated with the device type. These operations are performed by generating a verifiable credential containing the claim being made, which is then submitted to the verifiable credential server to sign the credential. The signed verifiable credential is then sent to the Registrar Continuous Assurance Server to be verified and used to update the SQLite database on the registrar. The code for the Demo Web Application is hosted at the GitHub repository.

Figure 6-3 NQM BRSKI Policy App Web Interface

6.2.2.5 Application server The application server is hosted on a remote server and is the destination for data consumed from the pledge device. To onboard onto the application server, the pledge device establishes a secure TLS connection using its IDevID certificate. Currently, the pledge uses OpenSSL's s_client to initiate the TLS session with the application server, which runs off-site. As a proof of concept, the pledge device sends data—such as the current date and CPU temperature—to be logged on the application server.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

43

FINAL 6.2.2.5.1 Installation/Configuration Hardware requirements, pre-installation steps, installation steps, and configuration instructions for the router can be found at the official NquiringMinds repository. 6.2.2.5.2 Operation/Demonstration The instructions for using this factory use case code to provision an IDevID onto your pledge are also located at the official NquiringMinds repository in the above section.

6.3 Onboarding Demonstration 6.3.1 Prerequisites Prior to beginning the demonstration, the router and pledge devices must be connected to power and the network via their Ethernet port. Both devices should start the services required to demonstrate the BRSKI flow on boot.

Figure 6-4 Diagram of Physical/Logical Components Used to Demonstrate BRSKI Flow To support the demo and debug features, the pledge and the registrar need to be connected to physical Ethernet, ideally with internet access. They should still function without an internet connection, but the SBOMs' vulnerability scores will not be updated, and the demo web apps will only be accessible on the local network. The details of the networking setup are available in the NquiringMinds NIST Trusted Onboarding Build-5.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

44

FINAL

6.3.2 Onboarding Demonstration Once the devices have been configured and the prerequisite conditions have been achieved, the onboarding demonstration can be executed following the NquiringMinds Demo Continuous Assurance Workflow.

6.3.3 Continuous Assurance Demonstration The instructions to demonstrate the continuous assurance workflow are contained in the official NquiringMinds documentation.

6.4 BRSKI Factory Provisioning Build This Factory Provisioning Build includes many of the components listed in Section 6.2, including the Pledge, Registrar, and other services. An Infineon Secure Element was also included in the build and provides secure generation and storage of the key material and certificates provisioned to the device.

6.4.1 Pledge The pledge acts as the IoT device attempting to onboard onto the secure network. It implements the pledge functionality as per the IETF BRSKI specification. It consists of a Raspberry Pi Model 4B equipped with an Infineon Optiga SLB 9670 TPM 2.0 Secure Element, which was connected to the Raspberry Pi via the built-in GPIO pins.

6.4.1.1 Factory Use Case - IDevID provisioning NquiringMinds provided demonstration code that generates a public/private key pair within the secure element, creates a CSR, and uses that CSR to obtain an IDevID certificate from tdx Volt. The demonstration process can be found in the official NquiringMinds documentation. Initially, it generates a CSR using the TPM secure element to sign it, then sends the CSR to the MPR server (the manufacturer’s IDevID Certificate Authority) and bootstraps the vanilla firmware on the pledge’s creation in the factory. The MPR sends back a unique IDevID for the pledge, which it stores in its secure element. The code for this is hosted at the official NquiringMinds repository.

6.4.2 Installation and Configuration Hardware requirements, pre-installation steps, installation steps, and configuration instructions for the pledge can be found in the official NquiringMinds repository referenced above.

6.4.3 Operation and Demonstration The instructions for using this factory provisioning use case code to provision an IDevID onto the pledge are also in the official NquiringMinds repository referenced above.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

45

FINAL

Appendix A

List of Acronyms

AKM

Authentication and Key Management

AOS

ArubaOS

AP

Access Point

API

Application Programming Interface

ASN.1

Abstract Syntax Notation One

AWS

Amazon Web Services

BRSKI

Bootstrapping Remote Secure Key Infrastructure

BSS

Basic Service Set

CA

Certificate Authority

CRADA

Cooperative Research and Development Agreement

CSR

Certificate Signing Request

DPP

Device Provisioning Protocol (Wi-Fi Easy Connect)

EAP

Extensible Authentication Protocol

GPIO

General Purpose Input/Output

GUI

Graphical User Interface

HPE

Hewlett Packard Enterprise

IaaS

Infrastructure as a Service

IDevID

Initial Device Identifier

IEEE

Institute of Electrical and Electronics Engineers

IoT

Internet of Things

IPv4

Internet Protocol Version 4

IPv6

Internet Protocol Version 6

ITL

Information Technology Laboratory

LDevID

Locally Significant Device Identifier

MASA

Manufacturer Authorized Signing Authority

MPR

Manufacturer Provisioning Root

MUD

Manufacturer Usage Description

MQTT

MQ Telemetry Transport

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

46

FINAL NCCoE

National Cybersecurity Center of Excellence

NIST

National Institute of Standards and Technology

OCF

Open Connectivity Foundation

OS

Operating System

OTBR

Open Thread Border Router

PNG

Portable Network Graphics

POP

Proof of Possession

QR

Quick-Response

RF

Radio Frequency

SBOM

Software Bill of Materials

SP

Special Publication

SoC

System-on-Chip

SSID

Service Set Identifier

TPM

Trusted Platform Module

UID

Unique Identifier

URI

Uniform Resource Identifier

USB

Universal Serial Bus

UXI

User Experience Insight

VLAN

Virtual Local Area Network

VM

Virtual Machine

WLAN

Wireless Local Area Network

WPA2

Wi-Fi Protected Access 2

WPA3

Wi-Fi Protected Access 3

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

47

FINAL

Appendix B [1]

References

Wi-Fi Alliance. Wi-Fi Easy Connect. Available: https://www.wi-fi.org/discover-wi-fi/wi-fi-easyconnect.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

48

NIST SPECIAL PUBLICATION 1800-36D

Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management Enhancing Internet Protocol-Based IoT Device and Network Security Volume D: Functional Demonstrations

Murugiah Souppaya* Paul Watrobski*

Nick Allott Ashley Setter

Andy Dolan Kyle Haefner Craig Pratt Darshak Thakore

Michael Richardson

Brecht Wyseur

Silicon Labs, Austin, Texas

National Cybersecurity Center of Excellence Information Technology Laboratory

NquiringMinds Southampton, United Kingdom Sandelman Software Works Ontario, Canada

CableLabs Louisville, Colorado

Mike Dow Steve Egerter

Kudelski IoT Cheseaux-sur-Lausanne, Switzerland

Chelsea Deane Joshua Klosterman Blaine Mulugeta Charlie Rearick Susan Symington

The MITRE Corporation McLean, Virginia

November 2025 FINAL

Retired NIST Author*

*Former NIST employee; all work for this publication was done while at NIST.

This publication is available free of charge from https://doi.org/10.6028/NIST.SP.1800-36

FINAL

DISCLAIMER Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.

National Institute of Standards and Technology Special Publication 1800-36D, Natl. Inst. Stand. Technol. Spec. Publ. 1800-36D, 51 pages, November 2025, CODEN: NSPUE2

FEEDBACK As a private-public partnership, we are always seeking feedback on our practice guides. We are particularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us at iot-onboarding@nist.gov. All comments are subject to release under the Freedom of Information Act.

National Cybersecurity Center of Excellence National Institute of Standards and Technology 100 Bureau Drive Mailstop 2002 Gaithersburg, MD 20899 Email: nccoe@nist.gov

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

ii

FINAL

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the creation of practical cybersecurity solutions for specific industries, as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners—from Fortune 50 market leaders to smaller companies specializing in information technology security—the NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the steps needed for another entity to re-create the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland. To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align with relevant standards and best practices, and provide users with the materials lists, configuration files, and other information they need to implement a similar approach. The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.

KEYWORDS application-layer onboarding; bootstrapping; Internet of Things (IoT); Manufacturer Usage Description (MUD); network-layer onboarding; onboarding; Wi-Fi Easy Connect.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iii

FINAL

ACKNOWLEDGMENTS We are grateful to the following individuals for their generous contributions of expertise and time. Name

Organization

Amogh Guruprasad Deshmukh

Aruba, a Hewlett Packard Enterprise company

Dan Harkins

Aruba, a Hewlett Packard Enterprise company

Danny Jump

Aruba, a Hewlett Packard Enterprise company

Bart Brinkman

Cisco

Eliot Lear

Cisco

Peter Romness

Cisco

Tyler Baker

Foundries.io

George Grey

Foundries.io

David Griego

Foundries.io

Fabien Gremaud

Kudelski IoT

Faith Ryan

The MITRE Corporation

Toby Ealden

NquiringMinds

John Manslow

NquiringMinds

Antony McCaigue

NquiringMinds

Alexandru Mereacre

NquiringMinds

Loic Cavaille

NXP Semiconductors

Mihai Chelalau

NXP Semiconductors

Julien Delplancke

NXP Semiconductors

Anda-Alexandra Dorneanu

NXP Semiconductors

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iv

FINAL

Name

Organization

Todd Nuzum

NXP Semiconductors

Nicusor Penisoara

NXP Semiconductors

Laurentiu Tudor

NXP Semiconductors

Michael Richardson

Sandelman Software Works

Karen Scarfone

Scarfone Cybersecurity

Steve Clark

SEALSQ, a subsidiary of WISeKey

Pedro Fuentes

SEALSQ, a subsidiary of WISeKey

Gweltas Radenac

SEALSQ, a subsidiary of WISeKey

Kalvin Yang

SEALSQ, a subsidiary of WISeKey

Heather Flanagan

Spherical Cow Consulting

The Technology Partners/Collaborators who participated in this build submitted their capabilities in response to a notice in the Federal Register. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build this example solution. We worked with: Aruba, a Hewlett Packard Enterprise company CableLabs Cisco Foundries.io

Technology Collaborators Kudelski IoT NquiringMinds NXP Semiconductors Open Connectivity Foundation (OCF)

Sandelman Software Works Silicon Labs SEALSQ, a subsidiary of WISeKey

DOCUMENT CONVENTIONS The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the publication and from which no deviation is permitted. The terms “should” and “should not” indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. The terms

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

v

FINAL “may” and “need not” indicate a course of action permissible within the limits of the publication. The terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

PATENT DISCLOSURE NOTICE NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication. As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL. No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vi

FINAL

Contents 1 Introduction ........................................................................................ 1 1.1

How to Use This Guide .................................................................................................1

1.2

Typographic Conventions ............................................................................................3

2 Functional Demonstration Playbook ................................................... 4 2.1

Scenario 0: Factory Provisioning ..................................................................................4

2.2

Scenario 1: Trusted Network-Layer Onboarding ..........................................................5

2.3

Scenario 2: Trusted Application-Layer Onboarding......................................................6

2.4

Scenario 3: Re-Onboarding a Device ............................................................................7

2.5

Scenario 4: Ongoing Device Validation ........................................................................8

2.6

Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle ................................................................................9

3 Functional Demonstration Results .................................................... 10 3.1

Build 1 Demonstration Results...................................................................................10

3.2

Build 2 Demonstration Results...................................................................................17

3.3

Build 3 Demonstration Results...................................................................................23

3.4

Build 4 Demonstration Results...................................................................................29

3.5

Build 5 Demonstration Results...................................................................................35

Appendix A References ......................................................................... 43

List of Tables Table 2-1 Scenario 0 Factory Provisioning Capabilities That May Be Demonstrated .............................. 5 Table 2-2 Scenario 1 Trusted Network-Layer Onboarding Capabilities That May Be Demonstrated ...... 6 Table 2-3 Scenario 2 Trusted Application-Layer Onboarding Capabilities That May Be Demonstrated .. 7 Table 2-4 Scenario 3 Re-Onboarding Capabilities That May Be Demonstrated ...................................... 7 Table 2-5 Scenario 4 Ongoing Device Validation Capabilities That May Be Demonstrated .................... 8 Table 2-6 Scenario 5 Credential and Device Posture Establishment and Maintenance Capabilities That May Be Demonstrated ......................................................................................................................... 9 Table 3-1 Build 1 Capabilities Demonstrated ...................................................................................... 10 Table 3-2 Build 2 Capabilities Demonstrated ...................................................................................... 17 Table 3-3 Build 3 Capabilities Demonstrated ...................................................................................... 23

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vii

FINAL Table 3-4 Build 4 Capabilities Demonstrated ...................................................................................... 29 Table 3-5 Build 5 Capabilities Demonstrated ...................................................................................... 36

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

viii

FINAL

1 Introduction In this project, the National Cybersecurity Center of Excellence (NCCoE) is applying standards, recommended practices, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices and lifecycle management of those devices. We show how to provision network credentials to IoT devices in a trusted manner and maintain a secure posture throughout the device lifecycle. This volume of the NIST Cybersecurity Practice Guide describes functional demonstration scenarios that are designed to showcase the security capabilities and characteristics supported by trusted IoT device network-layer onboarding and lifecycle management solutions. Section 2, Functional Demonstration Playbook, defines the scenarios and lists the capabilities that can be showcased in each one. Section 3, Functional Demonstration Results, reports which capabilities have been demonstrated by each of the project’s implemented solutions.

1.1 How to Use This Guide This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design for implementing trusted IoT device network-layer onboarding and lifecycle management and describes various example implementations of this reference design. Each of these implementations, known as builds, is standards-based and designed to help provide assurance that networks are not put at risk as new IoT devices are added to them and to help safeguard IoT devices from being taken over by unauthorized networks. The reference design described in this practice guide is modular and can be deployed in whole or in part, enabling organizations to incorporate trusted IoT device network-layer onboarding and lifecycle management into their legacy environments according to goals that they have prioritized based on risk, cost, and resources. This guide contains five volumes: 

NIST SP 1800-36A: Executive Summary – why we wrote this guide, the challenge we address, why it could be important to your organization, and our approach to solving this challenge



NIST SP 1800-36B: Approach, Architecture, and Security Characteristics – what we built and why



NIST SP 1800-36C: How-To Guides – instructions for building the example implementations, including all the security-relevant details that would allow you to replicate all or parts of this project



NIST SP 1800-36D: Functional Demonstrations – use cases that have been defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabilities and the results of demonstrating these use cases with each of the example implementations (you are here)



NIST SP 1800-36E: Risk and Compliance Management – risk analysis and mapping of trusted IoT device network-layer onboarding and lifecycle management security characteristics to cybersecurity standards and recommended practices

Depending on your role in your organization, you might use this guide in different ways:

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

1

FINAL Business decision makers, including chief information security, product security, and technology officers, will be interested in the Executive Summary, NIST SP 1800-36A, which describes the following topics: 

challenges that enterprises face in migrating to the use of trusted IoT device network-layer onboarding



example solutions built at the NCCoE



benefits of adopting the example solution

Technology, security, and privacy program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in NIST SP 1800-36B, which describes what we did and why. Also, Section 4 of NIST SP 1800-36E will be of particular interest. Section 4, Mappings, maps logical components of the general trusted IoT device network-layer onboarding and lifecycle management reference design to security characteristics listed in various cybersecurity standards and recommended practices documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity Framework) and Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53). You might share the Executive Summary, NIST SP 1800-36A, with your leadership team members to help them understand the importance of using standards-based trusted IoT device network-layer onboarding and lifecycle management implementations. IT professionals who want to implement similar solutions will find the whole practice guide useful. You can use the how-to portion of the guide, NIST SP 1800-36C, to replicate all or parts of the builds created in our lab. The how-to portion of the guide provides specific product installation, configuration, and integration instructions for implementing the example solution. We do not re-create the product manufacturers’ documentation, which is generally widely available. Rather, we show how we incorporated the products together in our environment to create an example solution. Also, you can use Functional Demonstrations, NIST SP 1800-36D, which provides the use cases defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabilities and the results of demonstrating these use cases with each of the example implementations. Finally, NIST SP 1800-36E will help explain the security functionality that the components of each build provide. This guide assumes that IT professionals have experience implementing security products within the enterprise. While we have used a suite of commercial products to address this challenge, this guide does not endorse these particular products. Your organization can adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a trusted IoT device network-layer onboarding and lifecycle management solution. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. We hope that you will seek products that are congruent with applicable standards and recommended practices. A NIST Cybersecurity Practice Guide does not describe “the” solution; it provides examples of solutions. We seek feedback on the publication’s contents and welcome your input. Comments, suggestions, and

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

2

FINAL success stories will improve subsequent versions of this guide. Please contribute your thoughts to iotonboarding@nist.gov.

1.2 Typographic Conventions The following table presents typographic conventions used in this volume. Typeface/Symbol

Meaning

Example

Italics

file names and path names; references to documents that are not hyperlinks; new terms; and placeholders names of menus, options, command buttons, and fields command-line input, onscreen computer output, sample code examples, and status codes command-line user input contrasted with computer output link to other parts of the document, a web URL, or an email address

For language use and style guidance, see the NCCoE Style Guide.

Bold Monospace

Monospace Bold

blue text

Choose File > Edit. mkdir

service sshd start

All publications from NIST’s NCCoE are available at https://www.nccoe.nist.gov.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

3

FINAL

2 Functional Demonstration Playbook Six scenarios have been defined that demonstrate capabilities related to various aspects of trusted IoT device network-layer onboarding, application-layer onboarding, and device lifecycle management. These scenarios are as follows: 

Scenario 0: Factory Provisioning



Scenario 1: Trusted Network-Layer Onboarding



Scenario 2: Trusted Application-Layer Onboarding



Scenario 3: Re-Onboarding a Device



Scenario 4: Ongoing Device Validation



Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle

We executed the factory provisioning scenario (Scenario 0) using both a Bootstrapping Remote Secure Key Infrastructure (BRSKI) Factory Provisioning Build and a Wi-Fi Easy Connect Factory Provisioning Build, which have been implemented as part of this project. We executed the trusted network-layer onboarding and lifecycle management scenarios using each of the onboarding builds implemented as part of this project. The demonstrated capabilities depend on the features of the network-layer onboarding protocol (e.g., Wi-Fi Easy Connect) that the build supports and any additional mechanisms the build may have integrated (e.g., application-layer onboarding). Section 2.1 defines the factory provisioning scenario (Scenario 0). Sections 2.2 through Section 2.6 define each of the five onboarding scenarios.

2.1 Scenario 0: Factory Provisioning This scenario, which simulates the IoT device factory provisioning process, is designed to represent some steps that must be performed in the factory before the device is put into the supply chain. The device manufacturer or integrator performs these steps to provision a device with the information it requires to be able to participate in trusted network-layer onboarding and lifecycle management. The device is assumed to have been equipped with secure storage and the software or firmware needed to support a specific network-layer onboarding protocol (e.g., Wi-Fi Easy Connect or BRSKI). Scenario 0 includes the initial provisioning of the IoT device with its birth credential (e.g., its private key and initial device identifier (IDevID) [1]), where it is stored in secure storage to prevent tampering or disclosure. This process includes generation of the credential (e.g., a private key and other information), signing of this credential (if applicable, depending on what onboarding protocol the device is designed to support), and transfer of the device bootstrapping information (e.g., a DPP URI or the device’s IDevID) to the appropriate destination to ensure that it will be available for use during the network-layer onboarding process. Following provisioning, the birth credential may be used for network-layer or application-layer onboarding. Table 2-1 lists the capabilities that may be demonstrated in this factory provisioning scenario.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

FINAL Table 2-1 Scenario 0 Factory Provisioning Capabilities That May Be Demonstrated Demo Capability ID

Description

S0.C1

Birth Credential Generation and Storage

The device’s birth credentials are generated within or generated and provisioned into secure storage on the IoT device. The content and format of the credential are appropriate to the onboarding protocol (e.g., Wi-Fi Easy Connect [2] or BRSKI [3]) that the device is designed to support: • For BRSKI, the credential is a private key, a signed certificate (IDevID), a trust anchor for the manufacturer’s certificate authority (CA), and the location of a trusted manufacturer authorized signing authority (MASA). • For Wi-Fi Easy Connect, the credential is a private key and a public bootstrapping key.

S0.C2

Birth Credential Signing

The credential is signed by a trusted CA.

S0.C3

Bootstrapping Information Availability

The bootstrapping information required for onboarding the device is made available as needed. The format and content of the bootstrapping information depends on the onboarding protocol that the device is designed to support: • For BRSKI, the bootstrapping information is the certificate and ownership information that is sent to the MASA. • For Wi-Fi Easy Connect, the bootstrapping information is the Device Provisioning Protocol (DPP) uniform resource identifier (URI) (which contains the public key and optionally other information such as device serial number).

2.2 Scenario 1: Trusted Network-Layer Onboarding This scenario involves trusted network-layer onboarding of an authorized IoT device to a local network operated by the owner of the IoT device. The device is assumed to have been manufactured to support the type of network-layer onboarding protocol (e.g., Wi-Fi Easy Connect or BRSKI) used by the local network. The device is also assumed to have been provisioned with its birth credential in a manner similar to that described in Scenario 0: Factory Provisioning, including the transfer of the device’s bootstrapping information (e.g., its public key) to the operator of the local network to ensure that this information will be available to support authentication of the device during the initial phase of the trusted network-layer onboarding process. Onboarding is performed after the device has booted up and is placed in its onboarding mode. Because the organization operating the local network is the owner of the IoT device, the device is authorized to be onboarded to the network, and the network is authorized to onboard the device. In this scenario, after the identities of the device and the network are authenticated, a network onboarding component—a logical component authorized to onboard devices on behalf of the network—authenticates the device and provisions unique network credentials to the device over a secure channel. These network credentials are not just specific to the device; they are also

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

5

FINAL specific to the local network. The device then uses these credentials to connect to the network. Table 2-2 lists the capabilities that may be demonstrated in this scenario. Table 2-2 Scenario 1 Trusted Network-Layer Onboarding Capabilities That May Be Demonstrated Demo Capability ID

Description

S1.C1

Device Authentication

The onboarding mechanism authenticates the device’s identity.

S1.C2

Device Authorization

The onboarding mechanism verifies that the device is authorized to onboard to the network.

S1.C3

Network Authentication

The device can verify the network’s identity.

S1.C4

Network Authorization

The device can verify that the network is authorized to take control of it.

S1.C5

Secure Local Credentialing

The onboarding mechanism securely provisions local network credentials to the device.

S1.C6

Secure Storage

The local network credentials are provisioned to secure hardwarebacked storage on the device.

S1.C7

Network Selection

The onboarding mechanism provides the IoT device with the identifier of the network to which the device should onboard.

S1.C8

Interoperability

The network-layer onboarding mechanism can onboard a minimum of two types of IoT devices (e.g., different device vendors and models).

2.3 Scenario 2: Trusted Application-Layer Onboarding This scenario involves trusted application-layer onboarding that is performed automatically on an IoT device after the device connects to a network. As a result, this scenario can be thought of as a series of steps that would be performed as an extension of Scenario 1, assuming the device has been designed and provisioned to support application-layer onboarding. As part of these steps, the device mutually and automatically authenticates with a trusted application-layer onboarding service and establishes an encrypted connection to that service so the service can provision the device with application-layer credentials. The application-layer credentials could, for example, enable the device to securely connect to a trusted lifecycle management service to check for available updates or patches. For the applicationlayer onboarding mechanism to be trusted, it must establish an encrypted connection to the device without exposing any information that must be protected to ensure the confidentiality of that connection. Two types of application-layer onboarding are defined in NIST SP 1800-36B: streamlined and independent. Table 2-3 lists the capabilities that may be demonstrated in this scenario, including both types of application-layer onboarding.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

6

FINAL Table 2-3 Scenario 2 Trusted Application-Layer Onboarding Capabilities That May Be Demonstrated Demo Capability ID

Description

S2.C1

Automatic Initiation of Streamlined Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted application-layer onboarding after performing network-layer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been securely conveyed to the device during the network-layer onboarding process.

S2.C2

Automatic Initiation of Independent Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted application-layer onboarding after performing network-layer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been pre-provisioned to the device by the device manufacturer or integrator (e.g., as part of an application that was installed on the device during the manufacturing process).

S2.C3

Trusted ApplicationLayer Onboarding

The device and a trusted application service can establish an encrypted connection without exposing any information that must be protected to ensure the confidentiality of the connection. They can then use that secure association to exchange application-layer information.

2.4 Scenario 3: Re-Onboarding a Device This scenario involves re-onboarding an IoT device to a network after deleting its network credentials so that the device can be re-credentialed and reconnected. If the device also supports application-layer onboarding, application-layer onboarding should also be performed again after the device reconnects to the network. This scenario assumes that the device has successfully demonstrated trusted networklayer onboarding as defined in Scenario 1: Trusted Network-Layer Onboarding. If application-layer reonboarding is to be demonstrated as well, the scenario assumes that the device has also been able to successfully demonstrate at least one method of application-layer onboarding as defined in Scenario 2: Trusted Application-Layer Onboarding. Table 2-4 lists the capabilities that may be demonstrated in this scenario. Table 2-4 Scenario 3 Re-Onboarding Capabilities That May Be Demonstrated Demo Capability ID

Description

S3.C1

Credential Deletion

The device’s network credential can be deleted.

S3.C2

De-Credentialed Device Cannot Connect

After the device’s network credential has been deleted, the device is not able to connect to or communicate on the network securely.

S3.C3

Re-Onboarding (network layer)

After the device’s network credential has been deleted, the networklayer onboarding mechanism can securely re-provision a network

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

7

FINAL Demo Capability ID

Description credential to the device, which the device can then use to connect to the network securely.

S3.C4

Re-Onboarding (application layer)

After the device’s network and application-layer credentials have been deleted and the device has been re-onboarded at the network layer and reconnected to the network, the device can again perform trusted application-layer onboarding.

2.5 Scenario 4: Ongoing Device Validation This scenario involves ongoing device validation, not only as part of a trusted boot or attestation process prior to permitting the device to undergo network-layer onboarding, but also after the device has connected to the network. It may involve one or more security mechanisms designed to evaluate, validate, or respond to device trustworthiness using methods such as examining device behavior, ensuring device authenticity and integrity, and assigning the device to a specific network segment based on its conformance to policy criteria. Table 2-5 lists the capabilities that may be demonstrated in this scenario. None of these capabilities is integral to trusted network-layer onboarding; however, they may be used in conjunction with, or subsequent to, trusted network-layer onboarding to enhance device and network security. Table 2-5 Scenario 4 Ongoing Device Validation Capabilities That May Be Demonstrated Demo Capability ID

Description

S4.C1

Device Attestation (initial)

The network-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

S4.C2

Device Attestation (application layer)

The application-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

S4.C3

Device Attestation (ongoing)

Successful device attestation is required prior to permitting the device to perform some operation (e.g., accessing a high-value resource).

S4.C4

Local Network Segmentation (initial)

Upon connection, the IoT device is assigned to some local network segment in accordance with policy, which may include an assessment of its security posture.

S4.C5

Behavioral Analysis

Device behavior is observed to determine whether the device meets the policy criteria required to be permitted to perform a given operation (e.g., to access a high-value resource or be placed on a given network segment).

S4.C6

Local Network Segmentation (ongoing)

The IoT device can be reassigned to a different network segment based on ongoing assessments of its conformance to policy criteria.

S4.C7

Periodic Device Reauthentication

After connection, the IoT device’s identity is periodically reauthenticated in order to maintain network access.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

8

FINAL Demo Capability ID

Description

S4.C8

After connection, the IoT device’s authorization to access the network is periodically reconfirmed in order to maintain network access.

Periodic Device Reauthorization

2.6 Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle This scenario involves steps used to help establish and maintain the security posture of both the device’s network credentials and the device itself. It includes the capability to download and validate the device’s most recent firmware updates, securely integrate with a device communications intent enforcement mechanism (e.g., Manufacturer Usage Description (MUD) [4]), keep the device updated and patched, and establish and maintain the device’s network credentials by provisioning X.509 certificates or DPP Connectors to the device and updating expired network credentials. Table 2-6 lists the capabilities that may be demonstrated in this scenario. None of these capabilities is integral to trusted network-layer onboarding; however, they may be used in conjunction with or subsequent to trusted network-layer onboarding to enhance device and network security. Table 2-6 Scenario 5 Credential and Device Posture Establishment and Maintenance Capabilities That May Be Demonstrated Demo Capability ID

Description

S5.C1

Trusted Firmware Updates

The device can download the most recent firmware update and verify its signature before it is installed.

S5.C2

Credential Certificate Provisioning

The onboarding mechanism can interact with a certificate authority to sign a device’s X.509 certificate and provision it onto the device.

S5.C3

Credential Update

The device’s network credential can be updated after it expires.

S5.C4

Server Attestation

Successful server attestation is required prior to permitting the server to perform some operation on the device (e.g., prior to downloading and installing updates onto the device).

S5.C5

Secure Integration with MUD

The network-layer onboarding mechanism can convey necessary device communications intent information (e.g., the IoT device’s MUD URL) to the network in encrypted form, thereby securely binding this information to the device and ensuring its confidentiality and integrity.

S5.C6

Lifecycle Management Establishment

The device has a lifecycle management service and can automatically establish a secure association with it after performing network-layer onboarding and connecting to the network.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

9

FINAL

3 Functional Demonstration Results This section records the capabilities that were demonstrated for each of the builds. Note that in tables 3-1 through 3-5, “not supported in this build” means that the build did not support the capability, while “not demonstrated in this build” means the build could support the capability but it was not included in the demonstration.

3.1 Build 1 Demonstration Results Table 3-1 lists the capabilities that were demonstrated by Build 1. Table 3-1 Build 1 Capabilities Demonstrated Demo ID

Capability

Description

Demonstrated? Explanation/Notes

Scenario 0: Factory Provisioning S0.C1

Birth Credential Generation and Storage

The device’s birth credentials are generated within or generated and provisioned into secure storage on the IoT device. For Wi-Fi Easy Connect, the credential is a private key and a public bootstrapping key.

Yes

Public/private key pair is generated within the SEALSQ VaultIC secure element.

S0.C2

Birth Credential Signing

The credential is signed by a trusted CA.

No

There is no requirement to support this capability in this build. Birth credentials for devices supporting WiFi Easy Connect onboarding do not need to be signed.

S0.C3

Bootstrapping Information Availability

The bootstrapping information required for onboarding the device is made available as needed. For Wi-Fi Easy Connect, the bootstrapping information is the Device Provisioning Protocol (DPP) uniform resource identifier (URI) (which contains the public key and

Yes

The device’s DPP URI is generated using the public/private key pair that was generated in the device’s secure element. This DPP URI is encoded in a QR code that is written to a Portable Network Graphics (PNG) file and may be transferred from a vendor cloud upon acquisition of the device.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

10

FINAL Demo ID

Capability

Description

Demonstrated? Explanation/Notes

optionally other information such as device serial number). Scenario 1: Trusted Network-Layer Onboarding S1.C1

Device Authentication

The onboarding mechanism authenticates the device’s identity.

Yes

DPP performs device authentication.

S1.C2

Device Authorization

The onboarding mechanism verifies that the device is authorized to onboard to the network.

Yes

When the device’s URI is found on the HPE cloud service, this verifies that the device is authorized to onboard to the network.

S1.C3

Network Authentication

The device can verify the network’s identity.

No

This could be supported by providing the IoT device with the DPP URI of the network, but the Aruba User Experience Insight (UXI) sensor used in this build lacks the user interface needed to do so.

S1.C4

Network Authorization

The device can verify that the network is authorized to take control of it.

Yes

The network that possesses the device’s public key is implicitly authorized to onboard the device by virtue of its knowledge of the device’s public key. While this is not cryptographic, it does provide a certain level of assurance that the “wrong” network doesn’t take control of the device.

S1.C5

Secure Local Credentialing

The onboarding mechanism securely provisions local network credentials to the device.

Yes

DPP provisions the device’s network credentials over an encrypted channel.

S1.C6

Secure Storage

The local network credentials are provisioned to secure hardware-backed storage on the device.

No

The bootstrapping credentials are stored in a Trusted Platform Module (TPM) 2.0 hardware

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

11

FINAL Demo ID

Capability

Description

Demonstrated? Explanation/Notes enclave, but the local network credentials are not

S1.C7

Network Selection

The onboarding mechanism provides the IoT device with the identifier of the network to which the device should onboard.

Yes

The network responds to device chirps.

S1.C8

Interoperability

The network-layer onboarding mechanism can onboard a minimum of two types of IoT devices (e.g., different device vendors and models).

Yes

IoT devices from Build 2 were successfully onboarded in Build 1.

Scenario 2: Trusted Application-Layer Onboarding S2.C1

Automatic Initiation of Streamlined Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after performing networklayer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been securely conveyed to the device during the network-layer onboarding process.

No

Not supported in this build.

S2.C2

Automatic Initiation of Independent Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after performing networklayer onboarding and connecting to the network. In this case,

Yes

Once onboarded, the UXI sensor automatically initiates application-layer onboarding to the UXI application.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

12

FINAL Demo ID

Capability

Description

Demonstrated? Explanation/Notes

the application-layer onboarding bootstrapping information has been pre-provisioned to the device by the device manufacturer or integrator (e.g., as part of an application that was installed on the device during the manufacturing process). S2.C3

Trusted Application- Layer Onboarding

The device and a trusted application service can establish an encrypted connection without exposing any information that must be protected to ensure the confidentiality of the connection. They can then use that secure association to exchange applicationlayer information.

Yes

Once onboarded, the UXI sensor establishes a secure connection with the UXI cloud, which provisions the sensor with its credentials for the UXI application. Later, the sensor uploads data to the UXI application securely.

Scenario 3: Re-Onboarding a Device S3.C1

Credential Deletion

The device’s network credential can be deleted.

Yes

Factory reset and manual credential removal were leveraged.

S3.C2

De-Credentialed Device Cannot Connect

After the device’s network credential has been deleted, the device is not able to connect to or communicate on the network securely.

Yes

Observed.

S3.C3

Re-Onboarding (network layer)

After the device’s network credential has been deleted, the network-layer onboarding mechanism can securely reprovision a network

Yes

Observed.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

13

FINAL Demo ID

Capability

Description

Demonstrated? Explanation/Notes

credential to the device, which the device can then use to connect to the network securely. S3.C4

Re-Onboarding (application layer)

After the device’s network and application-layer credentials have been deleted and the device has been re-onboarded at the network layer and reconnected to the network, the device can again perform trusted applicationlayer onboarding.

Yes

Observed.

Scenario 4: Ongoing Device Validation S4.C1

Device Attestation (initial)

The network-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C2

Device Attestation (application layer)

The application-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C3

Device Attestation (ongoing)

Successful device attestation is required prior to permitting the device to perform some operation (e.g., accessing a high-value resource).

No

Not supported in this build.

S4.C4

Local Network Segmentation (initial)

Upon connection, the IoT device is assigned to some local network segment in accordance

No

Not demonstrated in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

14

FINAL Demo ID

Capability

Description

Demonstrated? Explanation/Notes

with policy, which may include an assessment of its security posture. S4.C5

Behavioral Analysis

Device behavior is observed to determine whether the device meets the policy criteria required to be permitted to perform a given operation (e.g., to access a high-value resource or be placed on a given network segment).

No

Not supported in this build.

S4.C6

Local Network Segmentation (ongoing)

The IoT device can be reassigned to a different network segment based on ongoing assessments of its conformance to policy criteria.

No

Not supported in this build.

S4.C7

Periodic Device Reauthentication

After connection, the IoT device’s identity is periodically reauthenticated in order to maintain network access.

No

Not supported in this build.

S4.C8

Periodic Device Reauthorization

After connection, the IoT device’s authorization to access the network is periodically reconfirmed in order to maintain network access.

No

Not supported in this build.

Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle S5.C1

Trusted Firmware Updates

The device can download the most recent firmware update and verify its signature before it is installed.

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

15

FINAL Demo ID

Capability

Description

Demonstrated? Explanation/Notes

S5.C2

Credential Certificate Provisioning

The onboarding mechanism can interact with a certificate authority to sign a device’s X.509 certificate and provision it onto the device.

Yes

This capability has been successfully demonstrated with the SEALSQ INeS CA.

S5.C3

Credential Update

The device’s network credential can be updated after it expires.

No

Not demonstrated in this build.

S5.C4

Server Attestation

Successful server attestation is required prior to permitting the server to perform some operation on the device (e.g., prior to downloading and installing updates onto the device).

No

Not supported in this build.

S5.C5

Secure Integration with MUD

The network-layer No onboarding mechanism can convey necessary device communications intent information (e.g., the IoT device’s MUD URL) to the network in encrypted form, thereby securely binding this information to the device and ensuring its confidentiality and integrity.

Supported by DPP but not demonstrated because Build 1 is not integrated with MUD or any other device communications intent enforcement mechanism.

S5.C6

Lifecycle Management Establishment

The device has a No lifecycle management service and can automatically establish a secure association with it after performing network-layer onboarding and

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

16

FINAL Demo ID

Capability

Description

Demonstrated? Explanation/Notes

connecting to the network.

3.2 Build 2 Demonstration Results Table 3-2 lists the capabilities that were demonstrated by Build 2. Table 3-2 Build 2 Capabilities Demonstrated Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

Scenario 1: Trusted Network-Layer Onboarding S1.C1

Device Authentication

The onboarding mechanism authenticates the device’s identity.

Yes

DPP performs device authentication.

S1.C2

Device Authorization

The onboarding mechanism verifies that the device is authorized to onboard to the network.

Yes

Only devices that have been added/approved by the administrator are onboarded. When the device’s URI is found, the controller authorizes the device to join the network.

S1.C3

Network Authentication

The device can verify the network’s identity.

No

This could be supported by providing the IoT device with the network's DPP URI, but this is not currently implemented.

S1.C4

Network Authorization

The device can verify that the network is authorized to take control of it.

Yes

The network that possesses the device’s public key is implicitly authorized to onboard the device by virtue of its knowledge of the device’s public key. While this is not cryptographic, it does provide a certain level of assurance that the “wrong” network doesn’t take control of the device.

S1.C5

Secure Local Credentialing

The onboarding mechanism securely provisions local

Yes

DPP provisions the device’s network credentials over an encrypted channel.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

17

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

network credentials to the device. S1.C6

Secure Storage

The local network credentials are provisioned to secure hardware-backed storage on the device.

No

The IoT device does not have secure hardwarebacked storage.

S1.C7

Network Selection

The onboarding mechanism provides the IoT device with the identifier of the network to which the device should onboard.

Yes

Network responds to device chirps.

S1.C8

Interoperability

The network-layer onboarding mechanism can onboard a minimum of two types of IoT devices (e.g., different device vendors and models).

Yes

Build 2 was able to onboard the IoT devices from Build 1.

Scenario 2: Trusted Application-Layer Onboarding S2.C1

Automatic Initiation of Streamlined Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after performing networklayer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been securely conveyed to the device during the network-layer onboarding process.

Yes

This has been demonstrated with the OCF Iotivity [5] custom extension. Iotivity is an open-source software framework that implements OCF standards and enables seamless device-to-device connectivity.

S2.C2

Automatic Initiation of Independent

The device can automatically (i.e., with no manual intervention required) initiate

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

18

FINAL Demo ID

S2.C3

Capability

Description

Application-Layer Onboarding

trusted applicationlayer onboarding after performing networklayer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been pre-provisioned to the device by the device manufacturer or integrator (e.g., as part of an application that was installed on the device during the manufacturing process).

Trusted ApplicationLayer Onboarding

The device and a trusted application service can establish an encrypted connection without exposing any information that must be protected to ensure the confidentiality of the connection. They can then use that secure association to exchange applicationlayer information.

Demonstrated?

Explanation/Notes

Yes

Once the device is onboarded to the network using DPP, the credentials for the application-layer onboarding are sent over the secure channel and provisioned by the onboarding tool (OBT).

Scenario 3: Re-Onboarding a Device S3.C1

Credential Deletion

The device’s network credential can be deleted.

Yes

Supports factory reset.

S3.C2

De-Credentialed Device Cannot Connect

After the device’s network credential has been deleted, the device is not able to connect to or communicate on the network securely.

Yes

Observed.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

19

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S3.C3

Re-Onboarding (network layer)

After the device’s network credential has been deleted, the network-layer onboarding mechanism can security reprovision a network credential to the device, which the device can then use to connect to the network securely.

Yes

Observed.

S3.C4

Re-Onboarding (application layer)

After the device’s network and application-layer credentials have been deleted and the device has been re-onboarded at the network layer and reconnected to the network, the device can again perform trusted applicationlayer onboarding.

Yes

Observed.

Scenario 4: Ongoing Device Validation S4.C1

Device Attestation (initial)

The network-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C2

Device Attestation (application layer)

The application-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C3

Device Attestation (ongoing)

Successful device attestation is required prior to permitting the device to perform some operation (e.g.,

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

20

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

accessing a high-value resource). S4.C4

Local Network Segmentation (initial)

Upon connection, the IoT device is assigned to some local network segment in accordance with policy, which may include an assessment of its security posture.

Yes

When the device is connected to the network, the gateway places it in a restricted network segment based on policy.

S4.C5

Behavioral Analysis

Device behavior is observed to determine whether the device meets the policy criteria required to be permitted to perform a given operation (e.g., to access a high-value resource or be placed on a given network segment).

No

Not supported in this build.

S4.C6

Local Network Segmentation (ongoing)

The IoT device can be reassigned to a different network segment based on ongoing assessments of its conformance to policy criteria.

Yes

Device can be moved to new network segments programmatically. The policy to do this is not defined in this build.

S4.C7

Periodic Device Reauthentication

After connection, the IoT device’s identity is periodically reauthenticated in order to maintain network access.

No

Not supported in this build.

S4.C8

Periodic Device Reauthorization

After connection, the IoT device’s authorization to access the network is periodically reconfirmed in order to maintain network access.

No

Not supported in this build.

Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

21

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S5.C1

Trusted Firmware Updates

The device can download the most recent firmware update and verify its signature before it is installed.

No

Not supported in this build.

S5.C2

Credential Certificate Provisioning

The onboarding mechanism can interact with a certificate authority to sign a device’s X.509 certificate and provision it onto the device.

No

Not supported in this build.

S5.C3

Credential Update

The device’s network credential can be updated after it expires.

No

Not demonstrated in this build.

S5.C4

Server Attestation

Successful server attestation is required prior to permitting the server to perform some operation on the device (e.g., prior to downloading and installing updates onto the device).

No

Not supported in this build.

S5.C5

Secure Integration with MUD

The network-layer onboarding mechanism can convey necessary device communications intent information (e.g., the IoT device’s MUD URL) to the network in encrypted form, thereby securely binding this information to the device and ensuring its confidentiality and integrity.

No

Supported by DPP but not demonstrated because Build 2 is not integrated with MUD or any other device communications intent enforcement mechanism.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

22

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S5.C6

Lifecycle Management Establishment

The device has a lifecycle management service and can automatically establish a secure association with it after performing network-layer onboarding and connecting to the network.

No

Not supported in this build.

3.3 Build 3 Demonstration Results Table 3-3 lists the capabilities that were demonstrated by Build 3. Table 3-3 Build 3 Capabilities Demonstrated Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

Scenario 1: Trusted Network-Layer Onboarding S1.C1

Device Authentication

The onboarding mechanism authenticates the device’s identity.

Yes

The local domain registrar receives the voucher request.

S1.C2

Device Authorization

The onboarding mechanism verifies that the device is authorized to onboard to the network.

Yes

The registrar verifies that the device is from an authorized manufacturer.

S1.C3

Network Authentication

The device can verify the network’s identity.

Yes

Demonstrated by the voucher.

S1.C4

Network Authorization

The device can verify that the network is authorized to take control of it.

Yes

The registrar examines the new voucher and passes it to the device for onboarding.

S1.C5

Secure Local Credentialing

The onboarding mechanism securely provisions local network credentials to the device.

Yes

A local device identifier (LDevID) (i.e., the device’s network credential) [1] is provisioned to the device after the device authentication and authorization process.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

23

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S1.C6

Secure Storage

The local network credentials are provisioned to secure hardware-backed storage on the device.

No

Not demonstrated in this build.

S1.C7

Network Selection

The onboarding mechanism provides the IoT device with the identifier of the network to which the device should onboard.

No

Not demonstrated in this build.

S1.C8

Interoperability

The network-layer onboarding mechanism can onboard a minimum of two types of IoT devices (e.g., different device vendors and models).

No

Supported by BRSKI, but not demonstrated in this build.

Scenario 2: Trusted Application-Layer Onboarding S2.C1

Automatic Initiation of Streamlined Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after performing networklayer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been securely conveyed to the device during the network-layer onboarding process.

No

Not supported in this build.

S2.C2

Automatic Initiation of Independent Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

24

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

No

Not supported in this build.

performing networklayer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been pre-provisioned to the device by the device manufacturer or integrator (e.g., as part of an application that was installed on the device during the manufacturing process). S2.C3

Trusted Application-Layer Onboarding

The device and a trusted application service can establish an encrypted connection without exposing any information that must be protected to ensure the confidentiality of the connection. They can then use that secure association to exchange applicationlayer information.

Scenario 3: Re-Onboarding a Device S3.C1

Credential Deletion

The device’s network credential can be deleted.

Yes

Observed.

S3.C2

De-Credentialed Device Cannot Connect

After the device’s network credential has been deleted, the device is not able to connect to or communicate on the network securely.

Yes

Observed.

S3.C3

Re-Onboarding (network-layer)

After the device’s network credential has been deleted, the

Yes

Observed.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

25

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

network-layer onboarding mechanism can security reprovision a network credential to the device, which the device can then use to connect to the network securely. S3.C4

Re-Onboarding (application layer)

After the device’s No network credentials have been deleted and the device has been reonboarded at the network layer and reconnected to the network, the device can perform applicationlayer onboarding automatically.

Not supported in this build.

Scenario 4: Ongoing Device Validation S4.C1

Device Attestation (initial)

The network-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C2

Device Attestation (application layer)

The application-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C3

Device Attestation (ongoing)

Successful device No attestation is required prior to permitting the device to perform some operation (e.g., accessing a high-value resource).

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

26

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S4.C4

Local Network Segmentation (initial)

Upon connection, the IoT device is assigned to some local network segment in accordance with policy, which may include an assessment of its security posture.

No

Not supported in this build.

S4.C5

Behavioral Analysis

Device behavior is No observed to determine whether the device meets the policy criteria required to be permitted to perform a given operation (e.g., to access a high-value resource or be placed on a given network segment).

Not supported in this build.

S4.C6

Local Network Segmentation (ongoing)

The IoT device can be reassigned to a different network segment based on ongoing assessments of its conformance to policy criteria.

No

Not supported in this build.

S4.C7

Periodic Device Reauthentication

After connection, the IoT device’s identity is periodically reauthenticated in order to maintain network access.

No

Not supported in this build.

S4.C8

Periodic Device Reauthorization

After connection, the IoT device’s authorization to access the network is periodically reconfirmed in order to maintain network access.

No

Not supported in this build.

Scenario 5: Establish and Maintain Credential and Device Security Posture Throughout the Lifecycle S5.C1

Trusted Firmware Updates

The device can download the most recent firmware update

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

27

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

and verify its signature before it is installed. S5.C2

Credential Certificate Provisioning

The onboarding Yes mechanism can interact with a certificate authority to sign a device’s X.509 certificate and provision it onto the device.

A vendor-installed X.509 certificate and a vendor’s authorizing service use linklocal connectivity to provision device credentials.

S5.C3

Credential Update

The device’s network credential (e.g., its LDevID or X.509 certificate) can be updated after it expires.

Not demonstrated in this build.

S5.C4

Server Attestation

Successful server No attestation is required prior to permitting the server to perform some operation on the device (e.g., prior to downloading and installing updates onto the device).

Not supported in this build.

S5.C5

Secure Integration with MUD

The network-layer onboarding mechanism can convey necessary device communications intent information (e.g., the IoT device’s MUD URL) to the network in encrypted form, thereby securely binding this information to the device and ensuring its confidentiality and integrity.

No

Supported by BRSKI but not demonstrated because Build 3 is not integrated with MUD or any other device communications intent enforcement mechanism.

S5.C6

Lifecycle Management Establishment

The device has a lifecycle management service and can automatically establish a secure association

No

Not supported in this build.

No

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

28

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

with it after performing network-layer onboarding and connecting to the network.

3.4 Build 4 Demonstration Results Table 3-4 lists the capabilities that were demonstrated by Build 4. Table 3-4 Build 4 Capabilities Demonstrated Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

Scenario 1: Trusted Network-Layer Onboarding S1.C1

Device Authentication

The onboarding mechanism authenticates the device’s identity.

No

The build performs trusted application-layer onboarding only.

S1.C2

Device Authorization

The onboarding mechanism verifies that the device is authorized to onboard to the network.

No

The build performs trusted application-layer onboarding only.

S1.C3

Network Authentication

The device can verify the network’s identity.

No

The build performs trusted application-layer onboarding only.

S1.C4

Network Authorization

The device can verify that the network is authorized to take control of it.

No

The build performs trusted application-layer onboarding only.

S1.C5

Secure Local Credentialing

The onboarding mechanism securely provisions local network credentials to the device.

No

The build performs trusted application-layer onboarding only.

S1.C6

Secure Storage

The local network credentials are provisioned to secure hardwarebacked storage on the device.

Yes

The local network credentials are stored in the Silicon Labs Secure Vault on the Thunderboard.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

29

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S1.C7

Network Selection

The onboarding mechanism provides the IoT device with the identifier of the network to which the device should onboard.

No

The device generates a pre-shared key that is manually entered in the OpenThread Border Router [6].

S1.C8

Interoperability

The network-layer onboarding mechanism can onboard a minimum of two types of IoT devices (e.g., different device vendors and models).

No

Not supported in this build.

Scenario 2: Trusted Application-Layer Onboarding S2.C1

Automatic Initiation of Streamlined ApplicationLayer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after performing network-layer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been securely conveyed to the device during the network-layer onboarding process.

No

Not supported in this build.

S2.C2

Automatic Initiation of Independent Application-

The device can automatically (i.e., with no manual intervention required) initiate

Yes

Trusted application-layer onboarding using Kudelski keySTREAM is configured to proceed automatically pending

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

30

FINAL Demo ID

S2.C3

Capability

Description

Layer Onboarding

trusted applicationlayer onboarding after performing network-layer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been preprovisioned to the device by the device manufacturer or integrator (e.g., as part of an application that was installed on the device during the manufacturing process).

Trusted ApplicationLayer Onboarding

The device and a trusted application service can establish an encrypted connection without exposing any information that must be protected to ensure the confidentiality of the connection. They can then use that secure association to exchange application-layer information.

Demonstrated?

Explanation/Notes confirmation from a user (through the press of a button).

Yes

Application-Layer Onboarding via Kudelski keySTREAM GUI / AWS IoT Core and through the Silicon Labs Simplicity Studio Device Console

Scenario 3: Re-Onboarding a Device S3.C1

Credential Deletion

The device’s network credential can be deleted.

Yes

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

The device can be removed from the network via the Open Thread Border Router

31

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes GUI and cannot rejoin without entering a new pre-shared key.

S3.C2

De-Credentialed Device Cannot Connect

After the device’s network credential has been deleted, the device is not able to connect to or communicate on the network securely.

Yes

Observed.

S3.C3

Re-Onboarding (network layer)

After the device’s network credential has been deleted, the network-layer onboarding mechanism can security re-provision a network credential to the device, which the device can then use to connect to the network securely.

Yes

Observed.

S3.C4

Re-Onboarding (application layer)

After the device’s network and application-layer credentials have been deleted and the device has been re-onboarded at the network layer and reconnected to the network, the device can again perform trusted applicationlayer onboarding.

Yes

Observed.

Scenario 4: Ongoing Device Validation S4.C1

Device Attestation (initial)

The network-layer onboarding mechanism requires successful device attestation prior to permitting the

No

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

Not supported in this build.

32

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

device to be onboarded. S4.C2

Device Attestation (application layer)

The application-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C3

Device Attestation (ongoing)

Successful device attestation is required prior to permitting the device to perform some operation (e.g., accessing a high-value resource).

No

Not supported in this build.

S4.C4

Local Network Segmentation (initial)

Upon connection, the IoT device is assigned to some local network segment in accordance with policy, which may include an assessment of its security posture.

No

Not supported in this build.

S4.C5

Behavioral Analysis

Device behavior is observed to determine whether the device meets the policy criteria required to be permitted to perform a given operation (e.g., to access a high-value resource or be placed on a given network segment).

No

Not supported in this build.

S4.C6

Local Network Segmentation (ongoing)

The IoT device can be reassigned to a different network

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

33

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

segment based on ongoing assessments of its conformance to policy criteria. S4.C7

Periodic Device After connection, Reauthentication the IoT device’s identity is periodically reauthenticated in order to maintain network access.

No

Not supported in this build.

S4.C8

Periodic Device Reauthorization

No

Not supported in this build.

After connection, the IoT device’s authorization to access the network is periodically reconfirmed in order to maintain network access.

Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle S5.C1

Trusted Firmware Updates

The device can download the most recent firmware update and verify its signature before it is installed.

No

Not supported in this build.

S5.C2

Credential Certificate Provisioning

The onboarding mechanism can interact with a certificate authority to sign a device’s X.509 certificate and provision it onto the device.

No

Not supported in this build.

S5.C3

Credential Update

The device’s network credential can be updated after it expires.

No

Not supported in this build.

S5.C4

Server Attestation

Successful server attestation is required prior to permitting the

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

34

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

server to perform some operation on the device (e.g., prior to downloading and installing updates onto the device). S5.C5

Secure Integration with MUD

The network-layer onboarding mechanism can convey necessary device communications intent information (e.g., the IoT device’s MUD URL) to the network in encrypted form, thereby securely binding this information to the device and ensuring its confidentiality and integrity.

No

Not supported in this build.

S5.C6

Lifecycle Management Establishment

The device has a lifecycle management service and can automatically establish a secure association with it after performing network-layer onboarding and connecting to the network.

No

Not supported in this build.

3.5 Build 5 Demonstration Results Table 3-5 lists the capabilities that were demonstrated by Build 5.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

35

FINAL Table 3-5 Build 5 Capabilities Demonstrated Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

Scenario 0: Factory Provisioning S0.C1

Birth Credential Generation and Storage

The device’s birth credentials are generated within or generated and provisioned into secure storage on the IoT device. For BRSKI, the credential is an IDevID certificate.

Yes

Public/private key pair is generated within the secure element, and signed IDevID certificate is placed into the secure element.

S0.C2

Birth Credential Signing

The credential is signed by a trusted CA.

Yes

The IDevID certificate is signed by the Build 5 Manufacturer Provisioning Root (MPR).

S0.C3

Bootstrapping Information Availability

The bootstrapping information required for onboarding the device is made available as needed. For BRSKI, the bootstrapping information is the IDevID certificate provisioned into the device’s secure element.

Yes

The device’s IDevID certificate is generated using the public/private key pair that was generated in the device’s secure element. This IDevID certificate is presented to verify the device’s identity during network-layer onboarding.

S1.C1

Device Authentication

S1.C2

Device Authorization

Scenario 1: Trusted Network-Layer Onboarding The device is authenticated The onboarding Yes using its provisioned IDevID. mechanism authenticates the device’s identity. The device is implicitly The onboarding Yes granted authorization mechanism verifies during the onboarding that the device is process within the registrar authorized to onboard implementation. However, to the network. this authorization is contingent upon the device satisfying the policy

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

36

FINAL Demo ID

Capability

Description

Demonstrated?

S1.C3

Network Authentication

The device can verify the network’s identity.

Yes

S1.C4

Network Authorization

The device can verify that the network is authorized to take control of it.

Yes

S1.C5

Secure Local Credentialing

The onboarding mechanism securely provisions local network credentials to the device.

Yes

S1.C6

Secure Storage

The local network credentials are provisioned to secure hardware-backed storage on the device.

No

S1.C7

Network Selection

The onboarding mechanism provides the IoT device with the identifier of the network to which the device should onboard.

Yes

S1.C8

Interoperability

The network-layer onboarding mechanism can onboard a minimum of two types of IoT devices (e.g.,

Yes

Explanation/Notes requirements for onboarding. Demonstrated by the voucher(note: source of voucher is explained in S1.C4). The device authenticates to the network using EAP-TLS. The registrar gets a voucher from the MASA verifying that the network is authorized to onboard the device. The registrar then passes this voucher to the device so the device can verify that the network is authorized to onboard it. A local device identifier (LDevID) (i.e., the device’s network credential) [1] is provisioned to the device as the culmination of the network-layer onboarding process. The IDevID (birth credential) keys are generated with a TPM secure element. The EAP-TLS negotiation is configured to use keys from the secure element. The local network credentials (LDevID) are not scored in secure storage. The identifier of the network is passed back in the common name field of the LDevID X.509 certificate.

Supported by BRSKI over IEEE 802.11 [7], but not demonstrated in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

37

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

different device vendors and models). Scenario 2: Trusted Application-Layer Onboarding S2.C1

Automatic Initiation of Streamlined Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after performing networklayer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been securely conveyed to the device during the network-layer onboarding process.

No

Not supported in this build

S2.C2

Automatic Initiation of Independent Application-Layer Onboarding

The device can automatically (i.e., with no manual intervention required) initiate trusted applicationlayer onboarding after performing networklayer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been pre-provisioned to the device by the device manufacturer or integrator (e.g., as part of an application that was installed on the device during the manufacturing process).

Yes

The IoT device (pledge) can use its IDevID and the private key in the secure element to automatically establish a TLS connection to an application server using OpenSSL s_client. The manufacturer has preprovisioned the address of the application server for the device.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

38

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S2.C3

Trusted Application-Layer Onboarding

The device and a trusted application service can establish an encrypted connection without exposing any information that must be protected to ensure the confidentiality of the connection. They can then use that secure association to exchange applicationlayer information.

Yes

The IoT device (pledge) can use its IDevID and the private key in the secure element to automatically establish a TLS connection to an application server using OpenSSL s_client. The manufacturer has preprovisioned the address of the application server for the device.

Scenario 3: Re-Onboarding a Device S3.C1

Credential Deletion

The device’s network credential can be deleted.

Yes

S3.C2

De-Credentialed Device Cannot Connect

After the device’s network credential has been deleted, the device is not able to connect to or communicate on the network securely.

Yes

The device is removed from the Radius server by revoking its voucher. If the credential is removed from the registrar/radius server, the device will not connect. Certificate revocation through CRL is also implemented.

S3.C3

Re-Onboarding (network-layer)

After the device’s network credential has been deleted, the network-layer onboarding mechanism can securely reprovision a network credential to the device, which the device can then use to connect to the network securely.

Yes

Upon a voucher being revoked, the LDevID is invalidated. The pledge can then perform the onboarding process again with a newly generated LDevID.

S3.C4

Re-Onboarding (application layer)

After the device’s network credentials have been deleted and the device has been reonboarded at the

Yes

After re-establishing a network connection, application onboarding happens automatically.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

39

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

network layer and reconnected to the network, the device can perform applicationlayer onboarding automatically. Scenario 4: Ongoing Device Validation S4.C1

Device Attestation (initial)

The network-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C2

Device Attestation (application layer)

The application-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded.

No

Not supported in this build.

S4.C3

Device Attestation (ongoing)

Successful device No attestation is required prior to permitting the device to perform some operation (e.g., accessing a high-value resource).

Not supported in this build.

S4.C4

Local Network Segmentation (initial)

Upon connection, the IoT device is assigned to some local network segment in accordance with policy, which may include an assessment of its security posture.

No

Not supported in this build.

S4.C5

Behavioral Analysis

Device behavior is Yes observed to determine whether the device meets the policy criteria required to be permitted to perform a given operation (e.g., to access a high-value

Real-time network events are propagated from the gateway(s) to the policy engine. When suspicious behavior is identified (e.g., contact denylisted IP address), device network access is revoked.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

40

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

resource or be placed on a given network segment). S4.C6

Local Network Segmentation (ongoing)

The IoT device can be reassigned to a different network segment based on ongoing assessments of its conformance to policy criteria.

No

Not supported in this build.

S4.C7

Periodic Device Reauthentication

After connection, the IoT device’s identity is periodically reauthenticated in order to maintain network access.

No

Not supported in this build.

S4.C8

Periodic Device Reauthorization

After connection, the IoT device’s authorization to access the network is periodically reconfirmed in order to maintain network access.

Yes

The continuous assurance policy is checked periodically, every 30 seconds in the demo. The policy sets the requirements for a device to be authorized to have access to the network. If a device fails this check, its voucher is revoked, invalidating the device’s LDevID.

Scenario 5: Establish and Maintain Credential and Device Security Posture Throughout the Lifecycle S5.C1

Trusted Firmware Updates

The device can download the most recent firmware update and verify its signature before it is installed.

No

Not supported in this build.

S5.C2

Credential Certificate Provisioning

The onboarding Yes mechanism can interact with a certificate authority to sign a device’s X.509 certificate and provision it onto the device.

In the BRSKI flows, the onboarding process results in an LDevID (X.509) certificate being provisioned on the device after the trustworthiness checks have been completed. This LDevID certificate is signed by the Domain CA.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

41

FINAL Demo ID

Capability

Description

Demonstrated?

Explanation/Notes

S5.C3

Credential Update

The device’s network credential (e.g., its LDevID or X.509 certificate) can be updated after it expires.

Yes

Device will automatically generate a new LDevID and re-onboard if the LDevID expires.

S5.C4

Server Attestation

Successful server No attestation is required prior to permitting the server to perform some operation on the device (e.g., prior to downloading and installing updates onto the device).

Not supported in this build.

S5.C5

Secure Integration with MUD

The network-layer onboarding mechanism can convey necessary device communications intent information (e.g., the IoT device’s MUD URL) to the network in encrypted form, thereby securely binding this information to the device and ensuring its confidentiality and integrity.

Yes

The continuous assurance policy engine sporadically resolves the MUD document of each unique connected device using all information available. In this build, we use the D3DB method of resolution, which resolves using chained verifiable credentials; specifically, the MUD document is bound to the device ID using a simulated managed firmware service. This provides a verifiable credential binding a device identifier (IDevID) to a full MUD document.

S5.C6

Lifecycle Management Establishment

The device has a lifecycle management service and can automatically establish a secure association with it after performing network-layer onboarding and connecting to the network.

No

Not supported in this build.

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

42

FINAL

Appendix A

References

[1]

IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Std 802.1AR-2018 (Revision of IEEE Std 802.1AR-2009), 2 Aug. 2018, 73 pp. Available: https://ieeexplore.ieee.org/document/8423794

[2]

Wi-Fi Alliance, Wi-Fi Easy Connect™ Specification Version 3.0, 2022. Available: https://www.wi-fi.org/system/files/Wi-Fi_Easy_Connect_Specification_v3.0.pdf

[3]

M. Pritikin, M. Richardson, T.T.E. Eckert, M.H. Behringer, and K.W. Watsen, Bootstrapping Remote Secure Key Infrastructure (BRSKI), IETF Request for Comments (RFC) 8995, October 2021. Available: https://datatracker.ietf.org/doc/rfc8995/

[4]

E. Lear, R. Droms, and D. Romascanu, Manufacturer Usage Description Specification, IETF Request for Comments (RFC) 8520, March 2019. Available: https://tools.ietf.org/html/rfc8520

[5]

Open Connectivity Foundation (OCF) Iotivity: https://iotivity.org/

[6]

Thread 1.1.1 1 Specification, February 13, 2017.

[7]

O. Friel, E. Lear, M. Pritikin, and M. Richardson, BRSKI over IEEE 802.11, IETF Internet-Draft (Individual), July 2018. Available: https://datatracker.ietf.org/doc/draft-friel-brski-over802dot11/01/

Note: Thread v1.1.1 was used during the development of this project. Implementers are encouraged to use the latest version of Thread available at https://www.threadgroup.org/Resources#specifications

1

NIST SP 1800-36D: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

43

NIST SPECIAL PUBLICATION 1800-36E

Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management:

Enhancing Internet Protocol-Based IoT Device and Network Security Volume E: Risk and Compliance Management Michael Fagan Jeffrey Marron Murugiah Souppaya* Paul Watrobski*

Karen Kent

Susan Symington

Nick Allott Ashley Setter

Trusted Cyber Annex

National Cybersecurity Center of Excellence Information Technology Laboratory The MITRE Corporation McLean, Virginia

William Barker Stratvia LLC Largo, Maryland

NquiringMinds, Southampton, United Kingdom

Dan Harkins

Aruba, a Hewlett Packard Enterprise Company San Jose, California

Steve Clark

Brecht Wyseur

Kudelski IoT Cheseaux-sur-Lausanne, Switzerland

Mike Dow Steve Egerter

SEALSQ, a Subsidiary of WISeKey Geneva, Switzerland

Silicon Labs, Austin, Texas

Andy Dolan Kyle Haefner Craig Platt Darshak Thakore

Michael Richardson

Sandelman Software Works, Ontario, Canada

CableLabs, Louisville, Colorado

November 2025 FINAL

Retired NIST Author*

*Former NIST employee; all work for this publication was done while at NIST.

This publication is available free of charge from https://doi.org/10.6028/NIST.SP.1800-36

FINAL

DISCLAIMER Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.

National Institute of Standards and Technology Special Publication 1800-36E, Natl. Inst. Stand. Technol. Spec. Publ. 1800-36E, 23 pages, November 2025, CODEN: NSPUE2

FEEDBACK As a private-public partnership, we are always seeking feedback on our practice guides. We are particularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us at iot-onboarding@nist.gov. All comments are subject to release under the Freedom of Information Act.

National Cybersecurity Center of Excellence National Institute of Standards and Technology 100 Bureau Drive Mailstop 2002 Gaithersburg, MD 20899 Email: nccoe@nist.gov

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

ii

FINAL

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the creation of practical cybersecurity solutions for specific industries, as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners—from Fortune 50 market leaders to smaller companies specializing in information technology security—the NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the steps needed for another entity to re-create the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland. To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align with relevant standards and best practices, and provide users with the materials lists, configuration files, and other information they need to implement a similar approach. The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.

KEYWORDS application-layer onboarding; bootstrapping; Internet of Things (IoT); Manufacturer Usage Description (MUD); network-layer onboarding; onboarding; Wi-Fi Easy Connect.

ACKNOWLEDGMENTS We are grateful to the following individuals for their generous contributions of expertise and time. Name

Organization

Amogh Guruprasad Deshmukh

Aruba, a Hewlett Packard Enterprise company

Danny Jump

Aruba, a Hewlett Packard Enterprise company

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iii

FINAL

Name

Organization

Bart Brinkman

Cisco

Eliot Lear

Cisco

Peter Romness

Cisco

Tyler Baker

Foundries.io

George Grey

Foundries.io

David Griego

Foundries.io

Fabien Gremaud

Kudelski IoT

Faith Ryan

The MITRE Corporation

Toby Ealden

NquiringMinds

John Manslow

NquiringMinds

Antony McCaigue

NquiringMinds

Alexandru Mereacre

NquiringMinds

Loic Cavaille

NXP Semiconductors

Mihai Chelalau

NXP Semiconductors

Julien Delplancke

NXP Semiconductors

Anda-Alexandra Dorneanu

NXP Semiconductors

Todd Nuzum

NXP Semiconductors

Nicusor Penisoara

NXP Semiconductors

Laurentiu Tudor

NXP Semiconductors

Pedro Fuentes

SEALSQ, a subsidiary of WISeKey

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

iv

FINAL

Name

Organization

Gweltas Radenac

SEALSQ, a subsidiary of WISeKey

Kalvin Yang

SEALSQ, a subsidiary of WISeKey

Heather Flanagan

Spherical Cow Consulting

The Technology Partners/Collaborators who participated in this build submitted their capabilities in response to a notice in the Federal Register. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build this example solution. We worked with: Technology Collaborators Aruba, a Hewlett Packard Enterprise company CableLabs Cisco

Foundries.io Kudelski IoT NquiringMinds NXP Semiconductors

Open Connectivity Foundation (OCF) Sandelman Software Works SEALSQ, a subsidiary of WISeKey Silicon Labs

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

v

FINAL

DOCUMENT CONVENTIONS The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the publication and from which no deviation is permitted. The terms “should” and “should not” indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. The terms “may” and “need not” indicate a course of action permissible within the limits of the publication. The terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

PATENT DISCLOSURE NOTICE NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication. As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL. No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vi

FINAL

Contents 1 Introduction ........................................................................................ 1 1.1

How to Use This Guide .................................................................................................1

1.2

Typographic Conventions ............................................................................................3

2 Risks Addressed by Trusted Network-Layer Onboarding and Lifecycle Management ...................................................................................... 3 2.1

Risks to the Network ....................................................................................................4 2.1.1

Risks to the Network Due to Device Limitations .......................................................... 4

2.1.2

Risks to the Network Due to Use of Shared Network Credentials ...............................4

2.1.3

Risks to the Network Due to Insecure Network Credential Provisioning .....................4

2.1.4

Risks to the Network Due to Supply Chain Attacks ...................................................... 4

2.2

Risks to the Device .......................................................................................................5

2.3

Risks to Secure Lifecycle Management ........................................................................5

2.4

Limitations and Dependencies of Trusted Onboarding ................................................5

3 Mapping Use Cases, Approach, and Terminology ................................ 6 3.1

Use Cases ....................................................................... Error! Bookmark not defined.

3.2

Mapping Producers......................................................................................................8

3.3

Mapping Approach ......................................................................................................8 3.3.1

Mapping Terminology ................................................................................................... 8

3.3.2

Mapping Process ........................................................................................................... 9

4 Mappings .......................................................................................... 11 4.1

4.2

NIST CSF Subcategory Mappings ................................................................................11 4.1.1

Mappings Between Reference Design Functions and NIST CSF Subcategories ..........11

4.1.2

Mappings Between Specific Onboarding Protocols and NIST CSF Subcategories ......11

4.1.3

Mappings Between Specific Builds and NIST CSF Subcategories ................................12

NIST SP 800-53 Control Mappings .............................................................................13 4.2.1

Mappings Between Reference Design Functions and NIST SP 800-53 Controls.........13

4.2.2

Mappings Between Specific Onboarding Protocols and NIST SP 800-53 Controls .....14

4.2.3

Mappings Between Specific Builds and NIST SP 800-53 Controls ..............................14

Appendix A References ......................................................................... 16

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

vii

FINAL

1 Introduction In this project, the National Cybersecurity Center of Excellence (NCCoE) applies standards, recommended practices, and commercially available technology to demonstrate various mechanisms for trusted network-layer onboarding of IoT devices and lifecycle management of those devices. We show how to provision network credentials to IoT devices in a trusted manner and maintain a secure posture throughout the device lifecycle. This volume of the NIST Cybersecurity Practice Guide discusses risks addressed by the trusted IoT device network-layer onboarding and lifecycle management reference design. It also maps between cybersecurity functionality provided by logical components of the reference design and Subcategories in the NIST Cybersecurity Framework 2.0 (CSF) [1] and controls in NIST Special Publication (SP) 800-53, Security and Privacy Controls for Information Systems and Organizations [2]. (Note: The reference design is described in detail in NIST SP 1800-36B, Section 4.) Mappings are also provided between cybersecurity functionality provided by specific network-layer onboarding protocols (e.g., Wi-Fi Easy Connect and Bootstrapping Remote Secure Key Infrastructure [BRSKI]) and those same Subcategories and controls, as well as between cybersecurity functionality provided by builds of the reference design that have been implemented as part of this project and those same Subcategories and controls. (Note: the composition of the builds is described in detail in the appendices of NIST SP 1800-36B.) None of the mappings we provide is intended to be exhaustive; the mappings focus on the strongest relationships involving each reference design cybersecurity function in order to help organizations prioritize their work. The mappings help users understand how trusted IoT device network-layer onboarding and lifecycle management can help them achieve their cybersecurity goals in terms of CSF Subcategories and SP 800-53 controls. The mappings also help users understand how they can implement trusted onboarding and lifecycle management by identifying how trusted onboarding functionality is supported by the user’s existing implementations of CSF Subcategories and SP 800-53 controls.

1.1 How to Use This Guide This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design for implementing trusted IoT device network-layer onboarding and lifecycle management. It describes various example implementations of this reference design. Each of these implementations, known as builds, is standards-based and is designed to help provide assurance that networks are not put at risk as new IoT devices are added to them and help safeguard IoT devices from being taken over by unauthorized networks. The reference design described in this practice guide is modular and can be deployed in whole or in part, enabling organizations to incorporate trusted IoT device network-layer onboarding and lifecycle management into their legacy environments according to goals that they have prioritized based on risk, cost, and resources. This guide contains five volumes: 

NIST SP 1800-36A: Executive Summary – why we wrote this guide, the challenge we address, why it could be important to your organization, and our approach to solving this challenge

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

1

FINAL 

NIST SP 1800-36B: Approach, Architecture, and Security Characteristics – what we built and why



NIST SP 1800-36C: How-To Guides – instructions for building the example implementations, including all the security-relevant details that would allow you to replicate all or parts of this project



NIST SP 1800-36D: Functional Demonstrations – use cases that have been defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabilities, and the results of demonstrating these use cases with each of the example implementations



NIST SP 1800-36E: Risk and Compliance Management – risk analysis and mapping of trusted IoT device network-layer onboarding and lifecycle management security characteristics to cybersecurity standards and best practices (you are here)

Depending on your role in your organization, you might use this guide in different ways: Business decision makers, including chief information security, product security, and technology officers, will be interested in the Executive Summary, NIST SP 1800-36A, which describes the following topics: 

challenges that enterprises face in migrating to the use of trusted IoT device network-layer onboarding



example solutions built at the NCCoE



benefits of adopting the example solution

Technology, security, and privacy program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in NIST SP 1800-36B, which describes what we did and why. Also, Section 4 of NIST SP 1800-36E will be of particular interest. Section 4, Mappings, maps logical components of the general trusted IoT device network-layer onboarding and lifecycle management reference design to security characteristics listed in various cybersecurity standards and recommended practices documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity Framework) and Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53). You might share the Executive Summary, NIST SP 1800-36A, with your leadership team members to help them understand the importance of using standards-based trusted IoT device network-layer onboarding and lifecycle management implementations. IT professionals who want to implement similar solutions will find the whole practice guide useful. You can use the how-to portion of the guide, NIST SP 1800-36C, to replicate all or parts of the builds created in our lab. The how-to portion of the guide provides specific product installation, configuration, and integration instructions for implementing the example solution. We do not re-create the product manufacturers’ documentation, which is generally widely available. Rather, we show how we incorporated the products together in our environment to create an example solution. Also, you can use Functional Demonstrations, NIST SP 1800-36D, which provides the use cases defined to showcase trusted IoT device network-layer onboarding and lifecycle management security capabilities and the

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

2

FINAL results of demonstrating these use cases with each of the example implementations. Finally, NIST SP 1800-36E will help explain the security functionality that the components of each build provide. This guide assumes that IT professionals have experience implementing security products within the enterprise. While we have used a suite of commercial products to address this challenge, this guide does not endorse these particular products. Your organization can adopt this solution or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a trusted IoT device network-layer onboarding and lifecycle management solution. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. We hope you will seek products that are congruent with applicable standards and recommended practices. A NIST Cybersecurity Practice Guide does not describe “the” solution; it provides examples of solutions. We seek feedback on the publication’s contents and welcome your input. Please contribute your thoughts to iot-onboarding@nist.gov.

1.2 Typographic Conventions The following table presents typographic conventions used in this volume. Typeface/Symbol

Meaning

Example

Italics

file names and path names; references to documents that are not hyperlinks; new terms; and placeholders names of menus, options, command buttons, and fields command-line input, onscreen computer output, sample code examples, and status codes command-line user input contrasted with computer output link to other parts of the document, a web URL, or an email address

For language use and style guidance, see the NCCoE Style Guide.

Bold Monospace

Monospace Bold

blue text

Choose File > Edit. mkdir

service sshd start

All publications from NIST’s NCCoE are available at https://www.nccoe.nist.gov.

2 Risks Addressed by Trusted Network-Layer Onboarding and Lifecycle Management Historically, IoT devices have not tended to be onboarded to networks in a trusted manner. This has left networks open to the threat of having unauthorized devices connect to them. It has also left devices open to the threat of being onboarded to networks that are not authorized to control them.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

3

FINAL

2.1 Risks to the Network Unauthorized devices that are able to connect to a network pose many risks to that network. They may be able to send and receive data on that network, scan the network for vulnerabilities, eavesdrop on the communications of other devices, and attack other connected devices to exfiltrate or modify their data or to compromise those devices and co-opt them into service to launch distributed denial of service (DDoS) attacks.

2.1.1

Risks to the Network Due to Device Limitations

Many IoT devices are manufactured to be as inexpensive as possible, which sometimes means that the devices are not equipped with secure storage, cryptographic modules, unique authoritative birth credentials, or other features needed to enable the devices to be identified and authenticated. This can make it impossible for a network to determine if a device attempting to connect to it is the intended device. Lack of these features can also make it impossible to protect the confidentiality of a device’s network credentials, both during the provisioning process and after the credentials have been installed on the device. NIST IR 8228 Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks documents the cybersecurity and privacy capabilities lacking in some IoT devices and the implications of those deficiencies.

2.1.2

Risks to the Network Due to Use of Shared Network Credentials

If a network uses a single network password shared among all devices rather than providing each device with a unique network credential, the network will be vulnerable to having unauthorized devices connect to it if the shared network password falls into the wrong hands, which can happen relatively easily. It also means that the network will permit devices to connect to it simply because a device presents the correct shared password, regardless of the device’s type or identity or whether it has any legitimate reason to connect to the network.

2.1.3

Risks to the Network Due to Insecure Network Credential Provisioning

If devices are manually provisioned with their network credentials, the provisioning process is errorprone, cumbersome, and vulnerable to disclosing the device’s network credentials. The credentials are also vulnerable to unauthorized disclosure if the devices are provisioned automatically over Wi-Fi or some other interface that does not use an encrypted channel. If the network credentials are not provisioned in a trusted manner, they are vulnerable to disclosure not only the first time the device is onboarded to the network but also every time it is onboarded, which may occur many times during the device lifecycle. For example, the device may need to be re-onboarded periodically to change its credentials in accordance with security policy, or it may need to be re-onboarded due to a security breach, hardware repair, security update, or other reasons. Any insecure features of the onboarding process, therefore, will render the device and network vulnerable every time the device is onboarded.

2.1.4

Risks to the Network Due to Supply Chain Attacks

If a device is compromised while in the supply chain or at some other point prior to being onboarded, then even though the device may be onboarded in a trusted manner, it may still pose a threat to the network, its data, and all devices connected to it. If, on the other hand, the trusted network-layer

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

FINAL onboarding mechanism is integrated with a device attestation or supply chain management service that is capable of evaluating the integrity and provenance of the device and detecting that it has been compromised or may have been tampered with, the trusted network-layer onboarding mechanism could prevent such a compromised device from being onboarded and connected to the network. NIST 800-161 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations provides guidelines to organizations on identifying, assessing, and mitigating cybersecurity risks throughout the supply chain at all levels of their organizations.

2.2 Risks to the Device Although it is relatively easy for one network to masquerade as another, IoT devices often do not authenticate the identity of the networks to which they allow themselves to be onboarded and connected. Devices may be unwittingly tricked into onboarding and connecting to imposter networks that are not authorized to onboard them. This makes those devices vulnerable to being taken control of by those unauthorized networks, preventing them from connecting to and performing their intended function on their authorized network.

2.3 Risks to Secure Lifecycle Management Even if a device is authorized to connect to a network and the network is authorized to control the device, if the device has not been onboarded in a trusted manner, then other security-related operations that are performed after the device has connected to the network may not have as secure a foundation as they would if the device had been onboarded in a trusted manner. For example, if device communications intent enforcement is performed but the integrity and confidentiality of the communicated device intent information are not protected (as it would be by a trusted network-layer onboarding mechanism), then trust in the device communications intent enforcement mechanism may not be as robust as it could have been. Similarly, if application-layer onboarding is performed after the device connects, but the information needed to bootstrap the application-layer onboarding process did not have its integrity and confidentiality protected (as it would be by a trusted network-layer onboarding mechanism), then trust in the application-layer onboarding mechanism may not be as robust as it could have been. Lack of trust in the application-layer onboarding mechanism may, in turn, undermine trust in the device lifecycle management or other application-layer service that is invoked as part of the application-layer onboarding process.

2.4 Limitations and Dependencies of Trusted Onboarding While implementing trusted IoT device network-layer onboarding and lifecycle management addresses many risks, it also has limitations. Use of trusted network-layer onboarding is designed to enable IoT devices to be provisioned with unique local network credentials in a manner that preserves credential confidentiality. As part of the trusted network-layer onboarding process, the device and the network may mutually authenticate one another, thereby protecting the network from having unauthorized devices connect to it and the device from being taken over by an unauthorized network. However, if the network also enables devices that do not support the trusted network-layer onboarding solution to be provisioned with network credentials and connect to it using a different (untrusted) onboarding solution, the network and all devices on it will still be at risk from IoT devices that have been onboarded

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

5

FINAL using untrusted mechanisms. The devices onboarded using untrusted mechanisms will still be at risk of being taken over by networks that are not authorized to control them. The trusted network-layer onboarding solution leverages the device’s unique, authoritative birth credentials, which are provisioned to the device by the device manufacturer and must consist, at a minimum, of a unique device identity and a secret. The trustworthiness of the network-layer onboarding process and the network credentials that it provisions to the device depends on the uniqueness, integrity, and confidentiality of the device’s birth credentials, which, in many cases, depend on the device’s hardware root of trust. If the manufacturer does not ensure the device’s credentials are unique, the device's identity cannot be definitively authenticated. If the manufacturer cannot maintain the confidentiality of the secret that is part of the device credentials, the trustworthiness of the device authentication process will be undermined, and the channel over which the device’s credentials are provisioned will be vulnerable to eavesdropping. The trusted network-layer onboarding solution depends upon the trustworthiness of the device’s secure storage to ensure the device's confidentiality and network credentials. If the device’s secure storage is vulnerable, the trustworthiness of the network-layer onboarding process and the confidentiality of the device’s network credentials will be compromised. If the secure storage in which the device’s network credentials are stored is vulnerable, the network will be at risk of having unauthorized devices attach to it. If the trusted network-layer onboarding mechanism is integrated with additional security capabilities such as device attestation, device communications intent enforcement, application-layer onboarding, and device lifecycle management, it can further increase trust in both the IoT device and, by extension, the network to which the device connects, assuming that these additional security capabilities themselves are secure and robust. If these security capabilities are not implemented correctly, then integrating with them is of no additional value and may provide a false sense of security.

3 Mapping Use Cases, Approach, and Terminology A mapping indicates that one concept is related to another concept. The remainder of this volume describes the mappings between trusted IoT device network-layer onboarding and lifecycle management cybersecurity functions and the security characteristics enumerated in relevant cybersecurity documents. For this mapping, we used the supportive relationship mapping style defined in Section 4.2 of NIST Internal Report (IR) 8477, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings [3]. Each set of mappings involves one of the following types of trusted IoT device network-layer onboarding and lifecycle management cybersecurity functions: 

Cybersecurity functions performed by the reference design’s logical components (see NIST SP 1800-36B Section 4)



Cybersecurity functions provided by specific network-layer onboarding protocols (e.g., Wi-Fi Easy Connect and BRSKI)

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

6

FINAL 

Cybersecurity functions provided by builds of the reference design that have been implemented as part of this project

Each of the cybersecurity functions is mapped to the security characteristics concepts found in the following widely used cybersecurity guidance documents: 

Subcategories from the NIST Cybersecurity Framework (CSF) 1.1 [4], and The NIST Cybersecurity Framework 2.0 (CSF 2.0) [1] . The CSF identifies enterprise-level security outcomes. Stakeholders have identified these outcomes as helpful for managing cybersecurity risk, but organizations adopting the CSF need to determine how to achieve the outcomes. Executive Order (EO) 13800, Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure [5], made the CSF mandatory for federal government agencies, and other government agencies and sectors have also made the CSF mandatory.



Security controls from NIST SP 800-53r5 (Security and Privacy Controls for Information Systems and Organizations) [2]. NIST SP 800-53 identifies security controls that apply to systems on which those enterprises are reliant. Which SP 800-53 controls need to be employed depends on system functions and a risk assessment of the perceived impact of loss of system functionality or exposure of information from the system to unauthorized entities. In the case of systems owned by or operated on behalf of federal government enterprises, the risk assessment and applicable SP 800-53 controls are mandated under the Federal Information Security Modernization Act (FISMA) [6]. Many other governments and private sector organizations voluntarily employ the Risk Management Framework [7] and associated SP 800-53 controls.

3.1 Uses for Mappings of Build Functions to CSF 2.0 and SP 800-53 All of the elements in these mappings—the trusted IoT device network-layer onboarding and lifecycle management cybersecurity functions, cybersecurity functions provided by specific network-layer onboarding protocols, cybersecurity functions provided by specific builds, CSF Subcategories, and SP 800-53 controls—are concepts involving ways to reduce cybersecurity risk. There are two primary use cases for this mapping. They are not intended to be comprehensive but rather to capture the strongest relationships involving the trusted IoT device network-layer onboarding and lifecycle management cybersecurity functions. 1. Why should organizations implement trusted IoT device network-layer onboarding and lifecycle management? This use case identifies how implementing trusted IoT device network-layer onboarding and lifecycle management can support organizations in achieving CSF Subcategories and SP 800-53 controls. This helps communicate to an organization’s chief information security officer, security team, and senior management that expending resources to implement trusted IoT device network-layer onboarding and lifecycle management can also aid in fulfilling other security requirements. 2. How can organizations implement trusted IoT device network-layer onboarding and lifecycle management? This use case identifies how an organization’s existing implementations of CSF Subcategories and SP 800-53 controls can help support a trusted IoT device network-layer onboarding and lifecycle management implementation. An organization wanting to implement trusted IoT device network-layer onboarding and lifecycle management might first assess its current security capabilities so that it can plan how to add missing capabilities and enhance existing

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

7

FINAL capabilities. Organizations can leverage their existing security investments and prioritize future security technology deployment to address the gaps. These mappings are intended to be used by any organization interested in implementing trusted IoT device network-layer onboarding and lifecycle management or that has begun or completed an implementation.

3.2 Mapping Producers The NCCoE trusted IoT device network-layer onboarding and lifecycle management project team developed the mappings between the cybersecurity functions performed by the reference design’s logical components (see NIST SP 1800 36B Section 4) and the security characteristics in the cybersecurity documents. They also developed the mappings between the cybersecurity functions performed by the specific network-layer onboarding protocols (i.e., Wi-Fi Easy Connect and BRSKI) and the security characteristics in the cybersecurity documents. These mappings were developed with input and feedback from the collaborators who have contributed technology to the builds of the reference design. Collaborators for each build, in conjunction with the NCCoE trusted IoT device network-layer onboarding and lifecycle management project team, performed the mappings between the cybersecurity functions provided by their contributed technologies in each build and the security characteristics in the cybersecurity documents.

3.3 Mapping Approach In addition to performing general mappings between the reference design’s cybersecurity functions and various sets of security characteristics, as well as between specific network-layer onboarding protocol cybersecurity functions and various sets of security characteristics, the NCCoE asked the collaborators for each build to indicate the mapping between the cybersecurity functions their technology components provide in that build and the sets of security characteristics. Using the logical components in the reference design as the organizing principle for the initial mapping of cybersecurity functions to security characteristics and then providing onboarding protocol-specific mappings was intended to make it easier for collaborators to map their build-specific technology contributions. Using this approach, the build-specific technology mappings are instantiations of the project’s general reference design and protocol-specific mappings for each document.

3.3.1

Mapping Terminology

In this publication, we use the following relationship types from NIST IR 8477 [3] to describe how the functions in our reference design relate to the NIST reference documents. Note that the Supports relationship applies only to use case 1 in Section 3.1; the Is Supported By relationship applies only to use case 2. 

Supports: Trusted IoT device network-layer onboarding and lifecycle management function X supports security control/Subcategory/capability/requirement Y when X can be applied alone or in combination with one or more other functions to achieve Y in whole or in part.



Is Supported By: Trusted IoT device network-layer onboarding and lifecycle management function X is supported by security control/Subcategory/capability/requirement Y when Y can be

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

8

FINAL applied alone or in combination with one or more other security controls/Subcategories/capabilities/requirements to achieve X in whole or in part. Each Supports and Is Supported By relationship have one of the following properties assigned to it: 

Example of: The supporting concept X is one way (an example) of achieving the supported concept Y in whole or in part. However, Y could also be achieved without applying X.



Integral to: The supporting concept X is integral to and a component of the supported concept Y. X must be applied as part of achieving Y.



Precedes: The supporting concept X precedes the supported concept Y when X must be achieved before applying Y. In other words, X is a prerequisite for Y.

When determining whether a reference design function’s support for a given CSF Subcategory or SP 80053 control is integral to that support versus an example of that support, we do not consider how that function may, in general, be used to support the Subcategory, control, capability, or requirement. Rather, we consider only how that function is intended to support that Subcategory, control, capability, or requirement within the context of our reference design. Also, when determining whether a function is supported by a CSF Subcategory, SP 800-53 control, capability, etc., with the relationship property of precedes, we do not consider whether it is possible to apply the function without first achieving the Subcategory, control, capability, or requirement. Rather, we consider whether, according to our reference design, the Subcategory, control, capability, or requirement is to be achieved prior to applying that function.

3.3.2

Mapping Process

The process that the NCCoE used to create the mapping from the logical components of the reference design to the security characteristics of a given document was as follows: 1. Create a table that lists each of the logical components of the reference design in column 1. 2. Describe each logical component’s cybersecurity function in column 2. 3. Map each cybersecurity function to each of the security characteristics in the document to which the function is most strongly related, and list each of these security characteristics on different sub-rows within column 3. Begin each security characteristic entry with an underlined keyword that describes the mapping’s relationship type (i.e., Supports, Is Supported By). After the keyword indicating the relationship type, put parentheses around the underlined keyword describing the relationship’s property (i.e., Example of, Integral to, or Precedes). 4. In the fourth column, briefly explain why that relationship type and property apply to the mapping. 5. After completing the mapping table entries as described above for all the logical components in the reference design, examine the mapping in the other direction, i.e., starting with the security characteristics listed in the document and considering whether they have a relationship to the logical components’ cybersecurity functions in the reference design. In other words, step through each security characteristic in the document and determine if some logical component in the reference design has a strong relationship to that security characteristic. If so, add an

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

9

FINAL entry for that security characteristic mapping to the table's logical component row. By examining the mapping in both directions, security characteristic mappings are less likely to be overlooked or omitted. 6. Once these steps are complete, any rows in the table without mappings should be deleted. The NCCoE applied this mapping process separately for each reference document. None of the mappings is intended to be exhaustive; they all focus on the strongest relationships involving each cybersecurity function in order to help organizations prioritize their work. Mapping every possible relationship, no matter how tenuous, would create so many mappings that they would not have any value in prioritization.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

10

FINAL

4 Mappings The mappings are provided in the form of Excel files. Links to the mapping Excel files are organized in the remainder of this document as follows: 



Section 4.1 – NIST CSF 1.1 [4] and NIST CSF 2.0 [1] mappings. These include: o

Section 4.1.1 – Mappings between reference design functions and NIST CSF Subcategories

o

Section 4.1.2 – Mappings between specific onboarding protocol (i.e., Wi-Fi Easy Connect and BRSKI) functions and NIST CSF Subcategories

o

Section 4.1.3 – Mappings between specific build functions and NIST CSF Subcategories

Section 4.2 – NIST SP 800-53r5 [2] mappings. These include: o

Section 4.2.1 – Mappings between reference design functions and NIST SP 800-53r5 controls

o

Section 4.2.2 – Mappings between specific onboarding protocol (i.e., Wi-Fi Easy Connect and BRSKI) functions and NIST SP 800-53r5 controls

o

Section 4.2.3 – Mappings between specific build functions and NIST SP 800-53r5 controls

4.1 NIST CSF Subcategory Mappings This section provides links to mappings between various elements that provide trusted network-layer onboarding functionality and NIST CSF Subcategories.

4.1.1

Mappings Between Reference Design Functions and NIST CSF Subcategories

This Excel file provides mappings between the logical components of the reference design and the NIST CSF Subcategories. These mappings indicate how trusted IoT device network-layer onboarding and lifecycle management functions help support CSF Subcategories and vice versa. Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-Reference Arch” (first tab)

4.1.2

Mappings Between Specific Onboarding Protocols and NIST CSF Subcategories

This section provides mappings between the functionality provided by two network-layer onboarding protocols, Wi-Fi Easy Connect and BRSKI, and the NIST CSF Subcategories.

4.1.2.1 Mapping Between Wi-Fi Easy Connect and NIST CSF Subcategories This Excel file provides a mapping between the functionality provided by the Wi-Fi Easy Connect protocol and the NIST CSF Subcategories. These mappings indicate how Wi-Fi Easy Connect functionality helps support CSF Subcategories and vice versa.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

11

FINAL Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-Wi-Fi EasyCnct” (third tab)

4.1.2.2 Mapping Between BRSKI and NIST CSF Subcategories This Excel file provides a mapping between the functionality provided by BRSKI and the NIST CSF Subcategories. These mappings indicate how BRSKI functionality helps support CSF Subcategories and vice versa. Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-BRSKI” (second tab)

4.1.3

Mappings Between Specific Builds and NIST CSF Subcategories

This section provides mappings between the functionality provided by builds of the trusted IoT device network-layer onboarding and lifecycle management reference design implemented as part of this project and the NIST CSF Subcategories.

4.1.3.1 Mapping Between Build 1 and NIST CSF Subcategories Build 1 is an implementation of network-layer onboarding using the Wi-Fi Easy Connect protocol. Aruba/HPE provided the onboarding infrastructure and related technology components for Build 1. Aruba/HPE and CableLabs provided IoT devices that were onboarded using Build 1. The technologies used in Build 1 are detailed in Appendix C of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 1 components and CSF Subcategories. These mappings indicate how these components help support CSF Subcategories and vice versa. Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-B1” (fourth tab)

4.1.3.2 Mapping Between Build 2 and NIST CSF Subcategories Build 2 is an implementation of network-layer onboarding using the Wi-Fi Easy Connect protocol. CableLabs and OCF provided the onboarding infrastructure and related technology components for Build 2. CableLabs, OCF, and Aruba/HPE provided IoT devices that were onboarded using Build 2. The technologies used in Build 2 are detailed in Appendix D of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 2 components and CSF Subcategories. These mappings indicate how these components help support CSF Subcategories and vice versa. Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-B2” (fifth tab)

4.1.3.3 Mapping Between Build 3 and NIST CSF Subcategories Build 3 is an implementation of network-layer onboarding using BRSKI. Sandelman Software Works provided the onboarding infrastructure and related technology components for Build 3. The IoT device used to demonstrate onboarding in Build 3 was a pledge simulator provided by Sandelman. The technologies used in Build 3 are detailed in Appendix E of SP 1800-36B.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

12

FINAL This Excel file details the mapping between the functionality provided by Build 3 components and CSF Subcategories. These mappings indicate how these components help support CSF Subcategories and vice versa. Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-B3” (sixth tab)

4.1.3.4 Mapping Between Build 4 and NIST CSF Subcategories Build 4 is an implementation of network-layer connection to an OpenThread network using preprovisioned network credentials as well as independent application-layer onboarding using the Kudelski KeySTREAM service. Silicon Labs and Kudelski provided the network infrastructure and related technology components for Build 4. Silicon Labs provided the IoT device used to demonstrate onboarding in Build 4. The technologies used in Build 4 are detailed in Appendix F of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 4 components and CSF Subcategories. These mappings indicate how these components help support CSF Subcategories and vice versa. Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-B4” (seventh tab)

4.1.3.5 Mapping Between Build 5 and NIST CSF Subcategories Build 5 is an implementation of network-layer onboarding using BRSKI over Wi-Fi and demonstrates a continuous authorization service. NquiringMinds provided the network-layer onboarding infrastructure and related technology components for Build 5. NquiringMinds also provided the IoT devices used to demonstrate onboarding in Build 5. The technologies used in Build 5 are detailed in Appendix G of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 5 components and CSF Subcategories. These mappings indicate how these components help support CSF Subcategories and vice versa. Link to the Excel file called “CSF 1.1 and 2.0 Tables”, and to the tab called “CSF-to-B5” (eighth tab)

4.2 NIST SP 800-53 Control Mappings This section provides mappings between various elements that provide trusted network-layer onboarding functionality and NIST SP 800-53 controls.

4.2.1 Mappings Between Reference Design Functions and NIST SP 800-53 Controls This Excel file provides a mapping between the logical components of the reference design and NIST SP 800-53 security controls. These mappings indicate how trusted IoT device network-layer onboarding and lifecycle management functions help support NIST SP 800-53 controls. Because hundreds of NIST SP 80053 controls can help support these functions, we have limited use case 2 (see Section 3.1) mappings to those controls on which specified supporting controls directly depend (e.g., dependence of cryptographic protection on key management). Readers needing to determine how their trusted IoT device network-layer onboarding and lifecycle management implementations support RMF processes can refer to these mappings.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

13

FINAL Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-Reference Arch” (first tab)

4.2.2

Mappings Between Specific Onboarding Protocols and NIST SP 800-53 Controls

This section provides mappings between the functionality provided by specific network-layer onboarding protocols and the NIST SP 800-53 controls. Mappings are provided for both the Wi-Fi Easy Connect protocol and BRSKI.

4.2.2.1 Mapping Between Wi-Fi Easy Connect and NIST SP 800-53 Controls This Excel file provides a mapping between the functionality provided by the Wi-Fi Easy Connect protocol and the NIST SP 800-53 controls. These mappings indicate how Wi-Fi Easy Connect functions help support NIST SP 800-53 controls and vice versa. Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-Wi-Fi EasyCnct” (second tab)

4.2.2.2 Mapping Between BRSKI and NIST SP 800-53 Controls This Excel file provides a mapping between the functionality provided by BRSKI and the NIST SP 800-53 controls. These mappings indicate how BRSKI functions help support NIST SP 800-53 controls and vice versa. Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-BRSKI” (third tab)

4.2.3

Mappings Between Specific Builds and NIST SP 800-53 Controls

This section provides mappings between the functionality provided by builds of the trusted IoT device network-layer onboarding and lifecycle management reference design that were implemented as part of this project and the NIST SP 800-53 controls.

4.2.3.1 Mapping Between Build 1 and NIST SP 800-53 Controls Build 1 is an implementation of network-layer onboarding that uses the Wi-Fi Easy Connect protocol. Aruba/HPE provided the onboarding infrastructure and related technology components for Build 1. Aruba/HPE and CableLabs provided the IoT devices that were onboarded using Build 1. The technologies used in Build 1 are detailed in Appendix C of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 1 components and SP 800-53 controls. These mappings indicate how these components help support SP 800-53 controls and vice versa. Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-B1” (fourth tab)

4.2.3.2 Mapping Between Build 2 and NIST SP 800-53 Controls Build 2 is an implementation of network-layer onboarding that uses the Wi-Fi Easy Connect protocol. CableLabs and OCF provided the onboarding infrastructure and related technology components for Build 2. CableLabs, OCF, and Aruba/HPE provided the IoT devices that were onboarded using Build 2. The technologies used in Build 1 are detailed in Appendix D of SP 1800-36B. NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

14

FINAL This Excel file details the mapping between the functionality provided by Build 2 components and SP 800-53 controls. These mappings indicate how these components help support SP 800-53 controls and vice versa. Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-B2” (fifth tab)

4.2.3.3 Mapping Between Build 3 and NIST SP 800-53 Controls Build 3 is an implementation of network-layer onboarding that uses BRSKI. Sandelman Software Works provided the onboarding infrastructure and related technology components for Build 3. Sandelman also provided the IoT device, a pledge simulator, that was used to demonstrate onboarding in Build 3. The technologies used in Build 3 are detailed in Appendix E of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 3 components and SP 800-53 controls. These mappings indicate how these components help support SP 800-53 controls and vice versa. Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-B3” (sixth tab)

4.2.3.4 Mapping Between Build 4 and NIST SP 800-53 Controls Build 4 is an implementation of network-layer connection to an OpenThread network using preprovisioned network credentials as well as independent application-layer onboarding using the Kudelski KeySTREAM service. Silicon Labs and Kudelski provided the network infrastructure and related technology components for Build 4. Silicon Labs provided the IoT device used to demonstrate onboarding in Build 4. The technologies used in Build 4 are detailed in Appendix F of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 4 components and SP 800-53 controls. These mappings indicate how these components help support SP 800-53 controls and vice versa. Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-B4” (seventh tab)

4.2.3.5 Mapping Between Build 5 and NIST SP 800-53 Controls Build 5 is an implementation of network-layer onboarding using BRSKI over Wi-Fi, as well as demonstration of a continuous authorization service. NquiringMinds provided the network-layer onboarding infrastructure and related technology components for Build 5. NquiringMinds also provided the IoT devices that were used to demonstrate onboarding in Build 5. The technologies used in Build 5 are detailed in Appendix G of SP 1800-36B. This Excel file details the mapping between the functionality provided by Build 5 components and SP 800-53 controls. These mappings indicate how these components help support SP 800-53 controls and vice versa. Link to the Excel file called “800-53 Tables”, and to the tab called “800-53-to-B5” (eighth tab)

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

15

FINAL

5 References [1]

National Institute of Standards and Technology (2024) The NIST Cybersecurity Framework (CSF) 2.0. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29

[2]

Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5. Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

[3]

Scarfone KA, Souppaya MP, Fagan MJ (2024) Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) NIST IR 8477. https://doi.org/10.6028/NIST.IR.8477

[4]

National Institute of Standards and Technology (2018) Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 6. https://doi.org/10.6028/NIST.CSWP.6

[5]

Executive Order 13800 (2017) Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure. (The White House, Washington, DC), DCPD-201700327, May 11, 2017. https://www.govinfo.gov/app/details/DCPD-201700327

[6]

S.2521 - Federal Information Security Modernization Act of 2014, 113th Congress (2013-2014), Became Public Law No: 113-283, December 18, 2014. Available: https://www.congress.gov/bill/113th-congress/senate-bill/2521

[7]

Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2. https://doi.org/10.6028/NIST.SP.800-37r2

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

16

Related documents

• Cybersecurity in the Internet of Things (IoT): Challenges and Solutions#119087
• Security of IoT Application Layer Protocols: Challenges and Findings#200874
• Machine Learning-Based Intrusion Detection Methods in IoT Systems: A Comprehensive Review#339537
• Empowering IoT Security: On-Device Intrusion Detection in Resource Constrained Devices#180587
• 17.3. The Eu-IoT Skills Framework#1966