Tag Archives: Arduino IoT Cloud

Arduino Security Primer

via Arduino Blog

SSL/TLS stack and HW secure element

At Arduino, we are hard at work to keep improving the security of our hardware and software products, and we would like to run you through how our IoT Cloud service works.

The Arduino IoT Cloud‘s security is based on three key elements:

  • The open-source library ArduinoBearSSL for implementing TLS protocol on Arduino boards;
  • A hardware secure element (Microchip ATECCX08A) to guarantee authenticity and confidentiality during communication;
  • A device certificate provisioning process to allow client authentication during MQTT sessions.

ArduinoBearSSL

In the past, it has been challenging to create a complete SSL/TLS library implementation on embedded (constrained) devices with very limited resources. 

An Arduino MKR WiFi 1010, for instance, only has 32KB of RAM while the standard SSL/TLS protocol implementations were designed for more powerful devices with ~256MB of RAM.

As of today, a lot of embedded devices still do not properly implement the full SSL/TLS stack and fail to implement good security because they misuse or strip functionalities from the library, e.g. we found out that a lot of off-brand boards use code that does not actually validate the server’s certificate, making them an easy target for server impersonation and man-in-the-middle attacks.

Security is paramount to us, and we do not want to make compromises in this regard when it comes to our offering in both hardware and software. We are therefore always looking at “safe by default” settings and implementations. 

Particularly in the IoT era, operating without specific security measures in place puts customers and their data at risk.

This is why we wanted to make sure the security standards adopted nowadays in high-performance settings are ported to microcontrollers (MCUs) and embedded devices.

Back in 2017, while looking at different SSL/TLS libraries supporting TLS 1.2 and modern cryptography (something that could work with very little RAM/ROM footprint, have no OS dependency, and be compatible with the embedded C world), we decided to give BearSSL a try.

BearSSL: What is it?

BearSSL provides an implementation of the SSL/TLS protocol (RFC 5246) written in C and developed by Thomas Pornin.

Optimized for constrained devices, BearSSL aims at small code footprint and low RAM usage. As per its guiding rules, it tries to find a reasonable trade-off between several partly conflicting goals:

  • Security: defaults should be robust and using patently insecure algorithms or protocols should be made difficult in the API, or simply not possible;
  • Interoperability with existing SSL/TLS servers; 
  • Allowing lightweight algorithms for CPU-challenged platforms; 
  • Be extensible with strong and efficient implementations on big systems where code footprint is less important.

BearSSL and Arduino

Our development team picked it as an excellent starting point for us to make BearSSL fit in our Arduino boards focusing on both security and performance.

The firmware developers team worked hard on porting BearSSL to Arduino bundling it together as a very nice and open-source library: ArduinoBearSSL.

Because the computational effort of performing a crypto algorithm is high, we decided to offload part of this task to hardware, using a secure element (we often call it a “cypto chip”). Its advantages are:

  • Making the computation of cryptography operations faster;
  • You are not forced to use all the available RAM of your device for these demanding tasks;
  • Allows storing private keys securely (more on this later);
  • It provides a true random number generator (TRNG).

How does the TLS protocol work?

TLS uses both asymmetric and symmetric encryption. Asymmetric encryption is used during the TLS handshake between the client and the server to exchange the shared session key for communication encryption. The algorithms commonly used in this phase are based on Rivest-Shamir-Adleman (RSA) or Diffie-Hellman algorithms. 

TLS 1.2 Handshake flow

After the TLS handshake, the client and the server both have a session key for symmetric encryption (e.g. algorithms AES 128 or AES 256).

The TLS protocol is an important part of our IoT Cloud security model because it guarantees an encrypted communication between the IoT devices and our servers.

The secure element

In order to save memory and improve security, our development team has chosen to introduce a hardware secure element to offload part of the cryptography algorithms computational load, as well as to generate, store, and manage certificates. For this reason, on the Arduino MKR family, Arduino Nano 33 IoT and Arduino Uno WiFi Rev2, you will find the secure element ATECC508A or ATECC608A manufactured by Microchip.

