The design is hierarchical with each mbed platform and shield communicating data from the sensor node to a web server that maintains a centralized log and dispatches notifications as necessary. The simplicity of this design enables rapid integration into any star-topology IoT network to provide security with the low overhead and cost provided by the ECDSA-P256 asymmetric-key and SHA-256 symmetric-key algorithms.
NOTE: Operating the MAXREFDES155# requires a separate purchase of a MAX32600MBED# mbed platform.
Refer to the Details tab for more information. Design files including; schematic, PCB files and bill of materials (BOM) can be downloaded from the Design Resources tab. As with all Maxim reference designs, boards are available for purchase.
- Public-key infrastructure to authenticate nodes and messages
- ECDSA-P256 public-key authentication
- SHA-256 HMAC secret-key authentication
- Securely controls on/off operation of IoT device endpoints
- Demonstrates secure download for remote update of an IoT device configuration file
- DeepCover secure key storage and protection
- Wifi interface for communication to a web server
- Crypto-strong authentication
- No need for secure-key storage memory on processor
- Low-overhead performance for signed data between the web server and the mbed platform
Designed, Built, Tested
Board pictured here has been fully assembled and tested.
In this IoT-embedded world, security emerges as a paramount feature to authenticate network connected equipment and sensors and to ensure that sensor endpoint measurements and control are securely operated. The MAXREFDES155# is a reference design that demonstrates a public-key-based authenticated data chain from a protected sensor node to a web server. The implementation provides a bidirectional ECDSA-based secure authentication model including:
- Web server-to-IoT device authenticated communication to deliver configuration file updates (i.e., secure download), enable power to the sensor endpoint with secure GPIO, and turn on/off periodic measurement updates from the controller.
- IoT device to web server authenticated transactions for enrollment of the controller, verification of the sensor endpoint HW, and measurement data from the sensor.
Detailed Description of Solution
The block diagram in Figure 1 shows the high-level implementation of the design. The operational sequence is as follows:
- The web server requests the ECDSA public key and certificate from the DS2476 protected mbed shield to authenticate the IoT device. The certificate is verified by the web server using the system authority public key stored on the web server.
- The mbed Platform uses the DS2476 to authenticate the DS28C36 on the sensor node. To demonstrate supported symmetric functionality, in this sequence, the DS2476 uses SHA-256 HMAC to verify that the DS28C36 is programmed with the correct secret.
- The sensor endpoint laser pointer is enabled by the user through the web server html interface that in turn uses a SHA-256-based command sequence to turn on a DS28C36 secure GPIO.
- Ambient and object thermal measurements by sensor endpoint are obtained by the mbed Platform and delivered to the web server with a sequence:
a. The mbed platform receives a command from the web server with an accompanying random challenge to prevent replay attacks.
b. Use the DS2476 to compute an ECDSA signature using the components: sensor-thermal data, received challenge from the web server, and DS2476 private key.
c. The mbed Platform sends sensor data and signature to the web server using a Wifi connection.
d. The web server verifies the signature, adds authenticated sensor data and results to the log, and distributes alerts if necessary.
- When a secure download is initiated by the html user interface, the web server delivers a file to the mbed platform; this simulates new/updated configuration data for the IoT device. This file is ECDSA signed by the system authority private key that is securely stored in the web server; the associated authority public key is stored in the DS2476. Demonstration of this secure download is accomplished by delivering a graphic to the mbed platform that is ultimately displayed on the LCD. The mbed platform uses the secure download/boot functionality of the DS2476 to verify integrity of the received file with a sequence:
a. The mbed platform uses the multiblock hash operation of the DS2476 to compute a SHA-256 hash of the file data.
b. The mbed platform provides the web server computed ECDSA signature of the file data to the DS2476.
c. The mbed platform uses the DS2476 to verify the ECDSA signature using the multi-block computed hash and stored system-authority public key.
d. The mbed platform receives pass/fail results of the operation from both logical (using command result parameter) and electrical (using GPIO state change).
Figure 1. Reference Design block diagram.
Description of the Web Server
The diagram of Figure 2 shows the architecture of the MAXREFDES155# web server implementation. The server consists of four basic components: web socket connections, TCP/IP connections, ECDSA crypto-client and data authentication, and a communication handler.
The mbed connections, crypto operations for authentication, and communication from web client-to-mbed are run under the Node.js services.
Node.js provides a connection between the website client and the mbed client, executes the ECDSA authentication from data received and sent, and sends data to each client using the mbed ROM ID and the website ID inside a JSON object. Servers use TCP/IP for mbed connections and ws sockets for website-client connections. Commands received and sent from each side are expected in JSON format.
To run all functions required by Node.js script, it is required to install express, ws, net, and crypto.
For more detailed information, refer to the Node.js library and all other required libraries needed for the server to run (see the online api provided by Node.js at https://nodejs.org.
The API reference documentation provides detailed information about a function or object in Node.js. This documentation indicates what arguments a method accepts, the return value of that method, and what errors might be related to that method. It also indicates which methods are available for different versions of Node.js.
Node.js was selected to control the communication and to provide fast communication response between the client and the mbed. The application is similar to an online chat room where the users select the person they want to talk to. The server employs the mbed’s ROM ID to direct the communications. Both the mbed and web client need to have the same ROMID to be able to send and receive commands, or results.
Depending on the server operating system, the libraries are available through npm -install or directly through downloads.
The server uses ports 3800 and 3900 to capture incoming traffic from each module. mbed shields connect to server through port 3800 and webclients connect to the server using port 3900.
Figure 2 provides additional information of the expected communication flow and operation of server.
Figure 2. The MAXREFDES155# web server implementation.
The hardware setup for this reference design is:
- An mbed Shield and Sensor Module (MAXREFDES155# available for purchase)
- Available for immediate download on the Design Resources tab are the schematic, BOM, and PCB Gerber.
- MAX32600MBED# (ARM mbed-enabled development platform for MAX32600—available for purchase separately) used as an embedded microprocessor for the mbed shield
- Wifi Hotspot (internet access is needed for MAXREFDES155#)
- USB-A to USB-micro-B cable
- Internet-connected computer with a USB port to load firmware and run the needed web client during the demo
- Web server (provided by Maxim Integrated for demonstration purposes)
Firmware for the MAXREFDES155# reference design is available for download from the mbed web page https://developer.mbed.org.
Figure 3 shows the shield pins (i.e., J1, J2, J4, and J5) that connect to the mbed platform (e.g., MAX32600MBED#).
Figure 3. Shield-compatible connections (actual connectors on the back).
Figure 4 shows the mbed shield I2C connections to the sensor module (J3), the six pushbuttons, the GREEN/BLUE LEDs (D1 & D2), and the LCD Display.
Figure 4. MAXREFDES155# mbed shield accessary connections.
Figure 5 shows the infrared (IR) laser-sensor module with the SR-cable signal connection (J7). This sensor module also shows the aiming button for the laser pointer and the IR-temperature sensor.
Figure 5. Infrared laser sensor module connections.
- MAXREFDES155# kit
- MAX32600MBED# or equivalent mbed platform
- Hotspot (Needed Internet access for MAXREFDES155#)
- Any PC or Notebook with an internet browser and a USB port
- USB-A to USB-micro-B cable
Download, read, and carefully follow each step in the appropriate MAXREFDES155# Quick Start Guide.
Arduino is a registered trademark of Arduino, LLC.
ARM is a registered service mark, and ARM and mbed are registered trademarks of ARM Limited.
DeepCover is a registered trademark of Maxim Integrated Products, Inc.
Windows is a registered trademark and registered service mark of Microsoft Corporation.
Order NowMAXREFDES155#: DeepCover Embedded Security in an IoT: Public-Key Secured Data Paths
|Part Number||Buy from Maxim or Third Party|
Maxim Devices (3)
|Part Number||Name||Product Family||Order||Design kits and evaluation modules|
|DS2476||DeepCover Secure Coprocessor||Secure Authentication||Buy Now||Design Kits|
|DS28C36||DeepCover Secure Authenticator||Secure Authentication||Buy Now||Design Kits|
|MAX32600MBED||ARM mbed Enabled Development Platform for MAX32600||MCU - Microcontroller||Buy Now||Not Available|
Maxim Devices (3)
|Part Number||Product Family|
DeepCover Secure Coprocessor
DeepCover Secure Authenticator
MCU - Microcontroller
ARM mbed Enabled Development Platform for MAX32600
Design Files (6)
|No Title ; MAXREFDES155#: DeepCover Embedded Security in an IoT: Public-Key Secured Data Paths||3MB||2017-11-03|
|MAXREFDES155_BOM_RA ; MAXREFDES155#: DeepCover Embedded Security in an IoT: Public-Key Secured Data Paths||82KB||2019-07-09|