Table of contents

RoadTest: MAXREFDES143#: DeepCover Embedded Security in IoT

Author: shabaz

Creation date: 24 Feb 2017

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: null

What were the biggest problems encountered?: Some minor issues with Windows 10 compatibility and WiFi module issue that didn't overly detract from working with the dev-board. Nothing that was a show-stopper.

Detailed Review:

Introduction

There can often be a requirement to authenticate certain things in a system. For example in an online banking offering there is a need for the system to be able to establish confidence that the person accessing a bank account is the person whose bank account it really is.

Some other examples could be:

• A need to be certain that only genuine brand peripherals are attached to equipment
• A need to be certain of correct resource usage, for example to identify when the ink level in a disposable print cartridge is higher than it previously was
• A need to be certain that only genuine equipment is connected to the cloud

One type of tool or function that comes in very handy for solving authentication problems is known as a hash algorithm. The algorithm can convert an input block of data into an output block (known as the hash; it is like a checksum) such that is considered impossible to convert the output of the algorithm back into the original data. Furthermore, the algorithm design is such that the output of the algorithm can vary immensely if the input data is varied slightly.

For example, this is a hash (using an algorithm called SHA-256) of the input word “grey”:

67fc36385bb47db091a4d850d450021a8b7ba3b58615fc918808d4e636d8ad46

By changing just one character of the input to “gray” this is the hash result:

0e92d69f9b951b18299f34b2e53dbba7e9ad0b070883c040c0fcc1f74e1985ef

Hashes are used all over the place. They are one of the cogs that makes secure web browsing possible, securing Internet banking, Bitcoin mining and checking e-mail. Hash algorithms are an enabler to implement encryption; they are a component of public key infrastructure (PKI).

Maxim’s DeepCover products are intended for a variety of security related purposes. In particular the DeepCover ‘Secure Authenticator’ products are intended for authentication purposes and can be used for the example use-cases listed earlier. At the heart of DeepCover Secure Authenticator products is a hardware SHA-256 engine.

The MAXREFDES143MAXREFDES143 and MAX32600MBEDMAX32600MBED bundle are a good way of trying out the DeepCover Secure Authenticator technology.

Hardware

The MAXREFDES143 product actually contains three boards; the main one is an Arduino Shield-like board with an LCD screen, some buttons and a few other features but in particular it contains the DeepCover DS2465 chip. A smaller board called the ‘Protected Sensor Node’ contains a couple of sensors and the DeepCover DS28E15 chip. Finally there is a small WiFi board; it is the popular ESP8266.

The MAX32600MBED board is like the Arduino; it is a microcontroller board with an easy-to-use development environment.

MAX32600MBED Board

The board comes with Arduino style headers; it is possible to plug typical Arduino Shield boards on top (although the logic level is 3.3V instead of 5V). The board is a square form-factor however so it is larger than an Arduino Uno. At its heart is Maxim’s MAX32600 microcontroller which has an ARM Cortex-M3 core.

The board is mbed-enabled which means that it has a USB connector that works with the online browser-based development method that is actually easier to use than the Arduino development environment. In a nutshell one can register an account at mbed.org, write code online and then when you hit the ‘compile’ button the code is downloaded to the PC. From there the file can be dragged onto the file system that appears when the USB cable from the board’s mbed interface is plugged into the PC.

The board has lots of I/O because the MAX32600 is a 192-pin ball grid array (BGA) device. There are plenty of header pins and unallocated header location surrounding the Arduino headers and these can be used to access the mass of I/O.

For quick software testing purposes there are four LEDs connected to GPIO, as well as a couple of push-buttons.

There are a variety of interesting integrated peripherals on the MAX32600 chip. In particular there are a lot of analog resources. The microcontroller is targeted towards applications such as wearable medical devices.

(image source: Maxim website)

