MAXREFDES155# IoT Embedded Security System Board - Review

Table of contents

RoadTest: MAXREFDES155# IoT Embedded Security System Board

Author: mconners

Creation date: 14 Jun 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?: None

What were the biggest problems encountered?: No problems

Detailed Review:

First off, I'd like to thank Element 14 and Maxim Integrated for the opportunity to perform this road test. While the road test itself is about the MAXREFDES155 shield, there is much more included in the kit.

There is also a MAX32600 mbed enabled development board, so let me start out by telling you a bit about that.

This board by itself would be worthy of a road test. It is an ARM Cortex M3 microcontroller on a board with Arduino compatible shield sockets. It contains the Maxim

MAX32600, which is described as a Wellness Measurement Microcontroller, an Ultra-Low-Power ARM Cortex-M3 with Wellness Sensor Analog Front-End and Advanced Hardware Security.

The board  has the circuitry available to be programmed in the MBED environment. When attached to your computer via the HDK usb port, it appears to you as a disk drive. This is how you program the board. No need

for a jtag device to program the board, no additional hardware, no command line to remember, just drag and drop the compiled program in the root directory of the device, wait for it to reboot, and you are in business.

This is how most modern MBED enabled devices work. In addition to the Arduino compatible pinout, there are additional pins available on the board to get to many of the peripherals available in the microcontroller.

These would include:

16-Bit ADC with Input Mux and PGA Up to 500ksps Conversion Rate

Programmable Buffers for ADC and DACs

Two 12-Bit DACs and Two 8-Bit DACs

Four Operational Amplifiers

Four Low-Power Comparators

Four Uncommitted SPST Analog Switches

Trust Protection Unit for End-to-End Security

USB Device Interface

LCD Controller

6-Channel DMA Engine Enables Intelligent Peripheral Operation While Micro is in Sleep Mode

Four 32-Bit Timers, Configurable to 8 x 16-Bit

32-Bit Real-Time Clock

Three SPI Masters

Two UARTs

Two I2C Master Ports

One I2C Slave Port

Up to 64 GPIO Pins with External Interrupt and Wake from Low-Power Mode

Pulse Train Engine with Eight Digital Output Channels

The MAXREFDES155 Shield

Also included in the shipment was the MAXREFDES155 shield, along with an I2C connected companion board containing a temperature sensor and a laser pointer.

The shield itself contains an LCD screen and 7 push-buttons. 1 is tied to reset, but the other 6 are there for the user. There are a couple of LEDs , and a WiFi connection as well.

Honestly though, I don't think these boards in total are expected to be the subject of this road test. The technology they want to highlight is the Maxim DS28C36 and the Maxim DS2476. Which

are the DeepCover Secure Authenticator and DeepCover Secure Coprocessor, respectively.

The Authenticator is defined by Maxim as:

The DS28C36 is a secure authenticator that provides a core set of cryptographic tools derived from integrated asymmetric (ECC-P256) and symmetric (SHA-256) security functions. In addition to the security services provided by the hardware implemented crypto engines, the device integrates a FIPS/NIST true random number generator (RNG), 8Kb of secured EEPROM, a decrement-only counter, two pins of configurable GPIO, and a unique 64-bit ROM identification number (ROM ID).

The Coprocessor is defined by Maxim as:

The DS2476 is a secure ECDSA and HMAC SHA-256 coprocessor companion to the DS28C36. The coprocessor can compute any required HMACs or ECDSA signatures to do any operation on the DS28C36. The DS2476 provides a core set of cryptographic tools derived from integrated asymmetric (ECC-P256) and symmetric (SHA-256) security functions. In addition to the security services provided by the hardware implemented crypto engines, the device integrates a FIPS/NIST true random number generator (RNG), 8Kb of secured EEPROM, a decrement-only counter, two pins of configurable GPIO, and a unique 64-bit ROM identification number (ROM ID).

The physical connection of these devices is simple enough. Schematics and reference designs are available from the vendor. To get the full data sheets an NDA is required, I opted not to request them for this review so as not to compromise anything I wrote. I was able to derive everything I wrote from resources available from the vendor via the software provided for the demo code and the publicly available resources describing the board and the chips.

The demo:

When you first get the board you are instructed to go to mbed.org and sign up for an account if you don't already have one. I had one and am familiar with the mbed environment, so I added the demo software to my account and got started.

