Folks who have been following the tech list recently know that the project engineering team has been busy testing the first 5 alpha boards received from our manufacturer. So far the results are beyond expectation.

All the initial tests show the board working as expected which makes it increasingly likely that we will have a working prototype to share with a wider community in time for the Berlin IETF 96.

We plan to hold a workshop where we hope it will be possible to get your hands on a cryptech alpha on the weekend before the IETF. We will be back with more details as soon as possible!

We are also working on an agreement with Crowd Supply to help us deal with some of the logistics.

Rob goes on to say the following about the ECDSA implementation:

As with the RSA code, does just enough to support what PKCS #11 wants. Includes just enough ASN.1 code to generate signatures (which are small ASN.1 objects for ECDSA) and to save and restore ECDSA private keys using AES-Keywrap.

Internal structure of the code attempts to be modular in a way that should make it easy to drop in Verilog replacements in the obvious places (either for the low-level field arithmetic operators, or, as we’re currently contemplating, for the entire higher-level point multiplier).

Code is written with an eye towards (relative) simplicity, constant-time (to confound timing channel attacks), and an embedded environment (so no unnecessary use of dynamic memory, etcetera). Price tag for some of this is that some of the elliptic curve math algorithms are not the speediest possible; we hope that the Verilog portions will make this a moot point, if not, we’ll revisit.

Opinions vary on how critical constant-time is for ECDSA. On the one hand, every signature uses a new random number, and, since we think we have a pretty good TRNG, this doesn’t give an attacker much to work with. On the other hand, due to the structure of the ECDSA algorithm, an attacker who can guess the random number used for any particular signature can recover the private key, which is as bad as it gets. So we’re into analyzing (very_low_probability * very_bad_outcome), a kind of multiplication problem humans are notoriously bad at solving. I chose to err on the side of paranoia at the cost of speed.

Next steps is to integrate the new set of mechanisms into the PKCS#11 layer.

Update: According to this blogpost from ISOC covering the same event, we were described as “awsome”.

The workshop will start at 9 AM at the Praha Hilton (the IETF conference site) in the Istambul Room. A draft agenda is here: https://wiki.cryptech.is/PrahaWorkshop

Why should a TLD care about cryptech?

The introduction of DNSSEC and the signing of the root zone almost 5 years ago meant that key management became a part of the operational considerations of most TLDs. In some cases TLDs have even begun to consider trust management as part of their business development strategy.
Multiple studies and surveys of the Internet have shown that there is ample room for improvement in the global deployment of technologies such as TLS, RPKI and DNSSEC. This means that trustworthy key management is going to become even more of an issue than it is today, and for even more organizations.

With wider adoption of DNSSEC, it also becomes possible to enable other forms of technical trust using DNSSEC as a foundation (eg DANE) and even though DANE has been largly abandoned for use on the web, its becoming more wide spread for other in other applications.
As DNSSEC is becoming an important foundation for trust, the practice and policies applied to key management for DNSSEC below the TLD will become more important and will be subject to scrutiny by relying parties. This change presents an oportunity and a challenge for a TLD: how to help your customers ”level up” their key management operations in order to be able to support new applications.
One important aspect of key management is the use of HSMs as bearers of cryptograpic key material. The problems involved in deploying the leading commercial HSMs is mostly one of trust and cost , but not always in that order.

Do you trust your HSMs?

The commercial market for HSMs is exceedingly small. Only a handful of vendors – most in countries in the five eyes community, control the entire market which has seen several M&As lately. Anyone who wants to deploy an HSM today is thus left with very few options.
Recently (and independently from the Snowden revelations) some have come to question the trustworthyness of a closed platform HSM but to date there has not been an alternative for high-assurance applications. The cryptech.is reference design has the potential to change that by making it possible for almost anyone to buy or build an HSM that has been developed in a completely open and transparent way.

Can your customers afford an HSM?

A typical HSM that can support high performance signing, costs around 10k-30k USD. With the need for redundancy and backup this quickly becomes a forbidding cost for many organizations.
The cryptech.is reference design will make it possible for new vendors to enter the HSM market by elliminating the development costs. These vendors will base their product on a completely open design and will therefore be much better placed to deliver higher quality at a much lower price point.

The cryptech.is design can be built and sold at a fraction of the cost of current HSM solutions. The ”build it yourself” HSM is however not just a question of cost but also one of trust.