The MAX32600MBED board is easy to use as are all mbed-enabled boards. One slight issue is that the mbed interface is running old firmware which is not compatible with Windows 10. I discovered this after a hunch, because I could not get it running on my PC. With Windows 7 it works fine. I also tested with Ubuntu Linux and that worked great too. I will raise a case with Maxim to see when new firmware is available. It is not a major issue because Windows 10 users could always run a Linux virtual machine.

MAXREFDES143 Hardware

The MAXREFDES143 bundle contains several boards. The main one is populated with an LCD screen, some user buttons and LEDs, and the Maxim DS2465Maxim DS2465 chip with DeepCover Secure Authenticator technology. The ‘Secure Authenticator’ marketing is referring to the use of the SHA-256 algorithm (all of the Maxim DeepCover Secure Authenticator range appear to use SHA-256).

The Secure Authenticator technology can be combined with other features, and the DS2465 chip contains I2C slave capability and a Maxim 1-Wire master function.  In effect the chip provides a gateway between the I2C world and the 1-Wire world for the purposes of communicating with Secure Authenticator 1-Wire slave devices.

Maxim 1-Wire refers to a single-wire (with ground return) serial interface that was developed by Dallas Semiconductor which Maxim acquired many years ago. 1-Wire is a low-level protocol that has uses which are similar to those for I2C. Multiple 1-Wire slave devices can be hooked onto the 1-Wire bus; they have addressing like I2C and also can be addressed with a totally unique identifier per physical part (i.e. no two are identical). This unique identifier feature was exploited for security related applications early on in the history of 1-Wire when Dallas Semiconductor offered 1-Wire chips enclosed in a metal case like a coin cell. They are still available, such as iButton EPROMiButton EPROM. These could be attached to a key-chain and used as a simple access control device for (say) room access.

The main board also contains another DeepCover Secure Authenticator part, the MAX66242 Secure Authenticator with RFID Transponder. This type of device plays a role in inventory tracking where it is possible to identify a package out of dozens (or more), using RFID to emit a signal that all devices simultaneously receive but only the addressed one responds to. The Secure Authenticator capability extends that to a more advanced inventory tracking solution. Although Maxim have included this part on their MAXREFDES143 board, it is for future use and doesn’t form part of the demonstrator software or Maxim’s MAXREFDES143 Quick Start Guide, and the demo code for it is not available; I had some success experimenting with it but it is beyond the scope of this RoadTest and will be revisited later.

Another DeepCover Secure Authenticator device, the 1-Wire slave DS28E15DS28E15 with EEPROM is provided on a separate small board which plugs onto the side of the main board. It is intended to act like a low-cost peripheral such as an authentic printer cartridge. The small board also contains a couple of sensors that are used for the demo application to simulate a resource (such as printer ink).

Finally the MAXREFDES143 bundle also contains a small WiFi interface known as the ESP8266-01. This is quite a popular device amongst the ‘maker’ community but it is unusual to see it supplied as part of a development kit. The ESP8266-01 has a UART interface that connects to the MAX32600MBED board via the MAXREFDES143 board. Certain ‘AT’ modem-style commands are dispatched by the MAX32600 microcontroller to the ESP8266-01 module in order to connect to a wireless LAN.

Building Solutions with Secure Authenticator Technology

With all the boards plugged together an example system is realized where the main boards represent a piece of hardware that will only interoperate with genuine peripherals that are simulated by the parts on the ‘Protected Sensor Node’ board.

The way the technology works is that it relies on a secret set of bytes known by the Protected Sensor Node’s Secure Authenticator chip, and the same set of bytes known by the main board’s DS2465 chip as well. These are not accessible to the outside world once computed and stored on the two chips.

