Testdriving the CrypTech Alpha Board

Team NLnet Labs -

By Yuri Schaeffer

Last summer there was a CrypTech workshop in Berlin right before the IETF. I did not attend the workshop personally but a mysterious anodized red box appeared on my desk shortly after. It was the CrypTech Alpha Board, an open source hardware cryptographic engine.

At the workshop OpenDNSSEC 1.4 was found to be able to work somewhat with the Alpha board, at that time still heavily being worked on. Naturally I liked to give it a go with the then just released OpenDNSSEC 2.0 and see if it worked (it didn’t).

In theory, since CrypTech implements a PKCS11 interface, OpenDNSSEC should be able to use it as a drop in replacement for SoftHSM or any other HSM. Although installation of the software went smooth it was not ready for prime time back then. One of the first things noticeable was that OpenDNSSEC was slowed down heavily. This wasn’t caused by the slow signing process persé but mainly because it took very long to connect to. Another hurdle was the limited number of slots available for keys. Only 10 keys could be stored. This would make any real setup unpractical. The deal breaker for OpenDNSSEC was however that only one application, in only one thread would be able to access the HSM. All other threads would be blocking until the current thread disconnects. OpenDNSSEC never closes a HSM connection, would have multiple threads per daemon using the HMS, and have multiple daemons involved concurrently. This was not going to fly for OpenDNSSEC.

A winter passed by, and the red box on my desk slowly build up a light gray film of dust. With spring around the corner, while the trees on Science Park released their pollen, a new version of the software and firmware where released. With tears in my eyes (pollen) I set out to test once more whether Cryptech worked with -by now- OpenDNSSEC version 2.1.1 (it did!)

My three major concerns are addressed. Logging in now is a considerably quicker operation than before (5 seconds versus 30). The 10 key limit has been raised considerably. This would be more than 4000 keys depending on the number of attributes stored along side the key. And, most important, a daemon called ‘cryptech_muxd’ is shipped with the software. It multiplexes connections to the HSM so any number of thread now can access the HSM concurrently.

Now it seems to ‘just work’ with OpenDNSSEC!

Further thoughts

  • At this point the performance isn’t stellar. The signer seems to indicate 2 to 3 signatures per second for my small test zone.
  • The device is rather chatty on the USB port. Roughly 200 packets a second back and forth between the muxer and the CrypTech when idle.
  • I do very much like the idea of a fully open HSM which can be reviewed by anyone with enough domain knowledge. However, documentation is not yet to a point where it would be easy for the community to contribute. We are eagerly awaiting more documentation!
  • While stepping through the code I noticed randomness generation is much slower than I expected. I (perhaps falsely) assumed that having it’s own avalanche diode based random generator would provide it with plenty randomness.