The Internet of Things on AWS – Official Blog
How to manage AWS IoT Greengrass core device certificates
Introduction
We’re very pleased to introduce the Certificate Rotator component for AWS IoT Greengrass, a new component in the Greengrass Software Catalog.
AWS IoT Greengrass brings the AWS cloud closer to edge devices to support applications that demand local data processing and low latency. The growing number of edge devices in consumer, enterprise, and industrial segments, raises questions about how to address security risks posed by IoT edge devices and device communication to and from the cloud. In Operational Technology (OT) environments with decades old Industrial Control Systems (ICS), which were not built with cybersecurity in mind, the edge device often plays the role of a gateway, guarding and interfacing with these less-capable systems.
AWS recommends a multilayered security approach to secure IoT solutions. To protect and encrypt data in transit from an IoT edge device to the cloud, AWS IoT Core supports Transport Layer Security (TLS)-based mutual authentication using X.509 certificates. Customers must provision a unique identity, including a unique private key and X.509 certificate, for each IoT edge device. Certificates are long-lived credentials, but you may need to renew the certificate during the lifetime of the device. Managing the device certificate lifecycle, including periodic rotation of the device certificate and private key, is one of the security best practices in the IoT Lens for the AWS Well-Architected Framework.
In this blog post, you will learn how to use the Certificate Rotator component and how to use AWS services to rotate AWS IoT Greengrass core device certificates and private keys. This solution is deployable as is, but is delivered as an open-source reference implementation that you can tailor to your needs.
Background
AWS IoT Greengrass is an IoT edge runtime and cloud service that helps you to build, deploy, and manage intelligent IoT device software. It provides you with pre-built components for common capabilities, such as local/cloud MQTT messaging, support for local edge processing including Machine Learning (ML) inference, logging and monitoring, out-of-the-box integration with AWS services, and local data aggregation, filtering, and transmission to cloud targets. Once development is complete, you can seamlessly deploy and remotely manage device software on millions of devices.
An AWS IoT Greengrass core device uses its device certificate and private key to authenticate and connect to AWS IoT Core. An AWS IoT policy authorizes access to the AWS IoT Core and AWS IoT Greengrass data planes. When the core device is authorized, AWS IoT Greengrass components can send and receive MQTT messages to and from AWS IoT Core using inter-process communication, without needing additional or independent authentication or authorization with AWS IoT Core. To obtain authorized access to non-IoT AWS services, AWS IoT Greengrass uses the Token Exchange Service and the AWS IoT Core credential provider to exchange the X.509 device certificate for time-limited AWS credentials. These time-limited credentials are authorized to perform the actions defined in the AWS IoT Greengrass core device role (also known as the token exchange role).
Therefore, the X.509 device certificate and private key are the foundation of an AWS IoT Greengrass core device’s identity and authentication. It is your responsibility to rotate the device certificate and private key based on your operational needs. To guide you in this implementation, AWS offers a device certificate rotation blog, an IoT Jumpstart workshop and the Connected Device Framework (CDF) Certificate Vendor module. These are documented rotation procedures and provide a partial implementation reference.
For many AWS IoT device types, it’s challenging to offer a full end-to-end device certificate rotation reference implementation because the device software is heavily dependent on the device hardware. In particular, certificate and private key storage and APIs are strongly influenced by the hardware and the Hardware Abstraction Layer (HAL). However, AWS IoT Greengrass standardizes the certificate and private key storage through the AWS IoT Greengrass Core software installation configuration. The location of the certificate and private key are defined by the certificateFilePath and privateKeyPath configuration parameters. Accordingly, a deployable end-to-end certificate rotation reference implementation can be delivered.
Solution overview
The Certificate Rotator component is a solution consisting of two parts: an AWS IoT Greengrass component named aws.greengrass.labs.CertificateRotator that delivers the device part of the contract and an AWS Cloud Development Kit (CDK) stack that delivers the companion cloud backend. The cloud backend is principally comprised of three Lambda functions, three AWS IoT Core rules, an AWS IoT custom job template named AWSLabsCertificateRotator, and an Amazon Simple Notification Service (SNS) topic. Certificates are issued by either AWS IoT Core or by AWS Private Certificate Authority (CA).
As indicated, the Certificate Rotator component and cloud backend communicate using MQTT. An AWS IoT Job defines a set of remote operations that can be sent to and run on one or more devices. The cloud application initiates a certificate and private key rotation by creating an AWS IoT Job using the custom job template. Invocation conditions and business logic for the job creation are left to the customer or application developer. In other words, this solution provides the means of rotating a device certificate and private key without dictating when or why it should be done. Example invocation conditions include AWS IoT Device Defender Audit checks or Detect anomalies, a regular cadence, or a new compliance requirement that demands a different private key algorithm.
The SNS topic is used to notify users of any certificate rotation failures. Customers can take advantage of the flexibility of SNS subscriptions to implement failure handling and recovery that’s appropriate for their business.
Major characteristics of the solution include:
- It can rotate credentials that are either stored as files on disk or as PKCS#11 objects in a Hardware Security Module (HSM). It’s your responsibility to choose the storage type, appropriate for your security posture. AWS recommends using an HSM to protect these credentials.
- The cloud backend can issue device certificates using either AWS IoT Core or AWS Private CA, selected by CDK context variables during solution deployment. Selecting AWS Private CA allows you to use your own CA and to control certificate expiry dates.
- The certificate rotation process is encapsulated in an AWS IoT Job, created from the supplied job template. This means you can take advantage of the advanced capabilities of jobs, such as job configurations and handling of devices with intermittent connectivity, to manage the credentials of your device fleet at scale.
- The component can be deployed to core devices that are either Linux or Windows. The only limitation is that the component assumes that AWS IoT Greengrass is installed as a system service.
- You have the flexibility to decide when to rotate certificates based on your use case, risk assessment and security strategy, and the renewal can be automatic to reduce any potential access disruption due to manual rotation.
- The solution is resilient to perturbation and provides notifications to users using SNS.
Solution deployment
Detailed deployment instructions and prerequisites are contained in the Certificate Rotator repository and in the “Certificate Rotator for AWS IoT Greengrass” video. You need to deploy the solution in each AWS account and/or region where you are running an IoT/IIoT workload. Deployment has two parts: deploying the cloud backend CDK application, and building, publishing and deploying the AWS IoT Greengrass component.
Rotating device certificates
With the component and cloud backend deployed, a certificate rotation can be performed simply by creating a job using the AWSLabsCertificateRotator job template. This job creation can be achieved in several ways, including:
Solution customization and testability
Although the solution is delivered in deployable form, you may wish to modify it, tailoring it for your use case. The component and cloud backend are delivered with:
- An extensive unit test suite, with 100% line and branch coverage.
- An extensive automated integration test suite, that tests certificate rotation against a user-defined thing group of AWS IoT Greengrass core devices.
- A CI/CD pipeline for development environments, that automates the build, publish and deployment of both the component and the cloud backend, and also runs the full suite of unit and integration tests for automated regression testing.
Conclusion
AWS recommends a multilayered security approach to secure IoT solutions, including the use of strong identities, least privileged access, monitoring of device health and anomalies, secure connections to devices to fix issues, and applying updates to keep devices up to date and healthy. When you use X.509 certificates for digital identity and authentication, you may need to rotate the certificate and private key based on device health and business context.
You can use AWS IoT Device Defender to audit when device certificates are expiring, check device certificate key quality and other certificate best practices which can act as an invocation condition on when to rotate IoT edge certificates and private keys. Although shorter certificate validity periods require more involvement, with this AWS IoT Greengrass Certificate Rotator component, AWS IoT makes rotation of IoT edge device certificates and private keys easier to perform and moreover, helps you improve your IoT system’s security posture.
Learn more
About the Authors
Greg Breen is a Senior IoT Specialist Solutions Architect at Amazon Web Services. Based in Australia, he helps customers throughout Asia Pacific to build their IoT solutions. With deep experience in embedded systems, he has a particular interest in assisting product development teams to bring their devices to market. |
Ryan Dsouza is a Principal Solutions Architect for IoT at AWS. Based in New York City, Ryan helps customers design, develop, and operate more secure, scalable, and innovative solutions using the breadth and depth of AWS capabilities to deliver measurable business outcomes. Ryan has over 25 years of experience in digital platforms, smart manufacturing, energy management, building and industrial automation, and OT/IIoT security across a diverse range of industries. Before AWS, Ryan worked for Accenture, SIEMENS, General Electric, IBM, and AECOM, serving customers for their digital transformation initiatives. |