The first thing they tell you to do is to set the name of your wireless SSID and password in the demo software, then compile it and drag and drop the program onto your board. After that step is complete you can attach the MAXREFDES155 shield to your board by lining up the pins.

You then reconnect the board via usb using the DEV port to power up the board. You are taken through a couple of screens, one of which will give you the unique serial number for the board. Once you have that, you are instructed to go to www.maxim-security.com, select the picture of the MAXREFDES155, and enter the unique Id. Once you do that you will be taken to the demo screen, you can then follow the instructions on the LCD on the MAXREFDES155 to complete the connection. The demo screen has a few buttons on it which allow you to request some temperature readings from the board, a switch to remotely enable the laser pointer, a button to download an image, etc ... Again, I don't think the demo software is the star of the show here. The board and the accompanying demo software appear to be pretty well done, but I'm reminded of when I'm watching a comedian and they say, "I only told you that, so I can now tell you this..." It's the setup. The boards, the mbed software, and the web demo solely exist to show you how using the DS28C36 and the DS2476 can protect your server from receiving bogus information from an unauthorized IoT node, and your sensor node or other IoT device from receiving unauthorized commands from a server that is not part of the authenticated network. That is the key take away here, everything else was built to demonstrate what the DeepCover chips can do.

One thing that is specifically part of the demo that is of interest is that there is an option on the board demo to use an invalid signature coming from the board, this has the effect of having the server disregarding any information it receives from the board, this shows me that using a Public Key Authorization (PKA) infrastructure that has remote IoT sensors that are paired and part of the trusted network can help protect your server software from receiving invalid information. This part of the demo shows me more that you can build safeguards into your server, rather than demonstrates the capabilities of the DeepCover chips. All that being said, I think it's a great demo. I can tell a lot of work went into it, and that tells me that this technology is something that Maxim is willing to invest money into. I have reached out to maxim support and asked for a copy of the web server side of the demo software, at the time I write this, my request is still being processed, but I think to really be able to take full advantage of the technology you need to have access to both sides of the wire and it would be nice to see a reference software design to accompany a reference hardware design. The mbed code is great but it is only one side of the equation, it could be reverse engineered, but that is a significant amount of effort. Below is a screenshot of the Demo software:

Now for the good stuff:

For a while I have been watching the news about exploits to IoT devices. Some are so ridiculous you can't believe anyone would go to market with such an insecure design. You hear about people hacking IoT doorbells, and home automation devices. It's ridiculous. It's good to see a company like Maxim designing products to address these issues. The way they decided to attack it was through a Public Key Infrastructure. They used a signing technique called ECDSA, which is the Elliptic Curve Digital Signing Algorithm, this is the same type of technology that is used to secure Bitcoin transactions. Feel free to google it, it's way too  much to put in a road test, but the way it applies is Maxim designed these two chips, the DS2476 and the DS28C36, to optimize the calcluations of the hashes, authentication,  and signing algorithms to offload the processing from your main cpu in your sensor or controller. In addition, the chips themselves have gpio outputs that can behave as any other gpio outputs, but only if all of the authentication mechanisms have been satisfied. Now much in the way that the demo software had a button to send an invalid signature to the server, I wanted to devise a way to test what happened if the server was trying to send invalid data to the remote sensor. This to me would be the true demonstration of these ICs.

I had to think for a bit on how to attack this problem. I ended up writing a little proxy server in node.js. I essentially became a Man in the Middle (MITM). You might be saying, but wait, won't these chips protect you from a MITM attack? Yes, they will, but realize that because of the NAT (Network Address Translation) on my router, the server back at maxim has no idea where the actual requests are coming from, and because I had access to the source for the mbed board I was able to change the server address to a machine on my network, and as long as the data was coming across with the proper signatures, the board itself doesn't care. The level of control that I had over the network and the software running on the client board would be unusual and if someone desiring to hack your network had an equal level of control you have got much larger problems to deal with.

Ok, so back to my  proxy server. I basically opened a socket connection to the maxim server and took any data they sent, copied it to the console, and forwarded it on to the client board. I started a listener on the port where I told the mbed board the maxim server was, and did the same thing, took any data sent, copied it to the console, and forwarded it unchanged back to the maxim server. I then started up my proxy, and repeated the steps to start the demo, my console output looked like this:

MITM listening on 0.0.0.0:6969

