Tl;Dr - Zymbit are creating RPi modulescreating RPi modules that let you drop-in some serious cryptographic weight and security features, in order to help better protect RPi's that need it. A first view has found zymbit's Zymkey 4i to be: slick on the website, light on the documentation, but easily operational and heavy on the initial feature offering.

 

Let's be honest - security is hard. And time consuming. And as a developer, it seems as if you can never get a single thing right!!

 

But we've also seen the headlines - every week, week on week - Big Corp Hacked! Major Hotel Chain Pwned! 5yo Finds Auth Bypass on Games Console! Not to mention the GDPR requirements on data, and users expecting more security, stringent security requirements and compliance procedures... what can we do about it?!?

 

Well, for many years, the 'last bastion' of security has been considered to be the 'secure element' - these have taken on many forms, and are sold as 'TPMs' (Trusted Platform Modules) if they conform to one standard, 'HSMs' (Hardware Security Modules) if they are more generic solutions, or just 'secure elements' if they have more specific purposes or featuresets. In general, they are all some sort of hardware device/chip/add-on/module/ancient crystal that when installed properly, gives you security as if by...

 

(actual footage)

 

The tl;dr for the devices is roughly "push the problem down the stack until it lands in specialised silicon, and then leave it to the experts". All very well and good, but how do these work in practice? Well, essentially the idea is roughly as follows:

  1. Purchase ACME Security Module
    1. Optional - Start talking about the 'secure element' or 'HSM Solution' in meetings with important C-level type people (or just anyone) a lot...
  2. Add ACME-SM to the product, and use the default libraries to get it working, knowing that the vendor is a Security Company™, and they've solved the hard problems for you!
  3. Ensure you add the padlock logos everywhere...
  4. Sell a secure product/deploy a secure solution.

Simple, really! Buy a small black box to add to your circuits, and solve the security problems all at once! Ace.

 

But here's the (multi-)billion dollar question - do they actually work? This is something I spend a lot of my time thinking about and devote a significant amount of research time towards. Can we trust these 'all-in-one' solutions, especially for IoT that, let's be perfectly honest here, doesn't have the best reputation nor track record when it comes to security?

 

This is what this blog hopes to look at, and we're starting with a rather exciting solution developed by Zymbit - the Zymkey; security for the Raspberry pi.

 

So, what's the skinny?

 

Tl;Dr - The Zymkey is a 'magic board' you add to the GPIO pins of your Raspberry Pi in order to add security functions, up to and including ECDH, cryptographic verification, LUKSs FDE key management, etc. etc. The modules are really cool - take a look at how they fit onto the RasPi on the zymbit website, with many nice gifs, here: https://www.zymbit.com/zymkey/

 

Their tagline is 'Easy to Integrate. Hard to Penetrate'. The idea is that the device snugly fits onto one end of the RasPi GPIO pin array, you download a few libraries and dependencies, and "you're secure!"

 

Here are the features off the Zymbit website:

  • Multifactor Device ID & Authentication
  • Data Encryption & Signing
  • Key Storage & Generation
  • Physical Tamper Detection
  • Hardware Root of Trust

 

Not a bad smorgasbord of features to shout about! If this works effectively, this module will be a worthy product for those who want to upgrade a standard RPi to have some decent security chops: SSL/TLS should be beefier and faster (with hardware acceleration), FDE should be more secure (with the key part-provided by the module), and anyone physically tampering with the device should be a threat incident that you can prepare for - though I've not see any zymbit-compatible RPi cases that have breakable mesh linings.

 

So what do you get?

The physical hardware is pleasingly minimal:

From the top, you can see the Atmel SAML21 microcontroller - this is the 'main brain' of the module, and looks to be handling all communications between the Pi and the other chips on the module.

 

From the bottom you can see some filter circuits and regulators, and then 3 features:

  • A micro-USB port - this is used as an easy standard interface for the perimeter monitoring
  • Next to this is a small square IC - this is the accelerometer
  • Next to this is a small UDFN that is an ATECC508A - one of Atmel's 'CryptoAuthentication' chips (there is, apparently, another option for the upgraded ATECC608A)

This should give you a good idea of the capabilities of these devices! They're a fairly nice package when mounted as well:

Here are the full feature sets for the Zymkey 4-series modules:

But is that it?