Whenever the microcontroller wants to check that the attached peripherals are genuine (typically this will occur at power-up and at periodic intervals) it will send a random string of bytes (known as the ‘Challenge’) to the local Secure Authenticator chip (DS2465) which will use that and the stored secret bytes to generate a hash with the SHA-256 engine. This hash is known as the message authentication code. The same ‘Challenge’ string of random numbers will be passed to the remote Secure Authenticator chip (DS28E15) over the 1-Wire link. The remote device will also compute a hash in the same manner and then pass the result back to the DS2465; this is known as the ‘Response’. It will compare response with the local hash. If the two match, then this proves that the secret information must also have theoretically matched. The point of the hash function is that the secret information never leaves the chip. Only the hash (message authentication code) traverses the wires outside the chip. Furthermore, a random challenge means that even if the information is snooped with an oscilloscope it cannot be replayed to simulate the Protected Sensor Node.

Security still relies on the entire solution, and it is very important that the code in the microcontroller is not accessible or easy to modify either. For example, someone who wanted to bypass the security check could modify the firmware in the microcontroller so that the challenge is never issued, and the code jumps to a location where it is assumed the check has occurred. It is the equivalent of the PC desktop software world where hackers try to modify binaries to skip license manager checks by patching code. This is not a weakness of the Maxim solution, it is up to the solution creator to determine how valuable it is to protect the system for the specific use-case, and take appropriate steps to protect the compiled firmware and hardware, and even the source code of course. For example a more secure code implementation would be for the software developer to issue challenges to the Protected Sensor Node at different points during program execution, with different challenges. This would make it more time consuming for someone to patch all instances if they managed to obtain the firmware out of the microcontroller. There are other techniques too, and some microcontrollers will have additional security features to prevent code from being changed or read, or to prevent modified code from running.

Physical security is something worth considering too. It makes breaking the solution very difficult if physical access is restricted. One method at the board hardware level is to apply epoxy resin to the chip. Some manufacturers will even stick an easy-to-tear hologram on top of the epoxy resin, so that if it is tampered with the recipient of the hardware will know.

Internally inside the DeepCover Secure Authenticator chips it is claimed by Maxim that ‘multiple layers of physical security’ are present. I do not have a way to verify that of course, but since the primary purpose of the devices is concerned with secure authentication I have no reason to doubt that Maxim will have taken some precautions to make life difficult for hardware hacks at the physical chip level.

With the Secure Authenticator technology it is also possible for the remote Protected Node to be able to confirm that the main board is authentic before allowing changes to the in-built memory in the DS28E15. The use-case for this could be for printer cartridges, where it must not be possible for third party hardware to be able to reprogram cartridges to make them appear to the printer that they are full again if third-party ink is injected into the spent cartridge. This uses a similar method whereby the DS28E15 will reject EEPROM write operations from the microcontroller unless a challenge is read from the DS28E15 and a correct response sent back. This reverse direction authentication too uses the SHA-256 engine inside the chips.

Yet another use for the Secure Authenticator technology is to use the SHA-256 engine to create a message authentication code (hash) for authenticating the hardware to any remote software (for example an application running in a cloud). A typical scenario would be to only allow genuine gateways or sensors to connect to a cloud based service. Third party devices would thus not be able to piggy-back onto manufacturer-owned cloud services for free. The way this scenario works is that the remote application sends the challenge; the Secure Authenticator computes the message authentication code and sends it back to the remote application. The MAXREFDES143 board has space for an ESP8266-01 module that connects to a cloud service for exactly this purpose.

Using the MAX32600MBED and MAXREFDES143 Boards

The easiest way to use the board is to write code with the mbed cloud service. With a free account, the developer can import demo code into the online integrated development environment (IDE), modify it and compile it. When the compile button is clicked the binary file is downloaded onto the PC’s file system.

The binary file is transferred onto the MAX32600MBED board by plugging in the USB cable to the mbed interface port. The board appears like a file system much like a USB memory stick and the binary file can be dragged onto it.

The code that is supplied is well-written however one issue that I couldn’t get to the bottom of in the limited time that I attempted was the WiFi connectivity. The ESP8266 module refused to connect to the three wireless LANs that I tried (all three had different access points). I tried the tricks of forcing low-value channels in case the ESP8266 was set to a non-European mode, and dropping the security briefly from WPA2 to WPA, and using a very old wireless access point in case the protocols CCMP and AES were not supported by the ESP8266 module firmware.