How do we use the secure element?

A secure element is an advanced hardware component able to perform cryptographic functions, we have decided to implement it on our boards to guarantee two fundamental security properties in the IoT communication: 

  • Authenticity: You can trust who you are communicating with;
  • Confidentiality: You can be sure the communication is private.

Moreover, the secure element is used during the provisioning process to configure the Arduino board for Arduino IoT Cloud. In order to connect to the Arduino IoT Cloud MQTT broker, our boards don’t use a standard credentials authentication (username/password pair). We rather opted for implementing a higher-level authentication, known as client certificate authentication.

How does the Arduino provisioning work?

The whole process is possible thanks to an API, which exposes an endpoint a client can interact with.

As you can see in the diagram below, first the Client requests to register a new device on Arduino IoT Cloud via the API, to which the server (API) returns a UUID (Universally Unique IDentifier). At this point, the user can upload the sketch Provisioning.ino to the target board. This code is responsible for multiple tasks:

  • Generating a private key using the ATECCX08A, and store it in a secure slot that can be only read by the secure element;
  • Generating a CSR (Certificate Signing Request) using the device UUID as Common Name (CN) and the generated private key to sign it;
  • Storing the certificate signed by Arduino acting as the authority.

After the CSR generation, the user sends it via the API to the server and the server returns a certificate signed by Arduino. This certificate is stored, in a compressed format, in a slot of the secure element (usually in slot 10) and it is used to authenticate the device to the Arduino IoT Cloud.

Remote working with Arduino: Alexa and the Arduino IoT Cloud

via Arduino Blog

We’ll certainly remember this year, with many of us learning how to adapt and live a safe life-style under the pandemic. As many countries begin to initiate a relaxation of restrictions and we are starting to be able to leave our houses, arrange shifts to get into work (still observing safety measures), we might find ourselves with different needs.

Perhaps we got used to having the TV on more often than usual, letting the voices of shows we don’t really watch keep us company in the background while home alone… working. Maybe we just like to have a corner light up with colors which soothe our moods, or give a fancy background tint to a remote disco party as we dress with big shades and wigs.

Many of these things can easily be automated using Alexa and Arduino IoT Cloud, so when we (finally) leave the house and are not sure if the TV is still on, or if our living room corner is still purple! we can simply ask “Alexa, turn the TV off” or “Alexa, turn the living room off” and a series of smart devices and software will take care of it for us.

Let’s give it a shot…

Getting the Alexa skill: Learn how to use Arduino IoT Cloud and Amazon Alexa to interact with your sensors.

Using the MKR RGB shield with Alexa: Learn how to control your MKR RGB Shield using Arduino IoT Cloud and Amazon Alexa.

Controlling TV with Alexa: Learn how to create a voice-controlled device with Alexa and Arduino IoT Cloud in 7 minutes

Create a voice-controlled device with Alexa: Learn how to turn on/off your lamp, and change the color and luminosity of the light in seven minutes!

Want to get started with the Arduino IoT Cloud? Check out this article!

Remote working with Arduino: An intro to the Arduino IoT Cloud

via Arduino Blog

As more of us have restrictions on leaving our houses, the time we take away from physical social interactions (namely “going out”) is put back into extracurricular activities. We catch up with old hobbies and bring new ones into our lives.

While baking is proving to be one of the most popular ones, testified by an unprecedented shortage of yeast and flour on supermarket shelves, there are activities for which gathering supplies hasn’t changed much.

We’d like to get you into learning something about the Internet of Things using our platform and boards.

If you’re reading this, you probably have some of the tools you need for the following tutorials, while the ones you don’t have are a click away.

We’ll start by learning how to connect a board to the Arduino IoT Cloud and in a matter of minutes have your environment data in an easy to read dashboard.

In the next installment, we’ll see how you can remotely control a device from a dashboard and maybe water your office plant while you’re stuck at home!