So, here's a few interesting thoughts based on reading the advertising and tech sheets for Zymkey vs. the datasheets for the ICs on the module:

  • The ATECC508A has 16 ECC key slots - designed for ECC private/public key pairs - so the offering of only 3 key storage slots is interesting (might be non-ECC keys that can be generated AND submitted)
  • The RTC requires a battery (not included), but it's a nice facility for maintaining a clock requirement without an internet connection.
  • The Tamper Detection is formed of both the physical wire break detection and the accelerometer. Open or move the device, and the Zymkey will lock down the device immediately, protecting data and IP.
  • The 'TrueRNG' is also on the ATECC508A, though the upgrade datasheet for the ATECC608A states that the latter has better TrueRNG. but both should be an improvement over the default available on the RPi (not that the datasheets are available... )

 

So, interesting outset - let's see how easy it is to setup!

 

Setting up the Zymkey 4i on a RasPi 3B

So, I'm going to be following this guide on Zymbit's website: https://community.zymbit.com/t/getting-started-with-zymkey-4i/202

 

My base is a completely default raspbian installation on a RPi3. Nothing unusual or different - I want to see how easily it works out of the box on a default install. So, first thing's first, I need to enable I2C on my RPi. This is done through sudo raspi-config from the command line, which is easy enough. I also enable SSH whilst I'm there.

 

Next up is the custom code required to interface with the Zymkey, and here is my first minor gripe - the command given to use is as follows:

 

curl -G https://s3.amazonaws.com/zk-sw-repo/install_zk_sw.sh | sudo bash

 

This rings some alarm bells to me, as a security person - it's essentially downloading a script directly into a root user bash shell, which isn't the most secure way of doing things. It would have been nice to see some sort of cryptographic verification step involved here, buuut this might just be me being a security person criticising a security company (I mean, RasPi always prompt you to verify the SHA256 checksum for raspbian images... just sayin'...)

 

So, the script downloads and installs a new repo certificate, installs some dependencies (beware pycurl - that might give you an issue, but can be resolved if you us easy_installer instead of pip), and if all is good, you should install everything no problem!

 

I, however, was not all good. Another niggle I had was this line:

 

apt-get install -y libzk libzymkeyssl zkbootrtc zkifc zkapputilslib cryptsetup &> /dev/null || exit

 

The stdio-to-/dev/null meant that I didn't see the script had failed. It just exits if it fails, which is really annoying as I was wondering why the rest of the setup guide wasn't working (!!!) and was left wondering what I had broken this time. As it happens, it was only a `sudo dpkg --configure -a` to relieve me of my malady, but because the output was invisible the helpful error message from apt-get that instructs you to do this vanished into the cyber-void. NB - The script should reboot the pi afterwards, and if yours doesn't reboot, this may be the issue - just FYI.

 

So what's it like to use?

If you're expecting everything to suddenly turn...

... you're gonna be disappointed...

 

No really...

 

If, however your idea of security is:

...otherwise known as 'Encrypt something, decrypt it and check, and then turn the LED on'... then, my good friend, you're in luck!!

 

I acquired this screenshot from running: python /usr/local/share/zymkey/examples/zk_app_utils_test.py

 

So, what now?

 

So, we have a python API, both C and C++ APIs... so, with that, you're gonna see some ultra-geek über-l33t mega-crypto I-haz-all-the-logarithm-bases crypto APIs, yeah? The kind of documentation that just oozes 'this, is crypto-town, and we don't mean the coins...' right? ... Yeah??....

 

Tl;Dr - No.

 

The documentation for the python API which, given this is for the RPi community which is fairly synonymous with python magic, is very thin on the ground: https://s3.amazonaws.com/zk-sw-repo/zk_app_utils.py.pdf I mean, sure, I know where some files are and what some things are called, but I'm not learning anything from them. The example files in `/usr/local/share/zymkey/examples` are actually fairly useful, so I think I'll start with the python libraries for testing and playing with the module on a working setup.

 

BTW - it passed all the tests!! So, it's very encouraging that this should work.

 

What next?

 

In short, try out all the things! Including:

 

  • Setting up an encrypted volume (maybe not FDE, but some LUKS on-disk volume initially I think)
  • Setup a physical security setup and test that
  • Test the AWS IoT integration - from a security readiness, robustness, and ease of setup points of view.
  • Setup and SSL enabled server or stunnel test.
  • Test the RTC with a battery

 

But, these are future problems! Ciao for now!