Snooping the serial interface connecting the ESP8266 to the microcontroller revealed the following messages if anyone is curious:

Ai-Thinker Technology Co.,Ltd.


ready
AT


OK
AT+CWMODE_CUR=3


OK
AT+RFPOWER=40


OK
AT+CWJAP_CUR="myssid","mypassword"
WIFI DISCONNECT
+CWJAP:1


FAIL

I also tried a few changes to the AT commands in case the particular ESP8266 module that was supplied with the bundle had different firmware. One annoyance of the ESP8266 is that there is no single repository of information and I wasn’t prepared to attempt a firmware upgrade of it without having a spare handy. I have ordered another ESP8266 module in case the current one is faulty but I suspect it could be that the firmware revision is the issue. I will raise this with Maxim to make them aware.

The lack of wireless connectivity was not a showstopper, it is possible to fully exercise the Maxim kit without it. For anyone creating their own cloud platform, it is possible to download SHA-256 hash libraries in a variety of languages.

To get the microcontroller code to run without the ESP8266 module, I made a few changes to the demo source code (if anyone wants the modified code I will publish it online, it was just a few trivial changes) and then I recompiled and transferred it to the board.

The demo code uses the light sensor to simulate filter usage before the filter needs changing (for example in a water filter jug). Covering the light sensor simulates filter usage and causes the remaining filter life to drop. Powering off and on of the hardware retains the current filter life level. This shows that it is possible to implement a solution where a genuine peripheral with a fixed life resource has been connected to the main hardware.

It is also possible to simulate invalid hardware (i.e. different secret sequence of bytes stored inside the Secure Authenticator chips) by holding down an 'invalidate' button on the board. When this is done, the green display changes to a purple error message to highlight this. Disconnecting the 1-Wire device by unplugging the Protected Sensor Node results in a red error. Incidentally the Maxim board hardware is very nice and I loved the programmable multi-color backlight LCD : )

Datasheet Availability

The general SHA-256 based message authentication code (MAC) method of authentication is well-established however the precise content and communication content that the Secure Authenticator chips will use is available only with a non-disclosure agreement (NDA) signed with Maxim.

All the information in this review was derived from the kit documentation and publicly available information (cut-down datasheets) on the Maxim website and through experimentation and inspection of the microcontroller demo code. Deeper examination requires the NDA, and it wouldn’t be possible to publicly report any findings based on that. I deliberately have not read the detailed documentation yet to avoid contamination of this report. To get the NDA, it is necessary to raise a case with Maxim (click on the datasheet link on the product web page for each Secure Authenticator part of interest).

Summary

The DeepCover Secure Authenticator at 50-cent prices (ballpark at current pricing in quantity) makes for a very low cost way of implementing good quality authenticity checks into products. It also doesn't use up a lot of space, just 3x3mm for the peripheral to be authenticated. It uses a well-established method (SHA-256) for computing message authentication and unlike normal microcontroller Flash or EEPROM there are chip-level techniques securing the data, and the ability to prevent reads and writes of certain information depending on device configuration and authentication.

Although I’ve not used 1-Wire much in the past I like the fact that it is just a single wire to secure against electro-static discharge (ESD) and that adding a single wire to a connector isn’t a lot of signal wiring overhead.

I had not used a Maxim microcontroller before and I was very happy to see that they’d taken the effort to get it integrated into mbed. It is so convenient I always prefer using a microcontroller supported by mbed rather than one that is not (an offline mbed compiler is also available for those that need/prefer this). I look forward to trying the analog functionality on the chip too.

Although there were minor hiccups (Win 10 compatibility and ESP8266 issue) these do not detract from experimentation with the Secure Authenticator devices since there are workarounds. Furthermore, I’m sure these issues will be resolved, they will be flagged to Maxim. Their e-mail engineering and customer support is usually extremely helpful.