Getting started with the Arduino IoT  Cloud

A basic guide on how to set up the IoT cloud can be found here.

Using the MKR ENV Shield with the Arduino IoT Cloud

This tutorial walks through displaying values from an environmental shield on the IoT dashboard.

How to deal with API clients, the lazy way — from code generation to release management

via Arduino Blog

This post is from Massimiliano Pippi, Senior Software Engineer at Arduino.

The Arduino IoT Cloud platform aims to make it very simple for anyone to develop and manage IoT applications and its REST API plays a key role in this search for simplicity. The IoT Cloud API at its core consists of a set of endpoints exposed by a backend service, but this alone is not enough to provide a full-fledge product to your users. What you need on top of your API service are:

  • Good documentation explaining how to use the service.
  • A number of plug-and-play API clients that can be used to abstract the API from different programming languages.

Both those features are difficult to maintain because they get outdated pretty easily as your API evolves but clients are particularly challenging: they’re written in different programming languages and for each of those you should provide idiomatic code that works and is distributed according to best practices defined by each language’s ecosystem.

Depending on how many languages you want to support, your engineering team might not have the resources needed to cover them all, and borrowing engineers from other teams just to release a specific client doesn’t scale much. 

Being in this exact situation, the IoT Cloud team at Arduino had no other choice than streamlining the entire process and automate as much as we could. This article describes how we provide documentation and clients for the IoT Cloud API.

Clients generation workflow

When the API changes, a number of steps must be taken in order to ship an updated version of the clients, as it’s summarized in the following drawing. 

As you can see, what happens after an engineer releases an updated version of the API essentially boils down to the following macro steps:

1. Fresh code is generated for each supported client.
2. A new version of the client is released to the public.

The generation process

Part 1: API definition

Every endpoint provided by the IoT Cloud API is listed within a Yaml file in OpenAPI v3 format, something like this (the full API spec is here):

/v2/things/{id}/sketch:
    delete:
      operationId: things_v2#deleteSketch
      parameters:
      - description: The id of the thing
        in: path
        name: id
        required: true
        schema:
          type: string
      responses:
        "200":
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ArduinoThing'
          description: OK
        "401":
          description: Unauthorized
        "404":
          description: Not Found

The format is designed to be human-readable, which is great because we start from a version automatically generated by our backend software that we manually fine-tune to get better results from the generation process. At this stage, you might need some help from the language experts in your team in order to perform some trial and error and determine how good the generated code is. Once you’ve found a configuration that works, operating the generator doesn’t require any specific skill, the reason why we were able to automate it.

Part 2: Code generation

To generate the API clients in different programming languages we support, along with API documentation we use a CLI tool called openapi-generator. The generator parses the OpenAPI definition file and produces a number of source code modules in a folder on the filesystem of your choice. If you have more than one client to generate, you will notice very soon how cumbersome the process can get: you might need to invoke openapi-generator multiple times, with different parameters, targeting different places in the filesystem, maybe different git repositories; when the generation step is done, you have to go through all the generated code, add it to version control, maybe tag, push to a remote… You get the gist. 

To streamline the process described above we use another CLI tool, called Apigentools, which wraps the execution of openapi-generator according to a configuration you can keep under version control. Once Apigentools is configured, it takes zero knowledge of the toolchain to generate the clients – literally anybody can do it, including an automated pipeline on a CI system.

Part 3: Automation

Whenever the API changes, the OpenAPI definition file hosted in a GitHub repository is updated accordingly, usually by one of the backend engineers of the team. A Pull Request is opened, reviewed and finally merged on the master branch. When the team is ready to generate a new version of the clients, we push a special git tag in semver format and a GitHub workflow immediately starts running Apigentools, using a configuration stored in the same repository. If you look at the main configuration file, you might notice for each language we want to generate clients for, there’s a parameter called ‘github_repo_name’: this is a killer feature of Apigentools that let us push the automation process beyond the original plan. Apigentools can output the generated code to a local git repository, adding the changes in a new branch that’s automatically created and pushed to a remote on GitHub.