Budget & Timeline

The project is currently one year into a 2-3 year arc with the aim to develop a reference architecture and a prototype HSM implementing this architecture. All results are published under BSD or Creative Commons license (as applicable).
The total budget is estimated at around 2M USD. The project is being run using agile project management methods and planning is done continuously. The project dashboard page [https://wiki.cryptech.is/Dashboard] reflects the current state of work and can also serve as a point of reference for specific work items of possible interest to sponsors. Currently the monthly operating cost for the project is around 50-70k USD.
We solicit sponsorship and collaborative funding up to a maximum of 100k USD per donor per year as the project is trying to avoid any one sponsor having too much influence over the project. We gladly accept any amount either as a one-time or recurring donation.

Why is this so expensive?

The cryptech.is project is trying to produce a complete and fully tested design for an HSM. Among other things, this involves establishing trust in the implementations of cryptographic functions such as true random number generators (TRNG), digital signature algorithms and stream ciphers as well as technical controls such as tamper detection, master key protection etc.
In order to establish ultimate trust in the deliverables, the project cannot rely on (say) the AES implementation bundled with a CPU but must implement all such functions from scratch. In order to reduce the attack surface of the HSM, most cryptographic functions are executed inside a Field Programmable Gate Array (FPGA). Implementing cryptographic primitives in an FPGA is both hard and expensive but the end result should be both secure and highly trustworthy.

In order to further increase trust in the project deliverables, the project is making an effort to be culturally and geographically diverse, This means engaging FPGA programmers, software developers, electronics designers from different parts of the world and with different backgrounds. The core team today includes individuals from the United States, Sweden, and Russia, and this of course contributes to increase overall project costs.
Designing an HSM in this way is expensive but will hopefully yield a design that can support even the most sensitive applications.

We need your support!

The cryptech.is project is a major undertaking which requires access to experts in electronics, trust management, application integration, embedded systems design, FPGA programming etc making this a non-trivial and a much more expensive undertaking than (say) producing a library of cryptographic functions to be run on a general purpose computer.
In order to become a success, the cryptech.is project needs your help and support! With support and funding the project can deliver a foundational component which will help reestablish trust in some of the most important parts of Internet infrastructure.

To fill this need the CrypTech project is developing an open-source hardware cryptographic hardware engine design that meets the needs of high assurance Internet infrastructure systems that use cryptography. The open-source hardware cryptographic engine must be of general use to the broad Internet community, covering needs such as securing email, web, DNSsec, PKIs, etc.

A number of interested organizations has provided funding for development, and public sector cryptographers and security hardware experts provide algorithmic advice and wide and open review.

The resulting open-source hardware cryptographic engine designs are intended to be buildable by anyone from CrypTech’s openly available specifications and the open-source firmware. Anyone can then adapt, modify, and operate it without fees of any kind.

The project is a year in and things are moving along well. There are two prototype platforms; the immediate one is based on the Novena laptop board (see the picture at https://wiki.cryptech.is/), which has an ARM System on Chip (SoC) and an unused FPGA. We expect to deliver an ARM and FPGA package able to do DNSsec signing on the Novena to early testers in late May.

At the same time, we are finishing the specification of a small alpha version of a custom CrypTech board, without all the security exposure of the the Novena’s devices needed to support a laptop. We are specifying key types and signing rates for various applications (DNSsec and RPKI signing, Tor consensus, etc.). In April, we will be selecting a board design house so that we can deliver on the order of a hundred custom prototype CrypTech boards in the summer. It is intended to be an ‘agile’ design, oversizing FPGA, ARM, and memory to be sure it will fit all software; and we expect to use it to get more real design parameters for a second board late in the year.

You can see the status of FPGA code at https://wiki.cryptech.is/Dashboard

You can see the alpha board design specifications at https://wiki.cryptech.is/AlphaBoardStrategy

You can find a recent presentation at http://archive.psg.com/141216.verisign-cryptech.pdf

This winter, we added a Russian FPGA developer to increase diversity and to speed up the hardware level development. We are really pleased with his work.

Up the stack, the C team is starting to integrate the ARM-based software on top of the FPGA EIM interface, and has crypto libraries up to the PKCS#11 border. The PKCS#11 application interface code is the main remaining C development this spring.