Server : Welcome to server mbed ip address: 75.91.81.172:32786

Client : {"challenge":"DE0F8D7794319C82D64049FA6B4964F76641313A7F16C20A55AA6E8565D5A3C9"}

Server : {"data":{"command":"getStatus","challenge":"32373C75B6D893C6B0A4E50083DCD89996AB4DC56163FC17EA5546A897315888"},"signature":{"r":"DA12A58E7DDD2E4EAC25A55BC2D69DB9E394B0DE2DAFEA4477C3DD66B47C9CD1","s":"B05658444197C906B1CB783C99E59AF625F492BF86EEE9C0D94EB5F9971AD963"}}

Client : {"message":"Received data is authentic"}

Client : {"data":{"id":"4EC10D00000000FC","publicKey":{"x":"2D7DBB21613C8D1C7838C7C1A917598D475B2167BE0CDA9E739FAD896EEAA890","y":"688573D428776FF15804989D24937996CE30CA2D4BD49B434289F93231D59FA8"},"certificate":{"r":"249B3317D99A13AA171763BE495469C24922CE69FCD5E45A35E55747F56FAD32","s":"9E59A67A829520375C8DA2C6B34396186501CBB025E6C8D2426BF3D65CB72101"},"challenge":"6B3EE37D2CBE1D0FD3815422BC894DA231E1C72B25300C69306BD45FDFF9EC60"},"signature":{"r":"A8F273E03899B6AD3ACE246DAFD17902041F52CEA86F3A46C135A2170CB2B19B","s":"649944FD214E9C536161943FD0A8562F465C0B733B01F35CF7CDEEF509CB53D2"}}

So right off the bat, I saw that the server and the client were talking using JSON encoded strings.

It looks like the first thing that happens when the client connects is that you get a welcome message from the server.

Then the client immediately sends a challenge string. Without having access to the server software, I'm not sure what the server does with this data, if it ignores it or it becomes part of the following message.

Immediately after the client challenge, the server sends a signed request for status, let me format the JSON so it's clearer to read:

The line preceded with Server : was the data I received from the server, the line preceded with Server mod : is the data after I modified the command, and this is what I sent to the board.

The client responded with:

Client : {"message":"Received data is not authentic"}

Because without the private keys used by the server, I would not be able to properly sign the message. The device can determine that the data packet was not authentic, and will not respond to the command.

There are several more experiments I could conduct at this point, such as modifying the client response to return an invalid temperature, but the result would be the same. I believe that integrating this type of technology into an IoT design would definitely increase the security and reliability of a network of attached devices. You always see in the movies where a group of intruders hack into the security cameras before they break into a building, had those devices had this type of technology, that type of exploit would be significantly more difficult if not impossible to pull off. Also having this type of technology on internet connected valves, motors, sensors would give an organization peace of mind that they and only they can control those devices and that the results returned from those devices are unaltered and authentic.

I think MaximIntegrated has a winning technology here. The capabilities built into the DeepCover series of ICs simplify the design, both hardware and software, of a secure network of IoT devices.

Now I have just touched the surface of all of this technology in this review, this is a broad and complicated subject, the reviews of this technology could go on for many pages, but that is not my intent here, many people much more experienced in this technology have written at length on the topic, but as a road test, I believe these devices hit the mark.

Resources:

https://www.maximintegrated.com/en/app-notes/index.mvp/id/5767

https://www.maximintegrated.com/en/design/reference-design-center/system-board/6388.html/tb_tab1

https://www.maximintegrated.com/en/design/videos.html/vd_5350783590001

In addition to the above resources, a quick google search will turn up tons of information regarding ECDSA, PKI, PKA, etc. As I mentioned this is a broad topic and I couldn't have covered all of it. I hope this review is helpful. If there is anything you would like me to try let me know in the comments and I can see what I can do. I still hope Maxim will come through with the source for the server. My original roadtest application mentioned perhaps using a temperature sensor I had built in place of the supplied sensor, but after getting the board, I think that is unfeasible and really doesn't prove anything more than what I have demonstrated here in the road test. I would highly recommend watching the video in the 3rd link above, I feel that it really describes the devices, the network, and the process much better than I can in a short, digestible session. I feel confident that I have validated the claims made in the video and that this really is a powerful technology that needs to make its way into commercial IoT products.

Thanks once again to MaximIntegrated and Element14.