(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 _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech