With AWS Greengrass, you can bring local compute, messaging, data caching, sync, and machine-learning inference capabilities to edge devices. Join us in this session to learn about new features that extend the capabilities of AWS Greengrass devices.
Write AWS Lambda functions, run at the edge
Communicate securely with applications and services, locally and in the cloud
Extend AWS services from to edge devices
Run ML inference to make predictions based on local data
Access local resources (cameras, file system, specialized hardware) on edge devices
Perform actions, run analytics, cache data in intermittent connectivity scenarios
Change to images; choose a few to highlight
More visual; split into what is it & how does it work slides
>AWS IoT Greengrass supports messaging both between the AWS IoT Cloud and the GGC, and between the GGC and other local devices through an MQTT server.
>AWS IoT Greengrass uses X.509 certificates and AWS Identity and Access Management (IAM) roles to ensure that these communication channels are secure.
>Core device certificates, core root CA certificates, and device certificates are all present to authenticate devices. There is a private key associated with each device certificate (one for the core device and one for the MQTT server certificate).
For a message to be sent to the cloud, the AWS IoT Greengrass core uses its IoT cloud client certificate, the private key, and the root certificate authority to validate device identity during the TLS messaging handshake. This process verifies that both the IoT Cloud endpoint and AWS IoT Greengrass core device are who they say they are.
A similar handshake occurs with local devices. After finding the IP address of the device with an AWS IoT Greengrass SDK, that device will pass its device certificate and client ID to the AWS IoT Greengrass core for validation before confirming the connection is valid.
Today, we hear from many customers who have devices that are being used in unsecured real-world locations. For example, you might want to run Machine Learning on a video camera streaming information about customers waiting in line for a bus. You might want to put smart emergency responder equipment that tracks location in a vehicle. You might be interested in using temperature sensors to monitor energy use or equipment in an industrial equipment.
PROBLEM / SOLUTION
Today, we hear from many customers who have devices that are being used in unsecured real-world locations. For example, customers might want to process video and images of bus lines locally, then send the outcome of that analysis to a dashboard to monitor wait times at a large event. In this case, the AWS Protective Services team is using AWS IoT Greengrass cores on Logic Supply devices with Intel TPMs to aggregate video information is not physically secured and could be vulnerable to tampering or other security risks.
Our new Hardware Security Integration features allows customers like this one [Amazon Device Security] to secure the private keys on the devices used for encryption in a tamper-proof physical hardware element.
What is hardware security integration?
AWS IoT Greengrass Core integrates with PKCS#11-compatible hardware secure elements for storing AWS IoT Greengrass core private keys
PKCS#11 is a platform-independent API specification to interact with secure elements
Secure element vendor configure PKCS#11 libraries to integrate with AWS IoT Greengrass Core
If you’re a partner, we’re adding new tooling and qualification support for AWS IoT Greengrass and features like this one. You can see more about IoT device tester ????? [+screen shot if you can get it]
Every day, we talk to clients who are tackling complex IoT challenges. They might have a unique software solution, or they might be an OEM building a device that requires reliable hardware, or they could be a large manufacturer trying to get their production equipment connected to the cloud.
Increasingly, our clients are moving their applications to the cloud, with AWS as a key component of making their solution competitive and effective in their market.
Factory Automation + ML600/ML500 (champlain cable?)
Emergency Communications (Singlewire)
Building Automation + CL200
Image of "smart building" application. Ideally, we're able to illustrate data being sent from each of these applications, to the cloud. The idea being that each of these streams can be protected using Greenkey. As new devices are deployed, they're all authenticated using Greenkey to ensure authenticity.
Each of these data streams, being sent to and acted on in the cloud have a hardware component gathering the data, a Logic Supply gateway device (pictures of a bunch of CL200s around the various places they might be used?)
Each of these streams present a possible point of network vulnerability, so it's vital that they are all protected, using authentication provided by Greenkey.
Image of "smart building" application. Ideally, we're able to illustrate data being sent from each of these applications, to the cloud. The idea being that each of these streams can be protected using Greenkey. As new devices are deployed, they're all authenticated using Greenkey to ensure authenticity.
Each of these data streams, being sent to and acted on in the cloud have a hardware component gathering the data, a Logic Supply gateway device (pictures of a bunch of CL200s around the various places they might be used?)
Each of these streams present a possible point of network vulnerability, so it's vital that they are all protected, using authentication provided by Greenkey.
Today, AWS IoT Greengrass provides the benefits of isolation and security that come with running in a container environment.
All AWS Lambda functions, including system AWS Lambda functions, are run outside of the AWS IoT Greengrass container environment.
Can directly access local device resources.
With non-containerized mode, you no longer need to make kernel-level changes to run AWS IoT Greengrass. AWS IoT Greengrass won’t have overlays or other container-level information.
Note: At launch, it will not support ML inference or AWS IoT Greengrass connectors.
Hybrid mode allows you to run specific AWS Lambda functions that need access to the underlying OS or hardware to run outside of containers.
What is it?
Customers can assign new UID and GID information at the level of AWS Lambda, giving them the option to assign new permissions to individual AWS Lambda functions
How does it work?
Customers will be able to make isolation changes at the group level, and both isolation and permission changes at the level of AWS Lambda from the AWS IoT Greengrass console