[Cryptech Tech] road to berlin

[Paul Selkirk]

(Not a Hope/Crosby movie, or a terrible Xbox game.)

For planning purposes, here are what I think needs to happen between now
and Berlin. This should not be considered authoritative or even
complete; it's mostly the software- and releng-related pieces I've been
thinking about. Also, while work items are numbered, this does not
necessarily imply priority or order of execution.

1. FPGA: The alpha board will have a newer, larger FPGA natively mounted.

To generate the bitstream, we'll use the same Xilinx toolchain, but will
have to update at least the UCF, and port the Spartan-6 modexp core to
Artix-7. Pavel will do the heavy lifting, and I'll update the Makefile.

To configure the FPGA with the bitstream, the initial plan is to use
JTAG. In the longer term, we need a software reconfiguration method
(host -> stm32 -> config memory). This will be initiated through the
admin interface (see below), although it might use the application
interface for the data transfer. Fredrik has offered to help on that,
but we need to work out the details.

2. RPC server: This is the main processing loop on the STM32, which
takes requests over the application interface (USART2), and dispatches
them to low-level software or cores. These are primitive operations
(e.g. hash this, sign that, generate a key). This is pretty much done,
modulo a bit of sanding and polishing; I included it to give a sense of
what the pieces are and how they fit together, absent an actual
architectural document.

3. RPC client: This runs on a PC on the other end of the USB cable.
Currently it's a static library (libhal hal_rpc_* functions), but it
needs to be able to handle multiple clients, with responses coming back
in a potentially arbitrary order, so I *think* it needs to be a shared
library with a communications thread. In any case, it's what I'm working
on now.

4. PKCS #11: Rob wrote a small library, to run on the Novena, directly
over the HAL API. This needs to be ported to the RPC API, which should
be pretty straightforward, but hasn't happened yet. It may be Rob, or it
may be me, it's just kind of floating for now.

5. Administrative interface: The alpha board includes a second USB/UART
interface, which will be a console interface for typing commands. Rob
thinks we should use libcli for this.

Commands will probably include:
- set passwords (wheel, security officer, user)
- create master key
- list keys
- show stats
- self tests
- load system updates (see below)
- set RTC (not sure if this is needed if we're not reading certs on the
device)

As may be apparent, this is currently half-baked. The actual command set
can be white-boarded (and will benefit from folks who actually use
HSMs). The initial implementation can be on Linux with stubs, and then
on the dev-bridge board over the single USB/UART interface.

6. AVR tamper detection: We have an ATTiny828 connected to the Master
Key Memory, and to a tamper circuit (currently a push-button labeled
PANIC). When the unit is tampered, it should wipe the MKM, and ideally
interrupt the STM32. This seems simple enough, but we haven't gotten
around to it yet.

It appears that the AVR is programmed through a 6-pin SPI header with a
usbtiny programmer, but we will need a software-based upgrade path (PC
-> STM32 -> AVR).

I can work on both parts of this (the software, and the upgrade),
although I'll need some help from Fredrik.

7. Field upgrade: This encompasses upgrades to the FPGA, the AVR, and
the STM32 itself. The STM32 is currently programmed through an ST-LINK
cable from a compatible ST board (any Nucleo or Discovery board). Our
backers have awesome technical chops, and may have special programmers
for special chips, but that's not really the way the market works, and
these devices need to be field upgradeable through software. So this
needs to be baked in and tested well before we get to Berlin.

8. Release engineering and packaging. This will build on Rob's work for
Prague last year. Packages will include both the client software,
running on the debian-ish PC, and the field upgrade package, possibly
with an upgrade script that will run through the admin interface. You
can see how far I've gotten into planning this one.

9. Documentation: At the very least, this will include a Quick Start,
for using canned software for dnssec signing. There should be
developers' guides at all levels, from PKCS #11, to the client-side RPC
interface, to the server-side HAL interface, to the FPGA cores. Because
documentation is one of the things we do best.

10. ?? What am I missing?

				paul