Securing the Wi-Fi Stepper

Hello everybody. As we get close to delivery, we thought we would share with you the security framework we’ve built into the Wi-Fi Stepper. Given that the board supports large stepper motors with high voltage and current, hacking could result in damage and injury. To us, security is a big concern and we need to get it right. To that end, we’d like to share with you the design choices and methodology used to secure the Wi-Fi Stepper and prevent unauthorized access.

Assumptions

We make three assumptions that guide the design choices and trade-offs we’ve made developing the security framework. They are:

1. You are in a secure environment during provisioning and security configuration (i.e., your factory/lab is secured when you configure the keys)
2. There is no private or sensitive data sent to the device during normal operation (the run/goto/etc commands do not contain any valuable information to an attacker)
3. If an attacker gains physical access to a device, he/she can reprogram the firmware and bypass any security methods thereafter (the code is open source, built with Arduino, and is easy to edit and reflash by design)

Assumption 1 - gives flexibility in how to initially provision the keys. The boards are initially unlocked and blank. It’s up to the user to decide when and how to lock the boards.

Assumption 2 - allows us to focus only on authentication and not encryption. The command messages are signed by both sides to prevent man-in-the-middle alteration and a nonce + monotonic counter is used to prevent replay attacks. The commands are then transmitted unencrypted (clear-text) with the signatures attached. By not using encryption, there is an added benefit of taking the cryptographic computational load off of the processor (which is somewhat expensive for the microcontroller we’re using). We’re using the HMAC algorithm and a shared private key to generate signatures for messages to and from the device.

Assumption 3 - means that handling the private shared key on the device is critical. We want to allow for the same private shared key to be used to secure many devices. If an attacker is able to gain access to and tamper with one device, the key should not be readable and the attack should be isolated to that one device.

Choosing the Atmel ECC508a

Early on we made the decision to use the Atmel ECC508a crypto companion processor. It provides the security algorithms we use, and more importantly, the key security we rely on. After provisioning, the authentication keys are locked into the EEPROM on-chip and cannot be read back out. All the HMAC computation is done on-chip in a secure way with only the resulting computed signature being transmitted back to the microcontroller.

Atmel ECC508a Crypto Chip

During provisioning, two keys are written to the ECC chip: They are the Master Key and the Auth Key. The Master Key is permanently written and can never be changed once provisioned. The Auth Key is then locked behind the Master Key and is used with the HMAC signature calculation. This allows the Auth Key to be changed only if the Master Key is known as well. However, only the Auth Key is needed during normal operation to generate the HMAC signatures.

Provisioning with the Web Interface

All the nuts and bolts to provision the ECC chip are handled for you if you use the Web Interface software that ships with the Wi-Fi Stepper. The only thing you need to provide are the two keys, and remember the Master Key as it is permanent.

Latency

We’ve tested the latency added to the command execution by the security framework. A typical command message will take an additional 25 to 30 milliseconds to be verified and a reply acknowledgment signature generated. Longer commands (such as motor setup and configuration) will take 50 to 75 milliseconds worst case.

What we did not consider

It is just as important to describe what we did not factor into the security design.

We did not include in the security model how user applications that send commands and interact with the Wi-Fi stepper handle the Auth Key. It is up to the individual applications to define and implement their own security model. The applications need the Auth Key to generate the HMAC signatures.

Denial of service

Radio communication is always susceptible to jamming and wifi in particular is easy to launch a denial-of-service attack against. There is not much you can do to prevent a motivated adversary from successfully carrying out an attack like this. There are timeouts on the device that can trigger command execution to safe the motor in various ways when a network dropout or other denial-of-service happens.

Tamper prevention and detection

Being able to prevent physical tampering is an important aspect of this security model. How you do that, though, is up to you. If your application requires high security, Assumption 3 means that the only real way to maintain communication security is to have hardened physical security as well. Tamper detection is another important aspect. If a device is physically compromised, being able to detect it is critical.

Security analysis

Security is hard. Really hard. In a world where IoT devices are notoriously bad at security, we hope this is a step in the right direction. While we humbly know there could always be improvements to security, and there is the potential for security bugs, we at Good Robotics want to show our commitment to security and collaboration in this space. Please reach out or give us feedback if this is an area of development that is important to you.

Security Recommendation

Security Recommendation panel in the Web Interface

The Wi-Fi Stepper can be controlled using a number of different services. To help on the security front, we’ve put together a guide that details the different services and their security levels. You set the desired security level you want to achieve and the tool will make security recommendations and show you features you can disable for improved security.