CrypTech 2017 Annual Report is now available

The CrypTech End-of-Year Report for 2017 is now available.  It includes a summary of the work completed during 2017 including a new release of software for the CrypTech Alpha focused on improvements and optimizations. The list of accomplishments includes an improved keystore, multicore resource management, Verilog work on ECDSA point multiplier and Ed25519, and various bug fixes and performance enhancements.

Also in 2017, Diamond Key Security was established and is now working collaboratively with CrypTech on long term product development and sustainability for CrypTech.

There is a link to it on the main page or you can find it here:

CrypTech End-of-year Report for 2017

Thanks again to all our supporters for past support and continuing support.

CrypTech version 3 firmware and software now available

This post is from Rob Austein:

The Cryptech Project is pleased to announce that version 3 of our
firmware and software package is now available. Like version 2, this
runs on the Alpha board. For those who have been following, this is
the code that until last week was the “ksng” branch.

Major new features:

* New keystore implementation which supports thousands of keys instead
of six. 🙂

* Support for multiple clients (eg, the OpenDNSSEC “enforcer” and
“signer” daemons) talking to the HSM in parallel.

* Key backup.

* Verilog support for (much) faster key generation and signing on the
ECDSA P-256 and P-384 curves.

See https://wiki.cryptech.is/wiki/ReleaseNotes for more details.

See https://wiki.cryptech.is/wiki/BinaryPackages and
https://wiki.cryptech.is/wiki/Upgrading for information on how to
download the new packages and upgrade the HSM firmware.

Please read the upgrade instructions BEFORE attempting to update the
firmware. The upgrade is a multi-step process, and the keystore
format change triggers a bug in the old bootloader which can brick
your HSM if you perform the upgrade steps in the wrong order.

If you ignored the above or managed to brick your HSM anyway, see
https://wiki.cryptech.is/wiki/DisasterRecovery and
https://wiki.cryptech.is/wiki/UsingSTLink .

Thank you for your patience with how long this has taken. We spent
far more time than we would have liked in a twisty maze of RTOS bugs
(eventually solved by removing the RTOS, see the release notes).

Special thanks to Yuri Schaeffer for help testing both the upgrade
process and the multi-client support with OpenDNSSEC.

Welcome to Berlin

The cryptech project is hosting a 1 1/2 day workshop in Berlin right before the IETF meeting this week. This will be the first opportunity to get hands-on experience with the new rev03 alpha board (depicted below). If you are unable to join us in Berlin but want to play with the alpha, you will be able to order your very own from crowdsupply.com this weekend!

Alpha_rev03_bottom
rev03 bottom view
Alpha_rev03_top
rev03 top view

 

ECDSA

Rob Austein recently announced that cryptech has a software ECDSA signature and verification implementation which runs on the Novena using the Cryptech TRNG. This is another major milestone for the project and enables a whole set of new usecases for cryptech.

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.

Snowden likes us … and also blinkenlights

After the screening of CitizenFour at the Prague IETF there was a q&a with Edward Snowden during which we learned that he not only knows about cryptech but thinks it is a pretty good thing! The team is very happy and proud to to learn this. We are also happy about the good feedback we’re getting from our recent hackathon, like this blogpost from George Michaelson.

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

First dnssec zone signed

Last night in Prague we conducted the first successful “full-up” test: a novena with the cryptech debian packages was successfully used to sign a dns zone using OpenDNSSEC. There are still a bunch of caveats and the project is by no means done but this represents an important milestone for the project. If you have a novena board you can take a look at the instructions for reproducing this test in the cryptech wiki.

Praha open cryptech hackday

The CrypTech team will hold an open hacking workshop in Praha on Saturday 18th of July right before the IETF meeting. This is a great opportunity to become acquainted with the CrypTech software platform using the novena development boards. There will be a limited number of novenas available to play with during the workshop (but we can’t send you home with one unfortunately). We will focus on DNSSEC signing as a use-case.

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://trac.cryptech.is/wiki/PrahaWorkshop

Two new funders: .SE and afnic

We thank two new funders today – .SE and afnic.fr. Both represent TLDs and we hope to see many more from that community contribute to the cryptech project.

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/wiki/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.