SparkFun Electronics and IoT Security

Nate Seidle, the CEO of SparkFun Electronics, was asked during a live AMA today about the security of the Internet of Things. He recalled an anecdote about politicians who refute climate change studies because they claim the data was collected improperly. This was discussed in the context of a secure data logging service and why it may be important to authenticate your sensor and your sensor’s data. Nate wrote the forward to my book as well where he had some more insightful comments about device security. Nate also had some kind words to say about me while answering the question 🙂

Working with SparkFun has been great. It started with my hacker-in-residence which resulted in the development of the CryptoCape. The goal of this project was to design a platform on which fellow hackers could build security applications. Some of these devices aren’t the easiest to use, but with the hookup guide, screencasts, and book, I’ve tried to provide some examples. I’ve received positive feedback, but there’s still a long road ahead to make these tools easier to use.

To help, I’ve created debian.cryptotronix.com to host armhf debian packages for CryptoCape software. Mainly, it includes newer builds of TPM related software and a debian package of hashlet. If you follow the instructions on that page, installing the software should be as easy as:

[code light=”true” language=”bash”]
sudo apt-get install cryptocape
[/code]

Hopefully this helps make installation a little bit easier. I’ll be adding more software to that repository, which you should be able to pick up with the normal update and upgrade commands.

One of SparkFun’s best qualities is that they not only provide the tools, but they spend equal, if not more time, teaching people how to build these tools themselves. I have certainly benefited from SparkFun’s tutorials and I’m very happy that I get to help provide some of this material.

2 thoughts on “SparkFun Electronics and IoT Security

  1. We’ve been working on authentication of sensor data for many years, mainly for monitoring compliance with nuclear weapons limitation treaties/agreements or for international nuclear safeguards. Our approach is to wrap the data packets or data files with digital signatures. For many years, we had to depend on symmetric algorithms for this because of the huge power draw that implementation of public key algorithms required.

    As you know, the key management for a symmetric key monitoring system is extremely difficult, especially in multiparty monitoring agreements. (Anyone who can verify the authenticity of the data can also alter it in a symmetric system.)

    Even now, it’s difficult to implement digital signatures in low power sensor platforms. That’s why I’m excited about products like Eclet and CryptoCape. It appears to be much easier to field sensor platforms that employ algorithms like ECDSA that are powered by batteries or solar collectors than it has been in the past.

    Keep up the good work, Josh, and let me know if there’s anything I can do to help.

    1. Thanks Keith. The low power applications is certainly what makes this chip interesting. I’m working on a kernel driver for the 204/108 which might be of interest to you. It mainly moves the communication layer into the kernel, but I do expose some useful sysfs features to get the serial num and config zones.

      It’s not quite ready for prime-time though. 🙂 I’ll put it up on that repository when it’s ready.

Comments are closed.