The release process

To ease the release process and to better organize the code, each API client has its own repo: you’ll find Python code in https://github.com/arduino/iot-client-py, Go code in https://github.com/arduino/iot-client-go and so on and so forth. Once Apigentools finishes its run, you end up with new branches containing the latest updates pushed to each one of the clients’ repositories on GitHub. As the branch is pushed, another GitHub workflow starts (see the one from the Python client as an example) and opens a Pull Request, asking to merge the changes on the master branch. The maintainers of each client receive a Slack notification and are asked to review those Pull Requests – from now on, the process is mostly manual.

It doesn’t make much sense automate further, mainly for two reasons:

  1. Since each client has its own release mechanism: Python has to be packaged in a Wheel and pushed to PyPI, Javascript has to be pushed to NPM, for Golang a tag is enough, docs have to be made publicly accessible. 
  2. We want to be sure a human validates the code before it’s generally available through an official release.

Conclusions

We’ve been generating API clients for the IoT Cloud API like this for a few months, performing multiple releases for each supported programming language and we now have a good idea of the pros and cons of this approach.

On the bright side: 

  • The process is straightforward, easy to read, easy to understand.
  • The system requires very little knowledge to be operated.
  • The time between a change in the OpenAPI spec and a client release is within minutes.
  • We had an engineer working two weeks to set up the system and the feeling is that we’re close to paying off that investment if we didn’t already.

On the not-so-bright side: 

  • If operating the system is trivial, debugging the pipeline if something goes awry requires a high level of skill to deep dive into the tools described in this article.
  • If you stumble upon a weird bug on openapi-generator and the bug doesn’t get attention, contributing patches upstream might be extremely difficult because the codebase is complex.

Overall we’re happy with the results and we’ll keep building up features on top of the workflow described here. A big shoutout to the folks behind openapi-generator and Apigentools!

LoRa made easy: Connect your devices to the Arduino IoT Cloud

via Arduino Blog

An important new feature is now available in the Arduino IoT Cloud — full support for LoRa® devices!

LoRa® is one of our favorite emerging technologies for IoT because it enables long-range and low power transmission of data without using cellular or WiFi connections. It’s a very powerful and promising technology but it comes with its own complexity. In our pursuit to make IoT easier, we’ve already released a few products that enable anyone to build a LoRa® device (or a fleet of LoRa® devices!). Thanks to the Arduino MKR WAN 1310 board, combined with the Arduino Pro Gateway you can create your own LoRaWAN™ network. But we have decided to do more than that, and it’s time to release one more important piece….

The  Arduino IoT Cloud now provides an incredibly easy way to collect data sent by your LoRa® devices. With a few clicks, the IoT Cloud will generate a sketch template for the boards that you can adapt to read data from your sensors, pre-process it as you want, and then send it to the IoT Cloud. With a few more clicks (no coding required), you’ll be able to create a graphical dashboard that displays the collected data in real-time and lets users see their history through charts and other widgets. You will not need to worry about coding your own compression, serialization and queueing algorithm, as it will all be done under the hood in a smart way — you’ll be able to transmit multiple properties (more than five), pushing the boundary beyond the packet size limits of LoRaWAN™

This is our take on edge computing – you program the device to collect and prepare your data locally, and then we take care of shipping such data to a centralized place.

Such a simplified tool for data collection is already quite innovative, but we decided to take it an important step further. All the available solutions for LoRa® currently focus on collecting data, but they do not address it from the other way round i.e. sending data from a centralized application to the LoRa® device(s). Arduino IoT Cloud now lets you do this — you’ll be able to control actuators connected to your device by sending messages via LoRa®, with no coding needed.

Build and control your own LoRaWAN™ network with Arduino IoT Cloud, the Pro Gateway and the new improved MKR WAN 1310 board that features the latest low-power architecture to extend the battery life and enable the power consumption to go as low as 104uA.