diff options
| author | Rob Austein <sra@hactrn.net> | 2021-02-14 01:55:38 +0000 |
|---|---|---|
| committer | Rob Austein <sra@hactrn.net> | 2021-02-14 01:55:38 +0000 |
| commit | b58c60bcc4a6f3d3ccf4194ef862a808fdc3313b (patch) | |
| tree | ad43c2b937db286c2b3320b57066a9581264444a | |
| parent | 23bb68fe7e9cc8af176ff60b56e8a51a70f05a89 (diff) | |
Hack images, store outputs in git again for now
Easier to track what each script change does if we keep the before and
after versions of the markdown in git too. Clean this up eventually,
but simplifies development.
124 files changed, 10680 insertions, 10 deletions
@@ -2,5 +2,5 @@ TAGS attachments trac.db tools/__pycache__ -markdown -tracwiki +#markdown +#tracwiki diff --git a/markdown/ASICImplementations.md b/markdown/ASICImplementations.md new file mode 100644 index 0000000..dc21bf9 --- /dev/null +++ b/markdown/ASICImplementations.md @@ -0,0 +1,106 @@ +# Development of a Cryptech ASIC Implementation + +## Introduction +The aim of the Cryptech project is to develop an open, free, and +auditable HSM. The Cryptech HSM includes both SW and HW parts. In at +least the first iteration of the Cryptech HSM, the HW parts are +implemented using FPGA devices. However, the ability to implement the +HW parts in a Cryptech ASIC device in a future iteration is anticipated +in the design. This text provides a short description of what the HW +part of the Cryptech HSM contains, the design style used, and what would +have to change in order to implement the HW part in an ASIC. + + +## General digital functions and internal memories +The Cryptech digital functionality cores, such as the SHA-256 core, are +written in generic RTL (Register Transfer Level) Verilog code. The code +is written in a fairly conservative coding style and use language +features from IEEE 1364-2001 (aka Verilog 2001). + +All RTL code is divided into modules that contain one process for register updates and reset (*reg_update*), one or more combinational processes for datapath and support logic such as counters. Finally if needed, each module has a separate process that implements the logic for the final state machine that controls the behaviour of the module. + +All cores are divided into a core, for example *sha256_core.v* and a number of submodules the core instantiates. The core provides raw, wide ports (256 bit wide key for AES for example) that is not suitable to use in a stand alone system. Instead each core comes with a top level wrapper, for example *sha256.v*. This top level wrapper contains all registers and logic needed to provide all functionality of the core via a simple 32-bit memory like interface. If the core is going to be used as a tightly integrated submodule, the wrapper can be discarded. Similarly, if the core is going to be used in a bus system that use a specific bus standard such as AMBA AHB, CoreConnect or WISHBONE, only the top level wrapper will be needed to be replaced or modified to match the desired bus standard. + +The RTL code does not explicitly instantiate any hard macros such as +memories, multipliers, etc. Instead all such functions are left to the +synthesis tool to infer based on the code. All memories are placed in separate modules to allow easy modification of the design. In an ASIC setting any memories not automatically mapped will be replaced by instantiation of specific macros. + +Some of the memories in the designs have combinational read (i.e the read +data is not locked by an output register, which infers a one cycle read +latency). For some FPGA technologies these memories are not compatible with the available physical memories. The synthesis tools therefor implement these memories +using separate registers rather than selecting a memory instance. In an ASIC +implementation these memories would likely become real memory macros to allow for a faster and more compact implementation. + + +## Interfaces +External interfaces such as GPIO, Ethernet GMII, UART, etc., will always +require some modification for the Cryptech design to be implemented in a +given technology, whether it is a specific FPGA type or an ASIC. The +important thing is that the Cryptech design does not use technology +specific macros to implement the interfaces. But pin assignments, +timing, and electrical requirements will always require adjustment and +work. + + +## Clocking and reset +The design style used in the Cryptech Verilog code currently follows the +guidelines from the FPGA vendors Altera and Xilinx. This means that we +use synchronous reset. For an ASIC implementation this will also work, +even though asynchronous reset is far more common in ASIC designs. Changing +to asynchronous reset is not a very big undertaking however, as the +register reset and update clocking are separated into easily +identifiable processes (*reg_update*) in the modules. + +Most if not all registers in the Cryptech Verilog code have a defined +reset state. Most registers also have a write enable signal that +controls the update. This corresponds well with the registers available +in FPGA technologies from Altera and Xilinx and their recommended design strategy from the vendors. This is also in line with common +and good design styles for ASICs, which allows for compact code and low +power implementations. The design is currently not use any clock gating. In future revisions this might be added if power consumption needs to be reduced and does not add side channel issues. + + +## External memories +The Cryptech hardware design will use external persistent memories for +protected key storage as well as external SRAM for protected master key +storage. In an ASIC implementation the master key memory would probably +be integrated to further enhance security. + +Just like other external interfaces (see above), the interfaces for the +external memories do not use any explicitly instantiated hard macros in +the FPGAs. + + +## Entropy sources +The current Cryptech design contains two separate physical entropy +sources. + +1: An avalanche noise based entropy source placed outside the FPGA. The +entropy source signal is sampled by the FPGA using a flank detection +mechanism. + +An ASIC implementation would be able to use the external entropy source just like the FPGA. Furthermore, depending on the process options, it might be +possible to have an internal avalanche diode based on ESD structures commonly used in I/O pin implementations. In a power management capable process, functionality available in step-up converters might also be possible to use as internal avalanche noise source. + +Note that integrating the avalanche noise source does not mean that an off-chip noise source is excluded. The Cryptech RNG is modular and having both an internal and an external avalanche noise source is quite possible. + +2: A ring oscillator based entropy source placed inside the FPGA. The ring oscillator used in the FPGA is based on carry chain feedback through adders. An ASIC implementation of this ring oscillator should work and produce noise with similar characteristics. However the specific circuit will have to be characterized with explicit layout and qualified for the given process. + + +## Toolchain +Crypech currently use Verilog simulators for functional verification and commercial FPGA tools for implementation including time analysis. + +An ASIC implementation will require several new tools including tools for synthesis, place & route and static time analysis that is acceptable as sign-off tool by the chip process vendor. + + +## Conclusions +The HW designed for the first iteration of Cryptech is not specifically +designed for FPGA implementation, but is in fact designed in a generic +way to allow for easy implementation using different technologies such +as ASICs. + +There are however parts of the design that will have to be updated or +modified in order to create a good ASIC implementation. The Cryptech +project is confident that we know what those parts are and what they +would entail. + +Developing an ASIC will however require new tools which will incur costs. diff --git a/markdown/AlphaBoard.md b/markdown/AlphaBoard.md new file mode 100644 index 0000000..9dd7fee --- /dev/null +++ b/markdown/AlphaBoard.md @@ -0,0 +1,36 @@ +# Alpha Board + +## Rev 02 + +### Components + + +- ARM Processor: [STM32F429](http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f429-439.html) +- FPGA: [Xilinx Artix-7 XC7A200T-1](http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html) +- Tamper Circuit: [ATtiny828](http://www.atmel.com/devices/ATTINY828.aspx) + + + + +### Status LEDs + +| ID | Color | Meaning | +|---|---|---| +| 01 | Green | ARM LED 2 | +| 02 | Red | ARM LED 4 | +| 03 | Blue | ARM LED 1 | +| 04 | Yellow | ARM LED 3 | +| 05 | Yellow | Application Access USB UART Rx | +| 06 | Green | Application Access USB UART Tx | +| 07 | Yellow | Management Access USB UART Rx | +| 08 | Green | Management Access USB UART Tx | +| 09 | Green | AVR LED 2 | +| 10 | Red | AVR LED 4 | +| 11 | Blue | AVR LED 1 | +| 12 | Yellow | AVR LED 3 | +| 13 | Red | FPGA Config NOT DONE | +| 14 | Red | FPGA LED 3 | +| 15 | Green | FPGA LED 1 | +| 16 | Yellow | FPGA LED 2 | +| 17 | Blue | FPGA LED 0. [Toggles with sys_clk when FMC is active.](https://trac.cryptech.is/browser/core/comm/fmc/src/rtl/fmc_indicator.v) | +| 18 | Green | Power OK | diff --git a/markdown/AlphaBoardComponents.md b/markdown/AlphaBoardComponents.md new file mode 100644 index 0000000..ba8ba53 --- /dev/null +++ b/markdown/AlphaBoardComponents.md @@ -0,0 +1,308 @@ +# CrypTech Alpha Board BOM and PCB design requirement sketch +This document contains a list of component level description and requirements for the Crypteh Alpha board.[[BR]] +The document is to be used as a BOM (Bill Of Materials) and PCB design requirement description for discussing with PCB designers on what we want to have designed.[[BR]] +The block diagram for the Alpha board can be seen at: [wiki:Hardware] + +The Alpha board basically consists of three major sub systems:[[BR]] +1. **The FPGA Sub System**[[BR]] + Used to implement CrypTech crypto/security cores accessible by the CPU as coprocessors.[[BR]] + +2. **The CPU Sub System**[[BR]] + Talks to host systems and handles incoming commands. Basically implements the application interface. + Controls the FPGA Sub System. The CPU Sub System is heavily inspired/based on the CPU parts of the Novena and the iMX6 Rex boards.[[BR]] + +3. **The Tamper Detect Sub System**[[BR]] + Responsible for implementing tamper detection and control/alarm as a separate functionality from the CPU. + On the Alpha board this system is fairly simplistic. But we want to at least have a minor MCU that can run + independently on battery power and control the Master Key Memory (MKM). detect external events and generate + alarms. This allows us to start developing and reason about tamper detection and monitoring separately from the CPU. + +The Alpha board should preferably be a single board with all three sub systems on the same board. + +We are currently using the [Novena] board, and the Alpha board CPU Sub System functionality from is based on the Novena. We also have a trust in the [http://www.imx6rex.com/ "iMX6 Rex"](http://www.kosagi.com/w/index.php?title=Novena_Main_Page) board. Using the the Novena and/or iMX6 Rex as basis for the Alpha board design might (should) be a good way forward. + + +### Authors and timeline/revision history +Joachim Strömbergson, Fredrik Thulin + + +* 2015-03-25: Updates from group and maillist discussions. Sync with the diagram. +* 2015-03-16: Updates from group discussions. +* 2015-03-09: Work started. Initial versions with headers for all blocks. + + + +# FPGA Sub System + +### FPGA +The board should be equipped with a Xilinx Artix-7 200T FPGA device, more specifically XC7A200T FBG484 speed grade -3. + +* [Xilinx Artix-7 XC7A200T FBG484.][[BR]](http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html) +* [Product family overview][[BR]](http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf) + + +The FPGA pad layout should be compatible with the Xilinx Artix-7 FGG484 used by XC7A100T and XC7A75T. + + +### FPGA Clocking and Reset + +* There should be a separate clock, fpga_clk, for the FPGA that starts providing a clock signal at power up. The base frequency for fpga_clk should be 50 MHz. +* There should be a separate reset circuitry for the FPGA that resets the FPGA at power up and make the FPGA read the configuration from the confguration memory. +* The ARM CPU should be able to reset the FPGA to force it reload the confiuration from configuration memory. The CPUY should be able to reset the FPGA by asserting a GPIO. The ability of the CPU to force reset should be possible to remove by removing a jumper. + + + +### FPGA CPU Interface + +* The FPGA is connected to the CPU using the i.MX6 EIM interface. +* The data width is 16 bits. +* The address width is 24 bits. +* The data bus and address bus should be separate buses between the CPU and the FPGA. +* The clock frequency of the EIM interface layout should support 66 MHz clock frequency. +* There should be at least three separate digital signals connected between the FPGA and GPIOs on the CPU to be able to send interrupt/events from the FPGA to the CPU. Things like RSA operation completed to internal alarms. (Slow signals.) + + + +### FPGA Debug Interface + +* The FPGA JTAG interface should be available on a header. The header shall be compatible with the [Xilinx Platform Cable USB II](http://www.xilinx.com/support/documentation/data_sheets/ds593.pdf). + + + +### FPGA Extras + +* 8 LEDs connected to output pins on the FPGA. For general debug uses. +* 4 LEDs connected to output pins on the FPGA. For heartbeat and status signalling. +* 100-mil header with VCC+GND+8 pins connected to pins on the FPGA for general input/output. Slow speed, 3v3 TTL. Some ESD protection would be considered good. + + + +### FPGA Configuration and Configuration Memory + +* The FPGA should read it's bitstream from the FPGA config memory by itself (Master mode). +* The FPGA is connected to the config memory with an SPI interface. + + + +* The ARM CPU should be able to download a bitstream into config memory by stealing the SPI interface. +* The ability to steal the SPI interface is implemented using a transparent MUX controlled by the CPU. The MUX control and the SPI interface to the MUX from the CPU should be possible to remove by removing jumper for the signals mux_ctrl, MISO, MOSI, MCLK. + + + +* Suggestion for FPGA config memory is ["M25P128 EEPROM from Micron"](http://www.micron.com/parts/nor-flash/serial-nor-flash/m25p128-vme6gb), with a jumper controlling the write-enable pin. +* Suggested MUX is the Quad 2-channel Analog Switch: ON Semi. MC14551B [http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF](http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF) + + + +### External RAM and Flash +No external RAM or Flash memories for FPGA application functionality shall be present and is connected to the FPGA on the Alpha board. + + +### Master Key Memory + +* The Master Key Memory (MKM) is a serial SRAM memory. +* The MKM is connected to the FPGA with a SPI interface. + + The MKM is connected to the Tamper Sub System with the same SPI interface. + +* The FPGA can read and write to the memory. +* The Tamper Sub System controller can read and writeto the memory. Optionally the MISO input wire to the Tamper Sub System can be tied low by setting using a jumper. This should cause the tamper controller to only read zeros from the memory and thus only be able to write to the memory. The Tamper Sub System Controller has strict priority over the CPU. Basically an external switch between the memory, the controller and CPU. +* The MKM is powered by a separate power supply using a CR2032 cell battery. The VCC pin connected to the battery should be under control from the Tamper Sub System controller. A transistor or analog switch controlled by the Tamper Sub System controller. + + +Suggested components for the MKM and the switch: + +* Memory: Microchip serial SRAM. 23A640, 8 kByte, 8-TSSOP or 8-SOIC + +[http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf][[BR]](http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf][[BR]) + + +* Quad 2-channel Analog Switch: ON Semi. MC14551B + +[http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF](http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF) + + +### Entropy Sources + +* The avalanche noise entropy source should be implemented according to [attachment:alpha_board_noise_source.pdf existing schematics]. +* The noise source should have a shielding can and suitable ground plane etc. to keep radiation of entropy bits as low as possible. +* The "12-15v stable" VCC should be controllable by the FPGA (enable/disable controlled by output pin on FPGA) to increase life time of components. + + Power requirements for this VCC is < 100 mA (needs measuring, but probably < 50 mA). + + +# Processor Sub System + +### CPU +The main CPU is a ST Microelectronics STM32F429BIT6 Cortex-M4 based MCU running at 180 MHz. The package used is the 208 pin LQFP. + +* [Reference Manual](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/DM00031020.pdf) (pdf) +* [Product Specification](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00077036.pdf) (pdf) +* [Data Sheet](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00077036.pdf) (pdf) + + + +### Host Interface + +* USB interface. USB 2.0 Full Speed compliant. +* USB interface implemented using an external USB-UART interface chip connected to a high speed (3 Mbps capable) UART interface on the CPU. +* Suggested USB-UART component: +* http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf +* LQPF48 packaging + + + +### Authenticator, Management and Backup Interface + +* USB interface. USB 2.0 Full Speed compliant. +* USB interface implemented using an external USB-UART interface chip connected to a high speed (3 Mbps capable) UART interface on the CPU. +* Suggested USB-UART component: +* http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf +* LQPF48 packaging + + + +### External Storage + +* SD Card connected as Micro SD card with 4 bit data interface (like the Novena.) +* Support for at least 2 GByte. + + + +### External RAM +The STM32 CPU supports two separate SDRAM banks. We use both of them with as big SDRAM chips we can find for each bank. The chip used is 64 MByte for a total of 128 Mbyte RAM. + +* ["ISSI IS45S32160F 64 MByte SDRAM with 32 bit data interface"](http://www.issi.com/WW/pdf/42-45R-S-32160F.pdf) + + + +### Real Time Clock + +* Battery backed RTC with calendar/date information. + + Connected to the CPU via serial, SPI or other interface. + +* Suggested chip: Microchip MCP79411 or MCP79412 connected to the CPU via I2C. + + [http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411][[BR]](http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411][[BR]) + [http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf][[BR]](http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf][[BR]) + This chip requires an external 32 kHz crystal. + +* Note: these chips contain per chip unique IDs as well as small EEPROM memory that can be memory protected. + + + +### Keystore + +* The keystore memory is a non volatile memory (NVRAM, EEPROM, Flash) with size of at least 8 MByte +* The keystore memory is connected to the CPU via a separate SPI interface. + + + +### CPU Debug port + +* CPU JTAG on header. + + + +### CPU Misc + +* Four LEDs conneced to the GPIOs on the CPU to allow heartbeat as well as status and debug signalling. +* We want 8 general I/Os with direction controlled by the CPU. The I/O:s should be present on a header. One purpose for these I/O:s is to connect: +* Keypad and LCD display +* Smartcart reader via I2C +* Bitbanged serial port for debugging + + +We may implement this keypad, smartcard reader and display using a simple MCU based board. + + +### CPU Interfaces Needed +SPI Interfaces + +* FPGA Config memory +* Key storage memory +* Master Key memory + + +FPGA Interface + +* EIM interface + + +Asynch serial ports (UARTs) + +* Host interface (high speed) +* Management interface (high speed) +* Tamper Sub System + + +Memory Interfaces + +* DDR3 +* External SD Flash memory + + +GPIOs + +* 3 signals from FPGA to CPU for signalling +* 1 signal from CPU to FPGA reset circuit to force reset +* 1 signal from CPU to FPGA confgig mem mux for control +* 3 signals from Tamper Sub System controller to CPU + + + +# Tamper Sub System +The Tamper Sub System on the Alpha Board is simplistic and does not do a lot of detection. But the sub system should be there to allow us to test and develop tamper detection mechanisms. + +### Tamper Sub System Controller + +* A simple 8-bit MCU. Atmel AVR. +* Suggested chip: ATTINY828R-AU. Has 28 GPIOs which is definitely more than we've used for this design. +* The Tamper Detection Sub System Controlller may need a separate 32 kHz crystal for periodical wake up. + + (The MCU should be able to wake up based on internal clock source.) + +* The JTAG interface for debug and firmware download should be accessible via a header. +* The MCU should at least have four LEDs under GPIO control to allow heartbeat, status and debug signalling. + + + +### CPU interface + +* A simple serial (UART) interface between the CPU and the controller. The serial interface can be removed by removing jumpers. +* One or a couple separate signals for event signalling from the Tamper Detection Sub System to the CPU Sub System. Slow speed 3V3 LVTTL. + + + +### Tamper Detection Mechanisms + +* A separate push button connected to the controller. +* Possibly using the internal temperature detection in the MCU. +* At least four digital input pins on a header for four different digital (HIGH) tamper detection mechanisms. +* At least two digital output pins on a header for four different digital (HIGH) tamper alarms. + + + +### Tamper Power Supply + +* Battery backed. CR2032 cell battery. + + + +# Board Form Factor and Power Supply +## Form factor +Reasonable small to easily fit all functionality +Holes to allow mounting the boards using board distances. + +## Power Supply +Power Supply similar to the Power Supply on the Novena. +7-19V nominal range. 2.5A typical. Max 3A at 12V. + +The board is powered from 18V (or 24V) DC from a standard external power supply. +It should be possible to power the board with a external 110V AC at 60 Hz and 230V AC at 50 Hz. + +The on board power supply block should provide a number of voltage supplies needed by the board. We need at least 5V, 3.3V, 2.5V 1.8V, 1.375V. +We also need a stable, low noise 12V voltage supply to power the Cryptech Avalanche noise source. + +The board designer should provide information about the power consumtion for the board. What is the current required at 12V? diff --git a/markdown/AlphaBoardPictures.md b/markdown/AlphaBoardPictures.md new file mode 100644 index 0000000..08c7d68 --- /dev/null +++ b/markdown/AlphaBoardPictures.md @@ -0,0 +1,12 @@ + +## High resolution pictures of the Alpha board + +Attached to this page are high resolution pictures. + +The current revision of the Alpha board is rev03. + +rev01 was the board known as the 'dev-bridge'. +rev02 was functionally the same as the rev03, but in another form factor. + +[[Image(Alpha_rev03_top_med.jpg)]] +[[Image(Alpha_rev03_bottom_med.jpg)]] diff --git a/markdown/AlphaBoardReview.md b/markdown/AlphaBoardReview.md new file mode 100644 index 0000000..98b3d33 --- /dev/null +++ b/markdown/AlphaBoardReview.md @@ -0,0 +1 @@ +## Alpha board Layout review diff --git a/markdown/AlphaBoardStrategy.md b/markdown/AlphaBoardStrategy.md new file mode 100644 index 0000000..e7f36a2 --- /dev/null +++ b/markdown/AlphaBoardStrategy.md @@ -0,0 +1,57 @@ +# The Cryptech Alpha Board + +## Goal +Develop a first, custom HSM board that can be used to support a first set of applications as well as being used for further development of new functionality as well as security mechanisms such as tamper detection and protection, key storage etc. Deadline is to produce palpable results before summer, 2015. + + +* The use cases and requirements for the alpha board are specified on the [Dashboard](http://trac.cryptech.is/wiki/Dashboard). +* The basic blocks of the Alpha board is [wiki:Hardware "shown here"]. +* The [wiki:AlphaBoardComponents "BOM and component requirements"]. +* The detailed ["Alpha board functional drawing"](http://trac.cryptech.is/browser/doc/design/Alpha_board_drawing.pdf). + + + +## Plan +1. Choose FPGA and ARM (done) +2. Develop BOM, requirements and functional diagram (done-ish). +3. Develop complete [wiki:AlphaSchematics "schematics"] (almost done). +4. Develop dev-board ouorselves to connect chosen ARM to FPGA on Novena, to do some early development and testing in parallell with step 5. +5. Get professional designer to do many-layer PCB from schematics. +6. Manufacture a couple of boards (~10). +7. Bug fix hardware+software. +8. Make beta design. +9. Manufacture more boards (~50). + + +## Way forward + +We currently use the Novena as a dev-board. It has a ["Freescale i.MX6 CPU (ARM Cortex A9)"], and a Xilinx Spartan-6 LX45 CSG324-packaged FPGA.[[BR]](http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&tab=Documentation_Tab&pspll=1&SelectedAsset=Documentation&ProdMetaId=PID/DC/i.MX6Q&fromPSP=true&assetLockedForNavigation=true&componentId=2&leftNavCode=1&pageSize=25&Documentation=Documentation/00610Ksd1nd%60%60Data%20Sheets&fpsp=1&linkline=Data%20Sheets) + +We want to over-size rather than under-size the FPGA on the Alpha board. The biggest FPGA from Xilinx/Altera that does not require tools with a commercial license that we've found is the Xilinx Artix-7 XC7A200T FBG484. + +We've only considered ARM CPUs. Either about the size of Cortex M3 / M4 (or future M7) or Cortex A8 / A9.[[BR]] +A design with an A8/A9 turned out to be unattractive from a complexity and price point of view, so we're going to use one of the biggest M4 we could find. STM32F429. + + +We are currently using a Freescale proprietary interface called EIM between the ARM and the FPGA on the Novena. EIM is not available with microcontrollers from ST, so we will use a similar interface made for connecting the ARM to external memory (called FMC). This interface runs at speeds up to 90 MHz, which is more than we are going to be using with our current FPGA cores. + + + +## Risks at this point + +1. Taking too long deciding on what the Alpha board should contain. +2. Ordering PCB design and manufacturing boards that just does not work for our purposes. +3. Getting Alpha boards that require too much time to get working. + + +## Conclusion + +Use a high-end Cortex-M4 ARM.[[BR]] +There is a huge difference in complexity between M4 and A9, mainly because of the DDR3 memory used with A9. An M4 design will both be easier to design, cheaper to both design and build and will be fast enough for all our early use cases anyways. + + +Do not use the exact same FPGA, as it is too small to fit everything we need.[[BR]] + + +Develop full schematics in-house.[[BR]] +It turned out to be hard, costly or both, to outsource this part. We will probably spend less time developing the schematics ourselves than we would spend explaining what to develop to a third party. diff --git a/markdown/AlphaReviewLog.md b/markdown/AlphaReviewLog.md new file mode 100644 index 0000000..2d49480 --- /dev/null +++ b/markdown/AlphaReviewLog.md @@ -0,0 +1,282 @@ +# Review feedback of the Alpha schematics + +## Power subsystem +|Comment |Who |Resolution |Status | +|---|---|---|---| +|The LTS3060ITS8 is a 8-lead device but the symbol shows only 6 (there are 3 GND leads). | \ +|Kent | \ +|ft to correct mapping of pins between symbol and package | \ +|Done | +|The output capacitor C13 can have higher capacitance. The 2.2 uF is the lowest recommended value and since this is a X7R/25V type it may well fall below that. I recommend 4.7uF to add some margin. C7 may also be changed to 4.7uF. | \ +|Kent | \ +|Updated schematics | \ +|Done | +|LMZ13608 has 11 pins plus an exposed pad (must be connected to pin 5) but only 9 pins are shown in the schematic symbol. | \ +|Kent | \ +|Will change symbol to show both name and pin number(s) | \ +|Done | +|The output voltage for LMZ13608 is calculated as 0.795 V * (1 + R8/R9) which is 4.93 V. It is a bit low for a 5.0 V supply. | \ +|Kent | \ +|5 volts not used, just an intermediate voltage. No change required. | \ +|Done | +|I don't see any SH pin in the datasheet for the LMZ13608 device. Is it the one called NC? | \ +|Kent | \ +|ft check symbol, then ask Pavel to review | \ +|ft done, pavel | +|What form factor and main power supply should we use for the Alpha? | \ +|ft | \ +|Try to find drawing with dimensions for NUC computers, to see if we can use that form factor and power supplies | \ +|Pavel | + + + +## Entropy source +|Comment |Who |Resolution |Status | +|---|---|---|---| +|Add optocoupler as per Jacob's suggestion on tech@ 2015-07-24? The suggestion is to add a fast optocoupler to really isolate AGND from GND. | \ +|Jacob W | \ +| As this appears to require a bigger digitizer, which in turn might require another 3V3 regulator, we don't want to add that to this otherwise quite well tested part of the circuitry for the Alpha. | \ +|Done | + + + +## STM32 +|Comment |Who |Resolution |Status | +|---|---|---|---| +|The JTAG port is not connected. For debug puposes, it could be good to have access to the JTAG port, at least at the prototype board. | \ +|Kent | \ +|We don't know of a reason to add the full JTAG, when we have SWD. At least not if we keep the LQFP package because then we don't think we need to be able to do boundary scan. | \ +|Done | +|The capacitors C22-C25 are connected between VCAP1/2 and VCCO_3V3. According to the datasheet as well as AN4488 they shall be connected to GND. It should be enough with one 2.2uF capacitor for each pin. | \ +|Kent | \ +|Yes, change to GND instead of 3V3. Our interpretation is that we actually should have 2x2.2 for both VCAP1 and VCAP2. We also prefer 2x2.2 over 1x4.7 so not changing that.| \ +|Done | + + + +## 2x512 Mbit SDRAM for the ARM +|Comment |Who |Resolution |Status | +|---|---|---|---| +|U6 has no speed grade specified. TSOP-II package is selected. The BGA package is much smaller and easier to handle in production. | \ +|Kent | \ +|We will investigate packages and speed | \ +|Pavel | + + + +## Keystore memory, 128 Mbit +|Comment |Who |Resolution |Status | +|---|---|---|---| +|Hard to see which resistor is R17 and R18. What is R17 (the left one) intended for? | \ +|Kent | \ +|Fixed the resistors. CS should be connected to ARM, default is "not enabled" through pull-up. | \ +|Done | + + + +## RTC +|Comment |Who |Resolution |Status | +|---|---|---|---| +|From where is 3V3_BATT supplied? Is it an external power source from connector JP3? Or the JP4 jumper? | \ +|Kent | \ +|Yes, external power source connected to JP4. | \ +|Done | +|Do we need a separate RTC chip at all? | \ +|Jacob W | \ +|Keeping it for the Alpha since it is already there. | \ +|Done | + + + +## Micro SD card + +|Comment |Who |Resolution |Status | +|---|---|---|---| +|Which connector to use? Haven't found a good one with Eagle symbol. Some different kinds available. | \ +|ft | \ +|Remove SD card. | \ +|Done | +|Novena seems to have card reset capability (power control from MCU). Do we want the same? | \ +|ft | \ +|Remove SD card. | \ +|Done | +|Novena has two SD slots, and list power at 200mA. Do we need a separate power regulator for the SD card, or can we use VCCO_3V3? | \ +|ft | \ +|Remove SD card. | \ +|Done | + + +## 2x USB UARTs for management and application access +|Comment |Who |Resolution |Status | +|---|---|---|---| +|Should we add an EEPROM for FTDI USB related settings or not? | \ +|ft | \ +|Not adding anything not strictly necessary to the schematics. | \ +|Done | +|LED6 is the same type as LED1 at page 4 but they have different values at their resistors (220/330 ohm). | \ +|Kent | \ +|Went with 330 for consistency. | \ +|Done | +|The recommended protection devices on D+ and D- are missing. | \ +|Kent | \ +|Pavel to look for reference | \ +|pavel | +|Hard to see what reference designators that belong to which component in some places. | \ +|Kent | \ +|Fredrik will improve clarity | \ +|Done | + + + +## AVR Tiny Tamper Detect MCU +Fredrik to verify if Kent had comments about AVR +|Comment |Who |Resolution |Status | +|---|---|---|---| +| | \ +| | \ +| | + + + +## Analog switch controlling access to the MKM +|Comment |Who |Resolution |Status | +|---|---|---|---| +|Suggest changing this chip to an 74AC244 like the one used for the FPGA config memory. | \ +|Pavel | \ +|Will change. | \ +|Done | + + + +## FPGA configuration +|Comment |Who |Resolution |Status | +|---|---|---|---| +|The mode signals are fixed to SPI Master mode. If more flexibility is needed, see next comment, jumpers may be added.| \ +|Kent | \ +|This is intentional. | \ +|Done | +|One-bit data us for the configuration memory makes the configuration rather slow. If higher speed is preferable the SPI memory supports 4-bit data. | \ +|Kent | \ +|Bitstream is around 65 MBit, takes 4-5 seconds to load using single bit (@ 15MHz). We think that should be good enough. | \ +|Done | + + + +## FPGA I/O +|Comment |Who |Resolution |Status | +|---|---|---|---| +|A lot of the FPGA I/Os are unused. For debug purposes some of these can be made available by connecting them to a pin header. Unconnected BGA balls are very hard to use. | \ +|Kent | \ +|Added two more GPIOs from AVR to FPGA and two more from AVR to ARM. Remaining question is how many we should add from FPGA to ARM. | \ +|Pavel | +|A zero ohm resistor at the oscillator output can simplify debug. | \ +|Kent | \ +|Fredrik will add zero ohm resistor | \ +|Done | +|Joachim suggests, that we may want to have some high-speed extension interface for debugging and dumping large amounts of data. For example, we can implement GMII or RGMII using external GbE PHY and GPIO header(s). In that sense, at least one of the GPIO header pins should be connected to clock-capable (MRCC) FPGA pin. | \ +|Pavel | \ +|Pavel will finalize notes in schematics to enable this. | \ +|pavel | + + + +## FPGA voltage regulators +|Comment |Who |Resolution |Status | +|---|---|---|---| +|U14 and U15 have 38 pins but only 11 are visible in the schematic symbol. No pin numbers are visible. The NC pins must not be connected which should be shown.| \ +|Kent | \ +|Fredrik will update symbol to show pins. | \ +|Done | +|I am not familiar with the EN6347Q device so I would add ferrite cores on the outputs, for debug and measurement. Maybe that's what the zero ohm resistors are intended for? | \ +|Kent | \ +|Will change 0-ohm to ferrites. Pavel will look up part number, Fredrik will update schematics. | \ +|pavel, ft| + + + +## FPGA power regulators +|Comment |Who |Resolution |Status | +|---|---|---|---| +|The EN5364 device has 68 pins and 2 exposed pads but the symbol only shows 19 pins, without pin number.| \ +|Kent | \ +|Fredrik will update symbol to show pins | \ +|Done | + + + + +### Additional comments from Kent +I have reviewed the schematic drawings for 'Cryptech Alpha board', rev 02 +(12/28/15), together with the block diagram, rev 0.010 (2015-05-27). I +have spent 8 hours on this review. + + +#### General + +The block diagram does not comply with the schematics: + +|Analog switch replaced by line driver (IC2) | \ +|---| +|Kent | \ +| | +|There is no reset block to the Tamper Detect CPU (U10) in the schematics | \ +|Kent | \ +| | +|I can't find any Reset_n signal to the FPGA (U13) nor any FPGA reset block (maybe it is supposed to indicate the FPGA configuration?). | \ +|Kent | \ +| | +|Interfaces for Smart Card and display/control seems to be missing in the schematics JTAG port for the ARM (U4) is not present in the schematics | \ +|Kent | \ +| | +|JTAG port for the Tamper Detect CPU (U10) is not present in the schematics | \ +|Kent | \ +| | +|Master Key Memory (U12) type is different (23A640 vs 23K640) | \ +|Kent | \ +| | +|Power supply voltages does not comply with the schematics | \ +|Kent | \ +| | +|The battery near the RTC on the block diagram is not present in the schematics | \ +|Kent | \ +| | +|Minor differences in component names (suggestion: remove details from block diagram) | \ + + +|The header information should be updated with design name/ID and author. | \ +|---| +|Kent | \ +| | +|Some components in the schematic (U1, U2, U14, U15, Q3) doesn't show pin numbers which make it harder to review | \ +|Kent | \ +| | +|The sheets seems to have different sizes (1-13 differs from 14-26) and origo is placed in different positions in different pages. Not important but looks a bit odd. | \ +|Kent | \ +| | +|Eagle doesn't seem to have a symbol for unconnected pins. If nothing else, a comment would be good so it is obvious that the pin shall be unconnected and is not forgotten. | \ +|Kent | \ +| | +|On prototype boards it can sometimes be beneficial to insert zero ohm resistances on certain nets, typical clock and reset signals, to simplify debug. Typical places can be voltage regulator outputs and signals that are buried in the PCB. | \ +|Kent | \ +| | +|The selected package for the CPU (U4) is LQFP208. The size is 30x30 mm compared to the TFBGA216 package that is only 13x13 mm. Also, the pitch is 0.5 mm for the LQFP208 while the TFBGA216 package has a ball pitch of 0.8 mm. | \ +|Kent | \ +|Joachim and ft thinks LQFP package makes sense for the Alpha - gives 208 "test points" and physical size not that important | +|For debug purposes it is recommended to place test points for signals that are hard to reach, to simplify measurement. | \ +|Kent | \ +| | + + + +#### Not Reviewed + +A one day review doesn't allow a thorough design review. Some +prioritizations are necessary. I have not reviewed: + +| FPGA pinout. The FPGA vendor tool (Vivado) does some of the checks. It checks that clock signals are placed at clock pins, that selected I/O types are compatible with the bank structure. Vivado can also check that not to much I/O switching power per bank is used and can also calculate power consumption (with correct user input). | +|---| +|Power calculations. The FPGA power is heavily dependent on how it is used. This can be estimated with the Vivado tool. | +|Supply voltage quality. This requires simulations that are out of scope for this review. | +|Power sequencing. | +|Physical properties like PCB symbols, layout issues, thermal design and board area use. | +|Production test or optimization for production. | diff --git a/markdown/AlphaSchematics.md b/markdown/AlphaSchematics.md new file mode 100644 index 0000000..7d20880 --- /dev/null +++ b/markdown/AlphaSchematics.md @@ -0,0 +1,9 @@ +The Alpha schematics are almost finished! + +PDF and Eagle files available for download here in the [[source:/hardware/eagle/alpha/rev02 | hardware]] repository. + +`https://wiki.cryptech.is/browser/hardware/eagle/alpha/rev02` + +The schematics are based on the dev-bridge board that we made in the summer of 2015, which is why it is called rev02. + +We are currently seeking review of the schematics to finalize them before starting layout. A log of various peoples review comments is kept [wiki:AlphaReviewLog here]. diff --git a/markdown/AlphaSealedBags.md b/markdown/AlphaSealedBags.md new file mode 100644 index 0000000..e99dbca --- /dev/null +++ b/markdown/AlphaSealedBags.md @@ -0,0 +1,62 @@ + +## Chain of custody + +At present, we can't make any statements at all about the integrity of the hardware before it reached us - assembled and ready. + +We test and program the Alphas using a dedicated computer, but not in a secure facility by any means. +A concerned user is advised to reprogram the firmware with binaries built from source. + +To provide some assurance the devices have not been tampered with after they have been programmed we put them in sealed bags with individual serial numbers. + +As the model of bags might change over time, we will publish photos of the bags used here as well as PGP signed statements for what serial numbers can be expected. +At this time, we do not keep records of which exact unit was sent to whom. + + + +This is a picture of the currently used bags: + +[[Image(Alpha_tamper_bag_2016-12-16.png, 640px)]] + + + +``` +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA512 + +At 2016-12-16, I put Cryptech Alpha units into sealed bags with the +following serial numbers: + + 26 0 027 233 507 + 26 0 027 233 508 + 26 0 027 233 509 + 26 0 027 233 510 + 26 0 027 233 511 + 26 0 027 233 512 + 26 0 027 233 513 + 26 0 027 233 514 + 26 0 027 233 515 + 26 0 027 233 516 + 26 0 027 233 517 + 26 0 027 233 518 + 26 0 027 233 519 + 26 0 027 233 520 + 26 0 027 233 521 + 26 0 027 233 522 + 26 0 027 233 523 + 26 0 027 233 524 + 26 0 027 233 525 + 26 0 027 233 526 + +/Fredrik +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2 + +iQEcBAEBCgAGBQJYU/MVAAoJEBmMGv1QUVLd+2gH/jLZ7aUGlZ+Iwj6b746Hh6u1 +2JAZ+2tk5tRooTwNb4A5P3ewRcbjA0jPJQQlpVqZcxdt0DDjS16AR0LEaH2rWL++ +sj/OtBm5rqAmVcf1NNvzpC8f8WWgRYhx4nNhWKnEcTBQXT9NbFQhQY0WH3ebupnn +8PK0mX8PpfsjM/3vxtVVLmi+vBsxv0hBcdl+t4IPw/UbzozicF6jZpxRXxVujTE6 +WLGXaCnySS4T1zgtpewfgVMOMouGScUw5n2yHRZJpissGUVJtuPrOEmNFvDz7LRD +i00Rc4i2emsKTgKrkMIKyQWSqFIQ1nBUQ5B5ES1Q50432cppbyEW2rJJZjAuxgM= +=s2D5 +-----END PGP SIGNATURE----- +``` diff --git a/markdown/AssuredTooChain.md b/markdown/AssuredTooChain.md new file mode 100644 index 0000000..89ea7d9 --- /dev/null +++ b/markdown/AssuredTooChain.md @@ -0,0 +1,16 @@ +# Issues of an Assured Tool-Chain + +We do not have any assurance that our basic tools are not compromised. + +* Compilers +* Operating Systems +* Hardware Platforms +* Verilog and Other Tools to Produce Chips + + +At the base, is the compiler. The fear was first formally expressed in +Ken Thompson's 1984 Turing Award Lecture +[Reflections on Trusting Trust](http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf). + +David A. Wheeler's PhD thesis, [Fully Countering Trusting Trust through Diverse Double-Compiling](http://www.dwheeler.com/trusting-trust/) +outlines how we might deal with the compiler trust conundrum. diff --git a/markdown/BerlinWorkshop.md b/markdown/BerlinWorkshop.md new file mode 100644 index 0000000..0c7da32 --- /dev/null +++ b/markdown/BerlinWorkshop.md @@ -0,0 +1,63 @@ +# CRYPTECH Workshop Agenda +### 15-16 July 2016 + +Intercontinental Berlin +Budapest Str. 2 +10787 Berlin, Germany + +Meeting Room: Köpenick III + +Cost of attendance: None + +Alpha Board cost: if you are an alpha tester and plan to take an alpha board home with you, we would like to recover cost for these boards from you. We are asking for 800USD. We plan to collect the money through [crowdsupply](https://www.crowdsupply.com/cryptech/open-hardware-security-module). + +## Draft Agenda + +### Friday 15 July +| 0830 | Coffee +|---| +| 0930 | Introductions, setup +| 1000 | Presentation of the cryptech alpha device +| | - cryptech overview (attachment:2016-07-15-berlin-main.pdf) +| | - overall hardware architecture (attachment:2016-07-15-berlin-hw.pdf) +| | - the FPGA (attachment:2016-07-15-berlin-fpga.pdf) +| | - HSM software architecture, CLI, and RPC mechanism (attachment:2016-07-15-berlin-sw.pdf) +| | - PKCS11, client-side software, how to configure the board (attachment:2016-07-15-berlin-fw.pdf) +| 1100 | Break +| 1130 | Hands-on testing +| | - get binary packages running on participants' own laptops ([[BinaryPackages]]) +| | - [[OpenDNSSEC]] is a guide for how to initialize a rev03 board and use it to sign a zone using OpenDNNSSEC - use as a baseline for own testing and experimentation with PKCS11-based applications. +| 1230 | Buffet lunch +| 1330 | Hands-on testing continues +| 1500 | Coffee break +| 1530 | Hands-on testing continues +| 1700 | Finish day one + + +### Saturday 16 July +| 0900 | Hands-on testing continues +|---| +| 1030 | Coffee break +| 1100 | Workshop wrap-up +| | - outstanding questions +| | - feedback from the participants +| | - opportunity to articulate what participants will need that isn't readily available +| 1300 | Finish + + +## What you need to bring +During the workshop you will have access to the cryptech platform using +a PKCS11 interface (reviewing PKCS11 might be a good way to prepare for +the workshop). We will use OpenDNSSEC (using PKCS11) as a reference +use case but you are encouraged to think about other applications that +use PKCS11 you want to test. We will be there to help and will do our +best to fix stuff that breaks along the way. + +Bring a laptop with 2 USB 2.0 ports free (or a USB hub) running either +MacOS or Debian Linux. We will provide client PKCS11 software +packages for Debian Jessie and Ubuntu Xenial, and Homebrew for MacOS. You +will use one USB port for PKCS11 and one USB port for admin CLI access +to the cryptech device. + +For admin access you will find useful some form of serial console application +capable of handling 921600 bps line speed. diff --git a/markdown/BinaryPackages.md b/markdown/BinaryPackages.md new file mode 100644 index 0000000..632299b --- /dev/null +++ b/markdown/BinaryPackages.md @@ -0,0 +1,154 @@ +[[PageOutline]] + +# Binary Packages for Cryptech Software and Firmware + +The Cryptech Project maintains APT and Homebrew repositories +containing packaged software for the Cryptech Alpha board for Debian +and Ubuntu Linux and for Mac OS X. The binary packages also include +pre-compiled images for the Alpha Board's Artix-7 FPGA, Cortex M4 ARM +CPU, and AVR ATtiny828 MCU. + +## How to get APT packages for Debian Stretch, Debian Buster, Ubuntu Xenial, or Ubuntu Bionic + + +* Fetch and validate the repository key. Presumably you're security + + concious (otherwise, why are you installing this stuff?), so you may + want to pay attention to what `gpg --check-sig` says here. + + ``` + $ id=37A8E93F5D7E7B9A + $ wget https://apt.cryptech.is/apt-gpg-key.gpg + $ gpg --recv-key $id + $ gpg --check-sig $id + ``` + + +* Install the repository key. We used to use `apt-key(8)` for this, + + these days the cool kids use the `/etc/apt/trusted.gpg.d/` directory: + + ``` + $ sudo chown root:root apt-gpg-key.gpg + $ sudo mv apt-gpg-key.gpg /etc/apt/trusted.gpg.d/cryptech.gpg + ``` + + +* Configure apt to use the repository. You need to add a couple of + + entries to `/etc/apt/source.list.d/`; which entries you need to add + depends on which distribution you're running. + + * For Debian Stretch, do: + ``` + $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.stretch.list + + ``` + + * For Debian Buster, do: + ``` + $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.buster.list + + ``` + + * For Ubuntu Xenial, do: + ``` + $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.xenial.list + + ``` + + * For Ubuntu Bionic, do: + ``` + $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.bionic.list + + ``` + + + +* Update the package index. + + + ``` + $ sudo apt-get update + ``` + + +* Install the `cryptech-alpha` package. + + + ``` + $ sudo apt-get install cryptech-alpha + ``` + +## Updating APT packages + +Once you've performed the steps above you should be able to upgrade to newer +version of the code using the normal APT upgrade process: + +``` +$ sudo apt-get update +$ sudo apt-get upgrade +``` + +## How to get Homebrew packages for Mac OS X + + +* Fetch and validate the repository key. Presumably you're security + + concious (otherwise, why are you installing this stuff?), so you may + want to pay attention to what `gpg --check-sig` says here. + + ``` + $ id=37A8E93F5D7E7B9A + $ gpg --recv-key $id + $ gpg --check-sig $id + ``` + + +* Configure Homebrew to use the repository. + + + ``` + $ brew tap cryptech/sw https://brew.cryptech.is/tap + ``` + + +* Update the package index. + + + ``` + $ brew update + ``` + + +* Check the commit signature on the cryptech-alpha package formula. + + This is optional (Homebrew doesn't care whether you do this), but if + you want to know whether the formula was signed by the Cryptech + project, this is how to check. + + ``` + $ brew log --max-count=1 --show-signature cryptech-alpha + ``` + + +* Install the `cryptech-alpha` package. At the moment, this is only + + available as a Homebrew source package due to licensing issues in + the MacOS Xcode SDK, so the installation will probably take several + minutes, as some of the libraries are a bit slow to compile (sorry...). + + ``` + $ brew install cryptech-alpha + ``` + +## Updating Homebrew packages + +Once you've performed the steps above you should be able to upgrade to newer +version of the code using the normal Homebrew upgrade process: + +``` +$ brew update +$ brew upgrade +$ brew cleanup +``` diff --git a/markdown/BuildingFromSource.md b/markdown/BuildingFromSource.md new file mode 100644 index 0000000..8f2a4fd --- /dev/null +++ b/markdown/BuildingFromSource.md @@ -0,0 +1,229 @@ +[[PageOutline]] + +# Building Cryptech Software/Firmware/Bitstream From Source + +Everything you need to build our software, firmware, and FPGA +bitstreams from source yourself is publicly available, but the process +is a bit complicated. Overall, there are two methods, one of which +our developers use while writing this stuff, the other of which we use +for the automated reproducible builds which go into our binary +distributions. Both methods eventually boil down to "get the source +code then run make", but the details differ. + +## What developers do + +We check out copies of all the several dozen separate repositories and +carefully arrange them in a tree structure which matches the official +naming scheme. Yes, really. It's tedious, but we have +[export:/user/sra/build-tools/https-sync-repos.py a script to automate this]. +Be warned that this script is a kludge which relies on parsing +XML from this Wiki; this is nasty, but reasonably stable, because the +XML itself is generated by another script. + +Once you have this tree, you can hop around within it, building +whichever bits are of interest to you. So if you want to rebuild just +the HSM firmware (the C code that runs on the ARM), you would go to +`sw/stm32` and run `make` there. + +## What we do for reproducible builds + +Reproducible builds use the same tree structure (as they must for the +various Makefiles to work properly), but the entire tree is embedded +in a git "superrepository" which also contains the release engineering +goo necessary to make the whole thing work. Do `git help submodule` +for an introduction to git's submodule mechanism. + +With this model, one just checks out a copy of +[source:/releng/alpha the superrepository], +runs `make` in its top directory, and eventually +the complete package pops out the other side. + +``` +git clone https://git.cryptech.is/releng/alpha.git +cd alpha +make +``` + +That's the good news. The bad news is that this process has higher +demands on its build environment: it expects to find the a complete +tool set, including the XiLinx synthesis tools, the several different +cross compilers for the firmware, and the `pbuilder` system for +building clean room packages for Ubuntu and Debian. + +As a compromise, one can use this source tree as if it were the +development source tree described above: just use the supermodule to +pull down everything else, but then ignore the supermodule and build +individual pieces as if you'd checked out all the repositories by +hand. + +## Skip all this git mess and just download a tarball + +There's another alternative, which is simpler than any of the above: +just download the source tarball. Since the only build environments +we support at the moment are Debian Jessie and Ubuntu Xenial, which +also happen to be environments for which we build binary packages, you +can just use APT: + +``` +apt-get source cryptech-alpha +``` + +Which will give you the same tree structure, but without all the git fun. + +## Build environment + +Our software and firmware developers use the Debian and Ubuntu Linux +distributions. Our current build box for binary packages runs Debian +Jessie. + +Our Verilog developers use various environments and have been known to +use graphical tools, but synthesis of the bitstreams that go in our +binary packages is done via the XiLinx command line tools on the same +Debian Jessie machine as the software and firmware builds. + +Which tools you need will of course depend on exactly what you're +trying to do. + +Most of the tools work on either 32-bit or 64-bit machines, but if you +intend to run the full binary package build script, you'll need a +64-bit machine (or VM) because the tools won't build 64-bit binaries +on a 32-bit machine. + +Basic tool set (not all required for every purpose, but they're all +supported Debian packages so it's usually easier just to install them +all and not worry about it): + +``` + apt-get install git pbuilder ubuntu-dev-tools rsync sudo + apt-get install python-yaml python-serial python-crypto python-ecdsa + apt-get install gcc-arm-none-eabi gdb-arm-none-eabi + apt-get install gcc-avr binutils-avr avr-libc + apt-get -t jessie-backports install debootstrap distro-info-data + apt-get install reprepro ubuntu-archive-keyring +``` + +This is not an exhaustive list, because some of the other packages we +use are pulled in by these as dependencies. + +You will also need a copy of the XiLinx tools, which is tedious enough +that it's described in a separate section, below. + +Once you have all the tools installed, you'll need a copy of the +source tree, as explained in the preceeding sections. + +pbuilder requires a bit of setup (you can skip this if you're not +trying to do the full binary package build): + +``` +for code in jessie xenial; do for arch in i386 amd64; do pbuilder-dist $code $arch create; done; done +ln -s jessie_result ~/pbuilder/jessie-amd64_result +ln -s xenial_result ~/pbuilder/xenial-amd64_result +``` + +## Installing the XiLinx tools + +XiLinx tools setup is a bit involved. You can skip this section if +you don't intend to build FPGA bitstreams. + +We use the command line versions of the XiLinx tools, but installing +them requires a graphical environment, because the XiLinx installer +and license manager are GUI tools. If you're running this on a server +and don't already have a graphical environment installed, you can get +away with something fairly minimal. For example, if you have a VNC +viewer such as "Chicken of the VNC" on your laptop, you can get away +with a fairly minimal X11 toolset: + +``` +apt-get install tightvncserver xterm icewm +``` + +If you're already running X11 on your laptop and are comfortable with +extruding that to the build machine, eg, via `ssh -Y`, you can just +use that (not recommended for long-haul use, eg, if the laptop is in +Boston and the server is in Reykjavik). + +You'll need to start by using a web browser to download the +[Xilinx ISE Design Suite](http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html). + +XiLinx only supports specific versions of Red Hat and Suse Linux, but +their tools do run on Debian and Ubuntu. A few caveats: + + +* Debian and Ubuntu symlink `/bin/sh` to `/bin/dash`, which can't handle + + some of the syntax used in XiLinx's shell scripts, so you'll need to + change that symlink to point to `/bin/bash`. + + +* Although the XiLinx software can be installed as user or root, by + + default it wants to install into /opt/Xilinx, so you need to install + as root if you want to do that. + + +* The XiLinx tools are disk hogs, so if you're building a VM for this, + + you'll probably want to give it at least 30-40 GB of disk space. + +Step-by-step installation: + +1. Unpack `Xilinx_ISE_DS_Lin_14.7_1015_1.tar` (or whatever version you have). +2. In an X11 environment, cd to `Xilinx_ISE_DS_Lin_14.7_1015_1`, and run `sudo ./xsetup` +3. Click through two screens of license agreements. +4. Select `ISE WebPACK`. +5. Unselect (or leave unselected) Install Cable Drivers. +6. Go! + +Well, not quite. You'll need to convince the ISE tools that you have +a valid license to use the ISE tools. Go to +http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm, +click the `Licensing Solutions` link. On the page to which that takes +you, expand the section `Obtain a license for Free or Evaluation +product`. To download the ISE Webpack, you should have created an +account, so now you can go to the Licensing Site and use that account +to create a Certificate Based License. + +You do not need to go through the HostID dance, just say Do It. You +will then receive a certificate in email (not an X.509 certificate) +which you will be able to use. Then start the ISE Webpack by issuing +the command `ise`. Go to the Help menu and Manage Licenses. Use the +resulting new License Manager window to install the `.lic` file. This +process is complex and flakey. + +Here's +[another description of installing ISE on Ubuntu](http://www.armadeus.com/wiki/index.php?title=ISE_WebPack_installation_on_Linux). + +The `ise` binary referred to above is in `/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise` +(or in `.../lin/ise`, but the pbuilder setup requires a 64-bit build machine). + +When running this remotely under tightvncserver, setup looks something like this: + +``` +vncserver :0 -geometry 1280x768 -depth 16 -localhost +export DISPLAY=:0 XAUTHORITY=~/.Xauthority +icewm& +``` + +Then, either in the same shell as the above or in an xterm in the new display + +``` +cd Xilinx_ISE_DS_Lin_14.7_1015_1 +sudo ./xsetup + +cd +/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise +``` + +It turns out you don't really need to run the whole `ise` tool to +get to the license manager, you can just run + +``` +/opt/Xilinx/14.7/ISE_DS/common/bin/lin64/xlcm -manage +``` + +But you do have to source the appropriate settings file first, none of +the XiLinx tools work properly without that: + +``` +. /opt/Xilinx/14.7/ISE_DS/settings64.sh +``` diff --git a/markdown/ConfigureFPGA.md b/markdown/ConfigureFPGA.md new file mode 100644 index 0000000..8a4beab --- /dev/null +++ b/markdown/ConfigureFPGA.md @@ -0,0 +1 @@ +*Page Under Development* diff --git a/markdown/CoretestHashesC5G.md b/markdown/CoretestHashesC5G.md new file mode 100644 index 0000000..7cc2e30 --- /dev/null +++ b/markdown/CoretestHashesC5G.md @@ -0,0 +1,534 @@ +# How to start using coretest_hashes on the TerasIC C5G Board +This is a writeup on how to setup, build and testrun the coretest_hashes +Cryptech subsystem on a TerasiC C5G Cyclone V GX Starter Kit FPGA +development board [1]. + + +## Introduction +### Test Setup +The test setup consists of: + +- A development computer running the Altera Quartus II FPGA development software. This computer will be building the FPGA comfiguration image (a sof-file) and then use the Altera USB-blaster to load the image into the FPGA on the TerasIC board. This computer shall therefore be connected to the USB-blaster port on the TerasIC board. + + + +- A host computer that runs the hash_tester application that communicates with the FPGA design downloaded into the FPGA and perform tests on the hash functions. The host computer is connected to the USB-serial port on the TerasIC board. + + + +- The TerasIC Cyclone 5 GX Starter Kit (C5G) board. + + +[[Image(http://www.terasic.com.tw/attachment/archive/830/image/image_74_thumb.jpg)]] + +*The TerasIC Cyclone 5 GX Starter Kit board.* + +The USB ports are the shown in the upper left corner. These are USB type B ports. The port to the left is the USB-blaster port. The port to the right is the USB-serial port. In the bottom right corner there is a row of buttons and just above them 8 LEDs. These will also be used by the coretest_hashes subsystem. There is a HDMI port on the C5G board but it will not be used. All communication is done in CLI on the host computer. + +**NOTE: You don't actually need two separate computers. You can use one computer with one or two USB ports. If you only have one USB port you will need to switch from connecting to the USB-Blaster port to the USB-serial port on the C5G board once the coretest_hashes FPGA configuration has been downloaded to the board.** + +My personal setup is a laptop with two USB ports which allows me to have connections to both USB ports on the C5G boards simultaneously. + + +### Coretest_hashes +The coretest_hashes is a subsystem that is a FPGA design that contains Cryptech application cores as well as support cores used to run tests of the +SHA-1 and SHA-256 hash functions from a host computer via a serial +interface connected to a FPGA device. The subsystem consists of: + + +- [browser:/core/sha1 "sha1"]: A HW implementation of the SHA-1 hash function. + + + +- [browser:/core/sha256 "sha56"]: A HW implementation of the SHA-256 hash function. + + + +- [browser:/core/coretest "coretest"]: A command parser that accepts read/write commands from a + + host, executes the commands and sends the response. + + +- [browser:/core/usrt "uart"]: A simple serial interface that connects coretest to the host. + + + +- [browser:/core/coretest_hashes "coretest_hashes"]: A top level wrapper that connects all the cores as + + well as connecting the rxd and txd ports on the uart to external pins as well as clk and reset. This core repo also contains the Python command line program hash_tester we will be using to talk to coretester and perform tests of the sha1 and sha256 cores. + +[[Image(coretest_hashes.png)]] + +*The coretest_hashes subsystem with sha1 and sha256 cores. The system is connected to a host computer via a serial interface.* + +## SW and system requirements +You need to download and install the Altera Quartus II Web Edition +software [2]. There are versions of Quartus II Web Edition for Windows and Linux. I'm using the Windows version, but Linux **should** work too. + +You will probably also install drivers for the Altera USB-blaster in order to program the FPGA on the development board. For instructions on how to install the driver, please see the Altera page for USB-blaster [7]. + +For communication with the coretest_hashes in the FPGA we will be using the USB-serial device on the development board. The USB-serial chip on the +board is a FTDI FT232R [3]. If your host OS does not have support for this device you will need to install drivers. For Windows the correct file to download seems to be a VCP file [7]. + +Finally, in order to talk to coretest_hashes from the host there is application SW. This SW is written in Python and uses the Pyserial[5] library. If you don't have Python and/or Pyserial installed you will need to install that too. + +**NOTE: Python and Pyserial does not have to be installed in the same OS as Quartus II but can be run from a separate system and OS.** + +(I'm using Quartus II 13.1 64-bit version running in Win8.1 in a VM in Parallels Desktop in OX 10.9.2 during this writeup. And I use Python and Pyserial in an iTerm in OSX for the serial communication.) + +With all this SW installed you should be ready to proceed to create the +coretest_hashes project. + +**I also recommend that you download the TerasIC C5G User Manual [4]. It is a really good document that describes the boards with all functions, pins etc.** + + +## Downloading the cores +Create a project directory. I'm using test_coretest_hashes. In it I add +a core directory and a toolruns directory: + +``` +#> ls test_coretest_hashes +cores/ toolruns/ +``` + +The cores we need to build the subsystem must be downloaded from the +Cryptech server. The cores we need are: + + +- sha1 +- sha256 +- uart +- coretest +- coretest_hashes + + +``` +#> cd cores +#> ssh git@git.cryptech.is +hello <FOO>, this is git@cryptech running gitolite3 v3.5.2-0-g926bd5f on git 1.9.0 + + R C [a-zA-Z0-9].* + R W core/coretest + R W core/coretest_hashes + R W core/coretest_test_core + R W core/sha1 + R W core/sha256 + R W core/test_core + R W core/uart + R W doc/presentations + R gitolite-admin +Connection to cryptech.is closed. +``` + +We can see the relevant cores and check them out one by one: +``` +#> git clone git@git.cryptech.is:core/sha1.git +#> git clone git@git.cryptech.is:core/sha256.git +#> git clone git@git.cryptech.is:core/uart.git +#> git clone git@git.cryptech.is:core/coretest.git +#> git clone git@git.cryptech.is:core/coretest_hashes.git +``` + +We should now have a cores directory like this: +``` +#> ls +coretest/ coretest_hashes/ sha1/ sha256/ uart/ +``` + +In each of these cores there are RTL and testbenches needed to simulate +and build each of them. For example the sha1 core contains: +``` +#> cd sha1 +#> ls +LICENSE.txt README.md src/ toolruns/ +``` + +The sha1 RTL source is in src/rtl. Lets take a look: +``` +#> cd src/rtl +#> ls +sha1.v sha1_core.v sha1_w_mem.v +``` + +These files are: + +- sha1.v: A top level wrapper that provides an interface to the core. In + + this case a 32-bit memory like interface. + + +- sha1_core.v: The actual SHA-1 hash function core. + + + +- sha1_w_mem.v: The W memory including sliding window functionality used + + by the core. + +The other cores follows a similar pattern with a top level wrapper named +<core_name>.v, the main functionality in <core_name>_core.v and then one +or more submodules. + + +## Creating the project in Quartus + +- Start Quartus and select file/new... and select New Quartus II + + Project. + + +- Select destination directory to be toolruns/ in your project + + directory. + + +- Set 'coretest_hashes' as name of the project + + + +- Set 'coretest_hashes' as nem of the top level design entity. (Should be + + done automatically when entering the name of the project.) + + +- Press next. + + + +- You should now be on the 'Add Files' page. Press '...'. + + + +- Navigate to test_coretest_hashes/cores/coretest/src/rtl. + + + +- Select coretest and press 'Open'. (Note: Quartus seems to sometimes omit the .v suffix + + for the files depending on Windows/OS version.) + + +- Back on the 'Add Files' page. Press Add to actually add coretest to + + the project. + + +- Press '...' again and navigate to the rtl directory in + + coretest_hashes. Add it like you did with coretest. + + +- Navigate to test_coretest_hashes/cores/sha1/src/rtl and add the files sha1, sha1_core, + + sha1_w_mem. This time you don't need to press 'Add' on the 'Add + Files'. It is done automatically when adding more than one file at a + time. + + +- Navigate to test_coretest_hashes/cores/sha256/src/rtl and add the files sha256, sha256_core, + + sha256_k_constants, sha256_w_mem. Do **NOT** add the file wb_sha256. This file contains an alternative top level wrapper to the one in sha256.v that instead provides a ["WISHBONE"](http://opencores.org/opencores,wishbone) interface. This interface is not used in the coretest_hashes design. + + +- Finally navigate to test_coretest_hashes/cores/uart/src/rtl and add uart, uart_core. + + +Back on the 'Add Files page you should now see a list of source files: +``` +../cores/uart/src/rtl/uart_core.v +../cores/uart/src/rtl/uart.v +../cores/sha256/src/rtl/sha256_w_mem.v +../cores/sha256/src/rtl/sha256_k_constants.v +../cores/sha256/src/rtl/sha256_core.v +../cores/sha256/src/rtl/sha256.v +../cores/sha1/src/rtl/sha1_w_mem.v +../cores/sha1/src/rtl/sha1_core.v +../cores/sha1/src/rtl/sha1.v +../cores/coretest_hashes/src/rtl/coretest_hashes.v +../cores/coretest/src/rtl/coretest.v +``` + +Press 'Next' to get to the 'Family & Device Settings' page. + + +- In 'Device Family', 'Family' list select 'Cyclone V (E/GX/GT/SX/SE/ST)'. + + + +- In 'Device Family', 'Devices' list select 'Cyclone V GX Extended Features' + + + +- In the 'Available Devices' list select: 5CGXFC5C6F27C7. + + +Press 'Finish'. + + +## Setting up and building the FPGA design +You should now be in the main Quartus II window. In the project +navigator you can see all files, open the source files etc. + +You could now just press 'Start Compilation' button in the menue row +(the purple play/triangle button.) This will build the complete +subsystem for the type of device selected. But the generated FPGA configuration image will not map to the correct pins on the C5G board. But this build should go through without errors or warnings related to problems in the source files. It is therefore a good test to see that all files has been included. + +The result from this generic build should be a FPGA configuration that +uses 3666 registers, 2846 ALMs, 12 pins and can run at 88.3 MHz in worst +case temperature and timing. + +You now need to define the correct pins and define the clock to allow +Quartus to create a FPGA configuration for our board. + +All pins needed are described in the C5G manual. To save time there is +also a pin list available in the coretest_hashes directory. + + +- Navigate to test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g + + + +- The file coretest_hashes.qsf contains assignments for a project like + + the one we are setting up. It contains the pin assignments. The + follwing list is a slightly cleaned up version of the pin assignments: + +``` +set_location_assignment PIN_R20 -to clk +set_location_assignment PIN_P11 -to reset_n +set_location_assignment PIN_M9 -to rxd +set_location_assignment PIN_L9 -to txd +set_location_assignment PIN_L7 -to debug[0] +set_location_assignment PIN_K6 -to debug[1] +set_location_assignment PIN_D8 -to debug[2] +set_location_assignment PIN_E9 -to debug[3] +set_location_assignment PIN_A5 -to debug[4] +set_location_assignment PIN_B6 -to debug[5] +set_location_assignment PIN_H8 -to debug[6] +set_location_assignment PIN_H9 -to debug[7] +set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to clk +set_instance_assignment -name IO_STANDARD "1.2 V" -to reset_n +set_instance_assignment -name IO_STANDARD "2.5 V" -to txd +set_instance_assignment -name IO_STANDARD "2.5 V" -to rxd +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[0] +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[1] +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[2] +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[3] +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[4] +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[5] +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[6] +set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[7] +``` + +As you can see, for each pin we want to use we need to define the actual +pin in the FPGA (PIN_R20 for example) and the I/O standard the pin +should use/support. + +In this design I've mapped the reset signal to the button 'KEY0' on the +board which you can find in the lower right corner. There is also a +debug port that in the coretest_hashes design is connected to the debug +port in the uart. This allows us to see byte values received by the +uart. This debug port is connected to pins that control the green LEDs +just above the row of buttons that includes 'KEY0'. + +In order to enter the pin assignments select 'Assignments' in the +Quartus top level menue bar. The select 'Assignment Editor'. Then either +manually enter each of the assignments above. This will require two rows +for each pin. For example for the clock ('clk') we would enter: + + +- Row 1: 'To': clk, 'Assignment name': Location, 'Value': PIN_R20 +- Row 2: 'To': clk, 'Assignment name': I/O Standard, 'Value': 3.3-V LVTTL + + +An easier way is to open up the file coretest_hashes.qsf in test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g and add the pin assignment from that file to your qsf file in test_coretest_hashes/toolruns. If you then open up the Assignments Editor the same definitions should be shown. + +We now need to define the clock. Under 'Assignments' in the top level +menue select 'TimeQuest Timing Analyzer Wizard'. Press 'Next' to get +from the 'Intro' page. + +Under 'Specify base clock settings' enter 'clk' as 'Clock Name' and +'Input Pin'. Enter '20' in 'Period' and note that 'ns' is selected as +time scale. In the 'Equivalent SDC Commands' you should see: + +``` + create_clock -name "clk" -period 20.000ns [get_ports {clk}] +``` + +Now press 'Next' four times to get to the final page and then press +'Finish' to complete the clock setup. If we now look in the +test_coretest_hashes/toolruns directory there should be a file called +coretest_hashes.sdc that contains the SDC command above. + +Now we are ready to build the real FPGA configuration. Press the purple +'Start Compilation' button again. After build we should now have an FPGA +configuration that requires 2852 ALMs, 3666 registers, 12 pins and meets +timing. The max clock frequency for the design should be about 72 MHz. + +Time to load the design onto the board. + + +## Configuring the FPGA on the C5G board +If you haven't turned on the C5G board and connected the board to the +computer Quartus is installed on, do so now. You should see the +7-segment displays and LEDs start flashing in a simple sequence. This +shows that the default configuration in the FPGA has been loaded and the +board works. + +In Quartus now locate the 'Programmer' menue button (it looks like a +chip with waves). Alternatively Select 'Tools' in the top level Menue +and then 'Programmer'. + +In the Programmer window if everything is working magically we should +see a list view with toolruns/output_files/coretest_hashes.sof +selected. And below this list a graphic that shows a 'TDI' arrow +pointing to an Altera 5CGXFC5C6F27C7 device with a 'TDO' going out from +the device. + +If the graphic is not showing (probably), you need to press 'Hardware +Setup'. In the Window you should see 'USB-blaster'. If not you need to +fix the drivers for the USB-blaster in your OS. If the USB-blaster is +present make sure it is selected and then press 'Close'. + +If the file is not showing, in the main Programmer window, select 'Add +File' and navigate and to toolruns/output_files in the project +directory. Select 'coretest_hashes.sof' and press 'Open'. + +In the main Programmer window now press 'Start' to start +programming. When this has been completed (See 'Progress' in the upper +right hand corner in the Programmer board) the LEDs etc should have +stopped blinking. We should now have coretest_hashes alive on the +development board. Time for host communication and testing! + + +## Talking to coretest_hashes and test of SHA-1 and SHA-256 +There is a (currently rather ugly) test program for +coretest_hashes. Navigate to test_coretest_hashes/cores/coretest_hashes/src/sw + +``` +#> ls +hash_tester.py +``` + +This is a Python2.x program that uses Pyserial [5] to open up a serial +port and talk to coretest via the uart. The command and response format +used is a very simple byte oriented format. For more info, see the +README.md in [browser:/core/coretest "the top of coretest"]. + +The program hash_tester.py needs to know which serial interface to +use. This is defined in the main() function (yes, VERY ugly). You will +need to edit the program source to point to the serial interface +connected to the USB-serial chip on the C5G board. For me that device +is: + +``` + ser.port='/dev/cu.usbserial-A801SA6T' +``` + +If everthing is working properly you should now just have to do: +``` + python hash_tester.py +``` + +If the communication has been set up properly you should now see: +``` + TC1-1: Reading name, type and version words from SHA-1 core. + READ_OK. address 0x1000 = 0x73686131. + READ_OK. address 0x1001 = 0x20202020. + READ_OK. address 0x1002 = 0x302e3530. + ... +``` + +That is the first test case that reads from specific registers in the +SHA-1 core. If we look in sha1/src/rtl/sha1.v there are some defines: +``` + parameter CORE_NAME0 = 32'h73686131; // "sha1" + parameter CORE_NAME1 = 32'h20202020; // " " + parameter CORE_VERSION = 32'h302e3530; // "0.50" +``` + +As we can see those hex values matches what is being read from the FPGA +and is the name and version strings in the core. + +Moving on, hash_tester.py also performs single block message hash tests +of both the SHA-1 and SHA-256 core. The message is "abc" padded to the +correct block size for SHA-1 and SHA-256. These tests are defined by +NIST including the expected result in [6]. The block is written as a +sequence of 32-bit words to addresses mapped to the block registers in +the sha1 core. + +Finally we set the init_flag in the control register in +sha1 to one which should make the sha1 core initialize and then process +the first (of possible several) message block. This takes in total 82 +cycles for the core. This means that by the time the host gets the +'WRITE_OK. address 0x1008.' message, the core is done since many cycles +ago. We therefore check status and try to extract the digest. + +Looking at the output from hash_tester.py we see: +``` + TC1-3: Reading SHA-1 status and digest. + READ_OK. address 0x1009 = 0x00000003. + READ_OK. address 0x1020 = 0xa9993e36. + READ_OK. address 0x1021 = 0x4706816a. + READ_OK. address 0x1022 = 0xba3e2571. + READ_OK. address 0x1023 = 0x7850c26c. + READ_OK. address 0x1024 = 0x9cd0d89d. +``` + +Address 0x1009 corresponds to address 0x09 in the SHA-1 core. This +address contains the status of the core. 0x03 means that the data in the +digest is valid and that the core is ready to accept now commnands. + +The digest generated by the sha1 core is in MSB format which means that +the digest generated is: +``` + 0xa9993e36 0x4706816a 0xba3e2571 0x7850c26c 0x9cd0d89d +``` + +If we compare that to the expected result in [6] we can see that this is +correct. Similarly, for SHA-256 we get: +``` + TC2-3: Reading SHA-256 status and digest. + READ_OK. address 0x2009 = 0x00000003. + READ_OK. address 0x2020 = 0xba7816bf. + READ_OK. address 0x2021 = 0x8f01cfea. + READ_OK. address 0x2022 = 0x414140de. + READ_OK. address 0x2023 = 0x5dae2223. + READ_OK. address 0x2024 = 0xb00361a3. + READ_OK. address 0x2025 = 0x96177a9c. + READ_OK. address 0x2026 = 0xb410ff61. + READ_OK. address 0x2027 = 0xf20015ad. +``` + +The digest generated is thus: +``` + 0xba7816bf 0x8f01cfea 0x414140de 0x5dae2223 + 0xb00361a3 0x96177a9c 0xb410ff61 0xf20015ad +``` + +Which again matches what is specified in [6] + + +## Summary +We have now set up a complete development and verification environment +for Cryptech. We have setup and built the coretest_hashes subsystem for +the TerasIC C5G board. Finally we have connected to coretest_hashes from +SW in the host and verified that we can write to and receive response +needed to perform SHA-1 and SHA-256 hash operations and get correct +digest back. + +If you have not been able to complete this, please contact me (Joachim Strömbergson). + +Happy Hashing! + + +## References + +- [1]: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=830 +- [2]: http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html +- [3]: http://www.ftdichip.com/Products/ICs/FT232R.htm +- [4]: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=830&PartNo=4 +- [5]: http://pyserial.sourceforge.net/ +- [6]: http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA_All.pdf +- [7]: http://www.ftdichip.com/Drivers/VCP.htm +- [8]: http://www.altera.com/download/drivers/usb-blaster/dri-usb-blaster-vista.html diff --git a/markdown/CoretestHashesNovena.md b/markdown/CoretestHashesNovena.md new file mode 100644 index 0000000..6bc9c2a --- /dev/null +++ b/markdown/CoretestHashesNovena.md @@ -0,0 +1,260 @@ +# How to start using coretest_hashes on the Novena PVT1 + +This is a writeup on how to setup, build and testrun the coretest_hashes +Cryptech subsystem on a Novena PVT1 development board. + +## Getting started with Novena + +[Novena](http://www.kosagi.com/w/index.php?title=Novena_Main_Page) is an open hardware and F/OSS-friendly computing platform. + +[[Image(http://bunniefoo.com/novena/pvt1_release/novena_pvt1e_top_sm.jpg)]] + +It is a small single-board Linux PC, which happens to include a Xilinx [Spartan-6 FPGA]. This, together with the TerasIC [http://trac.cryptech.is/wiki/CoretestHashesC5G Cyclone 5 GX](http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/lx.html), is what we are using to develop and test the Cryptech cores. + +The Novena includes an HDMI adapter and two USB ports, so you can plug in a monitor, keyboard, and mouse, and have a graphical desktop environment. However, I prefer to run it headless, and ssh to it. To ssh to the Novena, you need to know its IP address, which means you need to either statically configure it, or you need to assign it an address in your DHCP server. + +If you go the DHCP route, be aware that Novena doesn't used a fixed hardware address, so you'll have to statically configure **that**. +Open `/etc/network/interfaces`, and add something like the following lines: +``` +allow-hotplug eth0 +iface eth0 inet dhcp + hwaddress ether 00:0e:c6:87:72:01 +``` + + + +* The specific CPU on the Novena is the Freescale i.MX6 MCIMX6Q5EYM12AC device. A quad core, ARM A9 device running at 1.2 GHz. +* The specific FPGA on the Novena is the Xilinx Spartan-6 XC6SLX45-3CSG324C device. +* Here are ["the schematics for the Novena PVT2 board"](http://bunniefoo.com/novena/pvt2_release/novena_pvt2.PDF). + + + +### Coretest_hashes + +The coretest_hashes is a subsystem that is a FPGA design that contains +Cryptech application cores as well as support cores used to run tests +of the SHA-1 and SHA-2 hash functions from the host computer via an +I2C serial bus. The subsystem consists of: + + +- [browser:/core/sha1 sha1]: A HW implementation of the SHA-1 hash function. + + + +- [browser:/core/sha256 sha256]: A HW implementation of the SHA-256 hash + + function. + + +- [browser:/core/sha512 sha512]: A HW implementation of the SHA-512 hash + + function. + + +- [browser:/core/coretest coretest]: A command parser that accepts read/write + + commands from a host, executes the commands and sends the response. + + +- [browser:/core/i2c i2c]: A serial interface that connects coretest to the + + host. + + +- [browser:/core/novena novena]: A top-level wrapper that connects all + + the cores, and connects i2c to external pins as well as clk and + reset. This repo also contains userland software that talks to + coretest and performs tests of the sha1, sha256, and sha512 cores. + +## Software and system requirements + +You need to download and install the Xilinx +[ISE Design Suite](http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html). + +Note: this software runs on a Windows or x86 Linux host, **not** on the Novena. + +### Installing on Linux + +The Windows install is pretty straight-forward. So is the Linux +install, but with a few extra notes: + + +- Xilinx only supports specific versions of Red Hat and Suse Linux, but it does run on Ubuntu, with the following caveat: Ubuntu symlinks `/bin/sh` to `dash`, which can't handle `if [ ]` syntax in shell scripts, so I symlinked `/bin/sh` to `bash` instead. + + + +- ISE Design Suite uses a graphical installer, so has to be installed + + on a desktop edition, not a server edition. + + +- Although the software can be installed as user or root, by default + + it wants to install into `/opt/Xilinx`, so you need to install as root + if you want to do that. + + +- The Xilinx tools are disk hogs, so if you're building a VM for this, you'll probably want to give it at least 30-40 GB of disk space. + + +Step-by-step installation: +1. Unpack Xilinx_ISE_DS_Lin_14.7_1015_1.tar (or whatever version you have). +2. `cd` to Xilinx_ISE_DS_Lin_14.7_1015_1, and run `sudo ./xsetup` +3. Click through two screens of license agreements. +4. Select `ISE WebPACK`. +5. Unselect (or leave unselected) `Install Cable Drivers`. +6. Go! + +Well, not quite. You will need to convince the ISE that you have a license. + +On the page [http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm](http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm) click on the `Licensing Solutions` link. On the resulting page, expand the section `Obtain a license for Free or Evaluation product`. To download the ISE Webpack, you should have created an account, so now you can go to the Licensing Site and use that account to create a Certificate Based License. + +You do not need to go through the HostID dance, just say Do It. You will then receive a certificate in email (not an X.509 certificate) which you will be able to use. Then start the ISE Webpack by issuing the command `ise`. Go to the Help menu and `Manage Licenses`. Use the resulting new License Manager window to install the .lic file. This process is complex and flakey. + +Here is a more detailed description of ["installing ISE in Ubuntu."](http://www.armadeus.com/wiki/index.php?title=ISE_WebPack_installation_on_Linux) + +Platforms on which at least one person has done this succesfully: + + +* ISE 14.7 on a 32-bit Debian Wheezy VM running under VirtualBox on MacOSX. +* ISE 14.7 on a 64-bit Debian Jessie VM running under virsh/kvm. +* ISE 14.7 on 32-bit Debian Jessie on a Shuttle XS36V. + + +## Downloading the cores + +Create a project directory, e.g. `coretest/core`. + +The cores we need to build the subsystem must be downloaded from the +Cryptech server. Check them out one by one: +``` +#!sh +git clone http://git.cryptech.is/core/sha1.git +git clone http://git.cryptech.is/core/sha256.git +git clone http://git.cryptech.is/core/sha512.git +git clone http://git.cryptech.is/core/i2c.git +git clone http://git.cryptech.is/core/coretest.git +git clone http://git.cryptech.is/core/novena.git +``` + +If you are a cryptech core member, use the ssh method, e.g. +``` +git clone git@git.cryptech.is:core/sha1.git +``` + +## Building the cores + +### Building in Linux command-line + +Go to `novena/synth` and run `make`. + +Depending on your version of ISE Design Suite, where you installed it, +and whether you're running it on 32-bit or 64-bit hardware, you may +have to change the `isedir` and `xil_env` values in `Makefile`. + +### Building in the ISE application + +On Windows, open the Project Navigator link. + +On Linux, run e.g. `/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise` + +a. Create the project: + Select `File` > `New Project` + + - Name: novena + - Location: .../toolruns (automatically appends "novena") + - Family: Spartan6 + - Device: XC6SLX45 + - Package: CSG324 + - Speed: -3 + + +b. Add files to the project: + + - coretest/src/rtl/coretest.v + - coretest_test_core/src/rtl/coretest_test_core.v + - i2c/src/rtl/i2c.v + - i2c/src/rtl/i2c_core.v + - novena/src/rtl/coretest_hashes.v + - novena/src/rtl/novena_fpga.v + - novena/synth/coretest-novena.ucf + - sha1/src/rtl/sha1.v + - sha1/src/rtl/sha1_core.v + - sha1/src/rtl/sha1_w_mem.v + - sha256/src/rtl/sha256.v + - sha256/src/rtl/sha256_core.v + - sha256/src/rtl/sha256_k_constants.v + - sha256/src/rtl/sha256_w_mem.v + - sha512/src/rtl/sha512.v + - sha512/src/rtl/sha512_core.v + - sha512/src/rtl/sha512_h_constants.v + - sha512/src/rtl/sha512_k_constants.v + - sha512/src/rtl/sha512_w_mem.v + + +c. Set some non-default options: + + *Note: these are derived from other Novena projects, and I'm not sure + what they mean, but they don't make things blow up.* + + + - In the `Process` window, right-click on `Generate Programming File`, select `Process Properties...`. + - In `Configuration Options`, find `-g UnusedPin`, and change it from `Pull Down` to `Float`. + - In `Startup Options`, find `-g DriveDone`, and check the box. + + +d. Build the project + + Select `Process` > `Implement Top Module` + + +The expected build time should be something like 5 and 10 minutes, depending on the computer used. +Some measured build times for the design: + + + - 5,30 minutes on MacbookPro 2013 with tools in 64-bit SUSE Linux in VM + - 9,20 minutes on AMD A10-6800K with tools in Windows 7 in Virtualbox VM with one CPU core and 4 GByte RAM. + + + +## Running coretest on the Novena + +`scp` the built `coretest-novena.bit` to the Novena. + +Fetch +[devmem2.c](https://github.com/xobs/novena-scope-drivers/blob/master/userspace/devmem2.c) +and compile it on the Novena. + +`scp` the following files from `novena/src/sw` to the Novena: + +- configure.sh +- hash_tester.py + + +To configure the coretest image into the FPGA, run +``` +#!sh +./configure.sh coretest-novena.bit +``` + +This should light a small green LED (labeled "fpga") next to the high-speed +expansion connector. The console log should be: + +``` +Setting export of reset pin +setting reset pin to out +flipping reset +configuring FPGA +11597+1 records in +11597+1 records out +1484509 bytes (1.5 MB) copied, 2.34345 s, 633 kB/s +turning on clock to FPGA +/dev/mem opened. +Memory mapped at address 0x76f51000. +Value at address 0x20C8160 (0x76f51160): 0x40B +Written 0xD2B; readback 0xD2B +``` + +Run `hash_tester.py` to go through the full test suite. + diff --git a/markdown/DNSSEC%2FRequirements.md b/markdown/DNSSEC%2FRequirements.md new file mode 100644 index 0000000..36b1152 --- /dev/null +++ b/markdown/DNSSEC%2FRequirements.md @@ -0,0 +1,99 @@ +# DNSSEC Requirements + +## Questions + + +- Should we even support SHA-1? +- GOST? + + +## Must implement + +Target DNSSEC Algorithms: + + +- RSA/SHA-256 (RFC 5702) +- RSA/SHA-512 (RFC 5702) + + +Algorithms: + + +- Hash: SHA-256 +- Hash: SHA-512 +- Sign: RSA + + +Required PKCS11 Mechs: + + +- CKM_RSA_PKCS_KEY_PAIR_GEN +- CKM_SHA256_RSA_PKCS +- CKM_SHA512_RSA_PKCS +- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing) +- CKM_SHA256 +- CKM_SHA512 + + +## Should implement + +Target DNSSEC Algorithms: + + +- ECDSA/P-256/SHA-256 (RFC 6605) +- ECDSA/P-384/SHA-384 (RFC 6605) + + +Algorithms: + + +- Hash: SHA-256 +- Hash: SHA-384 +- Sign: P-256 +- Sign: P-384 + + +Required PKCS11 Mechs: + + +- CKM_EC_KEY_PAIR_GEN +- CKM_ECDSA_SHA256 +- CKM_ECDSA_SHA384 +- CKM_ECDSA (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing) +- CKM_SHA256 +- CKM_SHA384 + + +## May implement + +Target DNSSEC Algorithms: + + +- RSA/SHA-1 (RFC 3110) +- GOST (RFC 5933) + + +Algorithms: + + +- Hash: SHA-1 +- Sign: RSA + + + +- Hash: GOST R 34.11-94 (RFC5831) +- Sign: GOST R 34.10-2001 (RFC5832) + + +Required PKCS11 Mechs: + + +- CKM_RSA_PKCS_KEY_PAIR_GEN +- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA_1) +- CKM_SHA1_RSA_PKCS +- CKM_SHA_1 + + + +- CKM_GOSTR3410_KEY_PAIR_GEN +- CKM_GOSTR3410_WITH_GOSTR3411 diff --git a/markdown/DNSSEC.md b/markdown/DNSSEC.md new file mode 100644 index 0000000..4d57d27 --- /dev/null +++ b/markdown/DNSSEC.md @@ -0,0 +1,4 @@ +# DNSSEC + + +- [wiki:DNSSEC/Requirements DNSSEC Requirements] diff --git a/markdown/Dashboard.md b/markdown/Dashboard.md new file mode 100644 index 0000000..ca2c512 --- /dev/null +++ b/markdown/Dashboard.md @@ -0,0 +1,96 @@ +# Project Status Dashboard + +## Product Component Requirements + +| State | Component | DNSsec Signing | Let's Encrypt | Tor Consensus | Internal | Ticket | +|---|---|---|---|---|---|---| +| Done | AES / KEY WRAP | | | | Wrap/Bkup | #17 | +| | ECDSA p256 | secondary | Yes | | | | +| | ECDSA p384 | secondary | ? | | | | +| Testing | PKCS!#11 | Yes | Yes | Yes | Yes | #14 | +| Done | RSA | Yes | Yes | Yes | | #16 | +| Done | SHA-1 | | | Yes | | | +| Done | SHA-256 | Yes | Yes | Yes | | | +| Done | SHA-384 | Yes | ? | | | | +| Done | TRNG | padding | padding | padding | KeyGen | #15 | + + + +## Novena Alpha - DNSsec Only + +| Component | Who | About When | Ticket | +|---|---|---|---| +|RSA | Pavel, Rob | Done | #16 | +|AES/KEY WRAP | Rob | Done | #17 | +|SHA-256 | Joachim | Done | | +|TRNG | FT | Done | #15 | +|PKCS!#11 | Rob | Late May | | +|PKCS!#11 PIN | Rob | Mid June | #14 | +|Packaging | Paul, Rob | Done | | + + + +## Hardware cores + +### Hash Functions + +| Component | Status | Repository | Comment | +|---|---|---|---| +| SHA-1 | Done | [[GitRepositories/core/hash/sha1| core/hash/sha1]] | | +| SHA-256 | Done | [[GitRepositories/core/hash/sha256| core/hash/sha256]] | | +| SHA-512 | Done | [[GitRepositories/core/hash/sha512| core/hash/sha512]] | Support all four SHA-512/x modes defined in FIPS 180-4. | +| SHA-3 (Keccak ) | Started | [[GitRepositories/core/hash/sha3| core/hash/sha3]] | | +| GOST R 34.11-2012 | Started | | | + + + +### Symmetric Crypto + +| Component | Status | Repository | Comment | +|---|---|---|---| +| AES | Done | [[GitRepositories/core/cipher/aes| core/cipher/aes]] | AES cipher core with support for 128 and 256 bit keys. | +| ChaCha | Done | [[GitRepositories/core/cipher/chacha| core/cipher/chacha]] | High speed stream cipher. Based on the Salsa20 stream cipher. | + + + +### Asymmetric Crypto + +| Component | Status | Repository | Comment | +|---|---|---|---| +| ModExp -8192 (RSA) | Done | [[GitRepositories/core/math/modexps6| core/math/modexps6]] | | +| Curve25519 | Started | | | +| Ed25519 | Not started | | | +| P-256, P-384 ECDSA | Started | | | +| GOST R 34.10-2001 | Started | [[https://trac.cryptech.is/browser/user/shatov/gost/streebog]]([https://trac.cryptech.is/browser/user/shatov/gost/streebog]) | Core in provisional repo. Will be moved to the the hash core section.| + + + +### Random Number Generators + +| Component | Status | Repository | Comment | +|---|---|---|---| +| TRNG | Done | [[GitRepositories/core/rng/trng| core/rng/trng]] | Depends on SHA-512 and ChaCha | +| External Avalanche Entropy | Done | [[GitRepositories/core/rng/avalanche_entropy| core/rng/avalanche_entropy]] | [[GitRepositories/user/ft/stm32-avalanche-noise| Hardware]] and stand-alone PoC | +| Internal Ring Oscillator | Done | [[GitRepositories/core/rng/rosc_entropy| core/rng/rosc_entropy]] | | + + + +### Key wrapping and Cipher Modes + +| Component | Status | Repository | Comment | +|---|---|---|---| +| KEY WRAP | Done | | Key wrapping mode. Will be used for key storage. See ["rfc 3394"](https://tools.ietf.org/html/rfc3394). #17 | +| GCM | Not started | | Galois Counter Mode. AEAD cipher. | +| CTR and CBC | Not started | | Basic block cipher modes. | + + + +### Support Functionality + +| Component | Status | Repository | Comment | +|---|---|---|---| +| Coretest | Done | [[GitRepositories/core/comm/coretest| core/comm/coretest]] | Command-response based core tester for HW accelerated core verification. | +| UART | Done | [[GitRepositories/core/comm/uart| core/comm/uart]] | Serial interface module used on the TerasIC C5G development board. | +| I2C | Done | [[GitRepositories/core/comm/i2c| core/comm/i2c]] | I2C interface module used on the Novena board. | +| EIM | Done | [[GitRepositories/core/comm/eim| core/comm/eim]] | Interface for the Freescale EIM memory interface used on the Novena board. | +| FMC | Done | [[GitRepositories/core/comm/fmc| core/comm/fmc]] | Interface for the STM32 FMC memory interface used on the dev-bridge and Alpha boards. | diff --git a/markdown/DevBridgeBoard.md b/markdown/DevBridgeBoard.md new file mode 100644 index 0000000..f4dde47 --- /dev/null +++ b/markdown/DevBridgeBoard.md @@ -0,0 +1,40 @@ +[[PageOutline]] + +# dev-bridge board +In the process of developing the [wiki:AlphaBoardComponents] design, the project has made what is known as the "dev-bridge board". + +This is a board, 100x70 mm, with about 2/3 of the components intended to be on the Alpha design. What is missing is basically the FPGA and it's supporting circuits. + +To date, the dev-bridge board has been used to implement and validate the FMC based interface that will be used to connect the ARM and the FPGA on the Alpha. + +Schematics and layouts are at [user/ft/stm32-dev-bridge/hardware/rev01](https://wiki.cryptech.is/browser/user/ft/stm32-dev-bridge/hardware/rev01). + +High resolution pictures of rev01 of the dev-bridge board are attached at the bottom of this page, but the following should be more than sufficient to read the silkscreens. + +[[Image(dev-bridge_rev01_front_medium.jpg)]] + +[[Image(dev-bridge_rev01_back_medium.jpg)]] + +Here is the board mounted on the Novena, attached to the programmer: + +[[Image(IMG_9983s.jpg)]] + +Note that it's rather bigger than the Netgear enclosure I use to transport the Novena. (Not only does it protect the board, but I have this superstition that TSA is more comfortable with a home gateway than a bare motherboard.) + +Also note that the dev-bridge board is connected to the Novena by the +high-speed expansion connector, which forms a bit of a pivot point. +As Pavel says, "High speed and mechanical reliability are not very good +friends usually." + +For that reason, I highly recommend stabilizing the board by bolting it to +the Novena with a 5mm spacer. There are two through-holes that line up +with mounting holes on the Novena, one at the corner and one next to the +wifi connector. I've found that even one bolt is enough to stabilize the +board. + +Finally note that the board traces come rather close to the through-holes, so +you want to avoid scraping them with the bolt head or the nut. I happen to +be using a countersink-head bolt, which is beveled toward the shaft, but +it's probably even better to use a nylon washer. + +All the software, as well as flashing instructions, are at [wiki:GitRepositories/sw/stm32]. diff --git a/markdown/DevelopersGuide.md b/markdown/DevelopersGuide.md new file mode 100644 index 0000000..bbb0f1e --- /dev/null +++ b/markdown/DevelopersGuide.md @@ -0,0 +1,22 @@ +*Page Under Development* + +# Developers Guide + +## Architecture + +* OpenCryptoChip +* NoisyDiode +* AlphaBoard + + +## Known Limitations + +* AssuredTooChain + + + +* EDAToolchainSurvey" + + +## Building the Bitstream + diff --git a/markdown/DisasterRecovery.md b/markdown/DisasterRecovery.md new file mode 100644 index 0000000..9c0e56f --- /dev/null +++ b/markdown/DisasterRecovery.md @@ -0,0 +1,45 @@ +# Disaster Recovery + +This page covers a few likely (hopefully unlikely) oh-noes. + +## Oh no, I bricked my device + +### Recovering from a bad firmware install + +You can upload new firmware through the bootloader. On power-up or reset, +the bootloader flashes the blue LED for 10 seconds. During that time, start +`cryptech_upload`: + +``` +$ cryptech_upload --firmware --user wheel +PIN: <your-wheel-pin> +``` + +### Recovering from a bad bootloader install + +Well, now you've done it. You'll need to buy an ST-LINK programmer. +See [wiki:UsingSTLink]. + +## Oh no, I'm locked out of my device + +If you're staring at this thing for the first time, or if you ran +`keystore erase`, then you have no PIN. Believe it or not, this is the +best case scenario. Log in as wheel with the default PIN +`YouReallyNeedToChangeThisPINRightNowWeAreNotKidding`, and you should be +able to reset the PINs. + +If you forgot the PIN, I feel sorry for you. The only way out of this is +via [wiki:UsingSTLink ST-LINK]. The easiest way is to debug with `gdb`, set a breakpoint on +`hal_rpc_login`, and issue the gdb command `return 0`. + +## Oh no, I forgot (or reset) the master key + +As shipped, the Alpha doesn't include a battery backup for the Master Key +Memory. So if power is interrupted, the MKM is wiped. (Also, if we had +tamper protection more sophisticated than a Panic Button, it would wipe +the MKM when you opened the case to install the ST-LINK cable.) + +Sorry, there's nothing that can be done about that. All your keys are +still in flash memory, but encrypted with the KEK, which is now gone. +(Unless you used the `masterkey unsecure set` command to store the KEK in +unprotected flash memory, but you wouldn't do that, would you?) diff --git a/markdown/DocMeet.md b/markdown/DocMeet.md new file mode 100644 index 0000000..b49ec5d --- /dev/null +++ b/markdown/DocMeet.md @@ -0,0 +1,12 @@ +# Documents, Meetings, etc. + +## Meetings + +* At IETF88 an open lunch meeting was held with maybe 30-40 people. Minutes will be posted here shortly. +* An invitation-only initial exploratory and team-building meeting will be hosted by SUNET in Stockholm in December. Invitations are in process. Dress in layers. Anything useful that comes out of the meeting will be published on this wiki. + + +## Documents + +* [attachment:140109.cryptech.pdf 140109.cryptech.pdf Presentation - Overview of Project with Funding Requests] +* [attachment:141002.cryptech-iij.pdf 141002.cryptech-iij.pdf CrypTech Presentation at Open IIJ Seminar] diff --git a/markdown/Documents.md b/markdown/Documents.md new file mode 100644 index 0000000..77593fd --- /dev/null +++ b/markdown/Documents.md @@ -0,0 +1,21 @@ +# Presentations and Design Documents + +``` +#!comment + +Remember that links from this page to files in git repositories should use the "export:" tag, eg: + +[export:/doc/blarg.pdf "An interesting presentation about Blargs"] + +``` + +[RandomnessTesting Randomness Testing Tools][[BR]] + +[AlphaBoardStrategy Alpha board strategy] + +[export:/doc/design/Alpha_board_drawing.pdf "Alpha board drawing"] + +[AlphaBoardPictures Alpha board pictures] + +Placeholder until somebody fills this in with something else interesting. + diff --git a/markdown/EDAToolchainSurvey%22.md b/markdown/EDAToolchainSurvey%22.md new file mode 100644 index 0000000..5516a29 --- /dev/null +++ b/markdown/EDAToolchainSurvey%22.md @@ -0,0 +1,18 @@ +**Note: this page has been replaced by wiki:EDAToolchainSurvey** + +The major issue is finding tools that allows a designer, user to verify that the RTL source code (in Verilog or VHDL) matches what is generated at the physical level. As part of the project we need to investigate the current status of open tools in the toolchain for implementation and verification of hardware. This includes RTL simulation, synthesis, place & route, netlist verification, timing analysis and configuration file generation and analysis. (This implies that the target is an FPGA.). If there are no open tools we need to find ways of verifying pre- and post-functionality to check that the black box tool does not alter (subvert) the design in ways not intended. + +The basic action flow is: + +* Finding open EDA tools and assess their status +* Settling for Closed +* Strategy to Develop Trust in Tools +* Validation Methods for Output + + +Some tools and frameworks worth investigating are: + +* ["OpTiMSoC"](http://www.optimsoc.org/index.html) - An open System on Chip (SoC) framework built around the OpenRISC CPU. +* ["Icarus Verilog"](http://iverilog.icarus.com/) - An open Verilog event driven simulator that supports Verilog 2001, 2005 and SystemVerilog. +* ["gEDA"](http://www.geda-project.org/) - A project that aims at developing GNU based EDA tools. +* ["gplEDA"](http://www.gpleda.org/) - A collection of GPL licensed EDA tools. Points to gEDA. diff --git a/markdown/EDAToolchainSurvey.md b/markdown/EDAToolchainSurvey.md new file mode 100644 index 0000000..ffd40e6 --- /dev/null +++ b/markdown/EDAToolchainSurvey.md @@ -0,0 +1,16 @@ +The major issue is finding tools that allows a designer, user to verify that the RTL source code (in Verilog or VHDL) matches what is generated at the physical level. As part of the project we need to investigate the current status of open tools in the toolchain for implementation and verification of hardware. This includes RTL simulation, synthesis, place & route, netlist verification, timing analysis and configuration file generation and analysis. (This implies that the target is an FPGA.). If there are no open tools we need to find ways of verifying pre- and post-functionality to check that the black box tool does not alter (subvert) the design in ways not intended. + +The basic action flow is: + +* Finding open EDA tools and assess their status +* Settling for Closed +* Strategy to Develop Trust in Tools +* Validation Methods for Output + + +Some tools and frameworks worth investigating are: + +* ["OpTiMSoC"](http://www.optimsoc.org/index.html) - An open System on Chip (SoC) framework built around the OpenRISC CPU. +* ["Icarus Verilog"](http://iverilog.icarus.com/) - An open Verilog event driven simulator that supports Verilog 2001, 2005 and SystemVerilog. +* ["gEDA"](http://www.geda-project.org/) - A project that aims at developing GNU based EDA tools. +* ["gplEDA"](http://www.gpleda.org/) - A collection of GPL licensed EDA tools. Points to gEDA. diff --git a/markdown/ExternalProjects.md b/markdown/ExternalProjects.md new file mode 100644 index 0000000..d07eb4c --- /dev/null +++ b/markdown/ExternalProjects.md @@ -0,0 +1,4 @@ +External projects using [CrypTech](https://cryptech.is/) technology. + + +* [wiki:ExternalProjectsTorHSM TorHSM] diff --git a/markdown/ExternalProjectsTorHSM.md b/markdown/ExternalProjectsTorHSM.md new file mode 100644 index 0000000..9dd8b7c --- /dev/null +++ b/markdown/ExternalProjectsTorHSM.md @@ -0,0 +1,90 @@ +# External project TorHSM + +## Problem + +The [Tor network](https://www.torproject.org/about/overview.html.en) is defined by a small number, about ten, of special relays called Directory Authorities (DAs). + +Directory Authorities sign the critical `status votes` and `consensus status` documents using SHA-1 and SHA-256 together with RSA-2048 or RSA-3072 once per hour, using medium-term on-line `authority signing keys` signed by their individual off-line long-term `authority identity keys`. Authority signing keys typically have a lifetime of three to twelve months. + +Authority signing keys are currently kept on the same general purpose computer that runs the Directory Authority and are thus subject to a large number of network threats. + +## Proposed solution + +Move `authority signing keys` away from the general purpose computer onto an external device which can sign the consensus document without exposing key material to the networked computer system. + +The CrypTech project has created an open source (BSD licensed) `Alpha` hardware which would be especially suitable, because the open software and hardware offers unprecedented transparency while also enabling a simple, efficient and legacy-free solution. + +### Current typical key roll-over procedure + + +* Generate new `authority signing key` on offline system +* Sign new key using `authority identity key` on offline system +* Save new `authority signing key` and `key certificate` on USB stick +* Transfer new `authority signing key` and `key certificate` to DA system via network + + +### The key roll-over procedure becomes + + +* Use administrative tool from this project on DA system to generate new `authority signing key` on HSM + * The new `authority signing key` initially remains inactive and unavailable for use + * The public part of new `authority signing key` is exported from HSM onto the DA system +* Transfer new public part of `authority signing key` to USB stick +* Sign new public key using `authority identity key` on offline system +* Save `key certificate` on USB stick +* Transfer `key certificate` to DA system via network and make available to DA +* (Optional?) Use administrative tool from this project on DA to present `key certificate` to HSM +* Activate key (automatic on verified `key certificate`, manual without `key certificate` verification) + + +## Milestones + +The minimum viable product (MVP) at MS3 is a system where the authority signing key is no longer accessible by the DA system while not making any part of the process worse from a security perspective. + +The system at MS6 (to MS8) does not make any part of the process worse from a //usability// perspective (subjective) and also adds rate limiting. + +### MS1 -- PoC using OpenSSL `PKCS#11` engine + +* tor using openssl p11 engine; no key management or rate-limiting +* useful for test and verification + + +### MS2 -- Using CrypTech RPC instead of OpenSSL + +* function declarations in `sw/libhal/hal.h`, definitions in `sw/libhal/rpc_*.c` +* TODO: daemon + + +### MS3 (MVP) -- HSM configuration I + +* "HSM configuration" is aka "key management" +* administrator connected to MGMT can make HSM + * generate a MK based on passphrase + * print public part of MK +* administrator connected to USER can make HSM + * generate a new authority signing key pair, wrap the secret part in MK, store both parts in flash memory and export the public part + + +### MS4 -- HSM configuration II + +* rate limiting +* enforcing key validity + + +### MS5 -- Enforcing key validity HSM side + +### MS6 -- Rate limiting of signatures + +### MS7 -- New Shiny Crypto Hardware API using CrypTech RPC + +### MS8 -- Getting entropy from HSM + +### MS9 -- Support for more protocols in New Shiny Crypto Hardware API + +## References + + +* [Tor directory protocol, version 3](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt) +* [CrypTech Alpha system](https://www.crowdsupply.com/cryptech/open-hardware-security-module) + + diff --git a/markdown/GettingStartedNovena.md b/markdown/GettingStartedNovena.md new file mode 100644 index 0000000..66f220c --- /dev/null +++ b/markdown/GettingStartedNovena.md @@ -0,0 +1,147 @@ +[[PageOutline]] + +# Getting Started on the Novena + +## The Novena Board + +[[Image(http://bunniefoo.com/novena/pvt1_release/novena_pvt1e_top_sm.jpg)]] + +[Novena](http://www.kosagi.com/w/index.php?title=Novena_Main_Page) is an open hardware and F/OSS-friendly computing platform. It is a small single-board Linux PC, with a Freescale i.MX6 (ARM +Cortex-A9) CPU and a Xilinx Spartan-6 LX45 FPGA. + +It is available in limited quantities through [crowd supply](https://www.crowdsupply.com/sutajio-kosagi/novena). + +### Setting up the Novena + +The Novena PVT-2 requires some initial setup. You will need to attach a USB keyboard and HDMI monitor. + +Once this is done, most of us prefer to run it headless, and ssh in. + +You may also want to bring the packages up to date: + +``` +$ sudo apt-get update +$ sudo apt-get upgrade +``` + +## The Avalanche Noise Board + +[[Image(rev03-on-novena.jpg, 40%)]] + +The avalanche noise board is a Novena daughter board that contains a zener-diode noise circuit that can be read directly by the FPGA. + +*(More information from FT: block diagram, schematics, ...)* + +It is available in limited quantities directly from Fredrik Thulin, and will be distributed at the PrahaWorkshop. + +## Binary Packages + +Cryptech maintains an ```apt``` repository, with two binary packages for the Novena: + +* a bitstream, to be configured into the FPGA +* software, to run on the CPU + + +### How to get them + +All commands are run on the Novena. + +1. First, get the hactrn CA certificate: + +``` +$ wget http://www.hactrn.net/cacert.asc +``` + +Get the key used to sign the CA certificate. + +``` +$ gpg --recv-keys 2DC6FF82 +``` + +Validate the CA certificate + +``` +$ gpg cacert.asc +``` + +Install the CA certficiate. + +``` +$ sudo mkdir /usr/share/ca-certificates/hactrn.org +$ sudo mv cacert /usr/share/ca-certificates/hactrn.org/cacert.crt +$ sudo dpkg-reconfigure ca-certificates +``` + +2. Get the repository key. + +``` +$ wget https://apt.cryptech.is/novena/apt-gpg-key.asc +``` + +Validate the key. + +``` +$ id=37A8E93F5D7E7B9A +$ gpg --recv-key $id +$ gpg --check-sig $id +$ gpg --export $id | sudo apt-key add - +``` + +See the apt-key(8) manual page for more information about the APT key database, including how to remove keys you don't want anymore. + +Install the key. + +``` +$ sudo apt-key add apt-gpg-key.asc +``` + +3. Get the packages + +Configure apt to use the repository. + +``` +$ sudo wget -q -O /etc/apt/sources.list.d/novena.list http://apt.cryptech.is/novena/sources.list +``` + +Update the package index file. + +``` +$ sudo apt-get update +``` + +Get the cryptech meta-package. + +``` +$ sudo apt-get install cryptech-novena +``` + +This installs the ```cryptech-novena-rtl``` and ```cryptech-novena-sw``` packages. + +The ```cryptech-novena-rtl``` package includes an ```init.d``` script that configures the FPGA on system startup. This script should run automatically as part of the install process. + +### Updating the packages + +Once you've performed the steps above you should be able to upgrade to newer +version of the code using the normal APT upgrade process, eg: + +``` +$ sudo apt-get update +$ sudo apt-get upgrade +``` + +## Setting up PKCS!#11 + +The PKCS11 token is in /usr/lib/libpkcs11.so. In order to start using it you need to set a pin and an SO pin. This you do with p11util thus: + +``` +(echo 12345678;echo 1234) | sudo p11util --set-so-pin --set-user-pin --pin-from-stdin +``` + +It is strongly suggested to change the so pin and pin (in that order above) to something sensible. Now your token is ready to use. Your favorite PKCS11-client may or may not work depending on the state of support for PKCS11 function calls - please open tickets for whatever is missing. If you want/need to talk PKCS11 from another host, you could install and configure [[PKCS11Proxy]] on both the novena and your host. Note that currently pkcs11-proxy doesn't handle differing word-lengths so your client-side will have to be 32bit (since the novena is). + + +## Setting up the lab signer + +The lab DNSSEC signer MUST, at this point, be running on a 32-bit system in order to work with the 32-bit Novena. + +[[https://www.dropbox.com/s/f8b4s9vic7hsqyb/cryptech-proxy-lab-20150718r2.pdf]]([https://www.dropbox.com/s/f8b4s9vic7hsqyb/cryptech-proxy-lab-20150718r2.pdf]) diff --git a/markdown/Hardware.md b/markdown/Hardware.md new file mode 100644 index 0000000..e271794 --- /dev/null +++ b/markdown/Hardware.md @@ -0,0 +1,28 @@ +# Cryptech Hardware + +## Generation 1 + +Various generic FPGA development boards. + +## Generation 2 + +//[wiki:CoretestHashesNovena Novena]// + +## Generation 3 + +An Alpha version of a CrypTech HSM, currently in early design + +[[Image(cryptech-g3.png)]] + +There is no real tamper wrapping and no tamper sensors. The tamper switch is used to simulate tamper detection to test the system's tamper reaction(s). + +For the ARM, we think we want + + * No or minimal magic blobs because it's inside the security boundary + * Support for booting, flash file system, and USB + * Do not need memory protection or allocation, threads, video or sound or ... + * Some speed, but the crypto is done in the FPGA + * All components must be free of any GPL-like virus or restrictions + + +[wiki:AlphaBoardComponents The BOM and board requirements for the alpha board]. diff --git a/markdown/InterconnectStandards.md b/markdown/InterconnectStandards.md new file mode 100644 index 0000000..819b497 --- /dev/null +++ b/markdown/InterconnectStandards.md @@ -0,0 +1,319 @@ +# Comparison of On-Chip Bus Standards + +## Introduction +This document contains a brief summary of different on-chip bus +standards. The standards are described and compared based on license and +availability, technical specifications and general usage. + +The purpose of the document is to provide a basis for selecting the +primary bus standard for the Cryptech Open HSM project. + + +## Overview +System on Chip (SoC) designs require some sort of connectivity between +the different components (called cores or IP-cores, as in Intellectual +Property) that are placed onto the same die. + +There are several standards for on-chip interconnect, standards that +provide technical diversity that might be required by the +system. Typical differences are: + + + - Performance. The capacity as well as latency. + + + + - Intelligence. Simple master-slave read/write access or DMA-transfers, + + coherence support etc. + + + - point to point or point to multipoint. Basically bus based or switch + + fabric. + + +There are also non-technical differences: + + + - Licensing and pricing. Does using a standard add monetary cost and + + does using the standard infer restrictions in sharing, disclosure of + source code? + + + - Market share. The market share is primarily interesting as basis for + + the availability of other cores that could be integrated. + + +## Description of Standards + +### AMBA +AMBA (Advanced Microcontroller Bus Architecture) [#fn1 (1)], [#fn2 (2)] is a family of +interconnect standards from ARM Ltd. AMBA is widely used in systems +implemented in ASICs (for example mobile phone platforms), but are also +used in FPGAs. AMBA is for example used by the LEON [#fn3 (3)] processor +cores and subsystem GRLIB. + +AMBA currently contains four main interconnect types: + + + - APB. A simple register read/write bus used to connect simpler + + devices such as timers, IRQ handlers, slow serial I/O such as UARTS + and GPIO interfaces. The peripherals are connected to a common bus + with a single master. + + + - AHB. A more advanced bus based interconnect. Supports more complex + + data transfers of up to 1 kByte data. Supports multiple masters. + + + - AXI. A switch fabric based interconnect that supports multiple + + parallel transfers, multiple masters etc. + + + - ACE. A low latency interconnect that supports cache coherency to + + allow the design of multicore, multiprocessor systems on-chip. + +(There are also additional protocols in the AMBA specification for +things like tracing etc.) + +The license model for AMBA is _Open_ according to ARM. This seems to +mean that one can use AMBA to build a system. But at the same time, ARM +has intellectual properties to parts of the technology as well as +trademarks. For more information on ARM licensing, see [#fn4 (4)]. + +The OpenCores project [#fn7 (7)] lists several cores as well as tools for +different AMBA interconnect types. + +Pros: + + - Technically advanced and covers a wide range of system + + requirements. + + + - A huge user base. + + + + - A huge selection of third party support in terms of tools as well as + + cores. Most of these cores and tools are commercial and proprietary, + closed source. + +Cons: + + - Licensing. Would Cryptech need to get a license? + + + + - Availability of open cores + + + + +### Avalon +Avalon [#fn5 (5)] is a proprietary switch fabric interconnect from Altera +corporation. It is used in systems developed using the Altera Nios-II +[#fn6 (6)] family of soft processor cores and related peripherals. + +According to Altera, the license for Avalon is open: "Avalon interfaces +are an open standard. No license or royalty is required to develop and +sell products that use, or are based on Avalon interfaces." + +As far as we can discern, Avalon is not generally used outside of Altera +based designs and not supported by a large group of third party +vendors. The OpenCores project lists only a few cores that uses Avalon +as interface standard. + += +Pros: + + - Good technical features. + + + + - Easy integration in Nios-II based systems. + + +Cons: + + - Limited to Altera based FPGA designs. + + + + - Low support from open and proprietary third party suppliers of tools + + and cores. + + + +### CoreConnect +CoreConnect [#fn8 (8)] is an interconnect standard initially developed by +IBM. The standard is now used by several vendors, for example the +FPGA-vendor Xilinx[#fn9 (9)]. + +Similarly to AMBA, CoreConnect contains several types of buses providing +simple peripheral access (DCR), high speed access for processor based +systems (OPB), as well as multicore solutions (PLB). + +The license for CoreConnect is granted by IBM [#fn10 (10)]. The license seems to be +an AS IS-license, but contains a lot of other regulations. IBM holds a +number of patents related to CoreConnect (see the license agreement). + +Pros: + + - Good support on for systems implemented on Xilinx FPGAs. + + +Cons: + + - Low support by open cores and tools. + - License agreement. + + + +### OCP +The Open Core Protocol [#fn11 (11)] is a vendor neutral open interconnect standard +being developed by the EDA standards organisation Accellera [#fn12 (12)]. The +standards was previously developed by the vendor organisation OCP-IP [#fn13 (13)], +but were transferred to Accellera in October 2013. + +Like AMBA, OCP contains a wide range of interconnect types from simple +register read/write access over a common bus to point to +point-interconnect and coherency support. + +There are quite a few commercial cores using OCP, but there seem to be +very few open cores using OCP. OpenCores only lists a few cores and +they are all bridges used to connect OCP to AMBA or Wishbone. + +The license for accessing the specification itself is an amended AS +IS-type license[#fn14 (14)]. The license for the interconnect seems to be rather +open. + +Pros: + + - Good technical features. + + +Cons: + + - Not very common in use by open cores. + + + +### Wishbone +Wishbone [#fn15 (15)][#fn16 (16)] (often written WISHBONE) is an open interconnect +standard developed by members of the OpenCore project as an alternative +to commercial solutions - primarily AMBA. + +Wishbone supports bus based as well as switch fabric interconnect +solutions of Wishbone cores. There are cores and tools to create CPU +based systems with buses and fabrics. Technically Wishbone is simpler +that AMBA and CoreConnect, but provides multimasters, point to point +switch fabrics, etc. + +There are tools available to generate Wishbone interfaces for a core as +well as creating a Wishbone connected system with different types of +interconnect solutions. + +The main use is related to the OpenRISC CPU core platform +[#fn17 (17)][#fn18 (18)]. OpenCores lists a huge selection of cores with Wishbone +support. The majority of these cores have LGPL and GPL licenses. There +are also third party commercial vendors that support Wishbone cores and +systems. + +The license for the Wishbone standard is public domain and dos not +impose any restrictions on usage in cores and systems. The +specification document itself is close to Creative Commons CC-BY. + +Pros: + + - Fairly good technical support. + - Good support from open tools and cores. + - Public domain license. + + +Cons: + + - Not as advanced. No good coherency support for example. + + + +## Conclusions +OF the different standards, only two standards are really interesting +for Cryptech - AMBA and Wishbone. + +From a technical point of view, selecting AMBA would be the proper +choice. AMBA provides all types of interconnect that a Cryptech +implementation might need. Also, building a Cryptech implementation +using third party cores (CPU cores for example) would be easier with +AMBA than the other standards. Wher AMBA falls short is the questions +related to licensing as well as the a bit less common support from open +cores and tools. + +Based on ease of licensing, openness and availability of open cores, +Wishbone is an easy choice. Wishbone would quite probably meet all +performance and functionality requirements a Cryptech implementation +might have. Integration with and support from commercial cores, tools +and vendors will however not be as good. Choosing Wishbone will quite +probably mean more work for the Cryptech project to deliver cores and +tools. And for the users of Cryptech Wishbone may also require more work +and thus reduce the interest Cryptech as a HSM solution. + + + +## References +[=#fn1 (1)] https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture + +[=#fn2 (2)] http://www.arm.com/products/system-ip/amba/amba-open-specifications.php + +[=#fn3 (3)] https://en.wikipedia.org/wiki/LEON + +[=#fn4 (4)] http://www.arm.com/products/system-ip/amba/index.php?tab=AMBA+Trademark+Guidelines + +[=#fn5 (5)] http://www.altera.com/literature/manual/mnl_avalon_spec.pdf + +[=#fn6 (6)] http://www.altera.com/devices/processor/nios2/ni2-index.html + +[=#fn7 (7)] http://opencores.org/ + +[=#fn8 (8)] https://en.wikipedia.org/wiki/CoreConnect + +[=#fn9 (9)] http://www.xilinx.com/products/intellectual-property/dr_pcentral_coreconnect.htm + +[=#fn10 (10)] http://www.xilinx.com/ipcenter/doc/ibm_click_core_connect_license.pdf + +[=#fn11 (11)] https://en.wikipedia.org/wiki/Open_Core_Protocol + +[=#fn12 (12)] https://en.wikipedia.org/wiki/Accellera + +[=#fn13 (13)] http://www.ocpip.org/ + +[=#fn14 (14)] http://www.ocpip.org/license_signup.php + +[=#fn15 (15)] http://opencores.org/opencores,wishbone + +[=#fn16 (16)] https://en.wikipedia.org/wiki/Wishbone_(computer_bus) + +[=#fn17 (17)] http://openrisc.net/ + +[=#fn18 (18)] http://opencores.org/or1k/Main_Page + + +## Copyright and License + +This document has been written by Joachim Strömbergson. + +(c) 2014 SUNET - The Swedish University Network + +This document is licensed under a Creative Commons license (CC BY 3.0). +For more information, see: + +https://creativecommons.org/licenses/by/3.0/ diff --git a/markdown/Joachim%20Str%C3%B6mbergson.md b/markdown/Joachim%20Str%C3%B6mbergson.md new file mode 100644 index 0000000..dcf0a94 --- /dev/null +++ b/markdown/Joachim%20Str%C3%B6mbergson.md @@ -0,0 +1,336 @@ +# Joachim Strömbergson +## Bio + + +## Current activities + +* Developing coretest - a core testing framework for FPGAs. +* Implementation of UART +* Verification of SHA-256 +* Verification of SHA-1 +* Implementation of AES-128 +* Design proposal for TRNG +* Design proposal for Curve25519 accelerator + + + +## Work Notes +### Presentations from meeting 2014-03-10 (updated and extended): + +* [browser:/doc/presentations/Cryptech_HW_status_2014-03-10.pdf "Cryptech HW status 2014-03-10"] +* [browser:/doc/presentations/Cryptech_TRNG_Ideas_2014-03-17.pdf "Cryptech TRNG Ideas 2014-03-17"] + + +### Open EDA Tools + +* http://torc-isi.sourceforge.net/index.php - Torc is an open-source C++ infrastructure and tool set for reconfigurable computing + + + +### Curve25519 +We need to create an accelerator or possibly a complete implementation of the Curve25519 EC based DH-excgange. We should be able to look at some previous work: + + +* http://eprint.iacr.org/2013/375 - NaCl on 8-Bit AVR Microcontrollers. Includes an iterative implementation of Curve25519 +* http://cryptojedi.org/crypto/index.shtml - The code to the implementation +* http://nacl.cr.yp.to/ - The main NaCl library by DJB. +* http://cr.yp.to/ecdh/curve25519-20060209.pdf - The Curve25519 paper by DJB. + + + +## Pre meeting notes + +### Stockholm 2013-12-05 - 2012-12-06 +Preparation notes for the OpenHSM meeting 2013-12-05 -- +2013-12-06. The notes contains topics, questions and ideas +I want to bring up, check and discuss on the meeting. + +Philosophy +---------- + +- How to build trust in the project? + - Total openess and transparency + - Traceability of decisions + - Focus on simple third party validation + - Partitioning of security functions + + + +Project goal +------------ + +- Low cost vs high performance + + + +- Scalability + - Functionality + - Performance + - Security + + + +- Target system + - Performance + + + + - Self contained, external + - USB, + - Ethernet + + + + - Integrated + - PCIe + - Mem module + - SD card + + + +- Target users + - Single user + - Enterprise + + + +- Roadmap and development plan + - Prototyp - första målplattform + - Establish first Use cases + + + +- Deliveries + - Proof of concept, prototype + - Self assembly and/or finished product + - Source code for SW, HW + - PCB + - Enclosures + - Development environment + - Test, validation environment + - Tool development + + + + - Time plan + - Start when + - Proto when + - v 1.0 when + + + + +Project management +------------------ + +- Status financing + + + +- Ownership + + + +- Oveerseeing board + - IETF, ISOC,... ? + + + +- Advisory board + - Reviewers, external experts + - FPGA key extract dude + - DJB + + + +- Team + - Addtiona competency needed? + + + +- Project security + - Communication + - ... + + + +Development general +------------------- + +- License(s) + - GPLv2, v3 + - BSD + + + +- Methodology + - Agile + - Minimal functionality in PoC + - Clear increments + + + +- Repository + - Github + + + +Technology +---------- + +- Target technologies + - FPGA (+ internal, external CPUs) + - ASIC + - Pure CPU based + + + +- Target PoC board + - Select one early + + + +- Toolchains and languages + - SW + - HW + - Verilog 2001, 2005, SystemVerilog + - Icarus, gplcver + - Vendor specific + - Validation of bitstream + - Edge of trust, dowm the Rabbit hole + + + +- Security support in design + - JTAG + - BIST for functionality + - BIST for security + - KATS + + + + - On-line self check + - RNG + - Pathological problems + - Stuck at fixed values + - variance + - bias + + + +- Reuse of existing design, code? + - Cores - OpenCores + - OpenRISC + - AES, SHA, RSA + - SoftHSM - DNSSEC PKCS#11 + - Nettle + - ... + + + +- On chip 32-bit or 64 bit CPU core + - OpenRISC + - LGPL + - http://openrisc.net/ + - http://opencores.org/or1k/Main_Page + - https://en.wikipedia.org/wiki/OpenRISC + + + +- RNG + - More than one entropy source + - Just external sources + - User/vendor/implemented supplied + - One external, one internal + - YubiHSM entropy source: https://www.yubico.com/products/yubihsm/ + - Haveged: http://www.issihosts.com/haveged/ + - DakaRand: http://dankaminsky.com/2012/08/15/dakarand/ + - Jytter a userspace RNG: http://www.chronox.de/ + - CPU Jitter RNG: http://www.chronox.de/ + - CSPRNG based on Linux, OpenBSD, Fortuna, NIST etc. + - NIST SP 800-90. CTR_DRBG + - Fortuna https://en.wikipedia.org/wiki/Fortuna_PRNG + - Schneier, Ferguson. No estimator needed. + - OpenBSD arc4random: http://www.openbsd.org/cgi-bin/man.cgi?query=arc4random&sektion=3 + - Raw read access in test mode to collected entropy pre whitening + - Write access in test mode to CSPRNG + - No key generation etc allowed during test mode. + + + +Technical requirements +---------------------- + +- Functional requirements + - TLS 1.x + - Need roadmap for functions + - AES, SHA-256, DH, RSA first iteration + - Why GOST? + - Why MD5? + - Curves supported? + - Curve25519 + - NIST, IEEE, RFC 4xxx + + + +- HW/SW partitioning + - Modularity + + + +- API + - DMA, buffering, formats + - PKCS#11 + - Observability and control + + + +- Security requirements + - Common Criteria - EAL + - FIPS 140-2 level 3-4 + + + +- Performance + - Operations/s + - Packets per second + - Latency + + + +Validaiton +---------- + +- Methodology + - Unit tests, KATs + + + +- Documentation + - What to document + - How + + + +- Reviews + - Plan for them + - Who to ask + + + +- Tools + - Valgrind, Purify, linters + + + +Documentation +------------- + +- Meetings + - Discussions, MoMs + - Decisiona - motivation + + + + - Design + - Test and validation diff --git a/markdown/MailingLists.md b/markdown/MailingLists.md new file mode 100644 index 0000000..95cb5cf --- /dev/null +++ b/markdown/MailingLists.md @@ -0,0 +1,37 @@ +# Communications + +## Mailing Lists + +The following lists are open to all: + +* Cryptech Project Announcements\\ + + announce@cryptech.is\\ + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/announce)\\ + [Announce List Archive](https://lists.cryptech.is/archives/announce/) + +* General technology and engineering list\\ + + tech@cryptech.is\\ + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/tech)\\ + [Tech List Archive](https://lists.cryptech.is/archives/tech/) + +* Repository commit watch list (posting restricted)\\ + + commit@cryptech.is\\ + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/commits)\\ + [Commit List Archive](https://lists.cryptech.is/archives/commits) + +The following lists require approval for subscription: + +* Cryptech Project Core Team\\ + + core@cryptech.is\\ + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/core)\\ + [Core List Archive](https://lists.cryptech.is/archives/core/) + +* Finance, funding, administration\\ + + org@cryptec.is\\ + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/org)\\ + [Org List Archive](https://lists.cryptech.is/archives/org/) diff --git a/markdown/MiscStuff.md b/markdown/MiscStuff.md new file mode 100644 index 0000000..8742c7b --- /dev/null +++ b/markdown/MiscStuff.md @@ -0,0 +1,36 @@ +# References & Miscellaneous + +## Interesting research and people +Advisory board, reviewers etc. + +### Elliptic Curves + +* [http://safecurves.cr.yp.to/](http://safecurves.cr.yp.to/). Including Curve3617. +* [http://www.nsa.gov/ia/_files/nist-routines.pdf](http://www.nsa.gov/ia/_files/nist-routines.pdf). Details for implementing NIST curves. +* [http://blog.cr.yp.to/20140323-ecdsa.html](http://blog.cr.yp.to/20140323-ecdsa.html) djb on How to design an elliptic-curve signature system + + + +### Side channel attacks + +* [http://www.cl.cam.ac.uk/~sps32/](http://www.cl.cam.ac.uk/~sps32/), Dr Sergei Skorobogatov +* [BSI - Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_46_ECCGuide_e_pdf.pdf) + + +## Useful References + + +* [Remote timing attacks are practical](https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-timing.html), D. Boneh and D. Brumley. +* [Common Critiera Security Target for the AEP Keyper](http://www.cybersecurity.my/mycc/document/mycpr/C037/AEP_Keyper_EAL4_ASE_1.3.pdf) +* [Cryptographic hardware: how to make it cool, fast and unbreakable](https://www.cosic.esat.kuleuven.be/ches2012/tutorials.shtml), + + Junfeng Fan, KU Leuven + +* [REC FPGA Seminar IAP 1998](http://web.mit.edu/bunnie/www/xi/rec.html), Bunnie Huang +* [the formal verification of realistic compilers usable for critical embedded software](http://compcert.inria.fr/) + + +## Somewhat Related Web Sites + + +* [List of Open SW Alternatives](https://prism-break.org/) diff --git a/markdown/NoisyDiode.md b/markdown/NoisyDiode.md new file mode 100644 index 0000000..6a9caee --- /dev/null +++ b/markdown/NoisyDiode.md @@ -0,0 +1,28 @@ + +## Noisy Diode entropy source + +The Cryptech project is using Avalanche Noise as a physical entropy source connected to the FPGA. + +Avalanche breakdown is a physical process that occurs when current is forced backwards through a diode until it cannot hold back anymore. The diode will then begin conducting for a brief time until the voltage drops to a point where the diode recovers. The breakdown and recovery points are not deterministic, and can thus be used as a source of real physical entropy. + +The unamplified noise looks like this: + +[[Image(noise1.jpg)]] + +After amplification, details are lost but the signal is now 3.3V (blue is noise before amplification, yellow is amplified) + +[[Image(noise2.jpg)]] + +Many implementations on the Internet feed a similar signal into an ADC (Analog Digital converter) and use the resulting data value at the time of the sampling as entropy. The Cryptech project believes a more robust way of extracting entropy is to instead feed the noise to a Schmitt trigger and then measure the time between rising edges. This would be more robust since any analog reading of the noise (such as with an ADC) will be sensitive to changes in temperature, supplied voltage and component aging. + +After beeing fed through a Schmitt trigger, the noise looks like this (yellow signal, blue is just a 4 MHz clock): + +[[Image(noise-schmitt.jpg)]] + +The Cryptech project has to date made a couple of different hardware entropy source boards, but they all share the same design for the avalanche noise source. The core parts of the circuit are shown below. Git repository with full schematics and source code is linked at the bottom of this page. + +[[Image(noise-schematics.png)]] + +Links: + +[[GitRepositories/user/ft/stm32-avalanche-noise| Raspberry-Pi / USB entropy source]] diff --git a/markdown/OpenCryptoChip.md b/markdown/OpenCryptoChip.md new file mode 100644 index 0000000..521d19c --- /dev/null +++ b/markdown/OpenCryptoChip.md @@ -0,0 +1,183 @@ +[[PageOutline]] + +# An Open Crypto Chip + +## The Layer Cake Architecture Picture +\\ +[[Image(layer-cake.jpg)]] + +\\ +\\ +## Use Cases + +* RPKI/DNSSEC Signing +* Transport VPNs +* Routers and TCP/AO +* Email +* Federations, Identity Systems, SSO etc +* Password Stretching & HMAC:ing +* PGP and SSH Keys on a Stick +* High Quality Entropy Randomness +* A Communications Terminal Doing One Thing Well, Like Jabber w/o X11 +* HSM for Pond, OTR identity keys, ssh private keys, etc. (i.e. key gen, store, import/export non X.509 packages) +* Password management + + +[[Image(cryptech venn.png)]] + +## Basic Functions of Crypto Chip + +* Key Generation +* Key Storage +* Key Wrap +* Key Unwrap +* Hash +* Sign +* M of N Sign +* Verify Signature +* Encrypt +* Decrypt +* KDFs, e.g. Password Stretching (a la PBKDF2) +* Random (RO + noisy diode?) + + +## Key wrapping +We need to support key wrapping. Some pointers: + + +- https://en.wikipedia.org/wiki/Key_Wrap +- http://tools.ietf.org/html/rfc5297 +- http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf +- https://tools.ietf.org/html/rfc3394 +- https://tools.ietf.org/html/rfc5649 + + + +## Things we Should Try To Do, Even if we Can't Do Them Perfectly + +* Tamper Protection (wipe on signal, suggest detectors, suggest potting features) +* Side Channel Attack Reduction + + + + +# Rough Cut at v0.01 Proof of Concept Feature Set +As a proof of concept, to validate as much as possible the assurance of the tools and methods, and as a demonstration of the project tools, team, and architecture, we have a [wiki:RoughV1 proposed version 0.01 product] as a proof of concept and a demonstration of the project tools, team, and architecture +\\ +\\ +# Ongoing Decisions and Research + +* Security Target Description +* Performance Target(s) +* Tool-Chain Investigation +* Prototype Design +* Testing / Assurance Methods for all Components +* Verilog/RTL assurance, with open source and with proprietary +* Prototyping Platform(s) +* Documentation, Decision History, & Transparency + +\\ +\\ + +# Ongoing Development + +* [wiki:SunetInitialDevelopment "SUNET is sponsoring the first two development steps"] currently being done. +* [wiki:TRNGDevelopment " Investigation and planning of a TRNG with entropy sources"] +* [wiki:EDAToolchainSurvey" Investigation of possible EDA tools and ways to do open and assured HW development"] +* [wiki:SideChannel" Collection about side-channel attacks and detection, mitigation methods"] + + +# v0.1 Major Sub-Projects + +## Security Goals and Documentation + +* Agreement +* Specification + + +## Development Platform + +* The Bunnie laptop Novena. Includes a Xilinx Spartan 6 LX45 FPGHA. The specs, drivers, source for Novena can be found here: http://www.kosagi.com/w/index.php?title=Novena_Main_Page + + + +* TerasIC C5G Cyclone 5 GX Starter Kit. Includes an Altera C5GX FPGA. This board is used for core, subsystem development and verification. Info, documentation and ordering of the TerasIC board can be found here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 + + +Here is a writeup on how to [wiki:CoretestHashesC5G "setup and run coretest_hashes on the C5G board"]. + + +* TerasIC DE0-Nano board. This tiny, USB powered board is used for core development and verification. Info, documentation, resources, ordering of the TerasIC board can be found here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=593 + + + +## Hardware Development Tools + + +## Component Libraries + +* Research +* Select +* [wiki:InterconnectStandards "On-chip Interconnect Standards"] to use. + + +## Methods and Validation + +* Overall Strategy +* Following the Tool-Chain + + +## Detailed Specification + +* Feature Set + + +## QA & Documentation + +## Green/Yellow Software Support + +* Spec / ABI +* Development +* Documentationa and Testing + + +## Assured Linux Platform + +* DDC Compiler +* System Build +* Minimal Component Set + + +# v0.1 Project Timeline + +## February 2014 + +* Specification of v0.1 Goals and Feature Set +* Security Goals & Documentation Outline + + +## July 2014 + +* SHA & AES + + +## September 2014 + +* TRNG +* Assured Linux Platform - Initial Report + + +## November 2014 + +* Security Goals & Documentation Overall and v0.1 +* RSA Signing on Bunnie Board +* Assured Linux Platform - Compiler + + +## March 2015 + +* v0.1 Protoype + + +# Future Development +The v0.1 version of CrypTech is not the last version nor the only possible version. The project for example consider possible [wiki:ASICImplementations "ASIC Implementations"]. diff --git a/markdown/OpenDNSSEC.md b/markdown/OpenDNSSEC.md new file mode 100644 index 0000000..49e2868 --- /dev/null +++ b/markdown/OpenDNSSEC.md @@ -0,0 +1,138 @@ +# DNSSEC signing using OpenDNSSEC and a Cryptech alpha board rev03 + +## Before you start, you'll need + + +- A Cryptech Alpha board, preferrably revision "rev03" +- APT on the host system configured to find packages in the Cryptech + + repository, see BinaryPackages for instructions + +``` +apt-get install cryptech-alpha opendnssec opensc +``` + +Once you have the software package installed, you may need to [wiki:Upgrading upgrade your HSM's firmware]. + +## Configure the HSM + +For now, connect USB cables to both the DATA and MGMT ports of your HSM and plug them into the host where you will be running OpenDNSSEC. +In production use it should not be necessary to leave the MGMT port connected, but it's easier to set up this way, and, as this is still a development platform, this is the configuration that's gotten the most testing. + +``` +# eval $(cryptech_probe) +# cryptech_muxd & +# cryptech_console + +Username: wheel +Password: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding + +cryptech> keystore set pin wheel supersikritnewpw +cryptech> keystore set pin so 123456 +cryptech> keystore set pin user 1234 + +cryptech> masterkey set EFBEADDE +^C +``` + +Leave `cryptech_muxd` running, so that the PKCS !#11 library can use it to talk to the HSM. + + +## Configure OpenDNSSEC + +``` +mkdir /var/lib/opendnssec/cryptech + +cat > /var/lib/opendnssec/unsigned/example.com << EOF +\$TTL 600 +example.com. IN SOA hidden-master.example.com. hostmaster.example.com. ( + 2016041401 ; serial + 720 ; 28800 ; refresh (8 hours) + 720 ; 7200 ; retry (2 hours) + 300 ; 604800 ; expire (1 week) + 120 ; 3600 ; minimum (1 hour) + ) + + NS lab.cryptech.is. +test A 127.0.0.1 +EOF + +chown -R opendnssec: /var/lib/opendnssec/* +``` + + +## OpenDNSSEC configuration changes + +/etc/opendnssec/conf.xml: + +``` +<Repository name="Cryptech"> + <Module>/usr/lib/libcryptech-pkcs11.so</Module> + <TokenLabel>Cryptech Token</TokenLabel> + <PIN>1234</PIN> + <SkipPublicKey/> +</Repository> +``` + +The PIN is whatever was chosen as PIN for 'user' above. +The TokenLabel has to be "Cryptech Token", not something you choose. + + +/etc/opendnssec/kasp.xml: + + s/SoftHSM/Cryptech/ + +/etc/opendnssec/zonelist.xml: + +``` +<Zone name="example.com"> + <Policy>lab</Policy> + <SignerConfiguration>/var/lib/opendnssec/signconf/example.com.xml</SignerConfiguration> + <Adapters> + <Input> + <Adapter type="File">/var/lib/opendnssec/unsigned/example.com</Adapter> + </Input> + <Output> + <Adapter type="File">/var/lib/opendnssec/signed/example.com</Adapter> + </Output> + </Adapters> +</Zone> +``` + + +## Initialization and signing + +Make the deamons reload their configuration: + +``` + service opendnssec-enforcer restart + service opendnssec-signer restart +``` + +Initialize opendnssec: + +``` + ods-ksmutil setup +``` + +That should be it! + +See /var/log/syslog for output from ods-kaspcheck, ods-enforcerd and ods-signerd. +See /var/lib/opendnssec/signed/ for a signed example.com zone. + +To list keys using ods-ksmutil, accessing the HSM using pkcs11 +directly (rather than going through any of the opendnssec daemons), +export the environment variables from /etc/default/opendnssec and run +"ods-ksmutil keys list --verbose": + +``` +# ods-ksmutil keys list --verbose +SQLite database set to: /var/lib/opendnssec/kasp.db +Keys: +Zone: Keytype: State: Date of next transition (to): Size: Algorithm: CKA_ID: Repository: Keytag: +example.com KSK ready waiting for ds-seen (active) 2048 8 7f9b9329480ebe5dc81054ccb293e261 Cryptech 62642 +example.com ZSK active 2016-07-13 19:04:30 (retire) 1024 8 97e972633613bd605944a0531ff5399b Cryptech 56620 +``` + +If the output for repository is "Cryptech NOT IN repository", +ods-ksmutil has not been able to actually list the keys in the HSM. diff --git a/markdown/PKCS11Proxy.md b/markdown/PKCS11Proxy.md new file mode 100644 index 0000000..e0776a3 --- /dev/null +++ b/markdown/PKCS11Proxy.md @@ -0,0 +1,50 @@ +The pkcs11-proxy is a way to tunnel PKCS11 over TCP (TLS). This page explains how to build and install PKCS11 proxy on the novena. There are various forks of this on github. We're going to use the SUNET fork since it support TLS-PSK for authentication out of the box. The proxy does not currently support different word length on each side of the tunnel so to use it with the novena platform your PKCS11 client must be 32 bit. + +## Why would you want this? + +Not all applications will run on the arm-based novena. For instance not all parts of opendnssec is not fully ported to arm (and probably never will be). + +## Building PKCS11 proxy + +``` +# apt-get -y install git cmake libssl-dev +# git clone https://github.com/SUNET/pkcs11-proxy +# cd pkcs11-proxy +# mkdir build +# cd build +# cmake .. +# make +# make install +``` + +## Setting up pkcs11 proxy on the novena + +Next create a pre-shared secret for TLS authentication... + +``` +# (echo -n "psk:"`xxd -l 16 -p /dev/random`; echo) > psk.txt +``` + +The resulting file (psk.txt) needs to be present both on the server and client side of the PKCS11 tunnel so copy it (or its one-line content) to the client side of your proxy. + +Now start a pkcs11 proxy daemon: + +``` +# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11_DAEMON_SOCKET="tls://<your ip>:4444" pkcs11-daemon /usr/lib/libpkcs11.so +``` + +Now on another machine (where pkcs11-proxy has been installed) access the remote token via + +``` +# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11_PROXY_SOCKET="tls://<your ip>:4444" pkcs11-tool --module /usr/local/lib/libpkcs11-proxy.so -I +``` + +## Tracing PKCS11 calls + +If you want to trace the PKCS11 calls you can use pkcs11spy from the opensc package. If you install opensc look for an SO called pkcs11-spy.so. On the novena it is in /usr/lib/arm-linux-gnueabihf/pkcs11-spy.so. To use it set your environment variable PKCS11SPY to your real PKCS11 library and use pkcs11-spy.so instead. For instance to use PCKCS11 spy on the server side of the PKCS11 proxy start the pkcs11-daemon thus: + +``` +# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11SPY="/usr/lib/libpkcs11.so" PKCS11_DAEMON_SOCKET="tls://<your ip>:4444" pkcs11-daemon /usr/lib/arm-linux-gnueabihf/pkcs11-spy.so +``` + +This should now generate lots of output when you run PKCS11 calls over the tunnel. diff --git a/markdown/PostAlphaPlan.md b/markdown/PostAlphaPlan.md new file mode 100644 index 0000000..aadc44a --- /dev/null +++ b/markdown/PostAlphaPlan.md @@ -0,0 +1,71 @@ + +The core dev team had a design meeting in Berlin after the alpha workshop. We came up with a plan for the hardware and the software work for the next few months: + +## Hardware + +### Revision 04 + +This is targeted for the mid-flight revision in the 50 board order from propoint. For practical reasons, we should limit ourselves to bugfixes and other "low risk" changes for this release. + + +* On-board battery (super-cap, long battery life etc, battery outside the tamper boundary etc) +* Next generation USB based on Stuges daughter board work +* Support higher clock speeds +* Proposed: pull out 2 more UARTS from the STM32 to support memory-card readers and pin-entry devices + + +### Revision 05 + + +* Power instrumentation +* EMC +* Tamper revisions?? + + +## Software + +The software plan is divided into 3 parts: "now", "next week" and "next month". These are labels, not a time frame. The "now" list represents stuff that is currently seeing active work. We move stuff from "next week" to "now" and from "next month" to "next week" as part of our planning process (at the engineering calls). + +### Now + + +* CLI updates [Done, but waiting on a BSD-friendly license] +* rewrite keystore code to support larger keysizes and more slots [Done] +* multi-core resource management [Done] +* finish verilog EC point multiplier [Done] +* increase clock speed +* openssl engine [Done] +* debug log [Mechanism done, nothing using it yet] +* usb driver matching rev04 usb updates + + +### Next Week + + +* GOST drivers +* key backup [Done] +* SHA3 +* ECDSA verilog [Done] +* build system configuration management +* real documentation: user, admin and dev manuals +* Python RPC client [Done] +* set time and date from CLI + + +### Next Month + + +* 25519 verilog +* design papers +* doxygen +* m of n +* notify ARM and FPGA of tamper events +* secure channel +* ECDH +* AES drivers +* audit logging + + +### Eventually + +* Profiling [Mechanism done] diff --git a/markdown/PrahaWorkshop.md b/markdown/PrahaWorkshop.md new file mode 100644 index 0000000..6638dce --- /dev/null +++ b/markdown/PrahaWorkshop.md @@ -0,0 +1,86 @@ +[[PageOutline]] + +# CrypTech Workshop - 2015.07.18 Praha + +## Logistics + +* Hilton Hotel, the IETF venue +* Amsterdam Room (this is a change) +* 09:00 - 17:00 + + +## Introductions + +* The CrypTech Team +* Others Who Have Contributed +* Other Folk at the Meeting + + +## Workshop Goals + +* Get an understanding of the project status and roadmap +* Discus your requirements and expectations with the team +* Get hands-on experience with the cryptech code on the novena dev board +* Procrastinate finding a new name for the project +* NON-GOAL: you don't get to go home with hardware + + +## Overview of Project + +* Overall Goals + * A Set of Designs, not a product + * Save the World, Securely :) +* Short Term Goals + * Sign a DNSSEC Zone + * Sign RPKI Data +* Roadmap + * Novena Dev Platform + * Noise Board + * Bridge Board + * Alpha Board + * Better/Beta Board :) + + +## Status + +* Novena, Bridge, and Alpha Hardware +* Verilog Cores +* Software +* APIs +* Current Build and Work Packaging + + +## User Feedback So Far + +## Workshop 0 + +* Unpack Novenas +* Install Noise Board +* Build Bitstream and Download +* Build Software and Install +* Install DNSSEC Signware on Your Laptop +* Sign a Zone + + +## User Feedback So Far + +## Workshop 1 + +* Unpack and Install Bridge Boards +* Build Software and Install +* Install DNSSEC Signware on Your Laptop +* Sign a Zone + + +## User Feedback + +## Morning coffee break :) + +## You Should Bring + +* Laptop +* MacOSX, Linux, or ? (if you want to build FPGAware, debian 64-bit, and it needs a desktop, VM OK) +* Micro-SD card if you want to take images and/or data home +* Logic Analyzer (optional, for hardware geeks) +* JTAG Interface (optional, for hardware geeks) +* Cookies or Equivalent to Share diff --git a/markdown/PrahaWorkshopSSH.md b/markdown/PrahaWorkshopSSH.md new file mode 100644 index 0000000..a48c5b6 --- /dev/null +++ b/markdown/PrahaWorkshopSSH.md @@ -0,0 +1,16 @@ +## The list of all known SSH keys + +``` + + +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZJUtfVH0KQfdGhVetTQRpg9Ki8xGKNnO07r6df9DrrmDrsHVSsDOv8zxMoNh4XHbaLtmSCT8IkB8xLU6dXVCH4vWZZwfzaKKRNgMOSfOSc6blKKBV6xEw9qXeMe4dWcfknl3yAr6EqYsg5Lrmqgalr8Vyd6FGAoGbLR4Qh7vrahMqXp3+20kn1xfDm5reSJDbNPmU4eNhJykTNtr6l6CbK/OFzhqcMI/AW5AO0wL8f5wIoHQzescZWQMDMW+1gVyDiS8lGS6nhsSZwZZeAJrXHK/LF3ldz1To5HBxzpU5Sziav8C5bgTeYo5YfqDuBq8m9mgZTzqocXFcXUCr0I6x dol@dolmacbook +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnskRpNxWJE/YgDR3o6sMWwwmbUJ8f2SJa0gHfHM+fcxxC2zQN9/9mqJSxS1E9QdeuRbbHpYxEUtHoX0vSrmia/VALDiQAMps51RBqq6YlrYqvP/Rb0hZ0Z4/YgjTosLdu1PeTzih6mwbyNNF0+gY987Ig31qXQytNF+9G1oSY9dgBAq52lu170QXTRwum4B6Gh4/pCnM6xx+7nY2oqlgvl2wYHVAOJ39W9r4y9kBhcVs51XvJqYehjaoyKYf1+PzA0FsvhJkZuG6ws5eEGSB90lAzKGyFZXedvOLmnFmqAraoLeuKajHIFJDfKNfHHbYpn8ERIfVW66nbqlXFO2g3 fredrik@thulin.net +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo3wT4gGyEmGGw5ePMO+jscvq7lo4hIPQHVZNgrChVWphvD1MkkH6PfoUYNfKwagFjUPQcDotQxGaVfvxL6Y4WzOfwiONHTj/4b2skxdRw5B/K2ZnGw2pbfXP4Nhjb1gry2K+BSVWqP3pVZk5tQ+P0YqbwKNfBFlaqS1dR8uIwo6E/8wGIjcMcDMAioMyRlU2R/u1aXQliol75GWu0jP9xrDyE3mRxoptn7kiUi9JAs/iZtlsiJh51IOADhhNMLWcmQEzKrcR2zytWZqEPzCx9C72/nPl3WacNXqdrMMT5tjt18TOFCf1jhBCHzXMu+biaoHB5sSBtue0zLFyO1A1XxLYxCp+jqlwJm2xAkS1rpFhdW3qlJZe0dV3a3TwepMGi/ObhggEk8ygwDNpYPEbgKqBcKb5RMpPJS2aEKbKd1+UStCagwPNwgRLrBME9YIAI9zyN8sFgHyy70q2XzhUJ5zz+X8JMVaKEKMTVh31u01jQchdvHkkGD7/xbp3hluFOCI1ChYKSlRdakoS6XnPopZ/0tHrkpk+k5lScu9lPHvBTMa3gq+b++TDbkW8dtYq3c78xHcAmOEjXvezbTnKpe/dRfWEUbmrGOch3mzDPoYAtjj7fdEWUGELhCSJB813B7HcGS6oXmW0PYEtOEIgeo83JX6i2qYiTQmjY1kOgBw== jakob@kirei.se +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDEK7I/KcbkhIevS+N88wBEA7OP+HtsULSxB0zl9xZO34mjCHfN6jQDYulwDbsk7IikRO4kn4cqPiaLkSX+8gXv/NsNqLXttK0x5Yt95Q25rXUMKYw/wkDxArD8k+wI71c41iTHyId1ZkHnUNmS9qxS2ajEhOCTYhB5xYYgeUscGwn6iiz5Ksjru28UnL/JZUZ3BHxm62XEHL6Yr9Bz/yzCKatm7+55eH0BMtiWFADtKEKz1nUGR8EUEIuchfQRZzXhmJmk+LNh+ft/BKcAjWKjz7LxncDH0fPqtRBYdB9dxziGozviYi20kVLzDdsOsnVL5lF9km1JtpyMyAHb7fbNA5xsCSge0rRL6+K5g4iX9QcCiTf12HjurHpFOktopItGtF60yyfbK2itBDlYiQxBSU75mvvllBxQ3gk47WCNrhuut/Uyyc8tjLmPdTIfc0+Mjz4owh3hfgNpJTO22jwo7CDtn/2bPe24aRpcrzldlMMi4jLLP58znCxabJFwAe9YrxavqGr9qcS1lBaGCrLc98vTix4eJFQQOazwJIFrDUDeeyuTo/ebAZ3nVQyRBTBDCfr1w06/OVAF9QLuxp2wFtuiVdw/DHZ93OwyCN/wDIC8yH/zJuLPKRD5PyBrQ14KLY/iLHw8scWcebvRvTrCc3SZkdXqhIySArXb+17Qzw== js@snabbis.local +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVvB4gdJ6EWRmx8xUSxrhoUNnWxEf8ZwAqhzC1+7XBY/hSd/cbEotLB9gxgqt0CLW56VU4FPLTw8snD8tgsyZN6KH1Da7UXno8oMk8tJdwLQM0Ggx3aWuztItkDfBc3Lfvq5T07YfphqJO7rcSGbS4QQdflXuOM9JLi6NStVao0ia4aE6Tj68pVVb3++XYvqvbU6NtEICvkTxEY93YpnRSfeAi64hsbaqSTN4kpeltzoSD1Rikz2aQFtFXE03ZC48HtGGhdMFA/Ade6KWBDaXxHGARVQ9/UccfhaR2XSjVxSZ8FBNOzNsH4k9cQIb2ndkEOXZXnjF5ZjdI4ZU0F+t7 leifj+00060AD478D6@sunet.se +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQVmVIptFt7ghSm5PpKw6uRQSEozHGKRN6AUyevyarfMuRONWvnFawTL/bqc6atX23dV6q0mIRzfUu+43ABjv5suwXaXoDw6rc6b8jElX/aJTDjea7n3i2hkhmGQwe8ibvjz2ZgNEkzz8NJSJI9nEzgPoHHM9/enpMb/saPWU/JFfPLAQ9XsQV+u1fhuTyrTlVynKN1iQxxCRjySD9boWo7XGQ8/0VBy28xS/eGDGs4Wty+SKT9QEabipyq7gqqsgoo87B1UUP98kawZF/wPMk5D+bWUej6dHaJEZECdAcalHlj7TCfJJM+ELHcQ8BD+4YzbkjTWPFG6ihI29bnV3z linus@nordberg.se +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfi07vngzbVdipBCSC+pDoauAck0nN45sV+u9A5vRLM9qwYIZm8XFlqJmKhmZMJWaY+rR4VCZKD8F8/Tmw26Q2kOG4tAajA2kZV+2Us0nXHE8YktKoLqojjSxMi73LT/CtAjbxNZNs6hAVKgIDqFyY7pJhrpNkVxQGMHB/MboVTqS1X3Jglm8J9T5/kNNU6brjErFCxQIOnLFJHczdcLMio31wK37jXZUWvbp8dXJrjNINU1r953hBibkZ178LODsitojXWsBckJZPxc43of7caGROesbIZQeGi/BKnxOgKWXresgeZngw8+hb5bQemI+ktbCQg3Exna7EHi6TGCLV paul@Darkstar-VirtualBox +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9+qRUZdFK9Fcweb3Zemice+QFDmqn0uXfjnB9xjIGXlzV7mi7mcDIMwRdL8es4CbNzx7gk8qbxl+bzSWlGrW8mE2smXicvb5aXAl1Gq7A1tmwb9j7Pb3/AUA0fonh086AjH/olVDHEXfE6fA+auMeW7NcYEAY4YBn9yrQSmvS4i3RcZtAETe+aCO/Cjl147DIeqH9hcSbBdEWdcH5Q0DIPYY1QnOlZAdphXDm3Kvr9poSX+2W6Zm8tRYJAATXh+gCFYWF2xig40k/5C0/jX48muuJ+gemav07PiOs6gwrvc2hJvhdHm5+3FoE2MaqPm7xZvEg0maLEvGSvydw0MQ9 paul@psgd.org +ssh-dss AAAAB3NzaC1kc3MAAACBAMcyFrmcI06jwD2IEA5lvqNM84mr05eMIARy+JQ9f++tix9eMk5Y7b9Dmau3iYNG7WAEUtzEhj+ZO1QSMNqDX+TARAkesWHhRtNp5aTSpTrnyb7W74x7Wdjd0Zw6iQyYjzv8qYdcg3siN/POE6traHqzratuSrN9euEjXSq6lmutAAAAFQCo1RS1pRSCgmkTogCNHEqCnHDOOwAAAIEAg0XcJyRT3Er5oanfdQQT69mXfrGkcqGaahJchbIkVX9MDlFLmrAw8Av/77Plesq6uOgQuP1/tgJKN3gjW+n25S4Ly5L6P+vo8JH22+gSDWKdfjbf44xDRdorG19vbOrjynrZ/qZIS9UAdjT0aWiCkyRjhcqFpv3EvqXaqP/wpewAAACBAIu6JsMU53WWWDDVGtFVTKPkx1S0MF69xIOrVVbka88DzHsRg9qLqHlH/7TjVYv8Dzp4SBp1sf70JQhFgA0cPbQB7VcGX9rlJdvSqE2d695iSkJY8X08UrcSasjHbThtbjy1dsVXxiUV0Vt7rFYKaxlk4GJz83p8e7KorTiJMTu/ randy@psg.com +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCkrrpUCqIibbYB7v4Kr/B07yTGXJgMjAsFf+YHIC9WpcLvpe5v4+O8t4Q/WSMVETlkUZHIKVntHeLYLHIQVyL2njuM+MYShslz8lpc0Z/cIInpHSAM/rm9p/6MaKzAz8RODYe9Oxah34bNI7lXLUkNOBsUTRaKUA6jav/kfbPA/Y3ADIo8Hj1HcNfTxw6E+lmFAf3BkdzyvAmTGLIuv9BbD737B25BIERs5U0EltsdDvNPa3gMLyDt/slslu16WzBRE4tijf0Kbl7DyTeBKSi1EAaQe75N8cHgRSJe96ikkNqTy65vcKw41HTCoLzgJA/EuzwWgSvo96pK0uCM27R0+zlg1zp3Z6UQXDhKukmVYP72AF6Csk9BSkb3vURgMAwYDZQUKmzdd+YzE9sdmFa4fwYZmdHs+cC1XcU6uNbo3202yP/E5NiZ9wN8+fKqNpXVePUYPc8ACOYLBO3hjfvtwmXRM1rIcBgm5NbWotlCTmf6c2mfh+4tDtStSNGSf7a3bq9rHIS1GLDH0FNaWkjB+CKY5KnXF4vvMDqauDORt0pTH5OHsVsCgJjemwR0qHK6O7LxcSg8gzNvA5y4N/Pf6tcvoSNLbJoIF+XQ7oRhOYNPiR2gBziQ3paEMLsl57ewGOAvwT+O26wys1tmwcPr0FQHUnIzv+ecDY3oCw9fRw== sra@hactrn.net +``` diff --git a/markdown/ProjectArchive.md b/markdown/ProjectArchive.md new file mode 100644 index 0000000..0407c13 --- /dev/null +++ b/markdown/ProjectArchive.md @@ -0,0 +1,4 @@ +*Page Under Construction* + +# Project Archive and Far Future Planning +## [wiki:AssuredTooChain Assured Tool Chain] diff --git a/markdown/ProjectManagement.md b/markdown/ProjectManagement.md new file mode 100644 index 0000000..aad8443 --- /dev/null +++ b/markdown/ProjectManagement.md @@ -0,0 +1,26 @@ +[[PageOutline]] + +# v0.1 Resources + +## Human - 4-5 FTE + +* 0.5 Specifications +* 1.0 FPGA Tools and Core +* 1.0 Core Libraries and Interfaces +* 0.5 QA & Docs +* 0.5 Assured Linux Platform +* 1.0 Coordination + + +## Hardware + +* 4 Bunnie Boards +* 2 Altera Eval Systems +* Linux Platform + + +## Travel & Overhead + +* Travel $5k/mo +* Communications $1k/mo +* Administrative $1k/mo diff --git a/markdown/ProjectMetadata.md b/markdown/ProjectMetadata.md new file mode 100644 index 0000000..e9b9c70 --- /dev/null +++ b/markdown/ProjectMetadata.md @@ -0,0 +1,27 @@ + +# Project Metadata + +## Project Logo Files + +* See "Attachments" at the bottom of this page +* PhotoFolder + + +== Meeting Presentations and Notes == + +* DocMeet +* PrahaWorkshop +* BerlinWorkshop + + +== Technical References == + +* MiscStuff +* InterconnectStandards +* RandomnessTesting + + +== Related Work == + +* RelatedWork +* SideChannel diff --git a/markdown/ProjectStatus.md b/markdown/ProjectStatus.md new file mode 100644 index 0000000..c42d475 --- /dev/null +++ b/markdown/ProjectStatus.md @@ -0,0 +1,19 @@ +*Page Under Development* + +# Project Status + +## [wiki:Dashboard Project Dashboard] + +## Crypto Chip Design and Prototype + +* PostAlphaPlan +* AlphaBoardStrategy +* AlphaBoardComponents +* [Core Git Repository](http://trac.cryptech.is/wiki/GitRepositories/core) +* [wiki:Hardware] +* [wiki:DevBridgeBoard] + + +## Pilot Project + +* [wiki:DNSSEC Requirements] diff --git a/markdown/QuickStart.md b/markdown/QuickStart.md new file mode 100644 index 0000000..75d5a3f --- /dev/null +++ b/markdown/QuickStart.md @@ -0,0 +1,26 @@ +[[PageOutline]] +*Page Under Development* + +# Git Repositories +The team uses Git to store and track project development. All submissions are [signed](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work). + +The active repositories are automatically posted to GitRepositories. + + +# The Alpha Board + +The current hardware is the AlphaBoard. More information (to be organized at some point -- yes, this wiki is a mess, again): + +* AlphaBoardComponents +* AlphaBoardPictures +* AlphaBoardReview +* AlphaBoardStrategy +* AlphaReviewLog +* AlphaSchematics + + +The Alpha board currently ships with very old firmware, but you can [wiki:Upgrading upgrade it yourself]. + +# DNSSEC signing using OpenDNSSEC + +* [[OpenDNSSEC]] diff --git a/markdown/RandomnessTesting.md b/markdown/RandomnessTesting.md new file mode 100644 index 0000000..0b14c59 --- /dev/null +++ b/markdown/RandomnessTesting.md @@ -0,0 +1,80 @@ +# Randomness Testing Tools + +This page explains some basics on testing for randomness, and the background necessary to understand their outputs. + +## Basic Considerations +When testing the randomness of an alleged/assumed random bit/byte stream, there are two fundamentally different categories of tests: There are *blackbox* tests which are independent of the particular source, and *whitebox* tests tailored to the particular properties of the given source. + +For reasons rather unsurprising, the *blackbox* and *whitebox* categories largely correlate with the categories *publicly available tests from others* and *tests developed by the designers of the particular stream source*; this obviously leads to other issues concerning the trustworthiness and reliability of the tests---testing your own stuff is always a somewhat risky approach. + +All tests basically work by taking a certain part of the data space, declaring them as "not random" or possibly "suspect", and then comparing some test input against this partitioning. Mathematically speaking, all the possible partitionings are equally relevant and as such any stream is equally "random" or "non-random", so choosing any partitioning definition is somewhat arbitrary. + +The usual *blackbox* tests are effectively based on tests used for non-crypto pseudo random number generators; as such, they are generally useful for quick, preliminary testing and for establishing confidence in the source by outsiders. But to test the health of a source, eventually whitebox tests tailored to the failure modes of the given source are needed. + + +## The `dieharder` Test Suite +Dieharder is by far the most extensive blackbox test suite. However, it is originally aimed at testing the output of non-crypto pseudo random number generators; aside from the limitations of using it for an entirely different purpose, it is rather notorious with regard to its need for extensive amounts of input. Additionally, it runs all tests sequentially, rather than making use of today's multi-core multi-threaded CPU architectures; this leads to unnecessary I/O while reading an input file that doesn't fit the disk cache, and runtimes of about an hour or so depending on the sort of computer used. + +### Usage +Generally the best approach to use `dieharder` is to first generate an output file, e.g. `random.out` to run the tests on, so `dieharder` can apply all its individual tests to the same data. For a standard test, at least about 14 GB worth of data are needed; more if one of the tests needing large amounts of data returns a suspect result and `dieharder` re-tries the same test with more data. + +The command line options I (bs) personally use are `dieharder -g 201 -f random.out -s 1 -Y 1 -k 2 -a`: + -g 201 -f random.out:: Don't use a compiled-in pseudo RNG but the file `random.out` as input. + -s 1:: Rewind the input after every test. Without this, successive tests use successive parts of the input file. + -Y 1:: Keep testing until a definite (in probabilistic terms:-) test result is obtained. + -k 2:: Use some high precision numerics for the KS test; recommended by the man page. + -a:: Run all tests. + +Additionally, these may be useful for more targeted testing: + -m <n>:: Multiply the `psamples` value by `n`; good for getting even more reliable results, at the expense of the additional data needed. + -d <test name/number>:: Perform a specific test. + -l:: List all available tests by name and number. + -p <n>:: Set the `psamples` value. See below why you may need this. + +### Interpretation of Results +The way `dieharder` works, it simply returns a clear assessment of the test results; interpretation should be immediately obvious. + +### Caveats +There are a number of things to keep in mind when using `dieharder`, especially so when running it on a reduced amount of test data. + + * If `dieharder` reaches the end of the input file, it rewinds and uses the same test data again. This has rather drastic effects on several tests which assume that some sort of repetition in the input is a sign for a seriously flawed generator. + * The `-Y 1` option works by adding 100 to the value of `psamples` until a conclusive result is found. This works reasonably well with tests that start with a value of 100 to `psamples`, but there are tests starting with 1000, and others starting with 1. + * The `-m <n>` option also just affects the initial value of `psamples`. + * Some of the tests themselves are marked as "suspect" or "do not use" if you run `dieharder -l`. Still, `-a` runs them, for whatever reason. + * Expect about one test in a `-a` run to return a "weak" result that needs to be resolved. According to the man page, about 1 in 1000 tests (not `-a` runs!) may fail despite the fact that the input is good. In that case I suggest doubling the input size, either by using `-m <n>` (which only works in conjunction with `-a`) or by adjusting `psamples` and/or `tsamples` manually. + + +### Installation +The ["Dieharder home page"](http://www.phy.duke.edu/~rgb/General/dieharder.php) provides the source code as well as documentation. Dieharder is also available via package systems in Linux (apt-get install dieharder) and by brew for OSX. + + +## The FIPS140-2 Test Suite `rngtest` from `rng-tools` +While somewhat questionable in the way it has been defined in the FIPS140-2 document (and silently been removed in the -3 draft...), these tests are generally considered useful for a quick preliminary test on small amounts of test data. +They generally work on blocks of 20000 bits. + +### Usage +The `rngtest` program reads data from its standard input and by default returns a statistics overview when it reaches EOF. This can be changed with these two options (among others): + -c <n>:: Stop running after `n` blocks. + -b <n>:: Give intermediate results every `n` blocks. +Use at least one of these when running on a pipe or device... + +### Interpretation of Results +Since `rngtest` works on rather small sample sizes it causes a significant number of false alarms: +| Test | Expected failure rate | +|---|---| +| Total | 800ppm | +| Monobit | 100ppm | +| Poker | 100ppm | +| Runs | 300ppm | +| Long run | 300ppm | +| Continuous run | Extremely rare | + +These failure rates were however measured experimentally rather than derived from the algorithms themselves, so caveat utilitor. + +Seriously flawed inputs often show excessive failures from very small input; it is generally a good idea to keep testing until at least about 100 failures in total have occurred before seriously comparing the measured results to the expected failure rates from the table. + + + + + + diff --git a/markdown/RelatedWork.md b/markdown/RelatedWork.md new file mode 100644 index 0000000..8b48baf --- /dev/null +++ b/markdown/RelatedWork.md @@ -0,0 +1,22 @@ +# Related Work + +## Richard Lamb / ICANN +[Presentation at ICANN](http://ccnso.icann.org/file/32383/download/37379)\\ +[Presentation at ICANN](http://ccnso.icann.org/file/40211/download/52359)\\ +"I wrote pkcs11 libraries and also have modified BIND that offloads full +RRSIG calculation (including time) to board. Clearly can use anything +other than TPM to do RSA calculations." + +## SoftHSM + +- ["SoftHSM"](https://www.opendnssec.org/softhsm/) - part of OpenDNSSEC +- ["Possum"](http://wiki.cacert.org/Possum) - an earlier attempt att an Open Source HSM. + + + +## Project Turris - CZNIC +[Project Thuris Web Pages](http://www.turris.cz/en/)\\ +Project Turris is a service helping to protect its user's home network +with the help of a special router. It is a not-for-profit research +project of CZ.NIC, z. s. p. o., the registry of the Czech national top +level domain .CZ. diff --git a/markdown/ReleaseNotes.md b/markdown/ReleaseNotes.md new file mode 100644 index 0000000..43a7f5b --- /dev/null +++ b/markdown/ReleaseNotes.md @@ -0,0 +1,32 @@ +[[PageOutline]] + +# Release Notes + +## 3.0, May 2017 + + +* New keystore implementation. Basically a very small flash filesystem, including basic wear leveling. Maximum number of keys varies depending on key size and how many options are attached, but for any reasonable use it should hold on the order of 2,000 keys at least. +* In-memory keystore moved to HSM (previously was in memory of the client library), uses same API as flash keystore. +* RPC mechanism extended to support the new keystores (`hal_rpc_pkey_match()`, `hal_rpc_pkey_set_attributes()`, etc). +* PKCS !#11 code rewritten to use libhal attribute mechanism, sqlite3 database gone. +* Verilog implementations of ECDSA base point multipliers for P-256 and P-384 curves, key generation and signing significantly faster than with software ECDSA implementation. +* Key backup mechanism: two more RPC functions, and a Python script `cryptech_backup` to drive the process. +* Private key representation changed to PKCS !#8 format (a self-identifying uniform format with optional encryption, supported by many other tools). Key backup uses encrypted form of PKCS !#8. +* Default build of client software now uses a multiplexer daemon `cryptech_muxd` which allows multiple clients to talk to the HSM at once (packages such as OpenDNSSEC which uses multiple daemons talking to the same HSM need this). Software can still be built for direct connection to HSM but it is no longer the default. +* New trivial script `cryptech_console` to talk to the HSM's management port via the multiplexer daemon; `cryptech_upload` now supports both direct connection and connection via the multiplexer daemon. +* Python client implementations of libhal RPC mechanism and PKCS !#11 now installed as `cryptech.libhal` and `cryptech.py11`, respectively. +* Python PKCS !#11 client hacked to play nicely with `pkcs11-spy` debugging tool. +* RTOS replaced by simple non-preemptive (voluntary yield) tasking system, eliminating a huge morass of potential race conditions, debugging nightmares, priority inversions, and similar horrors. Lack of preemption means that console acess may have to wait for something else to yield the ARM CPU, but it's more than worth it to get rid of all the stability problems the RTOS was causing. +* [source:/user/sra/openssl-engine Sample code for using the HSM as an OpenSSL engine] is available. This only works with RSA for the moment, due to apparent limitations of the engine implementation. + + +Getting started with 3.0: + + +* [wiki:BinaryPackages Install the software]. +* [wiki:Upgrading Upgrade the firmware]. **Please note the warnings about bricking your HSM**, how to avoid that, and what to do if you failed to avoid it. +* Set the usual environment variables, perhaps using `cryptech_probe`. +* Start the multiplexer daemon `cryptech_muxd`. + + +At this point, you should be able to use the PKCS !#11 library, the `cryptech_backup` script, and so forth. diff --git a/markdown/Requirements.md b/markdown/Requirements.md new file mode 100644 index 0000000..434e4db --- /dev/null +++ b/markdown/Requirements.md @@ -0,0 +1,172 @@ +# HSM Requirements + +Requirements for the Cryptech Alpha System. Derived from Use Cases (see below). There are also utility, internal requirements (again, see below). + +## Capacity +### Per key storage requirements +In addition to the actual key data, each key requires + +- Key type – 4 bytes +- Key identifier – 4 bytes +- Key flags, e.g. exportable – 8 bytes + +This results a total 16 bytes overhead for each key. + +### Examples per algorithm +(For RSA, we might also want to include the primes p and q might also be included which requires additional storage.) + + +- RSA-8192 requires 1024 bytes secret key, 1024 bytes public key + 4 bytes exponent + 16 bytes overhead = 2068 bytes +- RSA-4096 requires 512 bytes secret key, 512 bytes public key + 4 bytes exponent + 16 bytes overhead = 1044 bytes +- RSA-2048 requires 256 bytes secret key, 256 bytes public key + 4 bytes exponent + 16 bytes overhead = 532 bytes +- EC P-256 requires 32 bytes secret key, 64 bytes public key + 16 bytes overhead = 112 bytes +- EC P-384 requires 48 bytes secret key, 96 bytes public key + 16 bytes overhead = 160 bytes +- Curve 25519 requires 32 bytes secret key, 32 bytes public key + 16 bytes overhead = 80 bytes + + + +## Use Cases +### DNSSEC +#### Number of keys + +- TLD (or provider using key sharing) requires ~ 100 key pairs +- 3 KSK per zone (previous, current, new) +- 3 ZSK per zone (previous, current, new) + +#### Possibly dual algorithms + +- A typical TLD operator usually has less than 10 TLDs +- Other DNS providers may use key sharing to limit number of keys required + +#### Algorithms + +- RSA-1024/SHA-256 +- RSA-2048/SHA-256 +- EC-P256/SHA-256 + +#### Performance +Each update to a zone requires 3-4 signatures (per algorithm) + +- Resign SOA (signed by ZSK) +- Resign updated RR (signed by ZSK) +- Resign NSEC/NSEC3 (signed by ZSK), may require multiple signatures + +Non-interactive latency (batch), dynamic updates may require faster signing + +### SAML +#### Number of keys +SAML federation operator requires max 10 key pairs (including space for roll) +#### Algorithms + +- RSA-2048/SHA-256 + +#### Performance + +- Non-interactive latency (batch) + - non-MDX: … +- Interactive latency + - MDX: … + + +### PKIX (including RPKI) +#### Number of keys + +- Typical Certification Authority ~ 10 key pairs + - CA key, OCSP, CRL per level in the CA + - Root CA is one level + - For subordinate CAs, perhaps 2-5 CAs in a HSM is reasonable? + +#### Algorithms + +- RSA-2048/SHA-256 +- RSA-4096/SHA-256 +- RSA-4096/SHA-512 ? +- EC-P256/SHA-256 + +#### Performance + +- Non-interactive latency + - Root CA: Less than 1 signature per day + - Issuing CA: One signature per issued certificate + - CRL: Less than 1 signature per hour +- Interactive latency + - OCSP: Multiple signatures per second + + +### Tor +Requirements according to (section 1): https://gitweb.torproject.org/torspec.git/plain/dir-spec.txt +#### Number of keys + +- 1 private key +- 10 public keys + +#### Algorithms + +- RSA-2048/SHA-1 ? +- RSA-2048/SHA-256 +- RSA-4096/SHA-256 ? +- RSA-4096/SHA-512 ? + +#### Performance + +- 2 signatures per hour +- 20 verification operations per hour +- 1 second max latency for RSA-2048 based verification + + +### Certificate Transparency (CT) +#### Number of keys +CT requires 1 key (ECDSA or RSA) per log +#### Algorithms + +- RSA-2048/SHA-256 +- RSA-4096/SHA-256 ? +- RSA-4096/SHA-512 ? +- EC-P256/SHA-256 + +#### Performance + +- A Certificate Transparency log uses one ECDSA or one RSA key to sign two separate documents: +- STH's might need to be signed once per hour +- SCT's might need to be signed once per second (*) + + +See RFC 6962, section 2.1.4 – https://tools.ietf.org/html/rfc6962 + + +## Internal Functional Requirements + +### Algorithms and functions + +- Key wrapping using AES-256 with SIV, http://tools.ietf.org/html/rfc5297 +- Internal Storage Master Key (ISMK) in battery backed RAM connected to FPGA + - Battery connection controlled by tamper mechanism + - Active erasure controlled by tamper mechanism +- 32-bit high quality random number generation + + +### PKCS11 + +The following PKCS11 mechanisms are required to fulfill the aforementioned use cases: + + +- RSA + - CKM_RSA_PKCS_KEY_PAIR_GEN + - CKM_RSA_PKCS + - CKM_RSA_X_509 ? + - CKM_SHA256_RSA_PKCS + - CKM_SHA512_RSA_PKCS ? +- ECDSA + - CKM_EC_KEY_PAIR_GEN + - CKM_ECDSA +- AES + - … TBD … +- Random + - … TBD … +- Key Wrapping + - … TBD … +- Hash + - CKM_SHA256 + - CKM_SHA512 (?) + + diff --git a/markdown/RoughV1.md b/markdown/RoughV1.md new file mode 100644 index 0000000..1891975 --- /dev/null +++ b/markdown/RoughV1.md @@ -0,0 +1,125 @@ +# Rough Cut at v0.01 Proof of Concept Feature Set + +[[PageOutline]] + +This is a proposed version 0.01 product as a proof of concept. The +intent is not to have a very useful product, but rather to gain +confidence in our architecture, tools, and team. The result is intended +to be the basis for further development into a more useful second stage, +in the sense of +[agile development](https://en.wikipedia.org/wiki/Agile_software_development). +It very intentionally is not a +[waterfall design](https://en.wikipedia.org/wiki/Waterfall_model), + +The interface between the Green and Yellow layers is seen as an important design +inflection. + +Some code will be in C in the Green (auxiliary core) because we can get it open +source out of the can. for v.2 (or whatever) we would move it down to the FPGA in +Verilog. + +## FPGA Overview +[[Image(HW_sketch_v0001.png)]] +\\ +\\ +## Sketch of TRNG Chain +[[Image(HW_RNG.png)]] +\\ +\\ + +## Off-FPGA + +* Persistent Storage + * For Keys and Time + * Or the battery for tamper wipe is big enough to hold the FPGA up + * Or the Green processor has enough non-volatile store +* Entropy Source +* Realtime Clock +* Tamper Mechanism + + +## Layers + +``` +#!html +<h1 style="text-align: left; color: blue"> + Blue / FPGA +</h1> +``` + + +* TRNG +* BigNumber, Modular, & Exponentiation (expose to green for RSA) +* SHA-256 +* AES-128 +* EC for ECDH. Curve3617 would be nice, but whatever we can get open source to start +* OpenRISC Core or ARM to support Green (maybe FreeScale from Bunnie) + + +``` +#!html +<h1 style="text-align: left; color: green"> + Green / On-Chip Core +</h1> +``` + + +* RSA 2048 & 4096 (move to blue later) [ 1024 for Tor? ] +* MACs: HMAC, 1305, uMAC +* DH (move to blue later) +* Device Activation, Move Authorization, Wiping + + +``` +#!html +<h1 style="text-align: left; color: yellow"> + Yellow / Off-Chip Support +</h1> +``` + + +* Interface to Red + * PKCS!#8 + * PKCS!#11 + * PGP Support +* X.509 and PGP +* PKCS!#11 for POLA resistance +* No PKCS!#10 because it will take a year +* Backup may be just dump/restore of the whole FPGA/CoreState + + +``` +#!html +<h1 style="text-align: left; color: red"> + Red / Applications +</h1> +``` + + +* X.509 CA +* DNSSEC +* PGP (asymmetric key sign/verify + symmetric message encryption/decryption) +* Tor consensus(?) + + +## Issues in v0.01 + + +* License of tool chain to build +* License for borrowed components (open cores, open fpga) +* License for result + * What we build ourselves - BSD + * What components we ship - life is compromise +* Toolchains, Verilog, C, ... +* FPGAs and ASICs use a Verilog-based toolchain. There are no mature open + + Verilog compilers so the [DDC approach](http://www.dwheeler.com/trusting-trust/) + will not work. Net-list optimization is also an issue. We're looking into this, + but it's going to be really hard. Research for v2. + +* Protoyping platform + * [Bunnie's Novena laptop](http://www.bunniestudios.com/blog/?p=3265) + * Altera Evaluation Board +* RTC, external connectivity to et some sort of assured time +* Repository - too many git junkies. Keep main repo on our server for the security boundary. Can mirror on GitHub to be socially cool. +* Emacs or vi (no Rob, not TECO) :) diff --git a/markdown/SecureChannel.md b/markdown/SecureChannel.md new file mode 100644 index 0000000..1d943d5 --- /dev/null +++ b/markdown/SecureChannel.md @@ -0,0 +1,179 @@ +# Secure Channel + +This is a sketch of a design for the secure channel that we want to +have between the Cryptech HSM and the client libraries which talk to +it. Work in progress, and not implemented yet because a few of the +pieces are still missing. + +## Design goals and constraints + +Basic design goals: + + +* End-to-end between client library and HSM. + + + +* Not require yet another presentation layer if we can avoid it (so, + + reuse XDR if possible, unless we have some strong desire to switch + to something else). + + +* Provide end-to-end message integrity between client library and HSM. + + + +* Provide end-to-end message confidentiality between client library + + and HSM. We only need this for a few operations, but between PINs + and private keys it would be simpler just to provide it all the time + than to be selective. + + +* Provide some form of mutual authentication between client library + + and HSM. This is tricky, since it requires either configuration (of + the other party's authenticator) or leap-of-faith. Leap-of-faith is + probably good enough for most of what we really care about (insuring + that we're talking to the same dog now as we were earlier). + + Not 100% certain we need this at all, but if we're going to leave + ourselves wide open to monkey-in-the-middle attacks, there's not + much point in having a secure channel at all. + + +* Use boring simple crypto that we already have (or almost have) and + + which runs fast. + + +* Continue to support multiplexer. Taken together with end-to-end + + message confidentiality, this may mean two layers of headers: an + outer set which the multiplexer is allowed to mutate, then an inner + set which is protected. Better, though, would be if the multiplexer + can work just by reading the outer headers without modifying + anything. + + +* Simple enough that we can implement it easily in HSM, PKCS #11 + + library, and Python library. + +## Why not TLS? + +We could, of course, Just Use TLS. Might end up doing that, if it +turns out to be easier, but TLS is a complicated beast, with far more +options than we need, and doesn't provide all of what we want, so a +fair amount of the effort would be, not wasted exactly, but a giant +step sideways. Absent sane alternatives, I'd just suck it up and do +this, with a greatly restricted ciphersuite, but I think we have a +better option. + +## Design + +Basic design lifted from "Cryptography Engineering: Design Principles +and Practical Applications" (ISBN 978-0-470-47424-2, +http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470474246.html), +tweaked in places to fit tools we have readily available. + +Toolkit: + + +* AES +* SHA-2 +* ECDH +* ECDSA +* XDR + + +As in the book, there are two layers here: the basic secure channel, +moving encrypted-and-authenticated frames back and forth, and a higher +level which handles setup, key agreement, and endpoint authentication. + +Chapter 7 outlines a simple lower layer using AES-CTR and +HMAC-SHA-256. I don't see any particular reason to change any of +this, AES-CTR is easy enough. I suppose it might be worth looking +into AES-CCM and AES-GCM, but they're somewhat more complicated; +section 7.5 ("Alternatives") discusses these briefly, we also know +some of the authors. + +For key agreement we probably want to use ECDH. We don't quite have +that yet, but in theory it's relatively minor work to generalize our +existing ECDSA code to cover that too, and, again in theory, it should +be possible to generalize our existing ECDSA fast base point multiplier +Verilog cores into fast point multiplier cores (sic: limitation of the +current cores is that they only compute scalar times the base point, +not scalar times an arbitrary point, which is fine for ECDSA but +doesn't work for ECDH). + +For signature (mutual authentication) we probably want to use ECDSA, +again because we have it and it's fast. The more interesting question +is the configuration vs leap-of-faith discussion, figuring out under +which circumstances we really care about the peer's identity, and +figuring out how to store state. + +Chapter 14 (key negotiation) of the same book covers the rest of the +protocol, substituting ECDH and ECDSA for DH and RSA, respectively. +As noted in the text, we could use a shared secret key and a MAC +function instead of public key based authentication. + +Alternatively, the Station-to-Station protocol described in 4.6.1 of +"Guide to Elliptic Curve Cryptography" (ISBN 978-0-387-95273-4, +https://link.springer.com/book/10.1007/b97644) appears to do what +we want, straight out of the box. + +Interaction with multiplexer is slightly interesting. The multiplexer +really only cares about one thing: being able to match responses from +the HSM to queries sent into the HSM, so that the multiplexer can send +the responses back to the right client. At the moment, it does this +by seizing control of the client_handle field in the RPC frame, which +it can get away with doing because there's no end-to-end integrity +check at all (yuck). We could add an outer layer of headers for the +multiplexer, but would rather not. + +The obvious "real" identity for clients to use would be the public +keys (ECDSA in the above discussion) they use to authenticate to the +HSM, or a hash (perhaps truncated) thereof. That's good as far as it +goes, and may suffice if we can assume that clients always have unique +keys, but if client keys are something over which the client has any +control (which includes selecting where they're stored, which we may +not be able to avoid), we have to consider the possibility of multiple +clients using the same key (yuck). So a candidate replacement for the +client_handle for multiplexer purposes would be some combination of a +public key hash and a process ID, both things the client could provide +without the multiplexer needing to do anything. + +The one argument in favor of leaving control of this to the +multiplexer (rather than the endpoints) is that it would (sort of) +protect against one client trying to masquerade as another -- but +that's really just another reason why clients should have their own +keys to the extent possible. + +As a precaution, perhaps the multiplexer should check for duplicate +identifiers, then do, um, something? if it finds duplicates. This +kind of violates Steinbach's Guideline for Systems Programming ("Never +test for an error condition you don't know how to handle"). Obvious +answer is to break all connections old and new using the duplicate +identity, minor questions about how to reset from that, whether worth +doing at all, etc. Maybe clients just shouldn't do that. + +## Open issues + + +* Does the resulting design pass examination by clueful people? + + + +* Does this end up still being significantly simpler than TLS? + + + +* The Cryptography Engineering protocols include a hack to work around + + a length extension weakness in SHA-2 (see section 5.4.2). Do we + need this? Would we be better off using SHA-3 instead? The book + claims that SHA-3 was expected to fix this, but that was before NIST + pissed away their reputation by getting too cosy with the NSA again. + Over my head, ask somebody with more clue. diff --git a/markdown/SideChannel.md b/markdown/SideChannel.md new file mode 100644 index 0000000..83d031a --- /dev/null +++ b/markdown/SideChannel.md @@ -0,0 +1,8 @@ + +# Side Channel Attacks + +Side Channel attacks on hardware are hard to avoid, detect and mitigate. But this should not stop us from trying. The CrypTech platform should be developed with side channel issues in mind. This page tries to collect information about relevant side channel attacks, mitigation strategies, side channel resistant design methods (blinding for example) and detection. + + +* http://eprint.iacr.org/2013/579 "On Measurable Side-Channel Leaks inside ASIC Design Primitives" +* http://people.umass.edu/gbecker/BeckerChes13.pdf "Stealthy Dopant-Level Hardware Trojans" diff --git a/markdown/StateOfPlay.md b/markdown/StateOfPlay.md new file mode 100644 index 0000000..b9b448b --- /dev/null +++ b/markdown/StateOfPlay.md @@ -0,0 +1,160 @@ +[[PageOutline]] + +# A Completely Informal Snapshot Of The Current State Of The Cryptech Project As Of 2014-11-06 + +This page contains a snapshot of the status in the project and will almost certainly be obsolete by the time you read it. If you find something that's wrong, please fix it! + + +## Cores +We have a bunch of cores, primarily for FPGA implementation. Some of them implement cryptographic +algorithms or critical functionality like the TRNG. Other cores are support cores for implementation of the Cryptech HSM. Other cores are for developing the cores and the HW. Finally some are just test +code. + +Cores that have been promoted to official cryptech HW cores: + + +* `core/chacha` - The ChaCha stream cipher +* `core/sha1` - FIPS 180-2 SHA-1 hash +* `core/sha256` - FIPS 180-4 SHA-256 hash +* `core/sha512` - FIPS 180-4 SHA-512/x hash +* `core/trng` - The Cryptech TRNG sub system. Uses ChaCha, SHA-512 and entropy cores. +* `core/avalanche_entropy` - Avalanche entropy provider core. Requires external avalanche noise source. +* `core/rosc_entropy` - Digital ring oscillator based entropy provider core. + + +Utility, test, board support: + + +* `core/coretest` - Core for performing command/response operations to drive testing of a core. +* `core/coretest_hashes` - Subsysem with coretest and the hash function cores as test objects. +* `core/coretest_test_core` - Coretest with a simple test core +* `core/i2c` - I2C interface core. +* `core/novena` +* `core/novena_eim` +* `core/novena_i2c_simple` +* `core/test_core` +* `core/uart`- UART interface core to allow serial communication with FPGA functionality. +* `core/vndecorrelator` - von Neumann decorrelation core. + + +Documentation is very haphazard: some of the repositories have +detailed README.md files, but in many cases the documentation, what +there is of it, is probably meaningful only to the person who wrote +it, not because of any lack of good intent, just because what's +written assumes that the reader knows everything that the author does +about the other cores, the rest of the environment, and how everything +fits together. + +## Builds + +At this point I have figured out how to build two different FPGA +images for the Novena PVT1. In both cases, I'm using the Makefile +rather than attempting to use the XiLinx GUI environment. + + +* `core/novena` builds the current set of digest cores into a + + framework that uses the "coretest" byte stream protocol over an I2C + bus. + + +* `core/novena_i2c_simple` builds the current set of digest cores into + + a framework that uses a simplfied write()/read() API over an I2C bus. + +There's a third build, `core/novena_eim`, which was only just updated +today, and which is reported as not quite stable yet. Will try +building it soon and report here. + +Both working builds (and, almost certainly, any useful build) involve +more than just the named repository. `verilator`, when asked nicely, +will draw a graph of Verilog module relationships. Take this with +salt, as I am a long way from getting `verilator` to run cleanly on +any of this, but the current graphs may still be useful in visualizing +what's happening here. + +At least some of the modules that `verilator` complains about not +being able to find appear to come from XiLinx libraries that +`verilator` doesn't know about. +See [Libraries Guide for HDL Designs]]([http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/spartan6_hdl.pdf|Spartan-6) for details. + +### Module relationships in core/novena build + +[[Image(novena__linkcells.svg)]] + +### Module relationships in core/novena_i2c_simple build + +[[Image(novena_i2c_simple__linkcells.svg)]] + +### Module relationships in core/novena_eim build + +[[Image(novena_eim__linkcells.svg)]] + +### Module relationships in cores/trng build + +By special request, here's a graph for the TRNG too, even though we +don't yet have a way to speak to it from the Novena: + +[[Image(trng__linkcells.svg)]] + +## C Code + +Most of the cores have at least minimal test frameworks, written in a +combination of Verilog, C, and Python, but there's also a preliminary +port of Cryptlib to the Cryptech environment, in `sw/cryptlib`. As of +this writing, the only Cryptech-specific features of this port, other +than a few makefile tricks, are: + + +* A set of HALs that make use of the `core/novena` and + + `core/novena_i2c_simple` FPGA builds, using the Linux /dev/i2c + device interface; and + + +* Another Python script to test the resulting Cryptlib build, using + + the stock Cryptlib Python bindings. + +No HAL for `core/novena_eim` yet. + +The Cryptlib Python bindings build kind of slowly on the Novena, sorry +about that. + +## Hardware + +The hardware guys have done cool stuff with hardware entropy sources. +I even have one of the noise boards, but until I have some way to +connect C code to the TRNG, I don't have much use for it other than to +admire the craftsmanship. Soon, I hope. + +## Tools + +Already mentioned `verilator`. In addition to generating GraphViz +input, `verilator` has a `--lint` mode which looks interesting. + +(JS) Verilator is fairly usable, at least as a linter. Adding `-Wall` provides more warnings. +Since we at least uses Icarus Verilog (iverilog), Altera Quartus and Xilinx ISE one would assume that they would provide all possible warnings. That is not the case. They all seem to fins different things to warn about. And Verilator provides even more. The more parsers and checkers the better. But we will not be able to, or want to fix all warnings. Some things are by design. We should probably document what we ignore. + +I haven't yet figured out whether we have any real use for +`verilator`'s core function of synthesizing Verilog into C++. I've +been toying with the idea of a software-only development environment, +where one simulates an embedded machine using two Unix processes: one +would be a virtual FPGA generated by `verilator`, the other would be a +classical deeply embedded system running as a single process. The two +processes would communicate via a `PF_UNIX` socket or something on +that order. It might be possible to jam everything into a single +process, but I suspect it wouldn't be worth the trouble. + +Joachim has Makefiles which use `iverilog` to generate simulation +images. Installing `iverilog` is easy enough (`apt-get install`, etc) +but I haven't yet figured out how to do anything interesting with the +simulation images. Joachim replies: + + There is help in the Makefile. You run the targets, either as + make sim-foo or just ./foo.sim. Most if not all tests are self + testing with test cases and should report number of test cases and + how many passed. Which should be all. + +As far as I know we've done nothing yet to deal with threats to the +tool chain (Thompson attack, etc). diff --git a/markdown/SunetInitialDevelopment.md b/markdown/SunetInitialDevelopment.md new file mode 100644 index 0000000..974bd5e --- /dev/null +++ b/markdown/SunetInitialDevelopment.md @@ -0,0 +1,137 @@ +# Planning for SUNET funded Cryptech Work +The following documents the first two development steps in Cryptech +funded by SUNET. The development is being done by Joachim Strömbergson +from Secworks AB. + +## Step one (Deadline 2014-02-28) + + - Acquire a FPGA development platform. + +DONE. We have a Terasic DE0 board and a Terasic Cyclone V GX starter kit board. + + + + - Create a working development and verification flow from RTL design + + downto FPGA. + + + - Verify the functionality of the SHA-256 core in a physical FPGA. + + + +### Actions for step one + + - Select FPGA development board to acquire + - Large enough to test sub systems and possibly a complete HSM. + - Good external interfaces for communication with host systems. + - Good external interfaces to entropy sources, memories, + + GPIO. Arduino Shields would be good. + + + - Create a survey on interconnect standards usable for Cryptech + - Availability and market share/usage in third party cores. + - License + - Technical details - Bus, fabric, performance etc. + + + + + - Create base coretest functionality to allow testing of cores in the + + FPGA on the development board. Read and write access to registers + over a known communication channel. + + + - Verify the development flow from Verilog RTL downto FPGA. + + + + - Verifiera SHA-256 core using coretest. + + + + - Start FPGA tool survey + - What is available as open tools and what is the status. + - What is available as open tools from the vendors. + - Talk to people in the industry to get their views on an open toolchain. + + + +## Step two (Deadline 2014-03-31) + + - Produce first draft of design proposal to the Cryptech True Random Number Generator (TRNG) + - Security target, security model and assumptions + - Structure, architecture + - API + - Functionality + - Online test system + - Verification model + - First two entropy sources + + + + - Complete SHA-1 core. Including functional verification in FPGA. + + + + - First draft of SHA-256 and SHA-1 core documentation. + + + +### Actions for step two + + - Create template for documentation + + + + - Collect info on known TRNGs and TRNG strategies + + + + - Collect info on online tests being used. + + + + - Create proposal for architecture. + + + + - Write implementation proposal. + + + + - Specify API. + + + + - Write security target and security model. + + + + - Write assumptions and limitations. + + + + - Write verification model. + + + + - Finalize SHA-1 core RTl. + + + + - Build SHA-1 core in FPGA. + + + + - Verify SHA-1 functionality in FPGA using coretest. + + + + - Write documentation for SHA-256 core. + + + + - Write documentation for SHA-1 core. diff --git a/markdown/TRNGDevelopment.md b/markdown/TRNGDevelopment.md new file mode 100644 index 0000000..9204952 --- /dev/null +++ b/markdown/TRNGDevelopment.md @@ -0,0 +1,9 @@ +# TRNG Development +One, if not THE key functionality in the Cryptech system is the True Random Number Generator (TRNG). We therefore need to discuss, investigate and test to find a TRNG that we and the users of Cryptech can trust and can verify to be trusted. + + +## Information collected + +* [http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Paper.pdf](http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Paper.pdf) (pdf) Pseudorandom Number Generation in Smart Cards: + +An Implementation, Performance and Randomness Analysis. A paper that uses Javacard to implement different TRNGs and evluates them. diff --git a/markdown/UpgradeToKSNG.md b/markdown/UpgradeToKSNG.md new file mode 100644 index 0000000..d33c834 --- /dev/null +++ b/markdown/UpgradeToKSNG.md @@ -0,0 +1,192 @@ +[[PageOutline]] + +# Upgrading Cryptech Alpha HSM to "ksng" development package + +This page attempts to explain the upgrade procedure for testing out +the new "ksng" development branch of the Cryptech Alpha firmware. + +## Cavats + +This particular upgrade is more complicated than we would have +preferred, due to the interaction of two unrelated factors: + +1. As the name (obscurely) implies, the main feature in the ksng + branch is a completely new HSM keystore implementation, which makes + better use of the Alpha's keystore flash, allows a much larger + number of keys, removes the need for an SQL database on the host, + gets your laundry 25% brighter, and leaves your breath alone. + + We did not attempt to provide any sort of backwards compatability + to the old minimalistic keystore implementation, so this upgrade + process will wipe your keystore. Sorry. More importantly (from + the limited viewpoint of the upgrade process), it will change how + the HSM stores its PINs, which complicates the upgrade process. + +2. The "Device Field Upgrade" (DFU) capability in the Alpha's firmware + was a last-minute addition before the Berlin workshop in July 2016, + and, as last minute additions often do, it turned out to be buggy. + There are three distinct pieces of software involved in the upgrade + process, and they were all slightly buggy, in different ways. + Because of this, one must perform the upgrade steps in a particular + order to avoid bricking the HSM. The upgrade includes fixes for + all the (known) bugs in the DFU process, so we hope that this will + be a one-time annoyance (famous last words). + +If something goes horribly wrong and you do somehow manage to brick +your Alpha, don't give up, recovery is still possible, it just +requires an ST-LINK debugger and cable (more on this below). + +## Overview + +Because of the tricky nature of this particular upgrade, you must +perform these steps, in the specified order: + + +* Install the new host software package using APT or Homebrew. +* Wipe the HSM keystore to reset PINs back to the "factory" state. +* Upgrade the main HSM firmware. +* Upgrade the HSM bootloader. +* Log in to upgraded HSM to set PINs, etc. + + +**Upgrading the bootloader before the main firmware will brick your +Alpha.** So don't do that. + +All of the operations here use the Alpha's "management" (MGMT) port, +so that cable must be connected to your Linux or OSX host machine. + +This upgrade procedure was tested on Debian Jessie, with an Alpha +whose firmware had been rolled back to the version from the Berlin +workshop (APT/Homebrew package version 2.0.1468584175, commit +cd445b69b2caa7205f4e1c368aa2c6bf8c2d7692 in repository +https://git.cryptech.is/releng/alpha.git). + +## Install cryptech-alpha-ksng package using apt-get or Homebrew + +Binaries for the "ksng" branch are available as a separate set of +"cryptech-alpha-ksng" packages, which replace the "cryptech-alpha" +packages for the master branch. This seemed the simplest way of +letting people experiment with the new code while falling back to the +old if necessary. The "cryptech-alpha-ksng" packages are declared to +conflict with the "cryptech-alpha" packages, because they install +programs by the same name in the same places and you need the version +of the host software which goes with the HSM firmware your running. + +APT handles package conflicts differently from the way that Homebrew +does. If you have "cryptech-alpha" installed and try to install +"cryptech-alpha-ksng", APT assumes you meant what you said and will +just replace the old package with the new one. Homebrew, on the other +hand, reports the conflict and refuses to proceed until you sort it out. + +The following assumes that you already had the Cryptech APT repository +or Homebrew tap configured; if not, see [[wiki:BinaryPackages]]. + +### Installing cryptech-alpha-ksng package using apt-get on Debian or Ubuntu Linux + +``` +$ sudo apt-get update +$ sudo apt-get install cryptech-alpha-ksng +``` + +### Installing cryptech-alpha-ksng package using Homebrew on OSX + +``` +$ brew update +$ brew uninstall cryptech-alpha +$ brew install cryptech-alpha-ksng +``` + +## Set usual CRYPTECH_* environment variables + +The upgrade process uses the `CRYPTECH_CTY_CLIENT_SERIAL_DEVICE` +environment variable. The easiest way to set it is by using the +`cryptech_probe` script, just as you would for other usage of the +Alpha. + +``` +$ eval `cryptech_probe -v` +``` + +## Clear the keystore flash + +Sorry about this. Yes, we know we need backup and restore, we'll get +there. But for this upgrade, it's safest to wipe the keystore. + +``` +$ cryptech_miniterm + +Username: wheel +Password: <your-wheel-pin-goes-here> + +cryptech> keystore erase YesIAmSure + +^] +``` + +## Upgrade the main HSM firmware + +``` +$ cryptech_upload --firmware --user wheel +PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding +``` + +## Upgrade the bootloader + +``` +$ cryptech_upload --bootloader --user wheel --simon-says-whack-my-bootloader +PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding +``` + +## Log in and set PINs, masterkey, etcetera + +``` +$ cryptech_miniterm + +Username: wheel +PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding + +cryptech> keystore set pin wheel fnord +cryptech> keystore set pin so fnord +cryptech> keystore set pin user fnord +cryptech> masterkey set + +^] +``` + +## What to do if you manage to brick your Alpha + +If the above procedure somehow goes horribly wrong and bricks your +alpha, you can still recover, but you'll need an ST-LINK programmer. +There's some discussion of this at [[wiki:GitRepositories/sw/stm32]]. + +Possible sources for the ST-LINK programmer and a suitable cable: + + +* http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyNUCLEO-F411RE +* https://www.sparkfun.com/products/10376 + + +These are relatively cheap, you'll probably pay as much for the +postage as for the parts themselves. If you have a better source, go +for it. + +The programmer is the important part, you can use any sort of cabling +you like so long as it connects the right pins of the programmer to +the corresponding pins on the Alpha; the SparkFun cable just happens +to be a tidy package which matches the relevant SWD headers. + +We'll include a more detailed description of the recovery process here +if anybody needs it, but the short version is: + + +* Install OpenOCD on your host machine. +* Open up the Alpha's case, take the board out. +* Connect the programmer and power the board back up. +* Use the `flash-target` script from the `sw/stm32` repository to + + stuff the `hsm.elf` and `bootloader.elf` files from the binary + firmware tarball into the HSM. + +* Power down, disconnect the programmer, put the Alpha back in its + + case, done. diff --git a/markdown/Upgrading.md b/markdown/Upgrading.md new file mode 100644 index 0000000..bfc9106 --- /dev/null +++ b/markdown/Upgrading.md @@ -0,0 +1,190 @@ + [[PageOutline]] + +# Upgrading the Cryptech Alpha HSM + +This page explains how to upgrade the Cryptech Alpha firmware, bootloader, +and FPGA bitstream (as needed). + +All of the operations here use the Alpha's "management" (MGMT) port, +so that cable must be connected to your Linux or OSX host machine. + +## Upgrading from the stock firmware (Berlin workshop or CrowdSupply) + +The main feature of the 3.0 firmware release is a completely new HSM +keystore implementation, which makes better use of the Alpha's keystore +flash, allows a much larger number of keys, and removes the need for an +SQL database on the host. (See ReleaseNotes.) + +We did not attempt to provide any sort of backwards compatability to the +original minimalistic keystore implementation, so this upgrade process +will wipe your keystore. Sorry. More importantly (from the limited +viewpoint of the upgrade process), it will change how the HSM stores its +PINs, which complicates the upgrade process. + +Because we use the bootloader to upgrade the firmware, and the firmware to +upgrade the bootloader, both use the PINs stored in the keystore to login, +so both need to understand the new keystore, so both need to be upgraded. + +Because of the tricky nature of this particular upgrade, you must +perform these steps, in the specified order: + + +* Install the new host software package using APT or Homebrew. +* Wipe the HSM keystore to reset PINs back to the "factory" state. +* Upgrade the main HSM firmware. +* Upgrade the HSM bootloader. +* Log in to upgraded HSM to set PINs, etc. + + +**Upgrading the bootloader before the main firmware will brick your +Alpha.** So don't do that. + +If something goes horribly wrong and you do somehow manage to brick +your Alpha, see DisasterRecovery. + +## Upgrading from 'ksng' + +A few intrepid users are already testing the 'ksng' development branch, +using the instructions at [wiki:UpgradeToKSNG]. In this case, and with future +upgrades, it it not necessary to either wipe the keystore or upgrade the +bootloader. + + +* Install the new host software package using APT or Homebrew. +* Upgrade the main HSM firmware. + + +## Install the cryptech-alpha package + +### using apt-get on Debian or Ubuntu Linux + +``` +$ sudo apt-get update +$ sudo apt-get install cryptech-alpha +``` + +Yes, you have to install it even if you already had it installed, because +APT wants permission before accepting the new package dependencies. + +Or you could instead run: + +``` +$ sudo apt-get upgrade --with-new-pkgs +``` + +but that might upgrade unrelated stuff. + +If you had the '-ksng' package installed, you might then want to run: + +``` +$ sudo apt-get remove cryptech-alpha-ksng +$ sudo apt-get autoclean +``` + +but nothing terrible is likely to happen if you omit those steps. + +If you're running on Debian Jessie, you may need to enable [`jessie-backports`](https://backports.debian.org/Instructions/) and make sure you're getting the `python-serial` and `python-tornado` dependencies from the backports (the versions of those packages in the base Debian Jessie distribution are too old). + +### using Homebrew on OSX + +If you're upgrading from the original firmware (have not installed the `-ksng` package), a normal Homebrew upgrade cycle +should suffice: + +``` +$ brew update +$ brew upgrade +``` + +If you have the `-ksng` package installed, you need to tell Homebrew that you want to switch back: + +``` +$ brew update +$ brew migrate cryptech-alpha-ksng +$ brew update +``` + +In either case, you might then want to do something like: + +``` +$ brew cleanup +``` + +but nothing terrible is likely to happen if you omit that step. + +If you've tried doing this and nothing happens, you might be hitting a known old bug in Homebrew itself. Make sure your copy of Homebrew is up to date, and if that still doesn't work, try deinstalling whichever `cryptech-alpha*` package you have installed and reinstalling `cryptech-alpha`. + +## Set usual CRYPTECH_* environment variables + +The upgrade process uses the `CRYPTECH_CTY_CLIENT_SERIAL_DEVICE` +environment variable. The easiest way to set it is by using the +`cryptech_probe` script, just as you would for other usage of the +Alpha. + +``` +$ eval `cryptech_probe` +``` + +(Note: you can use the new `cryptech_muxd` and `cryptech_console`, but +these instructions assume you are familiar with `cryptech_miniterm`. Or +you could be using `picocom` or `kermit` or something else. Doesn't matter +to us.) + +## Clear the keystore flash + +If you are upgrading from the original firmware, you will need to wipe the +keystore, to avoid confusing the new keystore code. + +The good news is that we have a utility to back up and restore the new +keystore. The bad news is that we don't have a way to back up the old +keystore. + +``` +$ cryptech_miniterm + +Username: wheel +Password: <your-wheel-pin-goes-here> + +cryptech> keystore erase YesIAmSure + +^] +``` + +## Upgrade the main HSM firmware + +``` +$ cryptech_upload --firmware --user wheel +PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding +``` + +## Upgrade the bootloader + +``` +$ cryptech_upload --bootloader --user wheel --simon-says-whack-my-bootloader +PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding +``` + +## (Optional) Upgrade the FPGA bitstream + +This upgrade includes an experimental ECDSA point multiplier in hardware, +which the firmware will use if present. + +``` +$ cryptech_upload --fpga --user wheel +PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding +``` + +## Log in and set PINs, masterkey, etcetera + +``` +$ cryptech_miniterm + +Username: wheel +PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding + +cryptech> keystore set pin wheel fnord +cryptech> keystore set pin so fnord +cryptech> keystore set pin user fnord +cryptech> masterkey set + +^] +``` diff --git a/markdown/UsingSTLink.md b/markdown/UsingSTLink.md new file mode 100644 index 0000000..02cc21e --- /dev/null +++ b/markdown/UsingSTLink.md @@ -0,0 +1,98 @@ +# Using ST-LINK + +ST-LINK is STM's implementation of the [| Serial Wire Debug (SWD)](https://developer.arm.com/products/architecture/cpu-architecture/debug-visibility-and-trace/coresight-architecture/serial-wire-debug) protocol. +Think of it as JTAG if you're more comfortable with that. + +## Getting an ST-LINK programmer + +ST-LINK is built into all(?) of STM's Nucleo and Discovery evaluation +boards, which can be had for as little as US$10 from [Mouser](http://mouser.com) +or [element14] ([http://newark.com Newark](http://element14.com) in +the Americas, [Farnell](http://farnell.com) in Europe). + +We have tested with STM32F0DISCOVERY and STM32F4DISCOVERY (both with ST-LINK +v2.0) and NUCLEO-F411RE (with ST-LINK v2.1). + +### Connecting the ST-LINK programmer to the Alpha + +On the STM board, remove the pair of ST-LINK jumpers (CN4 on the F4DISCO, +CN2 on the F0DISCO and NUCLEO). Then locate the 6-pin SWD header (CN3 on +the F0DISCO, CN2 on the F4DISCO, CN4 on the NUCLEO), and connect it to J1 +on the Alpha board (top, just left of center). + +This photo shows the correct orientation of the cables (both boards +oriented so that the logo is right-side up): + +[[Image(IMG_20170512_205557_s.jpg)]] + +NOTE: The STM boards have an unfortunate tendency to short unexpectedly, so +I recommend putting them in an enclosure. In this case, I've cut holes in +the original packaging. + +## Install OpenOCD and the debugger + +``` +$ apt-get install gdb-arm-none-eabi openocd +``` + +## Get the `debug` and `flash-target` scripts + +If you don't already have a cryptech source tree somewhere, get the source distribution, e.g. +``` +$ apt-get source cryptech-alpha +``` + +The scripts are in `sw/stm32/bin`. + +## Re-flashing the Alpha + +### To reflash with our binary firmware +``` +$ tar xfz /usr/share/cryptech-alpha-firmware.tar.gz +$ flash-target hsm +``` + + +What you should see is something like: +``` +** Programming Started ** +auto erase enabled +Info : device id = 0x20016419 +Info : flash size = 2048kbytes +Info : Dual Bank 2048 kiB STM32F42x/43x/469/479 found +target halted due to breakpoint, current mode: Thread +xPSR: 0x61000000 pc: 0x20000046 msp: 0x2002fffc +wrote 524288 bytes from file projects/hsm/hsm.elf in 12.344705s (41.475 KiB/s) +** Programming Finished ** +** Verify Started ** +target halted due to breakpoint, current mode: Thread +xPSR: 0x61000000 pc: 0x2000002e msp: 0x2002fffc +target halted due to breakpoint, current mode: Thread +xPSR: 0x61000000 pc: 0x2000002e msp: 0x2002fffc +verified 509100 bytes in 0.953672s (521.320 KiB/s) +** Verified OK ** +** Resetting Target ** +Info : Unable to match requested speed 2000 kHz, using 1800 kHz +Info : Unable to match requested speed 2000 kHz, using 1800 kHz +adapter speed: 1800 kHz +shutdown command invoked +``` + + +### To reflash with firmware you built from source + +See BuildingFromSource. + +## Debugging the Alpha + +This site shows several ways to use various debuggers to debug the +firmware in an STM32: + + http://fun-tech.se/stm32/OpenOCD/gdb.php + +There is a shell script called 'bin/debug' that starts an OpenOCD server +and GDB: + +``` +$ sw/stm32/bin/debug projects/hsm/hsm +``` diff --git a/markdown/WhoWeAre.md b/markdown/WhoWeAre.md new file mode 100644 index 0000000..bed3562 --- /dev/null +++ b/markdown/WhoWeAre.md @@ -0,0 +1,40 @@ +# Who We Are + +This effort was started at the suggestion of Russ Housley, Stephen Farrell, and Jari Arkko of the IETF, to meet the assurance needs of supporting IETF protocols in an open and transparent manner. + +But this is not an IETF, ISOC, ... project. As the saying goes, we work for the Internet. + +## Tech Core + +Fredrik Thulin\\ +Jakob Schlyter\\ +[[Joachim Strömbergson]]\\ +Leif Johansson\\ +Linus Nordberg\\ +Lucy Lynch\\ +Patrik Wallström \\ +Павел Шатов (Pavel Shatov)\\ +Peter Stuge\\ +[Randy Bush](https://psg.com/~randy)\\ +[Austein]]([https://www.hactrn.net/sra/|Rob)\\ +Steven Bellovin\\ +Basil Dolmatov\\ + +```#!comment == Technical Help == +Bart Preneel ![0]\\ +Tero Kivinenv ![0]\\ +``` + +## IETF Help + +Russ Housley\\ +Sean Turner\\ +Stephen Farrell\\ + +## Coordination + +Leif Johansson - Administration\\ +Randy Bush - Technical\\ +Russ Housley / Lynn StAmour - Finding Funding\\ + +------ diff --git a/markdown/WikiStart.md b/markdown/WikiStart.md new file mode 100644 index 0000000..c84bafb --- /dev/null +++ b/markdown/WikiStart.md @@ -0,0 +1,75 @@ +[[PageOutline]] + +# Overview + +Recent revelations have called into question the integrity of some of +the implementations of basic cryptographic functions and devices used to +secure communications on the Internet. There are serious questions about +algorithms and about implementations of those algorithms in software and +particularly hardware. The goal of the [CrypTech](https://cryptech.is) +project is to provide some possible answers to those questions by +developing an open-source hardware cryptographic engine that meets the +needs of high assurance Internet infrastructure systems that use +cryptography. + +The algorithmic issues are in the domain of the heavy math cryptography +folk; the implementation issues are the primary focus of the project. +The open-source hardware cryptographic engine must be of general use to +the broad Internet community, covering needs such as secure email, web, +DNS, PKIs, etc. + +The intent of the project is that the final open-source hardware cryptographic +engine can be built by anyone from public hardware specifications and +open-source firmware. Anyone can then operate it without fees of any +kind. + +# About Us +[CrypTech.IS](https://cryptech.is) is a loose international collective +of [WhoWeAre engineers] trying to improve assurance and privacy on the +Internet. It is funded diversely and is administratively quartered outside +the US. + +We are actively seeking use cases for an initial project which is to +produce a design of an open and auditable Hardware Security Module (HSM) +and supporting software. + +We are also considering the issues around assurance of a tool-chain, +from compiler to operating system and as close to the hardware as we can +reasonably get. + +The project solicits functional requirements from a wide range of +organizations. It will focus on the classic low level cryptographic +functions and primitives, and not get drawn into re-implementation of +application protocol layers. + +We hope that a group of interested organizations will offer funding +for development, and that the IACR and public sector cryptographers will +provide algorithmic advice and wide and open review. If you or your +organization is interested in helping this effort, please consider +offering [financial support](https://cryptech.is/funding/) to keep the +work flowing. + +# More Information +## [[span(style=color: brown,[QuickStart Quick Start Guide])]] + +* including pointers to the git repositories, information on how to set up and configure the board and software, and HSM requirements + + +## [[span(style=color: brown,[DevelopersGuide Developers Guide])]] + +* including the architecture diagrams, and known information + + +## [[span(style=color: brown,[ProjectStatus Project Status])]] + +* including information on the chip design and prototypes as well as the pilot project(s) + + +## [[span(style=color: brown,[ProjectMetadata Project Metadata])]] + +* including information on presentations and meeting notes, technical references, and related work + + +## [[span(style=color: brown,[ProjectArchive Project Archive])]] + +* including information on dormant and far-future work diff --git a/tools/trac2md.py b/tools/trac2md.py index 838a36f..214471f 100755 --- a/tools/trac2md.py +++ b/tools/trac2md.py @@ -17,6 +17,7 @@ wikilink_pattern = re.compile('\[http(.*)\]') wikilink_extract = re.compile('\[(.*)\]') strikethrough_pattern = re.compile('~~(.*)~~') camelcase_pattern = re.compile("!(\w+)") +image_pattern = re.compile("\[\[Image\((.*)\)\]\]") wikiheading_patterns = tuple((level, re.compile("^{} (.*)[ \t]*=*$".format("=" * level))) for level in range(1, 7)) @@ -104,6 +105,18 @@ def convert_strike(line): pass return line +def convert_image(line): + image_result = image_pattern.search(line) + if image_result: + try: + image_text = image_result.group(1).split(",")[0].strip() + old_text = image_result.group(0) + new_text = "<img src=\"{}\">".format(image_text) + line = line.replace(old_text, new_text) + except: + pass + return line + def WikiToMD(content): ''' Convert wiki/RST format to Markdown. Code blocks, bold/italics, wiki links, lists, striked text, and headers. ''' @@ -196,6 +209,9 @@ def WikiToMD(content): # Convert striked through text line = convert_strike(line) + # Convert images + line = convert_image(line) + # Convert bold and italic text (do this last) line = line.replace("'''", "**") # Convert bold text line = line.replace("''", "*") # Convert italic text @@ -204,11 +220,3 @@ def WikiToMD(content): new_content.extend(tail) return "".join(new_content) - -if __name__ == "__main__": - for f in sys.argv[1:]: - d = WikiToMD(open(f, "r").read()) - newf = f.replace(".trac", ".md") - with open(newf, "w") as fp: - fp.write(d) - pass diff --git a/tracwiki/ASICImplementations.trac b/tracwiki/ASICImplementations.trac new file mode 100644 index 0000000..2f6373e --- /dev/null +++ b/tracwiki/ASICImplementations.trac @@ -0,0 +1,106 @@ += Development of a Cryptech ASIC Implementation =
+
+== Introduction ==
+The aim of the Cryptech project is to develop an open, free, and
+auditable HSM. The Cryptech HSM includes both SW and HW parts. In at
+least the first iteration of the Cryptech HSM, the HW parts are
+implemented using FPGA devices. However, the ability to implement the
+HW parts in a Cryptech ASIC device in a future iteration is anticipated
+in the design. This text provides a short description of what the HW
+part of the Cryptech HSM contains, the design style used, and what would
+have to change in order to implement the HW part in an ASIC.
+
+
+== General digital functions and internal memories ==
+The Cryptech digital functionality cores, such as the SHA-256 core, are
+written in generic RTL (Register Transfer Level) Verilog code. The code
+is written in a fairly conservative coding style and use language
+features from IEEE 1364-2001 (aka Verilog 2001).
+
+All RTL code is divided into modules that contain one process for register updates and reset (''reg_update''), one or more combinational processes for datapath and support logic such as counters. Finally if needed, each module has a separate process that implements the logic for the final state machine that controls the behaviour of the module.
+
+All cores are divided into a core, for example ''sha256_core.v'' and a number of submodules the core instantiates. The core provides raw, wide ports (256 bit wide key for AES for example) that is not suitable to use in a stand alone system. Instead each core comes with a top level wrapper, for example ''sha256.v''. This top level wrapper contains all registers and logic needed to provide all functionality of the core via a simple 32-bit memory like interface. If the core is going to be used as a tightly integrated submodule, the wrapper can be discarded. Similarly, if the core is going to be used in a bus system that use a specific bus standard such as AMBA AHB, CoreConnect or WISHBONE, only the top level wrapper will be needed to be replaced or modified to match the desired bus standard.
+
+The RTL code does not explicitly instantiate any hard macros such as
+memories, multipliers, etc. Instead all such functions are left to the
+synthesis tool to infer based on the code. All memories are placed in separate modules to allow easy modification of the design. In an ASIC setting any memories not automatically mapped will be replaced by instantiation of specific macros.
+
+Some of the memories in the designs have combinational read (i.e the read
+data is not locked by an output register, which infers a one cycle read
+latency). For some FPGA technologies these memories are not compatible with the available physical memories. The synthesis tools therefor implement these memories
+using separate registers rather than selecting a memory instance. In an ASIC
+implementation these memories would likely become real memory macros to allow for a faster and more compact implementation.
+
+
+== Interfaces ==
+External interfaces such as GPIO, Ethernet GMII, UART, etc., will always
+require some modification for the Cryptech design to be implemented in a
+given technology, whether it is a specific FPGA type or an ASIC. The
+important thing is that the Cryptech design does not use technology
+specific macros to implement the interfaces. But pin assignments,
+timing, and electrical requirements will always require adjustment and
+work.
+
+
+== Clocking and reset ==
+The design style used in the Cryptech Verilog code currently follows the
+guidelines from the FPGA vendors Altera and Xilinx. This means that we
+use synchronous reset. For an ASIC implementation this will also work,
+even though asynchronous reset is far more common in ASIC designs. Changing
+to asynchronous reset is not a very big undertaking however, as the
+register reset and update clocking are separated into easily
+identifiable processes (''reg_update'') in the modules.
+
+Most if not all registers in the Cryptech Verilog code have a defined
+reset state. Most registers also have a write enable signal that
+controls the update. This corresponds well with the registers available
+in FPGA technologies from Altera and Xilinx and their recommended design strategy from the vendors. This is also in line with common
+and good design styles for ASICs, which allows for compact code and low
+power implementations. The design is currently not use any clock gating. In future revisions this might be added if power consumption needs to be reduced and does not add side channel issues.
+
+
+== External memories ==
+The Cryptech hardware design will use external persistent memories for
+protected key storage as well as external SRAM for protected master key
+storage. In an ASIC implementation the master key memory would probably
+be integrated to further enhance security.
+
+Just like other external interfaces (see above), the interfaces for the
+external memories do not use any explicitly instantiated hard macros in
+the FPGAs.
+
+
+== Entropy sources ==
+The current Cryptech design contains two separate physical entropy
+sources.
+
+1: An avalanche noise based entropy source placed outside the FPGA. The
+entropy source signal is sampled by the FPGA using a flank detection
+mechanism.
+
+An ASIC implementation would be able to use the external entropy source just like the FPGA. Furthermore, depending on the process options, it might be
+possible to have an internal avalanche diode based on ESD structures commonly used in I/O pin implementations. In a power management capable process, functionality available in step-up converters might also be possible to use as internal avalanche noise source.
+
+Note that integrating the avalanche noise source does not mean that an off-chip noise source is excluded. The Cryptech RNG is modular and having both an internal and an external avalanche noise source is quite possible.
+
+2: A ring oscillator based entropy source placed inside the FPGA. The ring oscillator used in the FPGA is based on carry chain feedback through adders. An ASIC implementation of this ring oscillator should work and produce noise with similar characteristics. However the specific circuit will have to be characterized with explicit layout and qualified for the given process.
+
+
+== Toolchain ==
+Crypech currently use Verilog simulators for functional verification and commercial FPGA tools for implementation including time analysis.
+
+An ASIC implementation will require several new tools including tools for synthesis, place & route and static time analysis that is acceptable as sign-off tool by the chip process vendor.
+
+
+== Conclusions ==
+The HW designed for the first iteration of Cryptech is not specifically
+designed for FPGA implementation, but is in fact designed in a generic
+way to allow for easy implementation using different technologies such
+as ASICs.
+
+There are however parts of the design that will have to be updated or
+modified in order to create a good ASIC implementation. The Cryptech
+project is confident that we know what those parts are and what they
+would entail.
+
+Developing an ASIC will however require new tools which will incur costs.
\ No newline at end of file diff --git a/tracwiki/AlphaBoard.trac b/tracwiki/AlphaBoard.trac new file mode 100644 index 0000000..0718ebb --- /dev/null +++ b/tracwiki/AlphaBoard.trac @@ -0,0 +1,33 @@ += Alpha Board =
+
+== Rev 02 ==
+
+=== Components ===
+
+- ARM Processor: [http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f429-439.html STM32F429]
+- FPGA: [http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html Xilinx Artix-7 XC7A200T-1]
+- Tamper Circuit: [http://www.atmel.com/devices/ATTINY828.aspx ATtiny828]
+
+
+
+=== Status LEDs ===
+
+||= ID =||= Color =||= Meaning =||
+|| 01 || Green || ARM LED 2 ||
+|| 02 || Red || ARM LED 4 ||
+|| 03 || Blue || ARM LED 1 ||
+|| 04 || Yellow || ARM LED 3 ||
+|| 05 || Yellow || Application Access USB UART Rx ||
+|| 06 || Green || Application Access USB UART Tx ||
+|| 07 || Yellow || Management Access USB UART Rx ||
+|| 08 || Green || Management Access USB UART Tx ||
+|| 09 || Green || AVR LED 2 ||
+|| 10 || Red || AVR LED 4 ||
+|| 11 || Blue || AVR LED 1 ||
+|| 12 || Yellow || AVR LED 3 ||
+|| 13 || Red || FPGA Config NOT DONE ||
+|| 14 || Red || FPGA LED 3 ||
+|| 15 || Green || FPGA LED 1 ||
+|| 16 || Yellow || FPGA LED 2 ||
+|| 17 || Blue || FPGA LED 0. [https://trac.cryptech.is/browser/core/comm/fmc/src/rtl/fmc_indicator.v Toggles with sys_clk when FMC is active.] ||
+|| 18 || Green || Power OK ||
diff --git a/tracwiki/AlphaBoardComponents.trac b/tracwiki/AlphaBoardComponents.trac new file mode 100644 index 0000000..eb62593 --- /dev/null +++ b/tracwiki/AlphaBoardComponents.trac @@ -0,0 +1,238 @@ += !CrypTech Alpha Board BOM and PCB design requirement sketch =
+This document contains a list of component level description and requirements for the Crypteh Alpha board.[[BR]]
+The document is to be used as a BOM (Bill Of Materials) and PCB design requirement description for discussing with PCB designers on what we want to have designed.[[BR]]
+The block diagram for the Alpha board can be seen at: [wiki:Hardware]
+
+The Alpha board basically consists of three major sub systems:[[BR]]
+1. '''The FPGA Sub System'''[[BR]]
+ Used to implement !CrypTech crypto/security cores accessible by the CPU as coprocessors.[[BR]]
+
+2. '''The CPU Sub System'''[[BR]]
+ Talks to host systems and handles incoming commands. Basically implements the application interface.
+ Controls the FPGA Sub System. The CPU Sub System is heavily inspired/based on the CPU parts of the Novena and the iMX6 Rex boards.[[BR]]
+
+3. '''The Tamper Detect Sub System'''[[BR]]
+ Responsible for implementing tamper detection and control/alarm as a separate functionality from the CPU.
+ On the Alpha board this system is fairly simplistic. But we want to at least have a minor MCU that can run
+ independently on battery power and control the Master Key Memory (MKM). detect external events and generate
+ alarms. This allows us to start developing and reason about tamper detection and monitoring separately from the CPU.
+
+The Alpha board should preferably be a single board with all three sub systems on the same board.
+
+We are currently using the [http://www.kosagi.com/w/index.php?title=Novena_Main_Page Novena] board, and the Alpha board CPU Sub System functionality from is based on the Novena. We also have a trust in the [http://www.imx6rex.com/ "iMX6 Rex"] board. Using the the Novena and/or iMX6 Rex as basis for the Alpha board design might (should) be a good way forward.
+
+
+=== Authors and timeline/revision history ===
+Joachim Strömbergson, Fredrik Thulin
+
+* 2015-03-25: Updates from group and maillist discussions. Sync with the diagram.
+* 2015-03-16: Updates from group discussions.
+* 2015-03-09: Work started. Initial versions with headers for all blocks.
+
+
+= FPGA Sub System =
+
+=== FPGA ===
+The board should be equipped with a Xilinx Artix-7 200T FPGA device, more specifically XC7A200T FBG484 speed grade -3.
+* [http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html Xilinx Artix-7 XC7A200T FBG484.][[BR]]
+* [http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf Product family overview][[BR]]
+
+The FPGA pad layout should be compatible with the Xilinx Artix-7 FGG484 used by XC7A100T and XC7A75T.
+
+
+=== FPGA Clocking and Reset ===
+* There should be a separate clock, fpga_clk, for the FPGA that starts providing a clock signal at power up. The base frequency for fpga_clk should be 50 MHz.
+* There should be a separate reset circuitry for the FPGA that resets the FPGA at power up and make the FPGA read the configuration from the confguration memory.
+* The ARM CPU should be able to reset the FPGA to force it reload the confiuration from configuration memory. The CPUY should be able to reset the FPGA by asserting a GPIO. The ability of the CPU to force reset should be possible to remove by removing a jumper.
+
+
+=== FPGA CPU Interface ===
+* The FPGA is connected to the CPU using the i.MX6 EIM interface.
+* The data width is 16 bits.
+* The address width is 24 bits.
+* The data bus and address bus should be separate buses between the CPU and the FPGA.
+* The clock frequency of the EIM interface layout should support 66 MHz clock frequency.
+* There should be at least three separate digital signals connected between the FPGA and GPIOs on the CPU to be able to send interrupt/events from the FPGA to the CPU. Things like RSA operation completed to internal alarms. (Slow signals.)
+
+
+=== FPGA Debug Interface ===
+* The FPGA JTAG interface should be available on a header. The header shall be compatible with the [http://www.xilinx.com/support/documentation/data_sheets/ds593.pdf Xilinx Platform Cable USB II].
+
+
+=== FPGA Extras ===
+* 8 LEDs connected to output pins on the FPGA. For general debug uses.
+* 4 LEDs connected to output pins on the FPGA. For heartbeat and status signalling.
+* 100-mil header with VCC+GND+8 pins connected to pins on the FPGA for general input/output. Slow speed, 3v3 TTL. Some ESD protection would be considered good.
+
+
+=== FPGA Configuration and Configuration Memory ===
+* The FPGA should read it's bitstream from the FPGA config memory by itself (Master mode).
+* The FPGA is connected to the config memory with an SPI interface.
+
+* The ARM CPU should be able to download a bitstream into config memory by stealing the SPI interface.
+* The ability to steal the SPI interface is implemented using a transparent MUX controlled by the CPU. The MUX control and the SPI interface to the MUX from the CPU should be possible to remove by removing jumper for the signals mux_ctrl, MISO, MOSI, MCLK.
+
+* Suggestion for FPGA config memory is [http://www.micron.com/parts/nor-flash/serial-nor-flash/m25p128-vme6gb "M25P128 EEPROM from Micron"], with a jumper controlling the write-enable pin.
+* Suggested MUX is the Quad 2-channel Analog Switch: ON Semi. MC14551B [http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF]
+
+
+=== External RAM and Flash ===
+No external RAM or Flash memories for FPGA application functionality shall be present and is connected to the FPGA on the Alpha board.
+
+
+=== Master Key Memory ===
+* The Master Key Memory (MKM) is a serial SRAM memory.
+* The MKM is connected to the FPGA with a SPI interface.
+ The MKM is connected to the Tamper Sub System with the same SPI interface.
+* The FPGA can read and write to the memory.
+* The Tamper Sub System controller can read and writeto the memory. Optionally the MISO input wire to the Tamper Sub System can be tied low by setting using a jumper. This should cause the tamper controller to only read zeros from the memory and thus only be able to write to the memory. The Tamper Sub System Controller has strict priority over the CPU. Basically an external switch between the memory, the controller and CPU.
+* The MKM is powered by a separate power supply using a CR2032 cell battery. The VCC pin connected to the battery should be under control from the Tamper Sub System controller. A transistor or analog switch controlled by the Tamper Sub System controller.
+
+Suggested components for the MKM and the switch:
+* Memory: Microchip serial SRAM. 23A640, 8 kByte, 8-TSSOP or 8-SOIC
+[http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf][[BR]]
+
+* Quad 2-channel Analog Switch: ON Semi. MC14551B
+[http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF]
+
+
+=== Entropy Sources ===
+* The avalanche noise entropy source should be implemented according to [attachment:alpha_board_noise_source.pdf existing schematics].
+* The noise source should have a shielding can and suitable ground plane etc. to keep radiation of entropy bits as low as possible.
+* The "12-15v stable" VCC should be controllable by the FPGA (enable/disable controlled by output pin on FPGA) to increase life time of components.
+ Power requirements for this VCC is < 100 mA (needs measuring, but probably < 50 mA).
+
+
+= Processor Sub System =
+
+=== CPU ===
+The main CPU is a ST Microelectronics STM32F429BIT6 Cortex-M4 based MCU running at 180 MHz. The package used is the 208 pin LQFP.
+* [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/DM00031020.pdf Reference Manual] (pdf)
+* [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00077036.pdf Product Specification] (pdf)
+* [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00077036.pdf Data Sheet] (pdf)
+
+
+=== Host Interface ===
+* USB interface. USB 2.0 Full Speed compliant.
+* USB interface implemented using an external USB-UART interface chip connected to a high speed (3 Mbps capable) UART interface on the CPU.
+* Suggested USB-UART component:
+* http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf
+* LQPF48 packaging
+
+
+=== Authenticator, Management and Backup Interface ===
+* USB interface. USB 2.0 Full Speed compliant.
+* USB interface implemented using an external USB-UART interface chip connected to a high speed (3 Mbps capable) UART interface on the CPU.
+* Suggested USB-UART component:
+* http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf
+* LQPF48 packaging
+
+
+=== External Storage ===
+* SD Card connected as Micro SD card with 4 bit data interface (like the Novena.)
+* Support for at least 2 GByte.
+
+
+=== External RAM ===
+The STM32 CPU supports two separate SDRAM banks. We use both of them with as big SDRAM chips we can find for each bank. The chip used is 64 MByte for a total of 128 Mbyte RAM.
+* [http://www.issi.com/WW/pdf/42-45R-S-32160F.pdf "ISSI IS45S32160F 64 MByte SDRAM with 32 bit data interface"]
+
+
+=== Real Time Clock ===
+* Battery backed RTC with calendar/date information.
+ Connected to the CPU via serial, SPI or other interface.
+* Suggested chip: Microchip MCP79411 or MCP79412 connected to the CPU via I2C.
+ [http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411][[BR]]
+ [http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf][[BR]]
+ This chip requires an external 32 kHz crystal.
+* Note: these chips contain per chip unique IDs as well as small EEPROM memory that can be memory protected.
+
+
+=== Keystore ===
+* The keystore memory is a non volatile memory (NVRAM, EEPROM, Flash) with size of at least 8 MByte
+* The keystore memory is connected to the CPU via a separate SPI interface.
+
+
+=== CPU Debug port ===
+* CPU JTAG on header.
+
+
+=== CPU Misc ===
+* Four LEDs conneced to the GPIOs on the CPU to allow heartbeat as well as status and debug signalling.
+* We want 8 general I/Os with direction controlled by the CPU. The I/O:s should be present on a header. One purpose for these I/O:s is to connect:
+* Keypad and LCD display
+* Smartcart reader via I2C
+* Bitbanged serial port for debugging
+
+We may implement this keypad, smartcard reader and display using a simple MCU based board.
+
+
+=== CPU Interfaces Needed ===
+SPI Interfaces
+* FPGA Config memory
+* Key storage memory
+* Master Key memory
+
+FPGA Interface
+* EIM interface
+
+Asynch serial ports (UARTs)
+* Host interface (high speed)
+* Management interface (high speed)
+* Tamper Sub System
+
+Memory Interfaces
+* DDR3
+* External SD Flash memory
+
+GPIOs
+* 3 signals from FPGA to CPU for signalling
+* 1 signal from CPU to FPGA reset circuit to force reset
+* 1 signal from CPU to FPGA confgig mem mux for control
+* 3 signals from Tamper Sub System controller to CPU
+
+
+= Tamper Sub System =
+The Tamper Sub System on the Alpha Board is simplistic and does not do a lot of detection. But the sub system should be there to allow us to test and develop tamper detection mechanisms.
+
+=== Tamper Sub System Controller ===
+* A simple 8-bit MCU. Atmel AVR.
+* Suggested chip: ATTINY828R-AU. Has 28 GPIOs which is definitely more than we've used for this design.
+* The Tamper Detection Sub System Controlller may need a separate 32 kHz crystal for periodical wake up.
+ (The MCU should be able to wake up based on internal clock source.)
+* The JTAG interface for debug and firmware download should be accessible via a header.
+* The MCU should at least have four LEDs under GPIO control to allow heartbeat, status and debug signalling.
+
+
+=== CPU interface ===
+* A simple serial (UART) interface between the CPU and the controller. The serial interface can be removed by removing jumpers.
+* One or a couple separate signals for event signalling from the Tamper Detection Sub System to the CPU Sub System. Slow speed 3V3 LVTTL.
+
+
+=== Tamper Detection Mechanisms ===
+* A separate push button connected to the controller.
+* Possibly using the internal temperature detection in the MCU.
+* At least four digital input pins on a header for four different digital (HIGH) tamper detection mechanisms.
+* At least two digital output pins on a header for four different digital (HIGH) tamper alarms.
+
+
+=== Tamper Power Supply ===
+* Battery backed. CR2032 cell battery.
+
+
+= Board Form Factor and Power Supply =
+== Form factor ==
+Reasonable small to easily fit all functionality
+Holes to allow mounting the boards using board distances.
+
+== Power Supply ==
+Power Supply similar to the Power Supply on the Novena.
+7-19V nominal range. 2.5A typical. Max 3A at 12V.
+
+The board is powered from 18V (or 24V) DC from a standard external power supply.
+It should be possible to power the board with a external 110V AC at 60 Hz and 230V AC at 50 Hz.
+
+The on board power supply block should provide a number of voltage supplies needed by the board. We need at least 5V, 3.3V, 2.5V 1.8V, 1.375V.
+We also need a stable, low noise 12V voltage supply to power the Cryptech Avalanche noise source.
+
+The board designer should provide information about the power consumtion for the board. What is the current required at 12V?
diff --git a/tracwiki/AlphaBoardPictures.trac b/tracwiki/AlphaBoardPictures.trac new file mode 100644 index 0000000..83d5675 --- /dev/null +++ b/tracwiki/AlphaBoardPictures.trac @@ -0,0 +1,12 @@ +
+== High resolution pictures of the Alpha board ==
+
+Attached to this page are high resolution pictures.
+
+The current revision of the Alpha board is rev03.
+
+rev01 was the board known as the 'dev-bridge'.
+rev02 was functionally the same as the rev03, but in another form factor.
+
+[[Image(Alpha_rev03_top_med.jpg)]]
+[[Image(Alpha_rev03_bottom_med.jpg)]]
diff --git a/tracwiki/AlphaBoardReview.trac b/tracwiki/AlphaBoardReview.trac new file mode 100644 index 0000000..7736877 --- /dev/null +++ b/tracwiki/AlphaBoardReview.trac @@ -0,0 +1 @@ +== Alpha board Layout review
diff --git a/tracwiki/AlphaBoardStrategy.trac b/tracwiki/AlphaBoardStrategy.trac new file mode 100644 index 0000000..2ee4498 --- /dev/null +++ b/tracwiki/AlphaBoardStrategy.trac @@ -0,0 +1,55 @@ += The Cryptech Alpha Board =
+
+== Goal ==
+Develop a first, custom HSM board that can be used to support a first set of applications as well as being used for further development of new functionality as well as security mechanisms such as tamper detection and protection, key storage etc. Deadline is to produce palpable results before summer, 2015.
+
+* The use cases and requirements for the alpha board are specified on the [http://trac.cryptech.is/wiki/Dashboard Dashboard].
+* The basic blocks of the Alpha board is [wiki:Hardware "shown here"].
+* The [wiki:AlphaBoardComponents "BOM and component requirements"].
+* The detailed [http://trac.cryptech.is/browser/doc/design/Alpha_board_drawing.pdf "Alpha board functional drawing"].
+
+
+== Plan ==
+1. Choose FPGA and ARM (done)
+2. Develop BOM, requirements and functional diagram (done-ish).
+3. Develop complete [wiki:AlphaSchematics "schematics"] (almost done).
+4. Develop dev-board ouorselves to connect chosen ARM to FPGA on Novena, to do some early development and testing in parallell with step 5.
+5. Get professional designer to do many-layer PCB from schematics.
+6. Manufacture a couple of boards (~10).
+7. Bug fix hardware+software.
+8. Make beta design.
+9. Manufacture more boards (~50).
+
+
+== Way forward ==
+
+We currently use the Novena as a dev-board. It has a [http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&tab=Documentation_Tab&pspll=1&SelectedAsset=Documentation&ProdMetaId=PID/DC/i.MX6Q&fromPSP=true&assetLockedForNavigation=true&componentId=2&leftNavCode=1&pageSize=25&Documentation=Documentation/00610Ksd1nd%60%60Data%20Sheets&fpsp=1&linkline=Data%20Sheets "Freescale i.MX6 CPU (ARM Cortex A9)"], and a Xilinx Spartan-6 LX45 CSG324-packaged FPGA.[[BR]]
+
+We want to over-size rather than under-size the FPGA on the Alpha board. The biggest FPGA from Xilinx/Altera that does not require tools with a commercial license that we've found is the Xilinx Artix-7 XC7A200T FBG484.
+
+We've only considered ARM CPUs. Either about the size of Cortex M3 / M4 (or future M7) or Cortex A8 / A9.[[BR]]
+A design with an A8/A9 turned out to be unattractive from a complexity and price point of view, so we're going to use one of the biggest M4 we could find. STM32F429.
+
+
+We are currently using a Freescale proprietary interface called EIM between the ARM and the FPGA on the Novena. EIM is not available with microcontrollers from ST, so we will use a similar interface made for connecting the ARM to external memory (called FMC). This interface runs at speeds up to 90 MHz, which is more than we are going to be using with our current FPGA cores.
+
+
+
+== Risks at this point ==
+
+1. Taking too long deciding on what the Alpha board should contain.
+2. Ordering PCB design and manufacturing boards that just does not work for our purposes.
+3. Getting Alpha boards that require too much time to get working.
+
+
+== Conclusion ==
+
+Use a high-end Cortex-M4 ARM.[[BR]]
+There is a huge difference in complexity between M4 and A9, mainly because of the DDR3 memory used with A9. An M4 design will both be easier to design, cheaper to both design and build and will be fast enough for all our early use cases anyways.
+
+
+Do not use the exact same FPGA, as it is too small to fit everything we need.[[BR]]
+
+
+Develop full schematics in-house.[[BR]]
+It turned out to be hard, costly or both, to outsource this part. We will probably spend less time developing the schematics ourselves than we would spend explaining what to develop to a third party.
diff --git a/tracwiki/AlphaReviewLog.trac b/tracwiki/AlphaReviewLog.trac new file mode 100644 index 0000000..911f624 --- /dev/null +++ b/tracwiki/AlphaReviewLog.trac @@ -0,0 +1,249 @@ += Review feedback of the Alpha schematics =
+
+== Power subsystem ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||The LTS3060ITS8 is a 8-lead device but the symbol shows only 6 (there are 3 GND leads). || \
+||Kent || \
+||ft to correct mapping of pins between symbol and package || \
+||Done ||
+||The output capacitor C13 can have higher capacitance. The 2.2 uF is the lowest recommended value and since this is a X7R/25V type it may well fall below that. I recommend 4.7uF to add some margin. C7 may also be changed to 4.7uF. || \
+||Kent || \
+||Updated schematics || \
+||Done ||
+||LMZ13608 has 11 pins plus an exposed pad (must be connected to pin 5) but only 9 pins are shown in the schematic symbol. || \
+||Kent || \
+||Will change symbol to show both name and pin number(s) || \
+||Done ||
+||The output voltage for LMZ13608 is calculated as 0.795 V * (1 + R8/R9) which is 4.93 V. It is a bit low for a 5.0 V supply. || \
+||Kent || \
+||5 volts not used, just an intermediate voltage. No change required. || \
+||Done ||
+||I don't see any SH pin in the datasheet for the LMZ13608 device. Is it the one called NC? || \
+||Kent || \
+||ft check symbol, then ask Pavel to review || \
+||ft done, pavel ||
+||What form factor and main power supply should we use for the Alpha? || \
+||ft || \
+||Try to find drawing with dimensions for NUC computers, to see if we can use that form factor and power supplies || \
+||Pavel ||
+
+
+== Entropy source ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||Add optocoupler as per Jacob's suggestion on tech@ 2015-07-24? The suggestion is to add a fast optocoupler to really isolate AGND from GND. || \
+||Jacob W || \
+|| As this appears to require a bigger digitizer, which in turn might require another 3V3 regulator, we don't want to add that to this otherwise quite well tested part of the circuitry for the Alpha. || \
+||Done ||
+
+
+== STM32 ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||The JTAG port is not connected. For debug puposes, it could be good to have access to the JTAG port, at least at the prototype board. || \
+||Kent || \
+||We don't know of a reason to add the full JTAG, when we have SWD. At least not if we keep the LQFP package because then we don't think we need to be able to do boundary scan. || \
+||Done ||
+||The capacitors C22-C25 are connected between VCAP1/2 and VCCO_3V3. According to the datasheet as well as AN4488 they shall be connected to GND. It should be enough with one 2.2uF capacitor for each pin. || \
+||Kent || \
+||Yes, change to GND instead of 3V3. Our interpretation is that we actually should have 2x2.2 for both VCAP1 and VCAP2. We also prefer 2x2.2 over 1x4.7 so not changing that.|| \
+||Done ||
+
+
+== 2x512 Mbit SDRAM for the ARM ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||U6 has no speed grade specified. TSOP-II package is selected. The BGA package is much smaller and easier to handle in production. || \
+||Kent || \
+||We will investigate packages and speed || \
+||Pavel ||
+
+
+== Keystore memory, 128 Mbit ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||Hard to see which resistor is R17 and R18. What is R17 (the left one) intended for? || \
+||Kent || \
+||Fixed the resistors. CS should be connected to ARM, default is "not enabled" through pull-up. || \
+||Done ||
+
+
+== RTC ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||From where is 3V3_BATT supplied? Is it an external power source from connector JP3? Or the JP4 jumper? || \
+||Kent || \
+||Yes, external power source connected to JP4. || \
+||Done ||
+||Do we need a separate RTC chip at all? || \
+||Jacob W || \
+||Keeping it for the Alpha since it is already there. || \
+||Done ||
+
+
+== Micro SD card ==
+
+||=Comment =||=Who =||=Resolution =||=Status =||
+||Which connector to use? Haven't found a good one with Eagle symbol. Some different kinds available. || \
+||ft || \
+||Remove SD card. || \
+||Done ||
+||Novena seems to have card reset capability (power control from MCU). Do we want the same? || \
+||ft || \
+||Remove SD card. || \
+||Done ||
+||Novena has two SD slots, and list power at 200mA. Do we need a separate power regulator for the SD card, or can we use VCCO_3V3? || \
+||ft || \
+||Remove SD card. || \
+||Done ||
+
+== 2x USB UARTs for management and application access ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||Should we add an EEPROM for FTDI USB related settings or not? || \
+||ft || \
+||Not adding anything not strictly necessary to the schematics. || \
+||Done ||
+||LED6 is the same type as LED1 at page 4 but they have different values at their resistors (220/330 ohm). || \
+||Kent || \
+||Went with 330 for consistency. || \
+||Done ||
+||The recommended protection devices on D+ and D- are missing. || \
+||Kent || \
+||Pavel to look for reference || \
+||pavel ||
+||Hard to see what reference designators that belong to which component in some places. || \
+||Kent || \
+||Fredrik will improve clarity || \
+||Done ||
+
+
+== AVR Tiny Tamper Detect MCU ==
+Fredrik to verify if Kent had comments about AVR
+||=Comment =||=Who =||=Resolution =||=Status =||
+|| || \
+|| || \
+|| ||
+
+
+== Analog switch controlling access to the MKM ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||Suggest changing this chip to an 74AC244 like the one used for the FPGA config memory. || \
+||Pavel || \
+||Will change. || \
+||Done ||
+
+
+== FPGA configuration ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||The mode signals are fixed to SPI Master mode. If more flexibility is needed, see next comment, jumpers may be added.|| \
+||Kent || \
+||This is intentional. || \
+||Done ||
+||One-bit data us for the configuration memory makes the configuration rather slow. If higher speed is preferable the SPI memory supports 4-bit data. || \
+||Kent || \
+||Bitstream is around 65 MBit, takes 4-5 seconds to load using single bit (@ 15MHz). We think that should be good enough. || \
+||Done ||
+
+
+== FPGA I/O ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||A lot of the FPGA I/Os are unused. For debug purposes some of these can be made available by connecting them to a pin header. Unconnected BGA balls are very hard to use. || \
+||Kent || \
+||Added two more GPIOs from AVR to FPGA and two more from AVR to ARM. Remaining question is how many we should add from FPGA to ARM. || \
+||Pavel ||
+||A zero ohm resistor at the oscillator output can simplify debug. || \
+||Kent || \
+||Fredrik will add zero ohm resistor || \
+||Done ||
+||Joachim suggests, that we may want to have some high-speed extension interface for debugging and dumping large amounts of data. For example, we can implement GMII or RGMII using external GbE PHY and GPIO header(s). In that sense, at least one of the GPIO header pins should be connected to clock-capable (MRCC) FPGA pin. || \
+||Pavel || \
+||Pavel will finalize notes in schematics to enable this. || \
+||pavel ||
+
+
+== FPGA voltage regulators ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||U14 and U15 have 38 pins but only 11 are visible in the schematic symbol. No pin numbers are visible. The NC pins must not be connected which should be shown.|| \
+||Kent || \
+||Fredrik will update symbol to show pins. || \
+||Done ||
+||I am not familiar with the EN6347Q device so I would add ferrite cores on the outputs, for debug and measurement. Maybe that's what the zero ohm resistors are intended for? || \
+||Kent || \
+||Will change 0-ohm to ferrites. Pavel will look up part number, Fredrik will update schematics. || \
+||pavel, ft||
+
+
+== FPGA power regulators ==
+||=Comment =||=Who =||=Resolution =||=Status =||
+||The EN5364 device has 68 pins and 2 exposed pads but the symbol only shows 19 pins, without pin number.|| \
+||Kent || \
+||Fredrik will update symbol to show pins || \
+||Done ||
+
+
+
+=== Additional comments from Kent ===
+I have reviewed the schematic drawings for 'Cryptech Alpha board', rev 02
+(12/28/15), together with the block diagram, rev 0.010 (2015-05-27). I
+have spent 8 hours on this review.
+
+
+==== General ====
+
+The block diagram does not comply with the schematics:
+
+||Analog switch replaced by line driver (IC2) || \
+||Kent || \
+|| ||
+||There is no reset block to the Tamper Detect CPU (U10) in the schematics || \
+||Kent || \
+|| ||
+||I can't find any Reset_n signal to the FPGA (U13) nor any FPGA reset block (maybe it is supposed to indicate the FPGA configuration?). || \
+||Kent || \
+|| ||
+||Interfaces for Smart Card and display/control seems to be missing in the schematics JTAG port for the ARM (U4) is not present in the schematics || \
+||Kent || \
+|| ||
+||JTAG port for the Tamper Detect CPU (U10) is not present in the schematics || \
+||Kent || \
+|| ||
+||Master Key Memory (U12) type is different (23A640 vs 23K640) || \
+||Kent || \
+|| ||
+||Power supply voltages does not comply with the schematics || \
+||Kent || \
+|| ||
+||The battery near the RTC on the block diagram is not present in the schematics || \
+||Kent || \
+|| ||
+||Minor differences in component names (suggestion: remove details from block diagram) || \
+
+||The header information should be updated with design name/ID and author. || \
+||Kent || \
+|| ||
+||Some components in the schematic (U1, U2, U14, U15, Q3) doesn't show pin numbers which make it harder to review || \
+||Kent || \
+|| ||
+||The sheets seems to have different sizes (1-13 differs from 14-26) and origo is placed in different positions in different pages. Not important but looks a bit odd. || \
+||Kent || \
+|| ||
+||Eagle doesn't seem to have a symbol for unconnected pins. If nothing else, a comment would be good so it is obvious that the pin shall be unconnected and is not forgotten. || \
+||Kent || \
+|| ||
+||On prototype boards it can sometimes be beneficial to insert zero ohm resistances on certain nets, typical clock and reset signals, to simplify debug. Typical places can be voltage regulator outputs and signals that are buried in the PCB. || \
+||Kent || \
+|| ||
+||The selected package for the CPU (U4) is LQFP208. The size is 30x30 mm compared to the TFBGA216 package that is only 13x13 mm. Also, the pitch is 0.5 mm for the LQFP208 while the TFBGA216 package has a ball pitch of 0.8 mm. || \
+||Kent || \
+||Joachim and ft thinks LQFP package makes sense for the Alpha - gives 208 "test points" and physical size not that important ||
+||For debug purposes it is recommended to place test points for signals that are hard to reach, to simplify measurement. || \
+||Kent || \
+|| ||
+
+
+==== Not Reviewed ====
+
+A one day review doesn't allow a thorough design review. Some
+prioritizations are necessary. I have not reviewed:
+
+|| FPGA pinout. The FPGA vendor tool (Vivado) does some of the checks. It checks that clock signals are placed at clock pins, that selected I/O types are compatible with the bank structure. Vivado can also check that not to much I/O switching power per bank is used and can also calculate power consumption (with correct user input). ||
+||Power calculations. The FPGA power is heavily dependent on how it is used. This can be estimated with the Vivado tool. ||
+||Supply voltage quality. This requires simulations that are out of scope for this review. ||
+||Power sequencing. ||
+||Physical properties like PCB symbols, layout issues, thermal design and board area use. ||
+||Production test or optimization for production. ||
\ No newline at end of file diff --git a/tracwiki/AlphaSchematics.trac b/tracwiki/AlphaSchematics.trac new file mode 100644 index 0000000..940c5e2 --- /dev/null +++ b/tracwiki/AlphaSchematics.trac @@ -0,0 +1,9 @@ +The Alpha schematics are almost finished!
+
+PDF and Eagle files available for download here in the [[source:/hardware/eagle/alpha/rev02 | hardware]] repository.
+
+`https://wiki.cryptech.is/browser/hardware/eagle/alpha/rev02`
+
+The schematics are based on the dev-bridge board that we made in the summer of 2015, which is why it is called rev02.
+
+We are currently seeking review of the schematics to finalize them before starting layout. A log of various peoples review comments is kept [wiki:AlphaReviewLog here].
\ No newline at end of file diff --git a/tracwiki/AlphaSealedBags.trac b/tracwiki/AlphaSealedBags.trac new file mode 100644 index 0000000..247e26c --- /dev/null +++ b/tracwiki/AlphaSealedBags.trac @@ -0,0 +1,62 @@ +
+== Chain of custody ==
+
+At present, we can't make any statements at all about the integrity of the hardware before it reached us - assembled and ready.
+
+We test and program the Alphas using a dedicated computer, but not in a secure facility by any means.
+A concerned user is advised to reprogram the firmware with binaries built from source.
+
+To provide some assurance the devices have not been tampered with after they have been programmed we put them in sealed bags with individual serial numbers.
+
+As the model of bags might change over time, we will publish photos of the bags used here as well as PGP signed statements for what serial numbers can be expected.
+At this time, we do not keep records of which exact unit was sent to whom.
+
+
+
+This is a picture of the currently used bags:
+
+[[Image(Alpha_tamper_bag_2016-12-16.png, 640px)]]
+
+
+
+{{{
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+At 2016-12-16, I put Cryptech Alpha units into sealed bags with the
+following serial numbers:
+
+ 26 0 027 233 507
+ 26 0 027 233 508
+ 26 0 027 233 509
+ 26 0 027 233 510
+ 26 0 027 233 511
+ 26 0 027 233 512
+ 26 0 027 233 513
+ 26 0 027 233 514
+ 26 0 027 233 515
+ 26 0 027 233 516
+ 26 0 027 233 517
+ 26 0 027 233 518
+ 26 0 027 233 519
+ 26 0 027 233 520
+ 26 0 027 233 521
+ 26 0 027 233 522
+ 26 0 027 233 523
+ 26 0 027 233 524
+ 26 0 027 233 525
+ 26 0 027 233 526
+
+/Fredrik
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQEcBAEBCgAGBQJYU/MVAAoJEBmMGv1QUVLd+2gH/jLZ7aUGlZ+Iwj6b746Hh6u1
+2JAZ+2tk5tRooTwNb4A5P3ewRcbjA0jPJQQlpVqZcxdt0DDjS16AR0LEaH2rWL++
+sj/OtBm5rqAmVcf1NNvzpC8f8WWgRYhx4nNhWKnEcTBQXT9NbFQhQY0WH3ebupnn
+8PK0mX8PpfsjM/3vxtVVLmi+vBsxv0hBcdl+t4IPw/UbzozicF6jZpxRXxVujTE6
+WLGXaCnySS4T1zgtpewfgVMOMouGScUw5n2yHRZJpissGUVJtuPrOEmNFvDz7LRD
+i00Rc4i2emsKTgKrkMIKyQWSqFIQ1nBUQ5B5ES1Q50432cppbyEW2rJJZjAuxgM=
+=s2D5
+-----END PGP SIGNATURE-----
+}}}
diff --git a/tracwiki/AssuredTooChain.trac b/tracwiki/AssuredTooChain.trac new file mode 100644 index 0000000..e4cd7ab --- /dev/null +++ b/tracwiki/AssuredTooChain.trac @@ -0,0 +1,14 @@ += Issues of an Assured Tool-Chain =
+
+We do not have any assurance that our basic tools are not compromised.
+* Compilers
+* Operating Systems
+* Hardware Platforms
+* Verilog and Other Tools to Produce Chips
+
+At the base, is the compiler. The fear was first formally expressed in
+Ken Thompson's 1984 Turing Award Lecture
+[http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf Reflections on Trusting Trust].
+
+David A. Wheeler's PhD thesis, [http://www.dwheeler.com/trusting-trust/ Fully Countering Trusting Trust through Diverse Double-Compiling]
+outlines how we might deal with the compiler trust conundrum.
\ No newline at end of file diff --git a/tracwiki/BerlinWorkshop.trac b/tracwiki/BerlinWorkshop.trac new file mode 100644 index 0000000..e8463ed --- /dev/null +++ b/tracwiki/BerlinWorkshop.trac @@ -0,0 +1,59 @@ += CRYPTECH Workshop Agenda =
+=== 15-16 July 2016 ===
+
+Intercontinental Berlin
+Budapest Str. 2
+10787 Berlin, Germany
+
+Meeting Room: Köpenick III
+
+Cost of attendance: None
+
+Alpha Board cost: if you are an alpha tester and plan to take an alpha board home with you, we would like to recover cost for these boards from you. We are asking for 800USD. We plan to collect the money through [https://www.crowdsupply.com/cryptech/open-hardware-security-module crowdsupply].
+
+== Draft Agenda ==
+
+=== Friday 15 July ===
+|| 0830 || Coffee
+|| 0930 || Introductions, setup
+|| 1000 || Presentation of the cryptech alpha device
+|| || - cryptech overview (attachment:2016-07-15-berlin-main.pdf)
+|| || - overall hardware architecture (attachment:2016-07-15-berlin-hw.pdf)
+|| || - the FPGA (attachment:2016-07-15-berlin-fpga.pdf)
+|| || - HSM software architecture, CLI, and RPC mechanism (attachment:2016-07-15-berlin-sw.pdf)
+|| || - PKCS11, client-side software, how to configure the board (attachment:2016-07-15-berlin-fw.pdf)
+|| 1100 || Break
+|| 1130 || Hands-on testing
+|| || - get binary packages running on participants' own laptops ([[BinaryPackages]])
+|| || - [[OpenDNSSEC]] is a guide for how to initialize a rev03 board and use it to sign a zone using OpenDNNSSEC - use as a baseline for own testing and experimentation with PKCS11-based applications.
+|| 1230 || Buffet lunch
+|| 1330 || Hands-on testing continues
+|| 1500 || Coffee break
+|| 1530 || Hands-on testing continues
+|| 1700 || Finish day one
+
+=== Saturday 16 July ===
+|| 0900 || Hands-on testing continues
+|| 1030 || Coffee break
+|| 1100 || Workshop wrap-up
+|| || - outstanding questions
+|| || - feedback from the participants
+|| || - opportunity to articulate what participants will need that isn't readily available
+|| 1300 || Finish
+
+== What you need to bring ==
+During the workshop you will have access to the cryptech platform using
+a PKCS11 interface (reviewing PKCS11 might be a good way to prepare for
+the workshop). We will use OpenDNSSEC (using PKCS11) as a reference
+use case but you are encouraged to think about other applications that
+use PKCS11 you want to test. We will be there to help and will do our
+best to fix stuff that breaks along the way.
+
+Bring a laptop with 2 USB 2.0 ports free (or a USB hub) running either
+MacOS or Debian Linux. We will provide client PKCS11 software
+packages for Debian Jessie and Ubuntu Xenial, and Homebrew for MacOS. You
+will use one USB port for PKCS11 and one USB port for admin CLI access
+to the cryptech device.
+
+For admin access you will find useful some form of serial console application
+capable of handling 921600 bps line speed.
diff --git a/tracwiki/BinaryPackages.trac b/tracwiki/BinaryPackages.trac new file mode 100644 index 0000000..7920461 --- /dev/null +++ b/tracwiki/BinaryPackages.trac @@ -0,0 +1,126 @@ +[[PageOutline]]
+
+= Binary Packages for Cryptech Software and Firmware =
+
+The Cryptech Project maintains APT and Homebrew repositories
+containing packaged software for the Cryptech Alpha board for Debian
+and Ubuntu Linux and for Mac OS X. The binary packages also include
+pre-compiled images for the Alpha Board's Artix-7 FPGA, Cortex M4 ARM
+CPU, and AVR ATtiny828 MCU.
+
+== How to get APT packages for Debian Stretch, Debian Buster, Ubuntu Xenial, or Ubuntu Bionic ==
+
+* Fetch and validate the repository key. Presumably you're security
+ concious (otherwise, why are you installing this stuff?), so you may
+ want to pay attention to what `gpg --check-sig` says here.
+
+ {{{
+ $ id=37A8E93F5D7E7B9A
+ $ wget https://apt.cryptech.is/apt-gpg-key.gpg
+ $ gpg --recv-key $id
+ $ gpg --check-sig $id
+ }}}
+
+* Install the repository key. We used to use `apt-key(8)` for this,
+ these days the cool kids use the `/etc/apt/trusted.gpg.d/` directory:
+
+ {{{
+ $ sudo chown root:root apt-gpg-key.gpg
+ $ sudo mv apt-gpg-key.gpg /etc/apt/trusted.gpg.d/cryptech.gpg
+ }}}
+
+* Configure apt to use the repository. You need to add a couple of
+ entries to `/etc/apt/source.list.d/`; which entries you need to add
+ depends on which distribution you're running.
+ * For Debian Stretch, do:
+ {{{
+ $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.stretch.list
+ }}}
+ * For Debian Buster, do:
+ {{{
+ $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.buster.list
+ }}}
+ * For Ubuntu Xenial, do:
+ {{{
+ $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.xenial.list
+ }}}
+ * For Ubuntu Bionic, do:
+ {{{
+ $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.bionic.list
+ }}}
+
+
+* Update the package index.
+
+ {{{
+ $ sudo apt-get update
+ }}}
+
+* Install the `cryptech-alpha` package.
+
+ {{{
+ $ sudo apt-get install cryptech-alpha
+ }}}
+
+== Updating APT packages ==
+
+Once you've performed the steps above you should be able to upgrade to newer
+version of the code using the normal APT upgrade process:
+
+{{{
+$ sudo apt-get update
+$ sudo apt-get upgrade
+}}}
+
+== How to get Homebrew packages for Mac OS X ==
+
+* Fetch and validate the repository key. Presumably you're security
+ concious (otherwise, why are you installing this stuff?), so you may
+ want to pay attention to what `gpg --check-sig` says here.
+
+ {{{
+ $ id=37A8E93F5D7E7B9A
+ $ gpg --recv-key $id
+ $ gpg --check-sig $id
+ }}}
+
+* Configure Homebrew to use the repository.
+
+ {{{
+ $ brew tap cryptech/sw https://brew.cryptech.is/tap
+ }}}
+
+* Update the package index.
+
+ {{{
+ $ brew update
+ }}}
+
+* Check the commit signature on the cryptech-alpha package formula.
+ This is optional (Homebrew doesn't care whether you do this), but if
+ you want to know whether the formula was signed by the Cryptech
+ project, this is how to check.
+
+ {{{
+ $ brew log --max-count=1 --show-signature cryptech-alpha
+ }}}
+
+* Install the `cryptech-alpha` package. At the moment, this is only
+ available as a Homebrew source package due to licensing issues in
+ the MacOS Xcode SDK, so the installation will probably take several
+ minutes, as some of the libraries are a bit slow to compile (sorry...).
+
+ {{{
+ $ brew install cryptech-alpha
+ }}}
+
+== Updating Homebrew packages ==
+
+Once you've performed the steps above you should be able to upgrade to newer
+version of the code using the normal Homebrew upgrade process:
+
+{{{
+$ brew update
+$ brew upgrade
+$ brew cleanup
+}}}
diff --git a/tracwiki/BuildingFromSource.trac b/tracwiki/BuildingFromSource.trac new file mode 100644 index 0000000..2dc03ab --- /dev/null +++ b/tracwiki/BuildingFromSource.trac @@ -0,0 +1,223 @@ +[[PageOutline]]
+
+= Building Cryptech !Software/Firmware/Bitstream From Source =
+
+Everything you need to build our software, firmware, and FPGA
+bitstreams from source yourself is publicly available, but the process
+is a bit complicated. Overall, there are two methods, one of which
+our developers use while writing this stuff, the other of which we use
+for the automated reproducible builds which go into our binary
+distributions. Both methods eventually boil down to "get the source
+code then run make", but the details differ.
+
+== What developers do ==
+
+We check out copies of all the several dozen separate repositories and
+carefully arrange them in a tree structure which matches the official
+naming scheme. Yes, really. It's tedious, but we have
+[export:/user/sra/build-tools/https-sync-repos.py a script to automate this].
+Be warned that this script is a kludge which relies on parsing
+XML from this Wiki; this is nasty, but reasonably stable, because the
+XML itself is generated by another script.
+
+Once you have this tree, you can hop around within it, building
+whichever bits are of interest to you. So if you want to rebuild just
+the HSM firmware (the C code that runs on the ARM), you would go to
+`sw/stm32` and run `make` there.
+
+== What we do for reproducible builds ==
+
+Reproducible builds use the same tree structure (as they must for the
+various Makefiles to work properly), but the entire tree is embedded
+in a git "superrepository" which also contains the release engineering
+goo necessary to make the whole thing work. Do `git help submodule`
+for an introduction to git's submodule mechanism.
+
+With this model, one just checks out a copy of
+[source:/releng/alpha the superrepository],
+runs `make` in its top directory, and eventually
+the complete package pops out the other side.
+
+{{{
+git clone https://git.cryptech.is/releng/alpha.git
+cd alpha
+make
+}}}
+
+That's the good news. The bad news is that this process has higher
+demands on its build environment: it expects to find the a complete
+tool set, including the !XiLinx synthesis tools, the several different
+cross compilers for the firmware, and the `pbuilder` system for
+building clean room packages for Ubuntu and Debian.
+
+As a compromise, one can use this source tree as if it were the
+development source tree described above: just use the supermodule to
+pull down everything else, but then ignore the supermodule and build
+individual pieces as if you'd checked out all the repositories by
+hand.
+
+== Skip all this git mess and just download a tarball ==
+
+There's another alternative, which is simpler than any of the above:
+just download the source tarball. Since the only build environments
+we support at the moment are Debian Jessie and Ubuntu Xenial, which
+also happen to be environments for which we build binary packages, you
+can just use APT:
+
+{{{
+apt-get source cryptech-alpha
+}}}
+
+Which will give you the same tree structure, but without all the git fun.
+
+== Build environment ==
+
+Our software and firmware developers use the Debian and Ubuntu Linux
+distributions. Our current build box for binary packages runs Debian
+Jessie.
+
+Our Verilog developers use various environments and have been known to
+use graphical tools, but synthesis of the bitstreams that go in our
+binary packages is done via the !XiLinx command line tools on the same
+Debian Jessie machine as the software and firmware builds.
+
+Which tools you need will of course depend on exactly what you're
+trying to do.
+
+Most of the tools work on either 32-bit or 64-bit machines, but if you
+intend to run the full binary package build script, you'll need a
+64-bit machine (or VM) because the tools won't build 64-bit binaries
+on a 32-bit machine.
+
+Basic tool set (not all required for every purpose, but they're all
+supported Debian packages so it's usually easier just to install them
+all and not worry about it):
+
+{{{
+ apt-get install git pbuilder ubuntu-dev-tools rsync sudo
+ apt-get install python-yaml python-serial python-crypto python-ecdsa
+ apt-get install gcc-arm-none-eabi gdb-arm-none-eabi
+ apt-get install gcc-avr binutils-avr avr-libc
+ apt-get -t jessie-backports install debootstrap distro-info-data
+ apt-get install reprepro ubuntu-archive-keyring
+}}}
+
+This is not an exhaustive list, because some of the other packages we
+use are pulled in by these as dependencies.
+
+You will also need a copy of the !XiLinx tools, which is tedious enough
+that it's described in a separate section, below.
+
+Once you have all the tools installed, you'll need a copy of the
+source tree, as explained in the preceeding sections.
+
+pbuilder requires a bit of setup (you can skip this if you're not
+trying to do the full binary package build):
+
+{{{
+for code in jessie xenial; do for arch in i386 amd64; do pbuilder-dist $code $arch create; done; done
+ln -s jessie_result ~/pbuilder/jessie-amd64_result
+ln -s xenial_result ~/pbuilder/xenial-amd64_result
+}}}
+
+== Installing the !XiLinx tools ==
+
+!XiLinx tools setup is a bit involved. You can skip this section if
+you don't intend to build FPGA bitstreams.
+
+We use the command line versions of the !XiLinx tools, but installing
+them requires a graphical environment, because the !XiLinx installer
+and license manager are GUI tools. If you're running this on a server
+and don't already have a graphical environment installed, you can get
+away with something fairly minimal. For example, if you have a VNC
+viewer such as "Chicken of the VNC" on your laptop, you can get away
+with a fairly minimal X11 toolset:
+
+{{{
+apt-get install tightvncserver xterm icewm
+}}}
+
+If you're already running X11 on your laptop and are comfortable with
+extruding that to the build machine, eg, via `ssh -Y`, you can just
+use that (not recommended for long-haul use, eg, if the laptop is in
+Boston and the server is in Reykjavik).
+
+You'll need to start by using a web browser to download the
+[http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html Xilinx ISE Design Suite].
+
+!XiLinx only supports specific versions of Red Hat and Suse Linux, but
+their tools do run on Debian and Ubuntu. A few caveats:
+
+* Debian and Ubuntu symlink `/bin/sh` to `/bin/dash`, which can't handle
+ some of the syntax used in !XiLinx's shell scripts, so you'll need to
+ change that symlink to point to `/bin/bash`.
+
+* Although the !XiLinx software can be installed as user or root, by
+ default it wants to install into /opt/Xilinx, so you need to install
+ as root if you want to do that.
+
+* The !XiLinx tools are disk hogs, so if you're building a VM for this,
+ you'll probably want to give it at least 30-40 GB of disk space.
+
+Step-by-step installation:
+
+1. Unpack `Xilinx_ISE_DS_Lin_14.7_1015_1.tar` (or whatever version you have).
+2. In an X11 environment, cd to `Xilinx_ISE_DS_Lin_14.7_1015_1`, and run `sudo ./xsetup`
+3. Click through two screens of license agreements.
+4. Select `ISE WebPACK`.
+5. Unselect (or leave unselected) Install Cable Drivers.
+6. Go!
+
+Well, not quite. You'll need to convince the ISE tools that you have
+a valid license to use the ISE tools. Go to
+http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm,
+click the `Licensing Solutions` link. On the page to which that takes
+you, expand the section `Obtain a license for Free or Evaluation
+product`. To download the ISE Webpack, you should have created an
+account, so now you can go to the Licensing Site and use that account
+to create a Certificate Based License.
+
+You do not need to go through the HostID dance, just say Do It. You
+will then receive a certificate in email (not an X.509 certificate)
+which you will be able to use. Then start the ISE Webpack by issuing
+the command `ise`. Go to the Help menu and Manage Licenses. Use the
+resulting new License Manager window to install the `.lic` file. This
+process is complex and flakey.
+
+Here's
+[http://www.armadeus.com/wiki/index.php?title=ISE_WebPack_installation_on_Linux another description of installing ISE on Ubuntu].
+
+The `ise` binary referred to above is in `/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise`
+(or in `.../lin/ise`, but the pbuilder setup requires a 64-bit build machine).
+
+When running this remotely under tightvncserver, setup looks something like this:
+
+{{{
+vncserver :0 -geometry 1280x768 -depth 16 -localhost
+export DISPLAY=:0 XAUTHORITY=~/.Xauthority
+icewm&
+}}}
+
+Then, either in the same shell as the above or in an xterm in the new display
+
+{{{
+cd Xilinx_ISE_DS_Lin_14.7_1015_1
+sudo ./xsetup
+
+cd
+/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise
+}}}
+
+It turns out you don't really need to run the whole `ise` tool to
+get to the license manager, you can just run
+
+{{{
+/opt/Xilinx/14.7/ISE_DS/common/bin/lin64/xlcm -manage
+}}}
+
+But you do have to source the appropriate settings file first, none of
+the !XiLinx tools work properly without that:
+
+{{{
+. /opt/Xilinx/14.7/ISE_DS/settings64.sh
+}}}
diff --git a/tracwiki/ConfigureFPGA.trac b/tracwiki/ConfigureFPGA.trac new file mode 100644 index 0000000..6249faa --- /dev/null +++ b/tracwiki/ConfigureFPGA.trac @@ -0,0 +1 @@ +''Page Under Development''
\ No newline at end of file diff --git a/tracwiki/CoretestHashesC5G.trac b/tracwiki/CoretestHashesC5G.trac new file mode 100644 index 0000000..0fb9e8d --- /dev/null +++ b/tracwiki/CoretestHashesC5G.trac @@ -0,0 +1,471 @@ += How to start using coretest_hashes on the TerasIC C5G Board =
+This is a writeup on how to setup, build and testrun the coretest_hashes
+Cryptech subsystem on a TerasiC C5G Cyclone V GX Starter Kit FPGA
+development board [1].
+
+
+== Introduction ==
+=== Test Setup ===
+The test setup consists of:
+- A development computer running the Altera Quartus II FPGA development software. This computer will be building the FPGA comfiguration image (a sof-file) and then use the Altera USB-blaster to load the image into the FPGA on the TerasIC board. This computer shall therefore be connected to the USB-blaster port on the TerasIC board.
+
+- A host computer that runs the hash_tester application that communicates with the FPGA design downloaded into the FPGA and perform tests on the hash functions. The host computer is connected to the USB-serial port on the TerasIC board.
+
+- The TerasIC Cyclone 5 GX Starter Kit (C5G) board.
+
+[[Image(http://www.terasic.com.tw/attachment/archive/830/image/image_74_thumb.jpg)]]
+
+''The TerasIC Cyclone 5 GX Starter Kit board.''
+
+The USB ports are the shown in the upper left corner. These are USB type B ports. The port to the left is the USB-blaster port. The port to the right is the USB-serial port. In the bottom right corner there is a row of buttons and just above them 8 LEDs. These will also be used by the coretest_hashes subsystem. There is a HDMI port on the C5G board but it will not be used. All communication is done in CLI on the host computer.
+
+'''NOTE: You don't actually need two separate computers. You can use one computer with one or two USB ports. If you only have one USB port you will need to switch from connecting to the USB-Blaster port to the USB-serial port on the C5G board once the coretest_hashes FPGA configuration has been downloaded to the board.'''
+
+My personal setup is a laptop with two USB ports which allows me to have connections to both USB ports on the C5G boards simultaneously.
+
+
+=== Coretest_hashes ===
+The coretest_hashes is a subsystem that is a FPGA design that contains Cryptech application cores as well as support cores used to run tests of the
+SHA-1 and SHA-256 hash functions from a host computer via a serial
+interface connected to a FPGA device. The subsystem consists of:
+
+- [browser:/core/sha1 "sha1"]: A HW implementation of the SHA-1 hash function.
+
+- [browser:/core/sha256 "sha56"]: A HW implementation of the SHA-256 hash function.
+
+- [browser:/core/coretest "coretest"]: A command parser that accepts read/write commands from a
+ host, executes the commands and sends the response.
+
+- [browser:/core/usrt "uart"]: A simple serial interface that connects coretest to the host.
+
+- [browser:/core/coretest_hashes "coretest_hashes"]: A top level wrapper that connects all the cores as
+ well as connecting the rxd and txd ports on the uart to external pins as well as clk and reset. This core repo also contains the Python command line program hash_tester we will be using to talk to coretester and perform tests of the sha1 and sha256 cores.
+
+[[Image(coretest_hashes.png)]]
+
+''The coretest_hashes subsystem with sha1 and sha256 cores. The system is connected to a host computer via a serial interface.''
+
+== SW and system requirements ==
+You need to download and install the Altera Quartus II Web Edition
+software [2]. There are versions of Quartus II Web Edition for Windows and Linux. I'm using the Windows version, but Linux '''should''' work too.
+
+You will probably also install drivers for the Altera USB-blaster in order to program the FPGA on the development board. For instructions on how to install the driver, please see the Altera page for USB-blaster [7].
+
+For communication with the coretest_hashes in the FPGA we will be using the USB-serial device on the development board. The USB-serial chip on the
+board is a FTDI FT232R [3]. If your host OS does not have support for this device you will need to install drivers. For Windows the correct file to download seems to be a VCP file [7].
+
+Finally, in order to talk to coretest_hashes from the host there is application SW. This SW is written in Python and uses the Pyserial[5] library. If you don't have Python and/or Pyserial installed you will need to install that too.
+
+'''NOTE: Python and Pyserial does not have to be installed in the same OS as Quartus II but can be run from a separate system and OS.'''
+
+(I'm using Quartus II 13.1 64-bit version running in Win8.1 in a VM in Parallels Desktop in OX 10.9.2 during this writeup. And I use Python and Pyserial in an iTerm in OSX for the serial communication.)
+
+With all this SW installed you should be ready to proceed to create the
+coretest_hashes project.
+
+'''I also recommend that you download the TerasIC C5G User Manual [4]. It is a really good document that describes the boards with all functions, pins etc.'''
+
+
+== Downloading the cores ==
+Create a project directory. I'm using test_coretest_hashes. In it I add
+a core directory and a toolruns directory:
+
+{{{
+#> ls test_coretest_hashes
+cores/ toolruns/
+}}}
+
+The cores we need to build the subsystem must be downloaded from the
+Cryptech server. The cores we need are:
+
+- sha1
+- sha256
+- uart
+- coretest
+- coretest_hashes
+
+{{{
+#> cd cores
+#> ssh git@git.cryptech.is
+hello <FOO>, this is git@cryptech running gitolite3 v3.5.2-0-g926bd5f on git 1.9.0
+
+ R C [a-zA-Z0-9].*
+ R W core/coretest
+ R W core/coretest_hashes
+ R W core/coretest_test_core
+ R W core/sha1
+ R W core/sha256
+ R W core/test_core
+ R W core/uart
+ R W doc/presentations
+ R gitolite-admin
+Connection to cryptech.is closed.
+}}}
+
+We can see the relevant cores and check them out one by one:
+{{{
+#> git clone git@git.cryptech.is:core/sha1.git
+#> git clone git@git.cryptech.is:core/sha256.git
+#> git clone git@git.cryptech.is:core/uart.git
+#> git clone git@git.cryptech.is:core/coretest.git
+#> git clone git@git.cryptech.is:core/coretest_hashes.git
+}}}
+
+We should now have a cores directory like this:
+{{{
+#> ls
+coretest/ coretest_hashes/ sha1/ sha256/ uart/
+}}}
+
+In each of these cores there are RTL and testbenches needed to simulate
+and build each of them. For example the sha1 core contains:
+{{{
+#> cd sha1
+#> ls
+LICENSE.txt README.md src/ toolruns/
+}}}
+
+The sha1 RTL source is in src/rtl. Lets take a look:
+{{{
+#> cd src/rtl
+#> ls
+sha1.v sha1_core.v sha1_w_mem.v
+}}}
+
+These files are:
+- sha1.v: A top level wrapper that provides an interface to the core. In
+ this case a 32-bit memory like interface.
+
+- sha1_core.v: The actual SHA-1 hash function core.
+
+- sha1_w_mem.v: The W memory including sliding window functionality used
+ by the core.
+
+The other cores follows a similar pattern with a top level wrapper named
+<core_name>.v, the main functionality in <core_name>_core.v and then one
+or more submodules.
+
+
+== Creating the project in Quartus ==
+- Start Quartus and select file/new... and select New Quartus II
+ Project.
+
+- Select destination directory to be toolruns/ in your project
+ directory.
+
+- Set 'coretest_hashes' as name of the project
+
+- Set 'coretest_hashes' as nem of the top level design entity. (Should be
+ done automatically when entering the name of the project.)
+
+- Press next.
+
+- You should now be on the 'Add Files' page. Press '...'.
+
+- Navigate to test_coretest_hashes/cores/coretest/src/rtl.
+
+- Select coretest and press 'Open'. (Note: Quartus seems to sometimes omit the .v suffix
+ for the files depending on Windows/OS version.)
+
+- Back on the 'Add Files' page. Press Add to actually add coretest to
+ the project.
+
+- Press '...' again and navigate to the rtl directory in
+ coretest_hashes. Add it like you did with coretest.
+
+- Navigate to test_coretest_hashes/cores/sha1/src/rtl and add the files sha1, sha1_core,
+ sha1_w_mem. This time you don't need to press 'Add' on the 'Add
+ Files'. It is done automatically when adding more than one file at a
+ time.
+
+- Navigate to test_coretest_hashes/cores/sha256/src/rtl and add the files sha256, sha256_core,
+ sha256_k_constants, sha256_w_mem. Do '''NOT''' add the file wb_sha256. This file contains an alternative top level wrapper to the one in sha256.v that instead provides a [http://opencores.org/opencores,wishbone "WISHBONE"] interface. This interface is not used in the coretest_hashes design.
+
+- Finally navigate to test_coretest_hashes/cores/uart/src/rtl and add uart, uart_core.
+
+Back on the 'Add Files page you should now see a list of source files:
+{{{
+../cores/uart/src/rtl/uart_core.v
+../cores/uart/src/rtl/uart.v
+../cores/sha256/src/rtl/sha256_w_mem.v
+../cores/sha256/src/rtl/sha256_k_constants.v
+../cores/sha256/src/rtl/sha256_core.v
+../cores/sha256/src/rtl/sha256.v
+../cores/sha1/src/rtl/sha1_w_mem.v
+../cores/sha1/src/rtl/sha1_core.v
+../cores/sha1/src/rtl/sha1.v
+../cores/coretest_hashes/src/rtl/coretest_hashes.v
+../cores/coretest/src/rtl/coretest.v
+}}}
+
+Press 'Next' to get to the 'Family & Device Settings' page.
+
+- In 'Device Family', 'Family' list select 'Cyclone V (E/GX/GT/SX/SE/ST)'.
+
+- In 'Device Family', 'Devices' list select 'Cyclone V GX Extended Features'
+
+- In the 'Available Devices' list select: 5CGXFC5C6F27C7.
+
+Press 'Finish'.
+
+
+== Setting up and building the FPGA design ==
+You should now be in the main Quartus II window. In the project
+navigator you can see all files, open the source files etc.
+
+You could now just press 'Start Compilation' button in the menue row
+(the purple play/triangle button.) This will build the complete
+subsystem for the type of device selected. But the generated FPGA configuration image will not map to the correct pins on the C5G board. But this build should go through without errors or warnings related to problems in the source files. It is therefore a good test to see that all files has been included.
+
+The result from this generic build should be a FPGA configuration that
+uses 3666 registers, 2846 ALMs, 12 pins and can run at 88.3 MHz in worst
+case temperature and timing.
+
+You now need to define the correct pins and define the clock to allow
+Quartus to create a FPGA configuration for our board.
+
+All pins needed are described in the C5G manual. To save time there is
+also a pin list available in the coretest_hashes directory.
+
+- Navigate to test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g
+
+- The file coretest_hashes.qsf contains assignments for a project like
+ the one we are setting up. It contains the pin assignments. The
+ follwing list is a slightly cleaned up version of the pin assignments:
+
+{{{
+set_location_assignment PIN_R20 -to clk
+set_location_assignment PIN_P11 -to reset_n
+set_location_assignment PIN_M9 -to rxd
+set_location_assignment PIN_L9 -to txd
+set_location_assignment PIN_L7 -to debug[0]
+set_location_assignment PIN_K6 -to debug[1]
+set_location_assignment PIN_D8 -to debug[2]
+set_location_assignment PIN_E9 -to debug[3]
+set_location_assignment PIN_A5 -to debug[4]
+set_location_assignment PIN_B6 -to debug[5]
+set_location_assignment PIN_H8 -to debug[6]
+set_location_assignment PIN_H9 -to debug[7]
+set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to clk
+set_instance_assignment -name IO_STANDARD "1.2 V" -to reset_n
+set_instance_assignment -name IO_STANDARD "2.5 V" -to txd
+set_instance_assignment -name IO_STANDARD "2.5 V" -to rxd
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[0]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[1]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[2]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[3]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[4]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[5]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[6]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[7]
+}}}
+
+As you can see, for each pin we want to use we need to define the actual
+pin in the FPGA (PIN_R20 for example) and the I/O standard the pin
+should use/support.
+
+In this design I've mapped the reset signal to the button 'KEY0' on the
+board which you can find in the lower right corner. There is also a
+debug port that in the coretest_hashes design is connected to the debug
+port in the uart. This allows us to see byte values received by the
+uart. This debug port is connected to pins that control the green LEDs
+just above the row of buttons that includes 'KEY0'.
+
+In order to enter the pin assignments select 'Assignments' in the
+Quartus top level menue bar. The select 'Assignment Editor'. Then either
+manually enter each of the assignments above. This will require two rows
+for each pin. For example for the clock ('clk') we would enter:
+
+- Row 1: 'To': clk, 'Assignment name': Location, 'Value': PIN_R20
+- Row 2: 'To': clk, 'Assignment name': I/O Standard, 'Value': 3.3-V LVTTL
+
+An easier way is to open up the file coretest_hashes.qsf in test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g and add the pin assignment from that file to your qsf file in test_coretest_hashes/toolruns. If you then open up the Assignments Editor the same definitions should be shown.
+
+We now need to define the clock. Under 'Assignments' in the top level
+menue select 'TimeQuest Timing Analyzer Wizard'. Press 'Next' to get
+from the 'Intro' page.
+
+Under 'Specify base clock settings' enter 'clk' as 'Clock Name' and
+'Input Pin'. Enter '20' in 'Period' and note that 'ns' is selected as
+time scale. In the 'Equivalent SDC Commands' you should see:
+
+{{{
+ create_clock -name "clk" -period 20.000ns [get_ports {clk}]
+}}}
+
+Now press 'Next' four times to get to the final page and then press
+'Finish' to complete the clock setup. If we now look in the
+test_coretest_hashes/toolruns directory there should be a file called
+coretest_hashes.sdc that contains the SDC command above.
+
+Now we are ready to build the real FPGA configuration. Press the purple
+'Start Compilation' button again. After build we should now have an FPGA
+configuration that requires 2852 ALMs, 3666 registers, 12 pins and meets
+timing. The max clock frequency for the design should be about 72 MHz.
+
+Time to load the design onto the board.
+
+
+== Configuring the FPGA on the C5G board ==
+If you haven't turned on the C5G board and connected the board to the
+computer Quartus is installed on, do so now. You should see the
+7-segment displays and LEDs start flashing in a simple sequence. This
+shows that the default configuration in the FPGA has been loaded and the
+board works.
+
+In Quartus now locate the 'Programmer' menue button (it looks like a
+chip with waves). Alternatively Select 'Tools' in the top level Menue
+and then 'Programmer'.
+
+In the Programmer window if everything is working magically we should
+see a list view with toolruns/output_files/coretest_hashes.sof
+selected. And below this list a graphic that shows a 'TDI' arrow
+pointing to an Altera 5CGXFC5C6F27C7 device with a 'TDO' going out from
+the device.
+
+If the graphic is not showing (probably), you need to press 'Hardware
+Setup'. In the Window you should see 'USB-blaster'. If not you need to
+fix the drivers for the USB-blaster in your OS. If the USB-blaster is
+present make sure it is selected and then press 'Close'.
+
+If the file is not showing, in the main Programmer window, select 'Add
+File' and navigate and to toolruns/output_files in the project
+directory. Select 'coretest_hashes.sof' and press 'Open'.
+
+In the main Programmer window now press 'Start' to start
+programming. When this has been completed (See 'Progress' in the upper
+right hand corner in the Programmer board) the LEDs etc should have
+stopped blinking. We should now have coretest_hashes alive on the
+development board. Time for host communication and testing!
+
+
+== Talking to coretest_hashes and test of SHA-1 and SHA-256 ==
+There is a (currently rather ugly) test program for
+coretest_hashes. Navigate to test_coretest_hashes/cores/coretest_hashes/src/sw
+
+{{{
+#> ls
+hash_tester.py
+}}}
+
+This is a Python2.x program that uses Pyserial [5] to open up a serial
+port and talk to coretest via the uart. The command and response format
+used is a very simple byte oriented format. For more info, see the
+README.md in [browser:/core/coretest "the top of coretest"].
+
+The program hash_tester.py needs to know which serial interface to
+use. This is defined in the main() function (yes, VERY ugly). You will
+need to edit the program source to point to the serial interface
+connected to the USB-serial chip on the C5G board. For me that device
+is:
+
+{{{
+ ser.port='/dev/cu.usbserial-A801SA6T'
+}}}
+
+If everthing is working properly you should now just have to do:
+{{{
+ python hash_tester.py
+}}}
+
+If the communication has been set up properly you should now see:
+{{{
+ TC1-1: Reading name, type and version words from SHA-1 core.
+ READ_OK. address 0x1000 = 0x73686131.
+ READ_OK. address 0x1001 = 0x20202020.
+ READ_OK. address 0x1002 = 0x302e3530.
+ ...
+}}}
+
+That is the first test case that reads from specific registers in the
+SHA-1 core. If we look in sha1/src/rtl/sha1.v there are some defines:
+{{{
+ parameter CORE_NAME0 = 32'h73686131; // "sha1"
+ parameter CORE_NAME1 = 32'h20202020; // " "
+ parameter CORE_VERSION = 32'h302e3530; // "0.50"
+}}}
+
+As we can see those hex values matches what is being read from the FPGA
+and is the name and version strings in the core.
+
+Moving on, hash_tester.py also performs single block message hash tests
+of both the SHA-1 and SHA-256 core. The message is "abc" padded to the
+correct block size for SHA-1 and SHA-256. These tests are defined by
+NIST including the expected result in [6]. The block is written as a
+sequence of 32-bit words to addresses mapped to the block registers in
+the sha1 core.
+
+Finally we set the init_flag in the control register in
+sha1 to one which should make the sha1 core initialize and then process
+the first (of possible several) message block. This takes in total 82
+cycles for the core. This means that by the time the host gets the
+'WRITE_OK. address 0x1008.' message, the core is done since many cycles
+ago. We therefore check status and try to extract the digest.
+
+Looking at the output from hash_tester.py we see:
+{{{
+ TC1-3: Reading SHA-1 status and digest.
+ READ_OK. address 0x1009 = 0x00000003.
+ READ_OK. address 0x1020 = 0xa9993e36.
+ READ_OK. address 0x1021 = 0x4706816a.
+ READ_OK. address 0x1022 = 0xba3e2571.
+ READ_OK. address 0x1023 = 0x7850c26c.
+ READ_OK. address 0x1024 = 0x9cd0d89d.
+}}}
+
+Address 0x1009 corresponds to address 0x09 in the SHA-1 core. This
+address contains the status of the core. 0x03 means that the data in the
+digest is valid and that the core is ready to accept now commnands.
+
+The digest generated by the sha1 core is in MSB format which means that
+the digest generated is:
+{{{
+ 0xa9993e36 0x4706816a 0xba3e2571 0x7850c26c 0x9cd0d89d
+}}}
+
+If we compare that to the expected result in [6] we can see that this is
+correct. Similarly, for SHA-256 we get:
+{{{
+ TC2-3: Reading SHA-256 status and digest.
+ READ_OK. address 0x2009 = 0x00000003.
+ READ_OK. address 0x2020 = 0xba7816bf.
+ READ_OK. address 0x2021 = 0x8f01cfea.
+ READ_OK. address 0x2022 = 0x414140de.
+ READ_OK. address 0x2023 = 0x5dae2223.
+ READ_OK. address 0x2024 = 0xb00361a3.
+ READ_OK. address 0x2025 = 0x96177a9c.
+ READ_OK. address 0x2026 = 0xb410ff61.
+ READ_OK. address 0x2027 = 0xf20015ad.
+}}}
+
+The digest generated is thus:
+{{{
+ 0xba7816bf 0x8f01cfea 0x414140de 0x5dae2223
+ 0xb00361a3 0x96177a9c 0xb410ff61 0xf20015ad
+}}}
+
+Which again matches what is specified in [6]
+
+
+== Summary ==
+We have now set up a complete development and verification environment
+for Cryptech. We have setup and built the coretest_hashes subsystem for
+the TerasIC C5G board. Finally we have connected to coretest_hashes from
+SW in the host and verified that we can write to and receive response
+needed to perform SHA-1 and SHA-256 hash operations and get correct
+digest back.
+
+If you have not been able to complete this, please contact me (Joachim Strömbergson).
+
+Happy Hashing!
+
+
+== References ==
+- [1]: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=830
+- [2]: http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html
+- [3]: http://www.ftdichip.com/Products/ICs/FT232R.htm
+- [4]: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=830&PartNo=4
+- [5]: http://pyserial.sourceforge.net/
+- [6]: http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA_All.pdf
+- [7]: http://www.ftdichip.com/Drivers/VCP.htm
+- [8]: http://www.altera.com/download/drivers/usb-blaster/dri-usb-blaster-vista.html
\ No newline at end of file diff --git a/tracwiki/CoretestHashesNovena.trac b/tracwiki/CoretestHashesNovena.trac new file mode 100644 index 0000000..a614b62 --- /dev/null +++ b/tracwiki/CoretestHashesNovena.trac @@ -0,0 +1,226 @@ += How to start using coretest_hashes on the Novena PVT1 =
+
+This is a writeup on how to setup, build and testrun the coretest_hashes
+Cryptech subsystem on a Novena PVT1 development board.
+
+== Getting started with Novena ==
+
+[http://www.kosagi.com/w/index.php?title=Novena_Main_Page Novena] is an open hardware and F/OSS-friendly computing platform.
+
+[[Image(http://bunniefoo.com/novena/pvt1_release/novena_pvt1e_top_sm.jpg)]]
+
+It is a small single-board Linux PC, which happens to include a Xilinx [http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/lx.html Spartan-6 FPGA]. This, together with the TerasIC [http://trac.cryptech.is/wiki/CoretestHashesC5G Cyclone 5 GX], is what we are using to develop and test the Cryptech cores.
+
+The Novena includes an HDMI adapter and two USB ports, so you can plug in a monitor, keyboard, and mouse, and have a graphical desktop environment. However, I prefer to run it headless, and ssh to it. To ssh to the Novena, you need to know its IP address, which means you need to either statically configure it, or you need to assign it an address in your DHCP server.
+
+If you go the DHCP route, be aware that Novena doesn't used a fixed hardware address, so you'll have to statically configure **that**.
+Open `/etc/network/interfaces`, and add something like the following lines:
+{{{
+allow-hotplug eth0
+iface eth0 inet dhcp
+ hwaddress ether 00:0e:c6:87:72:01
+}}}
+
+
+* The specific CPU on the Novena is the Freescale i.MX6 MCIMX6Q5EYM12AC device. A quad core, ARM A9 device running at 1.2 GHz.
+* The specific FPGA on the Novena is the Xilinx Spartan-6 XC6SLX45-3CSG324C device.
+* Here are [http://bunniefoo.com/novena/pvt2_release/novena_pvt2.PDF "the schematics for the Novena PVT2 board"].
+
+
+=== Coretest_hashes ===
+
+The coretest_hashes is a subsystem that is a FPGA design that contains
+Cryptech application cores as well as support cores used to run tests
+of the SHA-1 and SHA-2 hash functions from the host computer via an
+I2C serial bus. The subsystem consists of:
+
+- [browser:/core/sha1 sha1]: A HW implementation of the SHA-1 hash function.
+
+- [browser:/core/sha256 sha256]: A HW implementation of the SHA-256 hash
+ function.
+
+- [browser:/core/sha512 sha512]: A HW implementation of the SHA-512 hash
+ function.
+
+- [browser:/core/coretest coretest]: A command parser that accepts read/write
+ commands from a host, executes the commands and sends the response.
+
+- [browser:/core/i2c i2c]: A serial interface that connects coretest to the
+ host.
+
+- [browser:/core/novena novena]: A top-level wrapper that connects all
+ the cores, and connects i2c to external pins as well as clk and
+ reset. This repo also contains userland software that talks to
+ coretest and performs tests of the sha1, sha256, and sha512 cores.
+
+== Software and system requirements ==
+
+You need to download and install the Xilinx
+[http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html ISE Design Suite].
+
+Note: this software runs on a Windows or x86 Linux host, **not** on the Novena.
+
+=== Installing on Linux ===
+
+The Windows install is pretty straight-forward. So is the Linux
+install, but with a few extra notes:
+
+- Xilinx only supports specific versions of Red Hat and Suse Linux, but it does run on Ubuntu, with the following caveat: Ubuntu symlinks `/bin/sh` to `dash`, which can't handle `if [ ]` syntax in shell scripts, so I symlinked `/bin/sh` to `bash` instead.
+
+- ISE Design Suite uses a graphical installer, so has to be installed
+ on a desktop edition, not a server edition.
+
+- Although the software can be installed as user or root, by default
+ it wants to install into `/opt/Xilinx`, so you need to install as root
+ if you want to do that.
+
+- The Xilinx tools are disk hogs, so if you're building a VM for this, you'll probably want to give it at least 30-40 GB of disk space.
+
+Step-by-step installation:
+1. Unpack Xilinx_ISE_DS_Lin_14.7_1015_1.tar (or whatever version you have).
+2. `cd` to Xilinx_ISE_DS_Lin_14.7_1015_1, and run `sudo ./xsetup`
+3. Click through two screens of license agreements.
+4. Select `ISE WebPACK`.
+5. Unselect (or leave unselected) `Install Cable Drivers`.
+6. Go!
+
+Well, not quite. You will need to convince the ISE that you have a license.
+
+On the page [http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm] click on the `Licensing Solutions` link. On the resulting page, expand the section `Obtain a license for Free or Evaluation product`. To download the ISE Webpack, you should have created an account, so now you can go to the Licensing Site and use that account to create a Certificate Based License.
+
+You do not need to go through the HostID dance, just say Do It. You will then receive a certificate in email (not an X.509 certificate) which you will be able to use. Then start the ISE Webpack by issuing the command `ise`. Go to the Help menu and `Manage Licenses`. Use the resulting new License Manager window to install the .lic file. This process is complex and flakey.
+
+Here is a more detailed description of [http://www.armadeus.com/wiki/index.php?title=ISE_WebPack_installation_on_Linux "installing ISE in Ubuntu."]
+
+Platforms on which at least one person has done this succesfully:
+
+* ISE 14.7 on a 32-bit Debian Wheezy VM running under !VirtualBox on MacOSX.
+* ISE 14.7 on a 64-bit Debian Jessie VM running under virsh/kvm.
+* ISE 14.7 on 32-bit Debian Jessie on a Shuttle XS36V.
+
+== Downloading the cores ==
+
+Create a project directory, e.g. `coretest/core`.
+
+The cores we need to build the subsystem must be downloaded from the
+Cryptech server. Check them out one by one:
+{{{
+#!sh
+git clone http://git.cryptech.is/core/sha1.git
+git clone http://git.cryptech.is/core/sha256.git
+git clone http://git.cryptech.is/core/sha512.git
+git clone http://git.cryptech.is/core/i2c.git
+git clone http://git.cryptech.is/core/coretest.git
+git clone http://git.cryptech.is/core/novena.git
+}}}
+
+If you are a cryptech core member, use the ssh method, e.g.
+{{{
+git clone git@git.cryptech.is:core/sha1.git
+}}}
+
+== Building the cores ==
+
+=== Building in Linux command-line ===
+
+Go to `novena/synth` and run `make`.
+
+Depending on your version of ISE Design Suite, where you installed it,
+and whether you're running it on 32-bit or 64-bit hardware, you may
+have to change the `isedir` and `xil_env` values in `Makefile`.
+
+=== Building in the ISE application ===
+
+On Windows, open the Project Navigator link.
+
+On Linux, run e.g. `/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise`
+
+a. Create the project:
+ Select `File` > `New Project`
+ - Name: novena
+ - Location: .../toolruns (automatically appends "novena")
+ - Family: Spartan6
+ - Device: XC6SLX45
+ - Package: CSG324
+ - Speed: -3
+
+b. Add files to the project:
+ - coretest/src/rtl/coretest.v
+ - coretest_test_core/src/rtl/coretest_test_core.v
+ - i2c/src/rtl/i2c.v
+ - i2c/src/rtl/i2c_core.v
+ - novena/src/rtl/coretest_hashes.v
+ - novena/src/rtl/novena_fpga.v
+ - novena/synth/coretest-novena.ucf
+ - sha1/src/rtl/sha1.v
+ - sha1/src/rtl/sha1_core.v
+ - sha1/src/rtl/sha1_w_mem.v
+ - sha256/src/rtl/sha256.v
+ - sha256/src/rtl/sha256_core.v
+ - sha256/src/rtl/sha256_k_constants.v
+ - sha256/src/rtl/sha256_w_mem.v
+ - sha512/src/rtl/sha512.v
+ - sha512/src/rtl/sha512_core.v
+ - sha512/src/rtl/sha512_h_constants.v
+ - sha512/src/rtl/sha512_k_constants.v
+ - sha512/src/rtl/sha512_w_mem.v
+
+c. Set some non-default options:
+
+ ''Note: these are derived from other Novena projects, and I'm not sure
+ what they mean, but they don't make things blow up.''
+
+ - In the `Process` window, right-click on `Generate Programming File`, select `Process Properties...`.
+ - In `Configuration Options`, find `-g UnusedPin`, and change it from `Pull Down` to `Float`.
+ - In `Startup Options`, find `-g DriveDone`, and check the box.
+
+d. Build the project
+
+ Select `Process` > `Implement Top Module`
+
+
+The expected build time should be something like 5 and 10 minutes, depending on the computer used.
+Some measured build times for the design:
+
+ - 5,30 minutes on MacbookPro 2013 with tools in 64-bit SUSE Linux in VM
+ - 9,20 minutes on AMD A10-6800K with tools in Windows 7 in Virtualbox VM with one CPU core and 4 GByte RAM.
+
+
+== Running coretest on the Novena ==
+
+`scp` the built `coretest-novena.bit` to the Novena.
+
+Fetch
+[https://github.com/xobs/novena-scope-drivers/blob/master/userspace/devmem2.c devmem2.c]
+and compile it on the Novena.
+
+`scp` the following files from `novena/src/sw` to the Novena:
+- configure.sh
+- hash_tester.py
+
+To configure the coretest image into the FPGA, run
+{{{
+#!sh
+./configure.sh coretest-novena.bit
+}}}
+
+This should light a small green LED (labeled "fpga") next to the high-speed
+expansion connector. The console log should be:
+
+{{{
+Setting export of reset pin
+setting reset pin to out
+flipping reset
+configuring FPGA
+11597+1 records in
+11597+1 records out
+1484509 bytes (1.5 MB) copied, 2.34345 s, 633 kB/s
+turning on clock to FPGA
+/dev/mem opened.
+Memory mapped at address 0x76f51000.
+Value at address 0x20C8160 (0x76f51160): 0x40B
+Written 0xD2B; readback 0xD2B
+}}}
+
+Run `hash_tester.py` to go through the full test suite.
+
diff --git a/tracwiki/DNSSEC%2FRequirements.trac b/tracwiki/DNSSEC%2FRequirements.trac new file mode 100644 index 0000000..b8f40f0 --- /dev/null +++ b/tracwiki/DNSSEC%2FRequirements.trac @@ -0,0 +1,76 @@ += DNSSEC Requirements =
+
+== Questions ==
+
+- Should we even support SHA-1?
+- GOST?
+
+== Must implement ==
+
+Target DNSSEC Algorithms:
+
+- RSA/SHA-256 (RFC 5702)
+- RSA/SHA-512 (RFC 5702)
+
+Algorithms:
+
+- Hash: SHA-256
+- Hash: SHA-512
+- Sign: RSA
+
+Required PKCS11 Mechs:
+
+- CKM_RSA_PKCS_KEY_PAIR_GEN
+- CKM_SHA256_RSA_PKCS
+- CKM_SHA512_RSA_PKCS
+- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing)
+- CKM_SHA256
+- CKM_SHA512
+
+== Should implement ==
+
+Target DNSSEC Algorithms:
+
+- ECDSA/P-256/SHA-256 (RFC 6605)
+- ECDSA/P-384/SHA-384 (RFC 6605)
+
+Algorithms:
+
+- Hash: SHA-256
+- Hash: SHA-384
+- Sign: P-256
+- Sign: P-384
+
+Required PKCS11 Mechs:
+
+- CKM_EC_KEY_PAIR_GEN
+- CKM_ECDSA_SHA256
+- CKM_ECDSA_SHA384
+- CKM_ECDSA (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing)
+- CKM_SHA256
+- CKM_SHA384
+
+== May implement ==
+
+Target DNSSEC Algorithms:
+
+- RSA/SHA-1 (RFC 3110)
+- GOST (RFC 5933)
+
+Algorithms:
+
+- Hash: SHA-1
+- Sign: RSA
+
+- Hash: GOST R 34.11-94 (RFC5831)
+- Sign: GOST R 34.10-2001 (RFC5832)
+
+Required PKCS11 Mechs:
+
+- CKM_RSA_PKCS_KEY_PAIR_GEN
+- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA_1)
+- CKM_SHA1_RSA_PKCS
+- CKM_SHA_1
+
+- CKM_GOSTR3410_KEY_PAIR_GEN
+- CKM_GOSTR3410_WITH_GOSTR3411
diff --git a/tracwiki/DNSSEC.trac b/tracwiki/DNSSEC.trac new file mode 100644 index 0000000..c6741b5 --- /dev/null +++ b/tracwiki/DNSSEC.trac @@ -0,0 +1,3 @@ += DNSSEC =
+
+- [wiki:DNSSEC/Requirements DNSSEC Requirements]
diff --git a/tracwiki/Dashboard.trac b/tracwiki/Dashboard.trac new file mode 100644 index 0000000..2b53f65 --- /dev/null +++ b/tracwiki/Dashboard.trac @@ -0,0 +1,81 @@ += Project Status Dashboard =
+
+== Product Component Requirements ==
+
+||= State =||= Component =||= DNSsec Signing =||= Let's Encrypt =||= Tor Consensus =||= Internal =||= Ticket =||
+|| Done || AES / KEY WRAP || || || || !Wrap/Bkup || #17 ||
+|| || ECDSA p256 ||= secondary =||= Yes =|| || || ||
+|| || ECDSA p384 ||= secondary =||= ? =|| || || ||
+|| Testing || PKCS!#11 ||= Yes =||= Yes =||= Yes =|| Yes || #14 ||
+|| Done || RSA ||= Yes =||= Yes =||= Yes =|| || #16 ||
+|| Done || SHA-1 || || =||= Yes =|| || ||
+|| Done || SHA-256 ||= Yes =||= Yes =||= Yes =|| || ||
+|| Done || SHA-384 ||= Yes =||= ? =|| || || ||
+|| Done || TRNG ||= padding =||= padding =||= padding =|| !KeyGen || #15 ||
+
+
+== Novena Alpha - DNSsec Only ==
+
+||= Component =||= Who =||= About When =||= Ticket =||
+||RSA || Pavel, Rob || Done || #16 ||
+||AES/KEY WRAP || Rob || Done || #17 ||
+||SHA-256 || Joachim || Done || ||
+||TRNG || FT || Done || #15 ||
+||PKCS!#11 || Rob || Late May || ||
+||PKCS!#11 PIN || Rob || Mid June || #14 ||
+||Packaging || Paul, Rob || Done || ||
+
+
+== Hardware cores ==
+
+=== Hash Functions ===
+
+||= Component =||= Status =||= Repository =||= Comment =||
+|| SHA-1 || Done || [[GitRepositories/core/hash/sha1| core/hash/sha1]] || ||
+|| SHA-256 || Done || [[GitRepositories/core/hash/sha256| core/hash/sha256]] || ||
+|| SHA-512 || Done || [[GitRepositories/core/hash/sha512| core/hash/sha512]] || Support all four SHA-512/x modes defined in FIPS 180-4. ||
+|| SHA-3 (Keccak ) || Started || [[GitRepositories/core/hash/sha3| core/hash/sha3]] || ||
+|| GOST R 34.11-2012 || Started || || ||
+
+
+=== Symmetric Crypto ===
+
+||= Component =||= Status =||= Repository =||= Comment =||
+|| AES || Done || [[GitRepositories/core/cipher/aes| core/cipher/aes]] || AES cipher core with support for 128 and 256 bit keys. ||
+|| !ChaCha || Done || [[GitRepositories/core/cipher/chacha| core/cipher/chacha]] || High speed stream cipher. Based on the Salsa20 stream cipher. ||
+
+
+=== Asymmetric Crypto ===
+
+||= Component =||= Status =||= Repository =||= Comment =||
+|| !ModExp -8192 (RSA) || Done || [[GitRepositories/core/math/modexps6| core/math/modexps6]] || ||
+|| Curve25519 || Started || || ||
+|| Ed25519 || Not started || || ||
+|| P-256, P-384 ECDSA || Started || || ||
+|| GOST R 34.10-2001 || Started || [[https://trac.cryptech.is/browser/user/shatov/gost/streebog]] || Core in provisional repo. Will be moved to the the hash core section.||
+
+
+=== Random Number Generators ===
+
+||= Component =||= Status =||= Repository =||= Comment =||
+|| TRNG || Done || [[GitRepositories/core/rng/trng| core/rng/trng]] || Depends on SHA-512 and !ChaCha ||
+|| External Avalanche Entropy || Done || [[GitRepositories/core/rng/avalanche_entropy| core/rng/avalanche_entropy]] || [[GitRepositories/user/ft/stm32-avalanche-noise| Hardware]] and stand-alone PoC ||
+|| Internal Ring Oscillator || Done || [[GitRepositories/core/rng/rosc_entropy| core/rng/rosc_entropy]] || ||
+
+
+=== Key wrapping and Cipher Modes ===
+
+||= Component =||= Status =||= Repository =||= Comment =||
+|| KEY WRAP || Done || || Key wrapping mode. Will be used for key storage. See [https://tools.ietf.org/html/rfc3394 "rfc 3394"]. #17 ||
+|| GCM || Not started || || Galois Counter Mode. AEAD cipher. ||
+|| CTR and CBC || Not started || || Basic block cipher modes. ||
+
+
+=== Support Functionality ===
+
+||= Component =||= Status =||= Repository =||= Comment =||
+|| Coretest || Done || [[GitRepositories/core/comm/coretest| core/comm/coretest]] || Command-response based core tester for HW accelerated core verification. ||
+|| UART || Done || [[GitRepositories/core/comm/uart| core/comm/uart]] || Serial interface module used on the TerasIC C5G development board. ||
+|| I2C || Done || [[GitRepositories/core/comm/i2c| core/comm/i2c]] || I2C interface module used on the Novena board. ||
+|| EIM || Done || [[GitRepositories/core/comm/eim| core/comm/eim]] || Interface for the Freescale EIM memory interface used on the Novena board. ||
+|| FMC || Done || [[GitRepositories/core/comm/fmc| core/comm/fmc]] || Interface for the STM32 FMC memory interface used on the dev-bridge and Alpha boards. ||
diff --git a/tracwiki/DevBridgeBoard.trac b/tracwiki/DevBridgeBoard.trac new file mode 100644 index 0000000..e601fda --- /dev/null +++ b/tracwiki/DevBridgeBoard.trac @@ -0,0 +1,40 @@ +[[PageOutline]]
+
+= dev-bridge board =
+In the process of developing the [wiki:AlphaBoardComponents] design, the project has made what is known as the "dev-bridge board".
+
+This is a board, 100x70 mm, with about 2/3 of the components intended to be on the Alpha design. What is missing is basically the FPGA and it's supporting circuits.
+
+To date, the dev-bridge board has been used to implement and validate the FMC based interface that will be used to connect the ARM and the FPGA on the Alpha.
+
+Schematics and layouts are at [https://wiki.cryptech.is/browser/user/ft/stm32-dev-bridge/hardware/rev01 user/ft/stm32-dev-bridge/hardware/rev01].
+
+High resolution pictures of rev01 of the dev-bridge board are attached at the bottom of this page, but the following should be more than sufficient to read the silkscreens.
+
+[[Image(dev-bridge_rev01_front_medium.jpg)]]
+
+[[Image(dev-bridge_rev01_back_medium.jpg)]]
+
+Here is the board mounted on the Novena, attached to the programmer:
+
+[[Image(IMG_9983s.jpg)]]
+
+Note that it's rather bigger than the Netgear enclosure I use to transport the Novena. (Not only does it protect the board, but I have this superstition that TSA is more comfortable with a home gateway than a bare motherboard.)
+
+Also note that the dev-bridge board is connected to the Novena by the
+high-speed expansion connector, which forms a bit of a pivot point.
+As Pavel says, "High speed and mechanical reliability are not very good
+friends usually."
+
+For that reason, I highly recommend stabilizing the board by bolting it to
+the Novena with a 5mm spacer. There are two through-holes that line up
+with mounting holes on the Novena, one at the corner and one next to the
+wifi connector. I've found that even one bolt is enough to stabilize the
+board.
+
+Finally note that the board traces come rather close to the through-holes, so
+you want to avoid scraping them with the bolt head or the nut. I happen to
+be using a countersink-head bolt, which is beveled toward the shaft, but
+it's probably even better to use a nylon washer.
+
+All the software, as well as flashing instructions, are at [wiki:GitRepositories/sw/stm32].
\ No newline at end of file diff --git a/tracwiki/DevelopersGuide.trac b/tracwiki/DevelopersGuide.trac new file mode 100644 index 0000000..55b49be --- /dev/null +++ b/tracwiki/DevelopersGuide.trac @@ -0,0 +1,16 @@ +''Page Under Development''
+
+= Developers Guide =
+
+== Architecture ==
+* OpenCryptoChip
+* NoisyDiode
+* AlphaBoard
+
+== Known Limitations ==
+* AssuredTooChain
+
+* EDAToolchainSurvey"
+
+== Building the Bitstream =
+
diff --git a/tracwiki/DisasterRecovery.trac b/tracwiki/DisasterRecovery.trac new file mode 100644 index 0000000..bdaa70f --- /dev/null +++ b/tracwiki/DisasterRecovery.trac @@ -0,0 +1,45 @@ += Disaster Recovery =
+
+This page covers a few likely (hopefully unlikely) oh-noes.
+
+== Oh no, I bricked my device ==
+
+=== Recovering from a bad firmware install ===
+
+You can upload new firmware through the bootloader. On power-up or reset,
+the bootloader flashes the blue LED for 10 seconds. During that time, start
+`cryptech_upload`:
+
+{{{
+$ cryptech_upload --firmware --user wheel
+PIN: <your-wheel-pin>
+}}}
+
+=== Recovering from a bad bootloader install ===
+
+Well, now you've done it. You'll need to buy an ST-LINK programmer.
+See [wiki:UsingSTLink].
+
+== Oh no, I'm locked out of my device ==
+
+If you're staring at this thing for the first time, or if you ran
+`keystore erase`, then you have no PIN. Believe it or not, this is the
+best case scenario. Log in as wheel with the default PIN
+`YouReallyNeedToChangeThisPINRightNowWeAreNotKidding`, and you should be
+able to reset the PINs.
+
+If you forgot the PIN, I feel sorry for you. The only way out of this is
+via [wiki:UsingSTLink ST-LINK]. The easiest way is to debug with `gdb`, set a breakpoint on
+`hal_rpc_login`, and issue the gdb command `return 0`.
+
+== Oh no, I forgot (or reset) the master key ==
+
+As shipped, the Alpha doesn't include a battery backup for the Master Key
+Memory. So if power is interrupted, the MKM is wiped. (Also, if we had
+tamper protection more sophisticated than a Panic Button, it would wipe
+the MKM when you opened the case to install the ST-LINK cable.)
+
+Sorry, there's nothing that can be done about that. All your keys are
+still in flash memory, but encrypted with the KEK, which is now gone.
+(Unless you used the `masterkey unsecure set` command to store the KEK in
+unprotected flash memory, but you wouldn't do that, would you?)
diff --git a/tracwiki/DocMeet.trac b/tracwiki/DocMeet.trac new file mode 100644 index 0000000..5d40191 --- /dev/null +++ b/tracwiki/DocMeet.trac @@ -0,0 +1,9 @@ += Documents, Meetings, etc. =
+
+== Meetings ==
+* At IETF88 an open lunch meeting was held with maybe 30-40 people. Minutes will be posted here shortly.
+* An invitation-only initial exploratory and team-building meeting will be hosted by SUNET in Stockholm in December. Invitations are in process. Dress in layers. Anything useful that comes out of the meeting will be published on this wiki.
+
+== Documents ==
+* [attachment:140109.cryptech.pdf 140109.cryptech.pdf Presentation - Overview of Project with Funding Requests]
+* [attachment:141002.cryptech-iij.pdf 141002.cryptech-iij.pdf CrypTech Presentation at Open IIJ Seminar]
\ No newline at end of file diff --git a/tracwiki/Documents.trac b/tracwiki/Documents.trac new file mode 100644 index 0000000..26397bd --- /dev/null +++ b/tracwiki/Documents.trac @@ -0,0 +1,21 @@ += Presentations and Design Documents =
+
+{{{
+#!comment
+
+Remember that links from this page to files in git repositories should use the "export:" tag, eg:
+
+[export:/doc/blarg.pdf "An interesting presentation about Blargs"]
+
+}}}
+
+[RandomnessTesting Randomness Testing Tools][[BR]]
+
+[AlphaBoardStrategy Alpha board strategy]
+
+[export:/doc/design/Alpha_board_drawing.pdf "Alpha board drawing"]
+
+[AlphaBoardPictures Alpha board pictures]
+
+Placeholder until somebody fills this in with something else interesting.
+
diff --git a/tracwiki/EDAToolchainSurvey%22.trac b/tracwiki/EDAToolchainSurvey%22.trac new file mode 100644 index 0000000..f49c37c --- /dev/null +++ b/tracwiki/EDAToolchainSurvey%22.trac @@ -0,0 +1,15 @@ +'''Note: this page has been replaced by wiki:EDAToolchainSurvey'''
+
+The major issue is finding tools that allows a designer, user to verify that the RTL source code (in Verilog or VHDL) matches what is generated at the physical level. As part of the project we need to investigate the current status of open tools in the toolchain for implementation and verification of hardware. This includes RTL simulation, synthesis, place & route, netlist verification, timing analysis and configuration file generation and analysis. (This implies that the target is an FPGA.). If there are no open tools we need to find ways of verifying pre- and post-functionality to check that the black box tool does not alter (subvert) the design in ways not intended.
+
+The basic action flow is:
+* Finding open EDA tools and assess their status
+* Settling for Closed
+* Strategy to Develop Trust in Tools
+* Validation Methods for Output
+
+Some tools and frameworks worth investigating are:
+* [http://www.optimsoc.org/index.html "OpTiMSoC"] - An open System on Chip (SoC) framework built around the OpenRISC CPU.
+* [http://iverilog.icarus.com/ "Icarus Verilog"] - An open Verilog event driven simulator that supports Verilog 2001, 2005 and SystemVerilog.
+* [http://www.geda-project.org/ "gEDA"] - A project that aims at developing GNU based EDA tools.
+* [http://www.gpleda.org/ "gplEDA"] - A collection of GPL licensed EDA tools. Points to gEDA.
diff --git a/tracwiki/EDAToolchainSurvey.trac b/tracwiki/EDAToolchainSurvey.trac new file mode 100644 index 0000000..4133456 --- /dev/null +++ b/tracwiki/EDAToolchainSurvey.trac @@ -0,0 +1,13 @@ +The major issue is finding tools that allows a designer, user to verify that the RTL source code (in Verilog or VHDL) matches what is generated at the physical level. As part of the project we need to investigate the current status of open tools in the toolchain for implementation and verification of hardware. This includes RTL simulation, synthesis, place & route, netlist verification, timing analysis and configuration file generation and analysis. (This implies that the target is an FPGA.). If there are no open tools we need to find ways of verifying pre- and post-functionality to check that the black box tool does not alter (subvert) the design in ways not intended.
+
+The basic action flow is:
+* Finding open EDA tools and assess their status
+* Settling for Closed
+* Strategy to Develop Trust in Tools
+* Validation Methods for Output
+
+Some tools and frameworks worth investigating are:
+* [http://www.optimsoc.org/index.html "OpTiMSoC"] - An open System on Chip (SoC) framework built around the OpenRISC CPU.
+* [http://iverilog.icarus.com/ "Icarus Verilog"] - An open Verilog event driven simulator that supports Verilog 2001, 2005 and SystemVerilog.
+* [http://www.geda-project.org/ "gEDA"] - A project that aims at developing GNU based EDA tools.
+* [http://www.gpleda.org/ "gplEDA"] - A collection of GPL licensed EDA tools. Points to gEDA.
diff --git a/tracwiki/ExternalProjects.trac b/tracwiki/ExternalProjects.trac new file mode 100644 index 0000000..99d6945 --- /dev/null +++ b/tracwiki/ExternalProjects.trac @@ -0,0 +1,3 @@ +External projects using [https://cryptech.is/ CrypTech] technology.
+
+* [wiki:ExternalProjectsTorHSM TorHSM]
diff --git a/tracwiki/ExternalProjectsTorHSM.trac b/tracwiki/ExternalProjectsTorHSM.trac new file mode 100644 index 0000000..13d88a6 --- /dev/null +++ b/tracwiki/ExternalProjectsTorHSM.trac @@ -0,0 +1,76 @@ += External project TorHSM
+
+== Problem
+
+The [https://www.torproject.org/about/overview.html.en Tor network] is defined by a small number, about ten, of special relays called Directory Authorities (DAs).
+
+Directory Authorities sign the critical `status votes` and `consensus status` documents using SHA-1 and SHA-256 together with RSA-2048 or RSA-3072 once per hour, using medium-term on-line `authority signing keys` signed by their individual off-line long-term `authority identity keys`. Authority signing keys typically have a lifetime of three to twelve months.
+
+Authority signing keys are currently kept on the same general purpose computer that runs the Directory Authority and are thus subject to a large number of network threats.
+
+== Proposed solution
+
+Move `authority signing keys` away from the general purpose computer onto an external device which can sign the consensus document without exposing key material to the networked computer system.
+
+The !CrypTech project has created an open source (BSD licensed) `Alpha` hardware which would be especially suitable, because the open software and hardware offers unprecedented transparency while also enabling a simple, efficient and legacy-free solution.
+
+=== Current typical key roll-over procedure
+
+* Generate new `authority signing key` on offline system
+* Sign new key using `authority identity key` on offline system
+* Save new `authority signing key` and `key certificate` on USB stick
+* Transfer new `authority signing key` and `key certificate` to DA system via network
+
+=== The key roll-over procedure becomes
+
+* Use administrative tool from this project on DA system to generate new `authority signing key` on HSM
+ * The new `authority signing key` initially remains inactive and unavailable for use
+ * The public part of new `authority signing key` is exported from HSM onto the DA system
+* Transfer new public part of `authority signing key` to USB stick
+* Sign new public key using `authority identity key` on offline system
+* Save `key certificate` on USB stick
+* Transfer `key certificate` to DA system via network and make available to DA
+* (Optional?) Use administrative tool from this project on DA to present `key certificate` to HSM
+* Activate key (automatic on verified `key certificate`, manual without `key certificate` verification)
+
+== Milestones
+
+The minimum viable product (MVP) at MS3 is a system where the authority signing key is no longer accessible by the DA system while not making any part of the process worse from a security perspective.
+
+The system at MS6 (to MS8) does not make any part of the process worse from a //usability// perspective (subjective) and also adds rate limiting.
+
+=== MS1 -- PoC using OpenSSL `PKCS#11` engine
+* tor using openssl p11 engine; no key management or rate-limiting
+* useful for test and verification
+
+=== MS2 -- Using !CrypTech RPC instead of OpenSSL
+* function declarations in `sw/libhal/hal.h`, definitions in `sw/libhal/rpc_*.c`
+* TODO: daemon
+
+=== MS3 (MVP) -- HSM configuration I
+* "HSM configuration" is aka "key management"
+* administrator connected to MGMT can make HSM
+ * generate a MK based on passphrase
+ * print public part of MK
+* administrator connected to USER can make HSM
+ * generate a new authority signing key pair, wrap the secret part in MK, store both parts in flash memory and export the public part
+
+=== MS4 -- HSM configuration II
+* rate limiting
+* enforcing key validity
+
+=== MS5 -- Enforcing key validity HSM side
+
+=== MS6 -- Rate limiting of signatures
+
+=== MS7 -- New Shiny Crypto Hardware API using !CrypTech RPC
+
+=== MS8 -- Getting entropy from HSM
+
+=== MS9 -- Support for more protocols in New Shiny Crypto Hardware API
+
+== References
+
+* [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt Tor directory protocol, version 3]
+* [https://www.crowdsupply.com/cryptech/open-hardware-security-module CrypTech Alpha system]
+
diff --git a/tracwiki/GettingStartedNovena.trac b/tracwiki/GettingStartedNovena.trac new file mode 100644 index 0000000..1de2cef --- /dev/null +++ b/tracwiki/GettingStartedNovena.trac @@ -0,0 +1,145 @@ +[[PageOutline]]
+
+= Getting Started on the Novena =
+
+== The Novena Board ==
+
+[[Image(http://bunniefoo.com/novena/pvt1_release/novena_pvt1e_top_sm.jpg)]]
+
+[http://www.kosagi.com/w/index.php?title=Novena_Main_Page Novena] is an open hardware and F/OSS-friendly computing platform. It is a small single-board Linux PC, with a Freescale i.MX6 (ARM
+Cortex-A9) CPU and a Xilinx Spartan-6 LX45 FPGA.
+
+It is available in limited quantities through [https://www.crowdsupply.com/sutajio-kosagi/novena crowd supply].
+
+=== Setting up the Novena ===
+
+The Novena PVT-2 requires some initial setup. You will need to attach a USB keyboard and HDMI monitor.
+
+Once this is done, most of us prefer to run it headless, and ssh in.
+
+You may also want to bring the packages up to date:
+
+{{{
+$ sudo apt-get update
+$ sudo apt-get upgrade
+}}}
+
+== The Avalanche Noise Board ==
+
+[[Image(rev03-on-novena.jpg, 40%)]]
+
+The avalanche noise board is a Novena daughter board that contains a zener-diode noise circuit that can be read directly by the FPGA.
+
+''(More information from FT: block diagram, schematics, ...)''
+
+It is available in limited quantities directly from Fredrik Thulin, and will be distributed at the PrahaWorkshop.
+
+== Binary Packages ==
+
+Cryptech maintains an {{{apt}}} repository, with two binary packages for the Novena:
+* a bitstream, to be configured into the FPGA
+* software, to run on the CPU
+
+=== How to get them ===
+
+All commands are run on the Novena.
+
+1. First, get the hactrn CA certificate:
+
+{{{
+$ wget http://www.hactrn.net/cacert.asc
+}}}
+
+Get the key used to sign the CA certificate.
+
+{{{
+$ gpg --recv-keys 2DC6FF82
+}}}
+
+Validate the CA certificate
+
+{{{
+$ gpg cacert.asc
+}}}
+
+Install the CA certficiate.
+
+{{{
+$ sudo mkdir /usr/share/ca-certificates/hactrn.org
+$ sudo mv cacert /usr/share/ca-certificates/hactrn.org/cacert.crt
+$ sudo dpkg-reconfigure ca-certificates
+}}}
+
+2. Get the repository key.
+
+{{{
+$ wget https://apt.cryptech.is/novena/apt-gpg-key.asc
+}}}
+
+Validate the key.
+
+{{{
+$ id=37A8E93F5D7E7B9A
+$ gpg --recv-key $id
+$ gpg --check-sig $id
+$ gpg --export $id | sudo apt-key add -
+}}}
+
+See the apt-key(8) manual page for more information about the APT key database, including how to remove keys you don't want anymore.
+
+Install the key.
+
+{{{
+$ sudo apt-key add apt-gpg-key.asc
+}}}
+
+3. Get the packages
+
+Configure apt to use the repository.
+
+{{{
+$ sudo wget -q -O /etc/apt/sources.list.d/novena.list http://apt.cryptech.is/novena/sources.list
+}}}
+
+Update the package index file.
+
+{{{
+$ sudo apt-get update
+}}}
+
+Get the cryptech meta-package.
+
+{{{
+$ sudo apt-get install cryptech-novena
+}}}
+
+This installs the {{{cryptech-novena-rtl}}} and {{{cryptech-novena-sw}}} packages.
+
+The {{{cryptech-novena-rtl}}} package includes an {{{init.d}}} script that configures the FPGA on system startup. This script should run automatically as part of the install process.
+
+=== Updating the packages ===
+
+Once you've performed the steps above you should be able to upgrade to newer
+version of the code using the normal APT upgrade process, eg:
+
+{{{
+$ sudo apt-get update
+$ sudo apt-get upgrade
+}}}
+
+== Setting up PKCS!#11 ==
+
+The PKCS11 token is in /usr/lib/libpkcs11.so. In order to start using it you need to set a pin and an SO pin. This you do with p11util thus:
+
+{{{
+(echo 12345678;echo 1234) | sudo p11util --set-so-pin --set-user-pin --pin-from-stdin
+}}}
+
+It is strongly suggested to change the so pin and pin (in that order above) to something sensible. Now your token is ready to use. Your favorite PKCS11-client may or may not work depending on the state of support for PKCS11 function calls - please open tickets for whatever is missing. If you want/need to talk PKCS11 from another host, you could install and configure [[PKCS11Proxy]] on both the novena and your host. Note that currently pkcs11-proxy doesn't handle differing word-lengths so your client-side will have to be 32bit (since the novena is).
+
+
+== Setting up the lab signer ==
+
+The lab DNSSEC signer MUST, at this point, be running on a 32-bit system in order to work with the 32-bit Novena.
+
+[[https://www.dropbox.com/s/f8b4s9vic7hsqyb/cryptech-proxy-lab-20150718r2.pdf]]
diff --git a/tracwiki/Hardware.trac b/tracwiki/Hardware.trac new file mode 100644 index 0000000..4a90775 --- /dev/null +++ b/tracwiki/Hardware.trac @@ -0,0 +1,26 @@ += Cryptech Hardware =
+
+== Generation 1 ==
+
+Various generic FPGA development boards.
+
+== Generation 2 ==
+
+//[wiki:CoretestHashesNovena Novena]//
+
+== Generation 3 ==
+
+An Alpha version of a !CrypTech HSM, currently in early design
+
+[[Image(cryptech-g3.png)]]
+
+There is no real tamper wrapping and no tamper sensors. The tamper switch is used to simulate tamper detection to test the system's tamper reaction(s).
+
+For the ARM, we think we want
+ * No or minimal magic blobs because it's inside the security boundary
+ * Support for booting, flash file system, and USB
+ * Do not need memory protection or allocation, threads, video or sound or ...
+ * Some speed, but the crypto is done in the FPGA
+ * All components must be free of any GPL-like virus or restrictions
+
+[wiki:AlphaBoardComponents The BOM and board requirements for the alpha board].
diff --git a/tracwiki/InterconnectStandards.trac b/tracwiki/InterconnectStandards.trac new file mode 100644 index 0000000..75bdeaa --- /dev/null +++ b/tracwiki/InterconnectStandards.trac @@ -0,0 +1,271 @@ += Comparison of On-Chip Bus Standards =
+
+== Introduction ==
+This document contains a brief summary of different on-chip bus
+standards. The standards are described and compared based on license and
+availability, technical specifications and general usage.
+
+The purpose of the document is to provide a basis for selecting the
+primary bus standard for the Cryptech Open HSM project.
+
+
+== Overview ==
+System on Chip (SoC) designs require some sort of connectivity between
+the different components (called cores or IP-cores, as in Intellectual
+Property) that are placed onto the same die.
+
+There are several standards for on-chip interconnect, standards that
+provide technical diversity that might be required by the
+system. Typical differences are:
+
+ - Performance. The capacity as well as latency.
+
+ - Intelligence. Simple master-slave read/write access or DMA-transfers,
+ coherence support etc.
+
+ - point to point or point to multipoint. Basically bus based or switch
+ fabric.
+
+
+There are also non-technical differences:
+
+ - Licensing and pricing. Does using a standard add monetary cost and
+ does using the standard infer restrictions in sharing, disclosure of
+ source code?
+
+ - Market share. The market share is primarily interesting as basis for
+ the availability of other cores that could be integrated.
+
+
+== Description of Standards ==
+
+=== AMBA ===
+AMBA (Advanced Microcontroller Bus Architecture) [#fn1 (1)], [#fn2 (2)] is a family of
+interconnect standards from ARM Ltd. AMBA is widely used in systems
+implemented in ASICs (for example mobile phone platforms), but are also
+used in FPGAs. AMBA is for example used by the LEON [#fn3 (3)] processor
+cores and subsystem GRLIB.
+
+AMBA currently contains four main interconnect types:
+
+ - APB. A simple register read/write bus used to connect simpler
+ devices such as timers, IRQ handlers, slow serial I/O such as UARTS
+ and GPIO interfaces. The peripherals are connected to a common bus
+ with a single master.
+
+ - AHB. A more advanced bus based interconnect. Supports more complex
+ data transfers of up to 1 kByte data. Supports multiple masters.
+
+ - AXI. A switch fabric based interconnect that supports multiple
+ parallel transfers, multiple masters etc.
+
+ - ACE. A low latency interconnect that supports cache coherency to
+ allow the design of multicore, multiprocessor systems on-chip.
+
+(There are also additional protocols in the AMBA specification for
+things like tracing etc.)
+
+The license model for AMBA is _Open_ according to ARM. This seems to
+mean that one can use AMBA to build a system. But at the same time, ARM
+has intellectual properties to parts of the technology as well as
+trademarks. For more information on ARM licensing, see [#fn4 (4)].
+
+The !OpenCores project [#fn7 (7)] lists several cores as well as tools for
+different AMBA interconnect types.
+
+Pros:
+ - Technically advanced and covers a wide range of system
+ requirements.
+
+ - A huge user base.
+
+ - A huge selection of third party support in terms of tools as well as
+ cores. Most of these cores and tools are commercial and proprietary,
+ closed source.
+
+Cons:
+ - Licensing. Would Cryptech need to get a license?
+
+ - Availability of open cores
+
+
+
+=== Avalon ===
+Avalon [#fn5 (5)] is a proprietary switch fabric interconnect from Altera
+corporation. It is used in systems developed using the Altera Nios-II
+[#fn6 (6)] family of soft processor cores and related peripherals.
+
+According to Altera, the license for Avalon is open: "Avalon interfaces
+are an open standard. No license or royalty is required to develop and
+sell products that use, or are based on Avalon interfaces."
+
+As far as we can discern, Avalon is not generally used outside of Altera
+based designs and not supported by a large group of third party
+vendors. The OpenCores project lists only a few cores that uses Avalon
+as interface standard.
+
+=
+Pros:
+ - Good technical features.
+
+ - Easy integration in Nios-II based systems.
+
+Cons:
+ - Limited to Altera based FPGA designs.
+
+ - Low support from open and proprietary third party suppliers of tools
+ and cores.
+
+
+
+=== !CoreConnect ===
+!CoreConnect [#fn8 (8)] is an interconnect standard initially developed by
+IBM. The standard is now used by several vendors, for example the
+FPGA-vendor Xilinx[#fn9 (9)].
+
+Similarly to AMBA, !CoreConnect contains several types of buses providing
+simple peripheral access (DCR), high speed access for processor based
+systems (OPB), as well as multicore solutions (PLB).
+
+The license for !CoreConnect is granted by IBM [#fn10 (10)]. The license seems to be
+an AS IS-license, but contains a lot of other regulations. IBM holds a
+number of patents related to !CoreConnect (see the license agreement).
+
+Pros:
+ - Good support on for systems implemented on Xilinx FPGAs.
+
+Cons:
+ - Low support by open cores and tools.
+ - License agreement.
+
+
+=== OCP ===
+The Open Core Protocol [#fn11 (11)] is a vendor neutral open interconnect standard
+being developed by the EDA standards organisation Accellera [#fn12 (12)]. The
+standards was previously developed by the vendor organisation OCP-IP [#fn13 (13)],
+but were transferred to Accellera in October 2013.
+
+Like AMBA, OCP contains a wide range of interconnect types from simple
+register read/write access over a common bus to point to
+point-interconnect and coherency support.
+
+There are quite a few commercial cores using OCP, but there seem to be
+very few open cores using OCP. !OpenCores only lists a few cores and
+they are all bridges used to connect OCP to AMBA or Wishbone.
+
+The license for accessing the specification itself is an amended AS
+IS-type license[#fn14 (14)]. The license for the interconnect seems to be rather
+open.
+
+Pros:
+ - Good technical features.
+
+Cons:
+ - Not very common in use by open cores.
+
+
+=== Wishbone ===
+Wishbone [#fn15 (15)][#fn16 (16)] (often written WISHBONE) is an open interconnect
+standard developed by members of the !OpenCore project as an alternative
+to commercial solutions - primarily AMBA.
+
+Wishbone supports bus based as well as switch fabric interconnect
+solutions of Wishbone cores. There are cores and tools to create CPU
+based systems with buses and fabrics. Technically Wishbone is simpler
+that AMBA and !CoreConnect, but provides multimasters, point to point
+switch fabrics, etc.
+
+There are tools available to generate Wishbone interfaces for a core as
+well as creating a Wishbone connected system with different types of
+interconnect solutions.
+
+The main use is related to the OpenRISC CPU core platform
+[#fn17 (17)][#fn18 (18)]. !OpenCores lists a huge selection of cores with Wishbone
+support. The majority of these cores have LGPL and GPL licenses. There
+are also third party commercial vendors that support Wishbone cores and
+systems.
+
+The license for the Wishbone standard is public domain and dos not
+impose any restrictions on usage in cores and systems. The
+specification document itself is close to Creative Commons CC-BY.
+
+Pros:
+ - Fairly good technical support.
+ - Good support from open tools and cores.
+ - Public domain license.
+
+Cons:
+ - Not as advanced. No good coherency support for example.
+
+
+== Conclusions ==
+OF the different standards, only two standards are really interesting
+for Cryptech - AMBA and Wishbone.
+
+From a technical point of view, selecting AMBA would be the proper
+choice. AMBA provides all types of interconnect that a Cryptech
+implementation might need. Also, building a Cryptech implementation
+using third party cores (CPU cores for example) would be easier with
+AMBA than the other standards. Wher AMBA falls short is the questions
+related to licensing as well as the a bit less common support from open
+cores and tools.
+
+Based on ease of licensing, openness and availability of open cores,
+Wishbone is an easy choice. Wishbone would quite probably meet all
+performance and functionality requirements a Cryptech implementation
+might have. Integration with and support from commercial cores, tools
+and vendors will however not be as good. Choosing Wishbone will quite
+probably mean more work for the Cryptech project to deliver cores and
+tools. And for the users of Cryptech Wishbone may also require more work
+and thus reduce the interest Cryptech as a HSM solution.
+
+
+
+== References ==
+[=#fn1 (1)] https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture
+
+[=#fn2 (2)] http://www.arm.com/products/system-ip/amba/amba-open-specifications.php
+
+[=#fn3 (3)] https://en.wikipedia.org/wiki/LEON
+
+[=#fn4 (4)] http://www.arm.com/products/system-ip/amba/index.php?tab=AMBA+Trademark+Guidelines
+
+[=#fn5 (5)] http://www.altera.com/literature/manual/mnl_avalon_spec.pdf
+
+[=#fn6 (6)] http://www.altera.com/devices/processor/nios2/ni2-index.html
+
+[=#fn7 (7)] http://opencores.org/
+
+[=#fn8 (8)] https://en.wikipedia.org/wiki/CoreConnect
+
+[=#fn9 (9)] http://www.xilinx.com/products/intellectual-property/dr_pcentral_coreconnect.htm
+
+[=#fn10 (10)] http://www.xilinx.com/ipcenter/doc/ibm_click_core_connect_license.pdf
+
+[=#fn11 (11)] https://en.wikipedia.org/wiki/Open_Core_Protocol
+
+[=#fn12 (12)] https://en.wikipedia.org/wiki/Accellera
+
+[=#fn13 (13)] http://www.ocpip.org/
+
+[=#fn14 (14)] http://www.ocpip.org/license_signup.php
+
+[=#fn15 (15)] http://opencores.org/opencores,wishbone
+
+[=#fn16 (16)] https://en.wikipedia.org/wiki/Wishbone_(computer_bus)
+
+[=#fn17 (17)] http://openrisc.net/
+
+[=#fn18 (18)] http://opencores.org/or1k/Main_Page
+
+
+== Copyright and License ==
+
+This document has been written by Joachim Strömbergson.
+
+(c) 2014 SUNET - The Swedish University Network
+
+This document is licensed under a Creative Commons license (CC BY 3.0).
+For more information, see:
+
+https://creativecommons.org/licenses/by/3.0/
diff --git a/tracwiki/Joachim%20Str%C3%B6mbergson.trac b/tracwiki/Joachim%20Str%C3%B6mbergson.trac new file mode 100644 index 0000000..151b814 --- /dev/null +++ b/tracwiki/Joachim%20Str%C3%B6mbergson.trac @@ -0,0 +1,253 @@ += Joachim Strömbergson =
+== Bio ==
+
+
+== Current activities ==
+* Developing coretest - a core testing framework for FPGAs.
+* Implementation of UART
+* Verification of SHA-256
+* Verification of SHA-1
+* Implementation of AES-128
+* Design proposal for TRNG
+* Design proposal for Curve25519 accelerator
+
+
+== Work Notes ==
+=== Presentations from meeting 2014-03-10 (updated and extended):
+* [browser:/doc/presentations/Cryptech_HW_status_2014-03-10.pdf "Cryptech HW status 2014-03-10"]
+* [browser:/doc/presentations/Cryptech_TRNG_Ideas_2014-03-17.pdf "Cryptech TRNG Ideas 2014-03-17"]
+
+=== Open EDA Tools ===
+* http://torc-isi.sourceforge.net/index.php - Torc is an open-source C++ infrastructure and tool set for reconfigurable computing
+
+
+=== Curve25519 ===
+We need to create an accelerator or possibly a complete implementation of the Curve25519 EC based DH-excgange. We should be able to look at some previous work:
+
+* http://eprint.iacr.org/2013/375 - NaCl on 8-Bit AVR Microcontrollers. Includes an iterative implementation of Curve25519
+* http://cryptojedi.org/crypto/index.shtml - The code to the implementation
+* http://nacl.cr.yp.to/ - The main NaCl library by DJB.
+* http://cr.yp.to/ecdh/curve25519-20060209.pdf - The Curve25519 paper by DJB.
+
+
+== Pre meeting notes ==
+
+=== Stockholm 2013-12-05 - 2012-12-06 ===
+Preparation notes for the OpenHSM meeting 2013-12-05 --
+2013-12-06. The notes contains topics, questions and ideas
+I want to bring up, check and discuss on the meeting.
+
+Philosophy
+----------
+- How to build trust in the project?
+ - Total openess and transparency
+ - Traceability of decisions
+ - Focus on simple third party validation
+ - Partitioning of security functions
+
+
+Project goal
+------------
+- Low cost vs high performance
+
+- Scalability
+ - Functionality
+ - Performance
+ - Security
+
+- Target system
+ - Performance
+
+ - Self contained, external
+ - USB,
+ - Ethernet
+
+ - Integrated
+ - PCIe
+ - Mem module
+ - SD card
+
+- Target users
+ - Single user
+ - Enterprise
+
+- Roadmap and development plan
+ - Prototyp - första målplattform
+ - Establish first Use cases
+
+- Deliveries
+ - Proof of concept, prototype
+ - Self assembly and/or finished product
+ - Source code for SW, HW
+ - PCB
+ - Enclosures
+ - Development environment
+ - Test, validation environment
+ - Tool development
+
+ - Time plan
+ - Start when
+ - Proto when
+ - v 1.0 when
+
+
+
+Project management
+------------------
+- Status financing
+
+- Ownership
+
+- Oveerseeing board
+ - IETF, ISOC,... ?
+
+- Advisory board
+ - Reviewers, external experts
+ - FPGA key extract dude
+ - DJB
+
+- Team
+ - Addtiona competency needed?
+
+- Project security
+ - Communication
+ - ...
+
+
+Development general
+-------------------
+- License(s)
+ - GPLv2, v3
+ - BSD
+
+- Methodology
+ - Agile
+ - Minimal functionality in PoC
+ - Clear increments
+
+- Repository
+ - Github
+
+
+Technology
+----------
+- Target technologies
+ - FPGA (+ internal, external CPUs)
+ - ASIC
+ - Pure CPU based
+
+- Target PoC board
+ - Select one early
+
+- Toolchains and languages
+ - SW
+ - HW
+ - Verilog 2001, 2005, SystemVerilog
+ - Icarus, gplcver
+ - Vendor specific
+ - Validation of bitstream
+ - Edge of trust, dowm the Rabbit hole
+
+- Security support in design
+ - JTAG
+ - BIST for functionality
+ - BIST for security
+ - KATS
+
+ - On-line self check
+ - RNG
+ - Pathological problems
+ - Stuck at fixed values
+ - variance
+ - bias
+
+- Reuse of existing design, code?
+ - Cores - OpenCores
+ - OpenRISC
+ - AES, SHA, RSA
+ - SoftHSM - DNSSEC PKCS#11
+ - Nettle
+ - ...
+
+- On chip 32-bit or 64 bit CPU core
+ - OpenRISC
+ - LGPL
+ - http://openrisc.net/
+ - http://opencores.org/or1k/Main_Page
+ - https://en.wikipedia.org/wiki/OpenRISC
+
+- RNG
+ - More than one entropy source
+ - Just external sources
+ - User/vendor/implemented supplied
+ - One external, one internal
+ - YubiHSM entropy source: https://www.yubico.com/products/yubihsm/
+ - Haveged: http://www.issihosts.com/haveged/
+ - DakaRand: http://dankaminsky.com/2012/08/15/dakarand/
+ - Jytter a userspace RNG: http://www.chronox.de/
+ - CPU Jitter RNG: http://www.chronox.de/
+ - CSPRNG based on Linux, OpenBSD, Fortuna, NIST etc.
+ - NIST SP 800-90. CTR_DRBG
+ - Fortuna https://en.wikipedia.org/wiki/Fortuna_PRNG
+ - Schneier, Ferguson. No estimator needed.
+ - OpenBSD arc4random: http://www.openbsd.org/cgi-bin/man.cgi?query=arc4random&sektion=3
+ - Raw read access in test mode to collected entropy pre whitening
+ - Write access in test mode to CSPRNG
+ - No key generation etc allowed during test mode.
+
+
+Technical requirements
+----------------------
+- Functional requirements
+ - TLS 1.x
+ - Need roadmap for functions
+ - AES, SHA-256, DH, RSA first iteration
+ - Why GOST?
+ - Why MD5?
+ - Curves supported?
+ - Curve25519
+ - NIST, IEEE, RFC 4xxx
+
+- HW/SW partitioning
+ - Modularity
+
+- API
+ - DMA, buffering, formats
+ - PKCS#11
+ - Observability and control
+
+- Security requirements
+ - Common Criteria - EAL
+ - FIPS 140-2 level 3-4
+
+- Performance
+ - Operations/s
+ - Packets per second
+ - Latency
+
+
+Validaiton
+----------
+- Methodology
+ - Unit tests, KATs
+
+- Documentation
+ - What to document
+ - How
+
+- Reviews
+ - Plan for them
+ - Who to ask
+
+- Tools
+ - Valgrind, Purify, linters
+
+
+Documentation
+-------------
+- Meetings
+ - Discussions, MoMs
+ - Decisiona - motivation
+
+ - Design
+ - Test and validation
diff --git a/tracwiki/MailingLists.trac b/tracwiki/MailingLists.trac new file mode 100644 index 0000000..44dfb84 --- /dev/null +++ b/tracwiki/MailingLists.trac @@ -0,0 +1,27 @@ += Communications =
+
+== Mailing Lists ==
+
+The following lists are open to all:
+* Cryptech Project Announcements\\
+ announce@cryptech.is\\
+ [https://lists.cryptech.is/listinfo/announce Subscribe/Unsubscribe]\\
+ [https://lists.cryptech.is/archives/announce/ Announce List Archive]
+* General technology and engineering list\\
+ tech@cryptech.is\\
+ [https://lists.cryptech.is/listinfo/tech Subscribe/Unsubscribe]\\
+ [https://lists.cryptech.is/archives/tech/ Tech List Archive]
+* Repository commit watch list (posting restricted)\\
+ commit@cryptech.is\\
+ [https://lists.cryptech.is/listinfo/commits Subscribe/Unsubscribe]\\
+ [https://lists.cryptech.is/archives/commits Commit List Archive]
+
+The following lists require approval for subscription:
+* Cryptech Project Core Team\\
+ core@cryptech.is\\
+ [https://lists.cryptech.is/listinfo/core Subscribe/Unsubscribe]\\
+ [https://lists.cryptech.is/archives/core/ Core List Archive]
+* Finance, funding, administration\\
+ org@cryptec.is\\
+ [https://lists.cryptech.is/listinfo/org Subscribe/Unsubscribe]\\
+ [https://lists.cryptech.is/archives/org/ Org List Archive]
diff --git a/tracwiki/MiscStuff.trac b/tracwiki/MiscStuff.trac new file mode 100644 index 0000000..7ac0d1e --- /dev/null +++ b/tracwiki/MiscStuff.trac @@ -0,0 +1,27 @@ += References & Miscellaneous =
+
+== Interesting research and people ==
+Advisory board, reviewers etc.
+
+=== Elliptic Curves ===
+* [http://safecurves.cr.yp.to/]. Including Curve3617.
+* [http://www.nsa.gov/ia/_files/nist-routines.pdf]. Details for implementing NIST curves.
+* [http://blog.cr.yp.to/20140323-ecdsa.html] djb on How to design an elliptic-curve signature system
+
+
+=== Side channel attacks ===
+* [http://www.cl.cam.ac.uk/~sps32/], Dr Sergei Skorobogatov
+* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_46_ECCGuide_e_pdf.pdf BSI - Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations]
+
+== Useful References ==
+
+* [https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-timing.html Remote timing attacks are practical], D. Boneh and D. Brumley.
+* [http://www.cybersecurity.my/mycc/document/mycpr/C037/AEP_Keyper_EAL4_ASE_1.3.pdf Common Critiera Security Target for the AEP Keyper]
+* [https://www.cosic.esat.kuleuven.be/ches2012/tutorials.shtml Cryptographic hardware: how to make it cool, fast and unbreakable],
+ Junfeng Fan, KU Leuven
+* [http://web.mit.edu/bunnie/www/xi/rec.html REC FPGA Seminar IAP 1998], Bunnie Huang
+* [http://compcert.inria.fr/ the formal verification of realistic compilers usable for critical embedded software]
+
+== Somewhat Related Web Sites ==
+
+* [https://prism-break.org/ List of Open SW Alternatives]
diff --git a/tracwiki/NoisyDiode.trac b/tracwiki/NoisyDiode.trac new file mode 100644 index 0000000..d20709b --- /dev/null +++ b/tracwiki/NoisyDiode.trac @@ -0,0 +1,28 @@ +
+== Noisy Diode entropy source ==
+
+The Cryptech project is using Avalanche Noise as a physical entropy source connected to the FPGA.
+
+Avalanche breakdown is a physical process that occurs when current is forced backwards through a diode until it cannot hold back anymore. The diode will then begin conducting for a brief time until the voltage drops to a point where the diode recovers. The breakdown and recovery points are not deterministic, and can thus be used as a source of real physical entropy.
+
+The unamplified noise looks like this:
+
+[[Image(noise1.jpg)]]
+
+After amplification, details are lost but the signal is now 3.3V (blue is noise before amplification, yellow is amplified)
+
+[[Image(noise2.jpg)]]
+
+Many implementations on the Internet feed a similar signal into an ADC (Analog Digital converter) and use the resulting data value at the time of the sampling as entropy. The Cryptech project believes a more robust way of extracting entropy is to instead feed the noise to a Schmitt trigger and then measure the time between rising edges. This would be more robust since any analog reading of the noise (such as with an ADC) will be sensitive to changes in temperature, supplied voltage and component aging.
+
+After beeing fed through a Schmitt trigger, the noise looks like this (yellow signal, blue is just a 4 MHz clock):
+
+[[Image(noise-schmitt.jpg)]]
+
+The Cryptech project has to date made a couple of different hardware entropy source boards, but they all share the same design for the avalanche noise source. The core parts of the circuit are shown below. Git repository with full schematics and source code is linked at the bottom of this page.
+
+[[Image(noise-schematics.png)]]
+
+Links:
+
+[[GitRepositories/user/ft/stm32-avalanche-noise| Raspberry-Pi / USB entropy source]]
\ No newline at end of file diff --git a/tracwiki/OpenCryptoChip.trac b/tracwiki/OpenCryptoChip.trac new file mode 100644 index 0000000..d924ccf --- /dev/null +++ b/tracwiki/OpenCryptoChip.trac @@ -0,0 +1,143 @@ +[[PageOutline]]
+
+= An Open Crypto Chip =
+
+== The Layer Cake Architecture Picture ==
+\\
+[[Image(layer-cake.jpg)]]
+
+\\
+\\
+== Use Cases ==
+* RPKI/DNSSEC Signing
+* Transport VPNs
+* Routers and TCP/AO
+* Email
+* Federations, Identity Systems, SSO etc
+* Password Stretching & HMAC:ing
+* PGP and SSH Keys on a Stick
+* High Quality Entropy Randomness
+* A Communications Terminal Doing One Thing Well, Like Jabber w/o X11
+* HSM for Pond, OTR identity keys, ssh private keys, etc. (i.e. key gen, store, import/export non X.509 packages)
+* Password management
+
+[[Image(cryptech venn.png)]]
+
+== Basic Functions of Crypto Chip ==
+* Key Generation
+* Key Storage
+* Key Wrap
+* Key Unwrap
+* Hash
+* Sign
+* M of N Sign
+* Verify Signature
+* Encrypt
+* Decrypt
+* KDFs, e.g. Password Stretching (a la PBKDF2)
+* Random (RO + noisy diode?)
+
+== Key wrapping ==
+We need to support key wrapping. Some pointers:
+
+- https://en.wikipedia.org/wiki/Key_Wrap
+- http://tools.ietf.org/html/rfc5297
+- http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf
+- https://tools.ietf.org/html/rfc3394
+- https://tools.ietf.org/html/rfc5649
+
+
+== Things we Should Try To Do, Even if we Can't Do Them Perfectly ==
+* Tamper Protection (wipe on signal, suggest detectors, suggest potting features)
+* Side Channel Attack Reduction
+
+
+
+= Rough Cut at v0.01 Proof of Concept Feature Set =
+As a proof of concept, to validate as much as possible the assurance of the tools and methods, and as a demonstration of the project tools, team, and architecture, we have a [wiki:RoughV1 proposed version 0.01 product] as a proof of concept and a demonstration of the project tools, team, and architecture
+\\
+\\
+= Ongoing Decisions and Research =
+* Security Target Description
+* Performance Target(s)
+* Tool-Chain Investigation
+* Prototype Design
+* Testing / Assurance Methods for all Components
+* Verilog/RTL assurance, with open source and with proprietary
+* Prototyping Platform(s)
+* Documentation, Decision History, & Transparency
+\\
+\\
+
+= Ongoing Development =
+* [wiki:SunetInitialDevelopment "SUNET is sponsoring the first two development steps"] currently being done.
+* [wiki:TRNGDevelopment " Investigation and planning of a TRNG with entropy sources"]
+* [wiki:EDAToolchainSurvey" Investigation of possible EDA tools and ways to do open and assured HW development"]
+* [wiki:SideChannel" Collection about side-channel attacks and detection, mitigation methods"]
+
+= v0.1 Major Sub-Projects =
+
+== Security Goals and Documentation ==
+* Agreement
+* Specification
+
+== Development Platform ==
+* The Bunnie laptop Novena. Includes a Xilinx Spartan 6 LX45 FPGHA. The specs, drivers, source for Novena can be found here: http://www.kosagi.com/w/index.php?title=Novena_Main_Page
+
+* TerasIC C5G Cyclone 5 GX Starter Kit. Includes an Altera C5GX FPGA. This board is used for core, subsystem development and verification. Info, documentation and ordering of the TerasIC board can be found here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
+
+Here is a writeup on how to [wiki:CoretestHashesC5G "setup and run coretest_hashes on the C5G board"].
+
+* TerasIC DE0-Nano board. This tiny, USB powered board is used for core development and verification. Info, documentation, resources, ordering of the TerasIC board can be found here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=593
+
+
+== Hardware Development Tools ==
+
+
+== Component Libraries ==
+* Research
+* Select
+* [wiki:InterconnectStandards "On-chip Interconnect Standards"] to use.
+
+== Methods and Validation ==
+* Overall Strategy
+* Following the Tool-Chain
+
+== Detailed Specification ==
+* Feature Set
+
+== QA & Documentation ==
+
+== !Green/Yellow Software Support ==
+* Spec / ABI
+* Development
+* Documentationa and Testing
+
+== Assured Linux Platform ==
+* DDC Compiler
+* System Build
+* Minimal Component Set
+
+= v0.1 Project Timeline =
+
+== February 2014 ==
+* Specification of v0.1 Goals and Feature Set
+* Security Goals & Documentation Outline
+
+== July 2014 ==
+* SHA & AES
+
+== September 2014 ==
+* TRNG
+* Assured Linux Platform - Initial Report
+
+== November 2014 ==
+* Security Goals & Documentation Overall and v0.1
+* RSA Signing on Bunnie Board
+* Assured Linux Platform - Compiler
+
+== March 2015 ==
+* v0.1 Protoype
+
+= Future Development =
+The v0.1 version of CrypTech is not the last version nor the only possible version. The project for example consider possible [wiki:ASICImplementations "ASIC Implementations"].
\ No newline at end of file diff --git a/tracwiki/OpenDNSSEC.trac b/tracwiki/OpenDNSSEC.trac new file mode 100644 index 0000000..1526a29 --- /dev/null +++ b/tracwiki/OpenDNSSEC.trac @@ -0,0 +1,136 @@ += DNSSEC signing using OpenDNSSEC and a Cryptech alpha board rev03 =
+
+== Before you start, you'll need ==
+
+- A Cryptech Alpha board, preferrably revision "rev03"
+- APT on the host system configured to find packages in the Cryptech
+ repository, see BinaryPackages for instructions
+
+{{{
+apt-get install cryptech-alpha opendnssec opensc
+}}}
+
+Once you have the software package installed, you may need to [wiki:Upgrading upgrade your HSM's firmware].
+
+== Configure the HSM ==
+
+For now, connect USB cables to both the DATA and MGMT ports of your HSM and plug them into the host where you will be running OpenDNSSEC.
+In production use it should not be necessary to leave the MGMT port connected, but it's easier to set up this way, and, as this is still a development platform, this is the configuration that's gotten the most testing.
+
+{{{
+# eval $(cryptech_probe)
+# cryptech_muxd &
+# cryptech_console
+
+Username: wheel
+Password: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+
+cryptech> keystore set pin wheel supersikritnewpw
+cryptech> keystore set pin so 123456
+cryptech> keystore set pin user 1234
+
+cryptech> masterkey set EFBEADDE
+^C
+}}}
+
+Leave `cryptech_muxd` running, so that the PKCS !#11 library can use it to talk to the HSM.
+
+
+== Configure OpenDNSSEC ==
+
+{{{
+mkdir /var/lib/opendnssec/cryptech
+
+cat > /var/lib/opendnssec/unsigned/example.com << EOF
+\$TTL 600
+example.com. IN SOA hidden-master.example.com. hostmaster.example.com. (
+ 2016041401 ; serial
+ 720 ; 28800 ; refresh (8 hours)
+ 720 ; 7200 ; retry (2 hours)
+ 300 ; 604800 ; expire (1 week)
+ 120 ; 3600 ; minimum (1 hour)
+ )
+
+ NS lab.cryptech.is.
+test A 127.0.0.1
+EOF
+
+chown -R opendnssec: /var/lib/opendnssec/*
+}}}
+
+
+== OpenDNSSEC configuration changes ==
+
+/etc/opendnssec/conf.xml:
+
+{{{
+<Repository name="Cryptech">
+ <Module>/usr/lib/libcryptech-pkcs11.so</Module>
+ <TokenLabel>Cryptech Token</TokenLabel>
+ <PIN>1234</PIN>
+ <SkipPublicKey/>
+</Repository>
+}}}
+
+The PIN is whatever was chosen as PIN for 'user' above.
+The !TokenLabel has to be "Cryptech Token", not something you choose.
+
+
+/etc/opendnssec/kasp.xml:
+
+ s/SoftHSM/Cryptech/
+
+/etc/opendnssec/zonelist.xml:
+
+{{{
+<Zone name="example.com">
+ <Policy>lab</Policy>
+ <SignerConfiguration>/var/lib/opendnssec/signconf/example.com.xml</SignerConfiguration>
+ <Adapters>
+ <Input>
+ <Adapter type="File">/var/lib/opendnssec/unsigned/example.com</Adapter>
+ </Input>
+ <Output>
+ <Adapter type="File">/var/lib/opendnssec/signed/example.com</Adapter>
+ </Output>
+ </Adapters>
+</Zone>
+}}}
+
+
+== Initialization and signing ==
+
+Make the deamons reload their configuration:
+
+{{{
+ service opendnssec-enforcer restart
+ service opendnssec-signer restart
+}}}
+
+Initialize opendnssec:
+
+{{{
+ ods-ksmutil setup
+}}}
+
+That should be it!
+
+See /var/log/syslog for output from ods-kaspcheck, ods-enforcerd and ods-signerd.
+See /var/lib/opendnssec/signed/ for a signed example.com zone.
+
+To list keys using ods-ksmutil, accessing the HSM using pkcs11
+directly (rather than going through any of the opendnssec daemons),
+export the environment variables from /etc/default/opendnssec and run
+"ods-ksmutil keys list --verbose":
+
+{{{
+# ods-ksmutil keys list --verbose
+SQLite database set to: /var/lib/opendnssec/kasp.db
+Keys:
+Zone: Keytype: State: Date of next transition (to): Size: Algorithm: CKA_ID: Repository: Keytag:
+example.com KSK ready waiting for ds-seen (active) 2048 8 7f9b9329480ebe5dc81054ccb293e261 Cryptech 62642
+example.com ZSK active 2016-07-13 19:04:30 (retire) 1024 8 97e972633613bd605944a0531ff5399b Cryptech 56620
+}}}
+
+If the output for repository is "Cryptech NOT IN repository",
+ods-ksmutil has not been able to actually list the keys in the HSM.
\ No newline at end of file diff --git a/tracwiki/PKCS11Proxy.trac b/tracwiki/PKCS11Proxy.trac new file mode 100644 index 0000000..c448a97 --- /dev/null +++ b/tracwiki/PKCS11Proxy.trac @@ -0,0 +1,50 @@ +The pkcs11-proxy is a way to tunnel PKCS11 over TCP (TLS). This page explains how to build and install PKCS11 proxy on the novena. There are various forks of this on github. We're going to use the SUNET fork since it support TLS-PSK for authentication out of the box. The proxy does not currently support different word length on each side of the tunnel so to use it with the novena platform your PKCS11 client must be 32 bit.
+
+== Why would you want this? ==
+
+Not all applications will run on the arm-based novena. For instance not all parts of opendnssec is not fully ported to arm (and probably never will be).
+
+== Building PKCS11 proxy ==
+
+{{{
+# apt-get -y install git cmake libssl-dev
+# git clone https://github.com/SUNET/pkcs11-proxy
+# cd pkcs11-proxy
+# mkdir build
+# cd build
+# cmake ..
+# make
+# make install
+}}}
+
+== Setting up pkcs11 proxy on the novena ==
+
+Next create a pre-shared secret for TLS authentication...
+
+{{{
+# (echo -n "psk:"`xxd -l 16 -p /dev/random`; echo) > psk.txt
+}}}
+
+The resulting file (psk.txt) needs to be present both on the server and client side of the PKCS11 tunnel so copy it (or its one-line content) to the client side of your proxy.
+
+Now start a pkcs11 proxy daemon:
+
+{{{
+# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11_DAEMON_SOCKET="tls://<your ip>:4444" pkcs11-daemon /usr/lib/libpkcs11.so
+}}}
+
+Now on another machine (where pkcs11-proxy has been installed) access the remote token via
+
+{{{
+# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11_PROXY_SOCKET="tls://<your ip>:4444" pkcs11-tool --module /usr/local/lib/libpkcs11-proxy.so -I
+}}}
+
+== Tracing PKCS11 calls ==
+
+If you want to trace the PKCS11 calls you can use pkcs11spy from the opensc package. If you install opensc look for an SO called pkcs11-spy.so. On the novena it is in /usr/lib/arm-linux-gnueabihf/pkcs11-spy.so. To use it set your environment variable PKCS11SPY to your real PKCS11 library and use pkcs11-spy.so instead. For instance to use PCKCS11 spy on the server side of the PKCS11 proxy start the pkcs11-daemon thus:
+
+{{{
+# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11SPY="/usr/lib/libpkcs11.so" PKCS11_DAEMON_SOCKET="tls://<your ip>:4444" pkcs11-daemon /usr/lib/arm-linux-gnueabihf/pkcs11-spy.so
+}}}
+
+This should now generate lots of output when you run PKCS11 calls over the tunnel.
diff --git a/tracwiki/PostAlphaPlan.trac b/tracwiki/PostAlphaPlan.trac new file mode 100644 index 0000000..fb4acef --- /dev/null +++ b/tracwiki/PostAlphaPlan.trac @@ -0,0 +1,60 @@ +
+The core dev team had a design meeting in Berlin after the alpha workshop. We came up with a plan for the hardware and the software work for the next few months:
+
+== Hardware ==
+
+=== Revision 04 ===
+
+This is targeted for the mid-flight revision in the 50 board order from propoint. For practical reasons, we should limit ourselves to bugfixes and other "low risk" changes for this release.
+
+* On-board battery (super-cap, long battery life etc, battery outside the tamper boundary etc)
+* Next generation USB based on Stuges daughter board work
+* Support higher clock speeds
+* Proposed: pull out 2 more UARTS from the STM32 to support memory-card readers and pin-entry devices
+
+=== Revision 05 ===
+
+* Power instrumentation
+* EMC
+* Tamper revisions??
+
+== Software ==
+
+The software plan is divided into 3 parts: "now", "next week" and "next month". These are labels, not a time frame. The "now" list represents stuff that is currently seeing active work. We move stuff from "next week" to "now" and from "next month" to "next week" as part of our planning process (at the engineering calls).
+
+=== Now ===
+
+* CLI updates [Done, but waiting on a BSD-friendly license]
+* rewrite keystore code to support larger keysizes and more slots [Done]
+* multi-core resource management [Done]
+* finish verilog EC point multiplier [Done]
+* increase clock speed
+* openssl engine [Done]
+* debug log [Mechanism done, nothing using it yet]
+* usb driver matching rev04 usb updates
+
+=== Next Week ===
+
+* GOST drivers
+* key backup [Done]
+* SHA3
+* ECDSA verilog [Done]
+* build system configuration management
+* real documentation: user, admin and dev manuals
+* Python RPC client [Done]
+* set time and date from CLI
+
+=== Next Month ===
+
+* 25519 verilog
+* design papers
+* doxygen
+* m of n
+* notify ARM and FPGA of tamper events
+* secure channel
+* ECDH
+* AES drivers
+* audit logging
+
+=== Eventually ===
+* Profiling [Mechanism done]
\ No newline at end of file diff --git a/tracwiki/PrahaWorkshop.trac b/tracwiki/PrahaWorkshop.trac new file mode 100644 index 0000000..57221b9 --- /dev/null +++ b/tracwiki/PrahaWorkshop.trac @@ -0,0 +1,71 @@ +[[PageOutline]]
+
+= !CrypTech Workshop - 2015.07.18 Praha =
+
+== Logistics ==
+* Hilton Hotel, the IETF venue
+* Amsterdam Room (this is a change)
+* 09:00 - 17:00
+
+== Introductions ==
+* The !CrypTech Team
+* Others Who Have Contributed
+* Other Folk at the Meeting
+
+== Workshop Goals ==
+* Get an understanding of the project status and roadmap
+* Discus your requirements and expectations with the team
+* Get hands-on experience with the cryptech code on the novena dev board
+* Procrastinate finding a new name for the project
+* NON-GOAL: you don't get to go home with hardware
+
+== Overview of Project ==
+* Overall Goals
+ * A Set of Designs, not a product
+ * Save the World, Securely :)
+* Short Term Goals
+ * Sign a DNSSEC Zone
+ * Sign RPKI Data
+* Roadmap
+ * Novena Dev Platform
+ * Noise Board
+ * Bridge Board
+ * Alpha Board
+ * !Better/Beta Board :)
+
+== Status ==
+* Novena, Bridge, and Alpha Hardware
+* Verilog Cores
+* Software
+* APIs
+* Current Build and Work Packaging
+
+== User Feedback So Far ==
+
+== Workshop 0 ==
+* Unpack Novenas
+* Install Noise Board
+* Build Bitstream and Download
+* Build Software and Install
+* Install DNSSEC Signware on Your Laptop
+* Sign a Zone
+
+== User Feedback So Far ==
+
+== Workshop 1 ==
+* Unpack and Install Bridge Boards
+* Build Software and Install
+* Install DNSSEC Signware on Your Laptop
+* Sign a Zone
+
+== User Feedback ==
+
+== Morning coffee break :) ==
+
+== You Should Bring ==
+* Laptop
+* MacOSX, Linux, or ? (if you want to build FPGAware, debian 64-bit, and it needs a desktop, VM OK)
+* Micro-SD card if you want to take images and/or data home
+* Logic Analyzer (optional, for hardware geeks)
+* JTAG Interface (optional, for hardware geeks)
+* Cookies or Equivalent to Share
diff --git a/tracwiki/PrahaWorkshopSSH.trac b/tracwiki/PrahaWorkshopSSH.trac new file mode 100644 index 0000000..8ec7080 --- /dev/null +++ b/tracwiki/PrahaWorkshopSSH.trac @@ -0,0 +1,16 @@ +== The list of all known SSH keys ==
+
+{{{
+
+
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZJUtfVH0KQfdGhVetTQRpg9Ki8xGKNnO07r6df9DrrmDrsHVSsDOv8zxMoNh4XHbaLtmSCT8IkB8xLU6dXVCH4vWZZwfzaKKRNgMOSfOSc6blKKBV6xEw9qXeMe4dWcfknl3yAr6EqYsg5Lrmqgalr8Vyd6FGAoGbLR4Qh7vrahMqXp3+20kn1xfDm5reSJDbNPmU4eNhJykTNtr6l6CbK/OFzhqcMI/AW5AO0wL8f5wIoHQzescZWQMDMW+1gVyDiS8lGS6nhsSZwZZeAJrXHK/LF3ldz1To5HBxzpU5Sziav8C5bgTeYo5YfqDuBq8m9mgZTzqocXFcXUCr0I6x dol@dolmacbook
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnskRpNxWJE/YgDR3o6sMWwwmbUJ8f2SJa0gHfHM+fcxxC2zQN9/9mqJSxS1E9QdeuRbbHpYxEUtHoX0vSrmia/VALDiQAMps51RBqq6YlrYqvP/Rb0hZ0Z4/YgjTosLdu1PeTzih6mwbyNNF0+gY987Ig31qXQytNF+9G1oSY9dgBAq52lu170QXTRwum4B6Gh4/pCnM6xx+7nY2oqlgvl2wYHVAOJ39W9r4y9kBhcVs51XvJqYehjaoyKYf1+PzA0FsvhJkZuG6ws5eEGSB90lAzKGyFZXedvOLmnFmqAraoLeuKajHIFJDfKNfHHbYpn8ERIfVW66nbqlXFO2g3 fredrik@thulin.net
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo3wT4gGyEmGGw5ePMO+jscvq7lo4hIPQHVZNgrChVWphvD1MkkH6PfoUYNfKwagFjUPQcDotQxGaVfvxL6Y4WzOfwiONHTj/4b2skxdRw5B/K2ZnGw2pbfXP4Nhjb1gry2K+BSVWqP3pVZk5tQ+P0YqbwKNfBFlaqS1dR8uIwo6E/8wGIjcMcDMAioMyRlU2R/u1aXQliol75GWu0jP9xrDyE3mRxoptn7kiUi9JAs/iZtlsiJh51IOADhhNMLWcmQEzKrcR2zytWZqEPzCx9C72/nPl3WacNXqdrMMT5tjt18TOFCf1jhBCHzXMu+biaoHB5sSBtue0zLFyO1A1XxLYxCp+jqlwJm2xAkS1rpFhdW3qlJZe0dV3a3TwepMGi/ObhggEk8ygwDNpYPEbgKqBcKb5RMpPJS2aEKbKd1+UStCagwPNwgRLrBME9YIAI9zyN8sFgHyy70q2XzhUJ5zz+X8JMVaKEKMTVh31u01jQchdvHkkGD7/xbp3hluFOCI1ChYKSlRdakoS6XnPopZ/0tHrkpk+k5lScu9lPHvBTMa3gq+b++TDbkW8dtYq3c78xHcAmOEjXvezbTnKpe/dRfWEUbmrGOch3mzDPoYAtjj7fdEWUGELhCSJB813B7HcGS6oXmW0PYEtOEIgeo83JX6i2qYiTQmjY1kOgBw== jakob@kirei.se
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDEK7I/KcbkhIevS+N88wBEA7OP+HtsULSxB0zl9xZO34mjCHfN6jQDYulwDbsk7IikRO4kn4cqPiaLkSX+8gXv/NsNqLXttK0x5Yt95Q25rXUMKYw/wkDxArD8k+wI71c41iTHyId1ZkHnUNmS9qxS2ajEhOCTYhB5xYYgeUscGwn6iiz5Ksjru28UnL/JZUZ3BHxm62XEHL6Yr9Bz/yzCKatm7+55eH0BMtiWFADtKEKz1nUGR8EUEIuchfQRZzXhmJmk+LNh+ft/BKcAjWKjz7LxncDH0fPqtRBYdB9dxziGozviYi20kVLzDdsOsnVL5lF9km1JtpyMyAHb7fbNA5xsCSge0rRL6+K5g4iX9QcCiTf12HjurHpFOktopItGtF60yyfbK2itBDlYiQxBSU75mvvllBxQ3gk47WCNrhuut/Uyyc8tjLmPdTIfc0+Mjz4owh3hfgNpJTO22jwo7CDtn/2bPe24aRpcrzldlMMi4jLLP58znCxabJFwAe9YrxavqGr9qcS1lBaGCrLc98vTix4eJFQQOazwJIFrDUDeeyuTo/ebAZ3nVQyRBTBDCfr1w06/OVAF9QLuxp2wFtuiVdw/DHZ93OwyCN/wDIC8yH/zJuLPKRD5PyBrQ14KLY/iLHw8scWcebvRvTrCc3SZkdXqhIySArXb+17Qzw== js@snabbis.local
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVvB4gdJ6EWRmx8xUSxrhoUNnWxEf8ZwAqhzC1+7XBY/hSd/cbEotLB9gxgqt0CLW56VU4FPLTw8snD8tgsyZN6KH1Da7UXno8oMk8tJdwLQM0Ggx3aWuztItkDfBc3Lfvq5T07YfphqJO7rcSGbS4QQdflXuOM9JLi6NStVao0ia4aE6Tj68pVVb3++XYvqvbU6NtEICvkTxEY93YpnRSfeAi64hsbaqSTN4kpeltzoSD1Rikz2aQFtFXE03ZC48HtGGhdMFA/Ade6KWBDaXxHGARVQ9/UccfhaR2XSjVxSZ8FBNOzNsH4k9cQIb2ndkEOXZXnjF5ZjdI4ZU0F+t7 leifj+00060AD478D6@sunet.se
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQVmVIptFt7ghSm5PpKw6uRQSEozHGKRN6AUyevyarfMuRONWvnFawTL/bqc6atX23dV6q0mIRzfUu+43ABjv5suwXaXoDw6rc6b8jElX/aJTDjea7n3i2hkhmGQwe8ibvjz2ZgNEkzz8NJSJI9nEzgPoHHM9/enpMb/saPWU/JFfPLAQ9XsQV+u1fhuTyrTlVynKN1iQxxCRjySD9boWo7XGQ8/0VBy28xS/eGDGs4Wty+SKT9QEabipyq7gqqsgoo87B1UUP98kawZF/wPMk5D+bWUej6dHaJEZECdAcalHlj7TCfJJM+ELHcQ8BD+4YzbkjTWPFG6ihI29bnV3z linus@nordberg.se
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfi07vngzbVdipBCSC+pDoauAck0nN45sV+u9A5vRLM9qwYIZm8XFlqJmKhmZMJWaY+rR4VCZKD8F8/Tmw26Q2kOG4tAajA2kZV+2Us0nXHE8YktKoLqojjSxMi73LT/CtAjbxNZNs6hAVKgIDqFyY7pJhrpNkVxQGMHB/MboVTqS1X3Jglm8J9T5/kNNU6brjErFCxQIOnLFJHczdcLMio31wK37jXZUWvbp8dXJrjNINU1r953hBibkZ178LODsitojXWsBckJZPxc43of7caGROesbIZQeGi/BKnxOgKWXresgeZngw8+hb5bQemI+ktbCQg3Exna7EHi6TGCLV paul@Darkstar-VirtualBox
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9+qRUZdFK9Fcweb3Zemice+QFDmqn0uXfjnB9xjIGXlzV7mi7mcDIMwRdL8es4CbNzx7gk8qbxl+bzSWlGrW8mE2smXicvb5aXAl1Gq7A1tmwb9j7Pb3/AUA0fonh086AjH/olVDHEXfE6fA+auMeW7NcYEAY4YBn9yrQSmvS4i3RcZtAETe+aCO/Cjl147DIeqH9hcSbBdEWdcH5Q0DIPYY1QnOlZAdphXDm3Kvr9poSX+2W6Zm8tRYJAATXh+gCFYWF2xig40k/5C0/jX48muuJ+gemav07PiOs6gwrvc2hJvhdHm5+3FoE2MaqPm7xZvEg0maLEvGSvydw0MQ9 paul@psgd.org
+ssh-dss AAAAB3NzaC1kc3MAAACBAMcyFrmcI06jwD2IEA5lvqNM84mr05eMIARy+JQ9f++tix9eMk5Y7b9Dmau3iYNG7WAEUtzEhj+ZO1QSMNqDX+TARAkesWHhRtNp5aTSpTrnyb7W74x7Wdjd0Zw6iQyYjzv8qYdcg3siN/POE6traHqzratuSrN9euEjXSq6lmutAAAAFQCo1RS1pRSCgmkTogCNHEqCnHDOOwAAAIEAg0XcJyRT3Er5oanfdQQT69mXfrGkcqGaahJchbIkVX9MDlFLmrAw8Av/77Plesq6uOgQuP1/tgJKN3gjW+n25S4Ly5L6P+vo8JH22+gSDWKdfjbf44xDRdorG19vbOrjynrZ/qZIS9UAdjT0aWiCkyRjhcqFpv3EvqXaqP/wpewAAACBAIu6JsMU53WWWDDVGtFVTKPkx1S0MF69xIOrVVbka88DzHsRg9qLqHlH/7TjVYv8Dzp4SBp1sf70JQhFgA0cPbQB7VcGX9rlJdvSqE2d695iSkJY8X08UrcSasjHbThtbjy1dsVXxiUV0Vt7rFYKaxlk4GJz83p8e7KorTiJMTu/ randy@psg.com
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCkrrpUCqIibbYB7v4Kr/B07yTGXJgMjAsFf+YHIC9WpcLvpe5v4+O8t4Q/WSMVETlkUZHIKVntHeLYLHIQVyL2njuM+MYShslz8lpc0Z/cIInpHSAM/rm9p/6MaKzAz8RODYe9Oxah34bNI7lXLUkNOBsUTRaKUA6jav/kfbPA/Y3ADIo8Hj1HcNfTxw6E+lmFAf3BkdzyvAmTGLIuv9BbD737B25BIERs5U0EltsdDvNPa3gMLyDt/slslu16WzBRE4tijf0Kbl7DyTeBKSi1EAaQe75N8cHgRSJe96ikkNqTy65vcKw41HTCoLzgJA/EuzwWgSvo96pK0uCM27R0+zlg1zp3Z6UQXDhKukmVYP72AF6Csk9BSkb3vURgMAwYDZQUKmzdd+YzE9sdmFa4fwYZmdHs+cC1XcU6uNbo3202yP/E5NiZ9wN8+fKqNpXVePUYPc8ACOYLBO3hjfvtwmXRM1rIcBgm5NbWotlCTmf6c2mfh+4tDtStSNGSf7a3bq9rHIS1GLDH0FNaWkjB+CKY5KnXF4vvMDqauDORt0pTH5OHsVsCgJjemwR0qHK6O7LxcSg8gzNvA5y4N/Pf6tcvoSNLbJoIF+XQ7oRhOYNPiR2gBziQ3paEMLsl57ewGOAvwT+O26wys1tmwcPr0FQHUnIzv+ecDY3oCw9fRw== sra@hactrn.net
+}}}
\ No newline at end of file diff --git a/tracwiki/ProjectArchive.trac b/tracwiki/ProjectArchive.trac new file mode 100644 index 0000000..1485c9b --- /dev/null +++ b/tracwiki/ProjectArchive.trac @@ -0,0 +1,4 @@ +''Page Under Construction''
+
+= Project Archive and Far Future Planning =
+== [wiki:AssuredTooChain Assured Tool Chain]
\ No newline at end of file diff --git a/tracwiki/ProjectManagement.trac b/tracwiki/ProjectManagement.trac new file mode 100644 index 0000000..b5646a0 --- /dev/null +++ b/tracwiki/ProjectManagement.trac @@ -0,0 +1,21 @@ +[[PageOutline]]
+
+= v0.1 Resources =
+
+== Human - 4-5 FTE ==
+* 0.5 Specifications
+* 1.0 FPGA Tools and Core
+* 1.0 Core Libraries and Interfaces
+* 0.5 QA & Docs
+* 0.5 Assured Linux Platform
+* 1.0 Coordination
+
+== Hardware ==
+* 4 Bunnie Boards
+* 2 Altera Eval Systems
+* Linux Platform
+
+== Travel & Overhead ==
+* Travel $5k/mo
+* Communications $1k/mo
+* Administrative $1k/mo
diff --git a/tracwiki/ProjectMetadata.trac b/tracwiki/ProjectMetadata.trac new file mode 100644 index 0000000..1c7712c --- /dev/null +++ b/tracwiki/ProjectMetadata.trac @@ -0,0 +1,20 @@ +
+= Project Metadata =
+
+== Project Logo Files ==
+* See "Attachments" at the bottom of this page
+* PhotoFolder
+
+== Meeting Presentations and Notes ==
+* DocMeet
+* PrahaWorkshop
+* BerlinWorkshop
+
+== Technical References ==
+* MiscStuff
+* InterconnectStandards
+* RandomnessTesting
+
+== Related Work ==
+* RelatedWork
+* SideChannel
\ No newline at end of file diff --git a/tracwiki/ProjectStatus.trac b/tracwiki/ProjectStatus.trac new file mode 100644 index 0000000..a2e5118 --- /dev/null +++ b/tracwiki/ProjectStatus.trac @@ -0,0 +1,16 @@ +''Page Under Development''
+
+= Project Status =
+
+== [wiki:Dashboard Project Dashboard] ==
+
+== Crypto Chip Design and Prototype ==
+* PostAlphaPlan
+* AlphaBoardStrategy
+* AlphaBoardComponents
+* [http://trac.cryptech.is/wiki/GitRepositories/core Core Git Repository]
+* [wiki:Hardware]
+* [wiki:DevBridgeBoard]
+
+== Pilot Project ==
+* [wiki:DNSSEC Requirements]
\ No newline at end of file diff --git a/tracwiki/QuickStart.trac b/tracwiki/QuickStart.trac new file mode 100644 index 0000000..e2bb94e --- /dev/null +++ b/tracwiki/QuickStart.trac @@ -0,0 +1,23 @@ +[[PageOutline]]
+''Page Under Development''
+
+= Git Repositories =
+The team uses Git to store and track project development. All submissions are [https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work signed].
+
+The active repositories are automatically posted to GitRepositories.
+
+
+= The Alpha Board =
+
+The current hardware is the AlphaBoard. More information (to be organized at some point -- yes, this wiki is a mess, again):
+* AlphaBoardComponents
+* AlphaBoardPictures
+* AlphaBoardReview
+* AlphaBoardStrategy
+* AlphaReviewLog
+* AlphaSchematics
+
+The Alpha board currently ships with very old firmware, but you can [wiki:Upgrading upgrade it yourself].
+
+= DNSSEC signing using OpenDNSSEC
+* [[OpenDNSSEC]]
diff --git a/tracwiki/RandomnessTesting.trac b/tracwiki/RandomnessTesting.trac new file mode 100644 index 0000000..4ec3acf --- /dev/null +++ b/tracwiki/RandomnessTesting.trac @@ -0,0 +1,76 @@ += Randomness Testing Tools =
+
+This page explains some basics on testing for randomness, and the background necessary to understand their outputs.
+
+== Basic Considerations ==
+When testing the randomness of an alleged/assumed random bit/byte stream, there are two fundamentally different categories of tests: There are ''blackbox'' tests which are independent of the particular source, and ''whitebox'' tests tailored to the particular properties of the given source.
+
+For reasons rather unsurprising, the ''blackbox'' and ''whitebox'' categories largely correlate with the categories ''publicly available tests from others'' and ''tests developed by the designers of the particular stream source''; this obviously leads to other issues concerning the trustworthiness and reliability of the tests---testing your own stuff is always a somewhat risky approach.
+
+All tests basically work by taking a certain part of the data space, declaring them as "not random" or possibly "suspect", and then comparing some test input against this partitioning. Mathematically speaking, all the possible partitionings are equally relevant and as such any stream is equally "random" or "non-random", so choosing any partitioning definition is somewhat arbitrary.
+
+The usual ''blackbox'' tests are effectively based on tests used for non-crypto pseudo random number generators; as such, they are generally useful for quick, preliminary testing and for establishing confidence in the source by outsiders. But to test the health of a source, eventually whitebox tests tailored to the failure modes of the given source are needed.
+
+
+== The `dieharder` Test Suite ==
+Dieharder is by far the most extensive blackbox test suite. However, it is originally aimed at testing the output of non-crypto pseudo random number generators; aside from the limitations of using it for an entirely different purpose, it is rather notorious with regard to its need for extensive amounts of input. Additionally, it runs all tests sequentially, rather than making use of today's multi-core multi-threaded CPU architectures; this leads to unnecessary I/O while reading an input file that doesn't fit the disk cache, and runtimes of about an hour or so depending on the sort of computer used.
+
+=== Usage ===
+Generally the best approach to use `dieharder` is to first generate an output file, e.g. `random.out` to run the tests on, so `dieharder` can apply all its individual tests to the same data. For a standard test, at least about 14 GB worth of data are needed; more if one of the tests needing large amounts of data returns a suspect result and `dieharder` re-tries the same test with more data.
+
+The command line options I (bs) personally use are `dieharder -g 201 -f random.out -s 1 -Y 1 -k 2 -a`:
+ -g 201 -f random.out:: Don't use a compiled-in pseudo RNG but the file `random.out` as input.
+ -s 1:: Rewind the input after every test. Without this, successive tests use successive parts of the input file.
+ -Y 1:: Keep testing until a definite (in probabilistic terms:-) test result is obtained.
+ -k 2:: Use some high precision numerics for the KS test; recommended by the man page.
+ -a:: Run all tests.
+
+Additionally, these may be useful for more targeted testing:
+ -m <n>:: Multiply the `psamples` value by `n`; good for getting even more reliable results, at the expense of the additional data needed.
+ -d <test name/number>:: Perform a specific test.
+ -l:: List all available tests by name and number.
+ -p <n>:: Set the `psamples` value. See below why you may need this.
+
+=== Interpretation of Results ===
+The way `dieharder` works, it simply returns a clear assessment of the test results; interpretation should be immediately obvious.
+
+=== Caveats ===
+There are a number of things to keep in mind when using `dieharder`, especially so when running it on a reduced amount of test data.
+ * If `dieharder` reaches the end of the input file, it rewinds and uses the same test data again. This has rather drastic effects on several tests which assume that some sort of repetition in the input is a sign for a seriously flawed generator.
+ * The `-Y 1` option works by adding 100 to the value of `psamples` until a conclusive result is found. This works reasonably well with tests that start with a value of 100 to `psamples`, but there are tests starting with 1000, and others starting with 1.
+ * The `-m <n>` option also just affects the initial value of `psamples`.
+ * Some of the tests themselves are marked as "suspect" or "do not use" if you run `dieharder -l`. Still, `-a` runs them, for whatever reason.
+ * Expect about one test in a `-a` run to return a "weak" result that needs to be resolved. According to the man page, about 1 in 1000 tests (not `-a` runs!) may fail despite the fact that the input is good. In that case I suggest doubling the input size, either by using `-m <n>` (which only works in conjunction with `-a`) or by adjusting `psamples` and/or `tsamples` manually.
+
+=== Installation ===
+The [http://www.phy.duke.edu/~rgb/General/dieharder.php "Dieharder home page"] provides the source code as well as documentation. Dieharder is also available via package systems in Linux (apt-get install dieharder) and by brew for OSX.
+
+
+== The FIPS140-2 Test Suite `rngtest` from `rng-tools` ==
+While somewhat questionable in the way it has been defined in the FIPS140-2 document (and silently been removed in the -3 draft...), these tests are generally considered useful for a quick preliminary test on small amounts of test data.
+They generally work on blocks of 20000 bits.
+
+=== Usage ===
+The `rngtest` program reads data from its standard input and by default returns a statistics overview when it reaches EOF. This can be changed with these two options (among others):
+ -c <n>:: Stop running after `n` blocks.
+ -b <n>:: Give intermediate results every `n` blocks.
+Use at least one of these when running on a pipe or device...
+
+=== Interpretation of Results ===
+Since `rngtest` works on rather small sample sizes it causes a significant number of false alarms:
+||= Test =||= Expected failure rate =||
+|| Total || 800ppm ||
+|| Monobit || 100ppm ||
+|| Poker || 100ppm ||
+|| Runs || 300ppm ||
+|| Long run || 300ppm ||
+|| Continuous run || Extremely rare ||
+These failure rates were however measured experimentally rather than derived from the algorithms themselves, so caveat utilitor.
+
+Seriously flawed inputs often show excessive failures from very small input; it is generally a good idea to keep testing until at least about 100 failures in total have occurred before seriously comparing the measured results to the expected failure rates from the table.
+
+
+
+
+
+
diff --git a/tracwiki/RelatedWork.trac b/tracwiki/RelatedWork.trac new file mode 100644 index 0000000..356f45e --- /dev/null +++ b/tracwiki/RelatedWork.trac @@ -0,0 +1,20 @@ += Related Work =
+
+== Richard Lamb / ICANN ==
+[http://ccnso.icann.org/file/32383/download/37379 Presentation at ICANN]\\
+[http://ccnso.icann.org/file/40211/download/52359 Presentation at ICANN]\\
+"I wrote pkcs11 libraries and also have modified BIND that offloads full
+RRSIG calculation (including time) to board. Clearly can use anything
+other than TPM to do RSA calculations."
+
+== SoftHSM ==
+- [https://www.opendnssec.org/softhsm/ "SoftHSM"] - part of OpenDNSSEC
+- [http://wiki.cacert.org/Possum "Possum"] - an earlier attempt att an Open Source HSM.
+
+
+== Project Turris - CZNIC ==
+[http://www.turris.cz/en/ Project Thuris Web Pages]\\
+Project Turris is a service helping to protect its user's home network
+with the help of a special router. It is a not-for-profit research
+project of CZ.NIC, z. s. p. o., the registry of the Czech national top
+level domain .CZ.
diff --git a/tracwiki/ReleaseNotes.trac b/tracwiki/ReleaseNotes.trac new file mode 100644 index 0000000..5cb9210 --- /dev/null +++ b/tracwiki/ReleaseNotes.trac @@ -0,0 +1,28 @@ +[[PageOutline]]
+
+= Release Notes =
+
+== 3.0, May 2017 ==
+
+* New keystore implementation. Basically a very small flash filesystem, including basic wear leveling. Maximum number of keys varies depending on key size and how many options are attached, but for any reasonable use it should hold on the order of 2,000 keys at least.
+* In-memory keystore moved to HSM (previously was in memory of the client library), uses same API as flash keystore.
+* RPC mechanism extended to support the new keystores (`hal_rpc_pkey_match()`, `hal_rpc_pkey_set_attributes()`, etc).
+* PKCS !#11 code rewritten to use libhal attribute mechanism, sqlite3 database gone.
+* Verilog implementations of ECDSA base point multipliers for P-256 and P-384 curves, key generation and signing significantly faster than with software ECDSA implementation.
+* Key backup mechanism: two more RPC functions, and a Python script `cryptech_backup` to drive the process.
+* Private key representation changed to PKCS !#8 format (a self-identifying uniform format with optional encryption, supported by many other tools). Key backup uses encrypted form of PKCS !#8.
+* Default build of client software now uses a multiplexer daemon `cryptech_muxd` which allows multiple clients to talk to the HSM at once (packages such as !OpenDNSSEC which uses multiple daemons talking to the same HSM need this). Software can still be built for direct connection to HSM but it is no longer the default.
+* New trivial script `cryptech_console` to talk to the HSM's management port via the multiplexer daemon; `cryptech_upload` now supports both direct connection and connection via the multiplexer daemon.
+* Python client implementations of libhal RPC mechanism and PKCS !#11 now installed as `cryptech.libhal` and `cryptech.py11`, respectively.
+* Python PKCS !#11 client hacked to play nicely with `pkcs11-spy` debugging tool.
+* RTOS replaced by simple non-preemptive (voluntary yield) tasking system, eliminating a huge morass of potential race conditions, debugging nightmares, priority inversions, and similar horrors. Lack of preemption means that console acess may have to wait for something else to yield the ARM CPU, but it's more than worth it to get rid of all the stability problems the RTOS was causing.
+* [source:/user/sra/openssl-engine Sample code for using the HSM as an OpenSSL engine] is available. This only works with RSA for the moment, due to apparent limitations of the engine implementation.
+
+Getting started with 3.0:
+
+* [wiki:BinaryPackages Install the software].
+* [wiki:Upgrading Upgrade the firmware]. **Please note the warnings about bricking your HSM**, how to avoid that, and what to do if you failed to avoid it.
+* Set the usual environment variables, perhaps using `cryptech_probe`.
+* Start the multiplexer daemon `cryptech_muxd`.
+
+At this point, you should be able to use the PKCS !#11 library, the `cryptech_backup` script, and so forth.
\ No newline at end of file diff --git a/tracwiki/Requirements.trac b/tracwiki/Requirements.trac new file mode 100644 index 0000000..50c54b0 --- /dev/null +++ b/tracwiki/Requirements.trac @@ -0,0 +1,136 @@ += HSM Requirements
+
+Requirements for the Cryptech Alpha System. Derived from Use Cases (see below). There are also utility, internal requirements (again, see below).
+
+== Capacity
+=== Per key storage requirements
+In addition to the actual key data, each key requires
+- Key type – 4 bytes
+- Key identifier – 4 bytes
+- Key flags, e.g. exportable – 8 bytes
+This results a total 16 bytes overhead for each key.
+
+=== Examples per algorithm
+(For RSA, we might also want to include the primes p and q might also be included which requires additional storage.)
+
+- RSA-8192 requires 1024 bytes secret key, 1024 bytes public key + 4 bytes exponent + 16 bytes overhead = 2068 bytes
+- RSA-4096 requires 512 bytes secret key, 512 bytes public key + 4 bytes exponent + 16 bytes overhead = 1044 bytes
+- RSA-2048 requires 256 bytes secret key, 256 bytes public key + 4 bytes exponent + 16 bytes overhead = 532 bytes
+- EC P-256 requires 32 bytes secret key, 64 bytes public key + 16 bytes overhead = 112 bytes
+- EC P-384 requires 48 bytes secret key, 96 bytes public key + 16 bytes overhead = 160 bytes
+- Curve 25519 requires 32 bytes secret key, 32 bytes public key + 16 bytes overhead = 80 bytes
+
+
+== Use Cases
+=== DNSSEC
+==== Number of keys
+- TLD (or provider using key sharing) requires ~ 100 key pairs
+- 3 KSK per zone (previous, current, new)
+- 3 ZSK per zone (previous, current, new)
+==== Possibly dual algorithms
+- A typical TLD operator usually has less than 10 TLDs
+- Other DNS providers may use key sharing to limit number of keys required
+==== Algorithms
+- RSA-1024/SHA-256
+- RSA-2048/SHA-256
+- EC-P256/SHA-256
+==== Performance
+Each update to a zone requires 3-4 signatures (per algorithm)
+- Resign SOA (signed by ZSK)
+- Resign updated RR (signed by ZSK)
+- Resign NSEC/NSEC3 (signed by ZSK), may require multiple signatures
+Non-interactive latency (batch), dynamic updates may require faster signing
+
+=== SAML
+==== Number of keys
+SAML federation operator requires max 10 key pairs (including space for roll)
+==== Algorithms
+- RSA-2048/SHA-256
+==== Performance
+- Non-interactive latency (batch)
+ - non-MDX: …
+- Interactive latency
+ - MDX: …
+
+=== PKIX (including RPKI)
+==== Number of keys
+- Typical Certification Authority ~ 10 key pairs
+ - CA key, OCSP, CRL per level in the CA
+ - Root CA is one level
+ - For subordinate CAs, perhaps 2-5 CAs in a HSM is reasonable?
+==== Algorithms
+- RSA-2048/SHA-256
+- RSA-4096/SHA-256
+- RSA-4096/SHA-512 ?
+- EC-P256/SHA-256
+==== Performance
+- Non-interactive latency
+ - Root CA: Less than 1 signature per day
+ - Issuing CA: One signature per issued certificate
+ - CRL: Less than 1 signature per hour
+- Interactive latency
+ - OCSP: Multiple signatures per second
+
+=== Tor
+Requirements according to (section 1): https://gitweb.torproject.org/torspec.git/plain/dir-spec.txt
+==== Number of keys
+- 1 private key
+- 10 public keys
+==== Algorithms
+- RSA-2048/SHA-1 ?
+- RSA-2048/SHA-256
+- RSA-4096/SHA-256 ?
+- RSA-4096/SHA-512 ?
+==== Performance
+- 2 signatures per hour
+- 20 verification operations per hour
+- 1 second max latency for RSA-2048 based verification
+
+=== Certificate Transparency (CT)
+==== Number of keys
+CT requires 1 key (ECDSA or RSA) per log
+==== Algorithms
+- RSA-2048/SHA-256
+- RSA-4096/SHA-256 ?
+- RSA-4096/SHA-512 ?
+- EC-P256/SHA-256
+==== Performance
+- A Certificate Transparency log uses one ECDSA or one RSA key to sign two separate documents:
+- STH's might need to be signed once per hour
+- SCT's might need to be signed once per second (*)
+
+See RFC 6962, section 2.1.4 – https://tools.ietf.org/html/rfc6962
+
+
+== Internal Functional Requirements
+
+=== Algorithms and functions
+- Key wrapping using AES-256 with SIV, http://tools.ietf.org/html/rfc5297
+- Internal Storage Master Key (ISMK) in battery backed RAM connected to FPGA
+ - Battery connection controlled by tamper mechanism
+ - Active erasure controlled by tamper mechanism
+- 32-bit high quality random number generation
+
+=== PKCS11
+
+The following PKCS11 mechanisms are required to fulfill the aforementioned use cases:
+
+- RSA
+ - CKM_RSA_PKCS_KEY_PAIR_GEN
+ - CKM_RSA_PKCS
+ - CKM_RSA_X_509 ?
+ - CKM_SHA256_RSA_PKCS
+ - CKM_SHA512_RSA_PKCS ?
+- ECDSA
+ - CKM_EC_KEY_PAIR_GEN
+ - CKM_ECDSA
+- AES
+ - … TBD …
+- Random
+ - … TBD …
+- Key Wrapping
+ - … TBD …
+- Hash
+ - CKM_SHA256
+ - CKM_SHA512 (?)
+
diff --git a/tracwiki/RoughV1.trac b/tracwiki/RoughV1.trac new file mode 100644 index 0000000..a142056 --- /dev/null +++ b/tracwiki/RoughV1.trac @@ -0,0 +1,112 @@ += Rough Cut at v0.01 Proof of Concept Feature Set =
+
+[[PageOutline]]
+
+This is a proposed version 0.01 product as a proof of concept. The
+intent is not to have a very useful product, but rather to gain
+confidence in our architecture, tools, and team. The result is intended
+to be the basis for further development into a more useful second stage,
+in the sense of
+[https://en.wikipedia.org/wiki/Agile_software_development agile development].
+It very intentionally is not a
+[https://en.wikipedia.org/wiki/Waterfall_model waterfall design],
+
+The interface between the Green and Yellow layers is seen as an important design
+inflection.
+
+Some code will be in C in the Green (auxiliary core) because we can get it open
+source out of the can. for v.2 (or whatever) we would move it down to the FPGA in
+Verilog.
+
+== FPGA Overview ==
+[[Image(HW_sketch_v0001.png)]]
+\\
+\\
+== Sketch of TRNG Chain ==
+[[Image(HW_RNG.png)]]
+\\
+\\
+
+== Off-FPGA ==
+* Persistent Storage
+ * For Keys and Time
+ * Or the battery for tamper wipe is big enough to hold the FPGA up
+ * Or the Green processor has enough non-volatile store
+* Entropy Source
+* Realtime Clock
+* Tamper Mechanism
+
+== Layers ==
+
+{{{
+#!html
+<h1 style="text-align: left; color: blue">
+ Blue / FPGA
+</h1>
+}}}
+
+* TRNG
+* !BigNumber, Modular, & Exponentiation (expose to green for RSA)
+* SHA-256
+* AES-128
+* EC for ECDH. Curve3617 would be nice, but whatever we can get open source to start
+* OpenRISC Core or ARM to support Green (maybe !FreeScale from Bunnie)
+
+{{{
+#!html
+<h1 style="text-align: left; color: green">
+ Green / On-Chip Core
+</h1>
+}}}
+
+* RSA 2048 & 4096 (move to blue later) [ 1024 for Tor? ]
+* MACs: HMAC, 1305, uMAC
+* DH (move to blue later)
+* Device Activation, Move Authorization, Wiping
+
+{{{
+#!html
+<h1 style="text-align: left; color: yellow">
+ Yellow / Off-Chip Support
+</h1>
+}}}
+
+* Interface to Red
+ * PKCS!#8
+ * PKCS!#11
+ * PGP Support
+* X.509 and PGP
+* PKCS!#11 for POLA resistance
+* No PKCS!#10 because it will take a year
+* Backup may be just dump/restore of the whole FPGA/!CoreState
+
+{{{
+#!html
+<h1 style="text-align: left; color: red">
+ Red / Applications
+</h1>
+}}}
+
+* X.509 CA
+* DNSSEC
+* PGP (asymmetric key sign/verify + symmetric message encryption/decryption)
+* Tor consensus(?)
+
+== Issues in v0.01 ==
+
+* License of tool chain to build
+* License for borrowed components (open cores, open fpga)
+* License for result
+ * What we build ourselves - BSD
+ * What components we ship - life is compromise
+* Toolchains, Verilog, C, ...
+* FPGAs and ASICs use a Verilog-based toolchain. There are no mature open
+ Verilog compilers so the [http://www.dwheeler.com/trusting-trust/ DDC approach]
+ will not work. Net-list optimization is also an issue. We're looking into this,
+ but it's going to be really hard. Research for v2.
+* Protoyping platform
+ * [http://www.bunniestudios.com/blog/?p=3265 Bunnie's Novena laptop]
+ * Altera Evaluation Board
+* RTC, external connectivity to et some sort of assured time
+* Repository - too many git junkies. Keep main repo on our server for the security boundary. Can mirror on !GitHub to be socially cool.
+* Emacs or vi (no Rob, not TECO) :)
diff --git a/tracwiki/SecureChannel.trac b/tracwiki/SecureChannel.trac new file mode 100644 index 0000000..0541a32 --- /dev/null +++ b/tracwiki/SecureChannel.trac @@ -0,0 +1,155 @@ += Secure Channel
+
+This is a sketch of a design for the secure channel that we want to
+have between the Cryptech HSM and the client libraries which talk to
+it. Work in progress, and not implemented yet because a few of the
+pieces are still missing.
+
+== Design goals and constraints
+
+Basic design goals:
+
+* End-to-end between client library and HSM.
+
+* Not require yet another presentation layer if we can avoid it (so,
+ reuse XDR if possible, unless we have some strong desire to switch
+ to something else).
+
+* Provide end-to-end message integrity between client library and HSM.
+
+* Provide end-to-end message confidentiality between client library
+ and HSM. We only need this for a few operations, but between PINs
+ and private keys it would be simpler just to provide it all the time
+ than to be selective.
+
+* Provide some form of mutual authentication between client library
+ and HSM. This is tricky, since it requires either configuration (of
+ the other party's authenticator) or leap-of-faith. Leap-of-faith is
+ probably good enough for most of what we really care about (insuring
+ that we're talking to the same dog now as we were earlier).
+
+ Not 100% certain we need this at all, but if we're going to leave
+ ourselves wide open to monkey-in-the-middle attacks, there's not
+ much point in having a secure channel at all.
+
+* Use boring simple crypto that we already have (or almost have) and
+ which runs fast.
+
+* Continue to support multiplexer. Taken together with end-to-end
+ message confidentiality, this may mean two layers of headers: an
+ outer set which the multiplexer is allowed to mutate, then an inner
+ set which is protected. Better, though, would be if the multiplexer
+ can work just by reading the outer headers without modifying
+ anything.
+
+* Simple enough that we can implement it easily in HSM, PKCS #11
+ library, and Python library.
+
+== Why not TLS?
+
+We could, of course, Just Use TLS. Might end up doing that, if it
+turns out to be easier, but TLS is a complicated beast, with far more
+options than we need, and doesn't provide all of what we want, so a
+fair amount of the effort would be, not wasted exactly, but a giant
+step sideways. Absent sane alternatives, I'd just suck it up and do
+this, with a greatly restricted ciphersuite, but I think we have a
+better option.
+
+== Design
+
+Basic design lifted from "Cryptography Engineering: Design Principles
+and Practical Applications" (ISBN 978-0-470-47424-2,
+http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470474246.html),
+tweaked in places to fit tools we have readily available.
+
+Toolkit:
+
+* AES
+* SHA-2
+* ECDH
+* ECDSA
+* XDR
+
+As in the book, there are two layers here: the basic secure channel,
+moving encrypted-and-authenticated frames back and forth, and a higher
+level which handles setup, key agreement, and endpoint authentication.
+
+Chapter 7 outlines a simple lower layer using AES-CTR and
+HMAC-SHA-256. I don't see any particular reason to change any of
+this, AES-CTR is easy enough. I suppose it might be worth looking
+into AES-CCM and AES-GCM, but they're somewhat more complicated;
+section 7.5 ("Alternatives") discusses these briefly, we also know
+some of the authors.
+
+For key agreement we probably want to use ECDH. We don't quite have
+that yet, but in theory it's relatively minor work to generalize our
+existing ECDSA code to cover that too, and, again in theory, it should
+be possible to generalize our existing ECDSA fast base point multiplier
+Verilog cores into fast point multiplier cores (sic: limitation of the
+current cores is that they only compute scalar times the base point,
+not scalar times an arbitrary point, which is fine for ECDSA but
+doesn't work for ECDH).
+
+For signature (mutual authentication) we probably want to use ECDSA,
+again because we have it and it's fast. The more interesting question
+is the configuration vs leap-of-faith discussion, figuring out under
+which circumstances we really care about the peer's identity, and
+figuring out how to store state.
+
+Chapter 14 (key negotiation) of the same book covers the rest of the
+protocol, substituting ECDH and ECDSA for DH and RSA, respectively.
+As noted in the text, we could use a shared secret key and a MAC
+function instead of public key based authentication.
+
+Alternatively, the Station-to-Station protocol described in 4.6.1 of
+"Guide to Elliptic Curve Cryptography" (ISBN 978-0-387-95273-4,
+https://link.springer.com/book/10.1007/b97644) appears to do what
+we want, straight out of the box.
+
+Interaction with multiplexer is slightly interesting. The multiplexer
+really only cares about one thing: being able to match responses from
+the HSM to queries sent into the HSM, so that the multiplexer can send
+the responses back to the right client. At the moment, it does this
+by seizing control of the client_handle field in the RPC frame, which
+it can get away with doing because there's no end-to-end integrity
+check at all (yuck). We could add an outer layer of headers for the
+multiplexer, but would rather not.
+
+The obvious "real" identity for clients to use would be the public
+keys (ECDSA in the above discussion) they use to authenticate to the
+HSM, or a hash (perhaps truncated) thereof. That's good as far as it
+goes, and may suffice if we can assume that clients always have unique
+keys, but if client keys are something over which the client has any
+control (which includes selecting where they're stored, which we may
+not be able to avoid), we have to consider the possibility of multiple
+clients using the same key (yuck). So a candidate replacement for the
+client_handle for multiplexer purposes would be some combination of a
+public key hash and a process ID, both things the client could provide
+without the multiplexer needing to do anything.
+
+The one argument in favor of leaving control of this to the
+multiplexer (rather than the endpoints) is that it would (sort of)
+protect against one client trying to masquerade as another -- but
+that's really just another reason why clients should have their own
+keys to the extent possible.
+
+As a precaution, perhaps the multiplexer should check for duplicate
+identifiers, then do, um, something? if it finds duplicates. This
+kind of violates Steinbach's Guideline for Systems Programming ("Never
+test for an error condition you don't know how to handle"). Obvious
+answer is to break all connections old and new using the duplicate
+identity, minor questions about how to reset from that, whether worth
+doing at all, etc. Maybe clients just shouldn't do that.
+
+== Open issues
+
+* Does the resulting design pass examination by clueful people?
+
+* Does this end up still being significantly simpler than TLS?
+
+* The Cryptography Engineering protocols include a hack to work around
+ a length extension weakness in SHA-2 (see section 5.4.2). Do we
+ need this? Would we be better off using SHA-3 instead? The book
+ claims that SHA-3 was expected to fix this, but that was before NIST
+ pissed away their reputation by getting too cosy with the NSA again.
+ Over my head, ask somebody with more clue.
diff --git a/tracwiki/SideChannel.trac b/tracwiki/SideChannel.trac new file mode 100644 index 0000000..bfeb2b5 --- /dev/null +++ b/tracwiki/SideChannel.trac @@ -0,0 +1,7 @@ +
+= Side Channel Attacks =
+
+Side Channel attacks on hardware are hard to avoid, detect and mitigate. But this should not stop us from trying. The CrypTech platform should be developed with side channel issues in mind. This page tries to collect information about relevant side channel attacks, mitigation strategies, side channel resistant design methods (blinding for example) and detection.
+
+* http://eprint.iacr.org/2013/579 "On Measurable Side-Channel Leaks inside ASIC Design Primitives"
+* http://people.umass.edu/gbecker/BeckerChes13.pdf "Stealthy Dopant-Level Hardware Trojans"
\ No newline at end of file diff --git a/tracwiki/StateOfPlay.trac b/tracwiki/StateOfPlay.trac new file mode 100644 index 0000000..f4178a2 --- /dev/null +++ b/tracwiki/StateOfPlay.trac @@ -0,0 +1,148 @@ +[[PageOutline]]
+
+= A Completely Informal Snapshot Of The Current State Of The Cryptech Project As Of 2014-11-06 =
+
+This page contains a snapshot of the status in the project and will almost certainly be obsolete by the time you read it. If you find something that's wrong, please fix it!
+
+
+== Cores ==
+We have a bunch of cores, primarily for FPGA implementation. Some of them implement cryptographic
+algorithms or critical functionality like the TRNG. Other cores are support cores for implementation of the Cryptech HSM. Other cores are for developing the cores and the HW. Finally some are just test
+code.
+
+Cores that have been promoted to official cryptech HW cores:
+
+* `core/chacha` - The !ChaCha stream cipher
+* `core/sha1` - FIPS 180-2 SHA-1 hash
+* `core/sha256` - FIPS 180-4 SHA-256 hash
+* `core/sha512` - FIPS 180-4 SHA-512/x hash
+* `core/trng` - The Cryptech TRNG sub system. Uses !ChaCha, SHA-512 and entropy cores.
+* `core/avalanche_entropy` - Avalanche entropy provider core. Requires external avalanche noise source.
+* `core/rosc_entropy` - Digital ring oscillator based entropy provider core.
+
+Utility, test, board support:
+
+* `core/coretest` - Core for performing command/response operations to drive testing of a core.
+* `core/coretest_hashes` - Subsysem with coretest and the hash function cores as test objects.
+* `core/coretest_test_core` - Coretest with a simple test core
+* `core/i2c` - I2C interface core.
+* `core/novena`
+* `core/novena_eim`
+* `core/novena_i2c_simple`
+* `core/test_core`
+* `core/uart`- UART interface core to allow serial communication with FPGA functionality.
+* `core/vndecorrelator` - von Neumann decorrelation core.
+
+Documentation is very haphazard: some of the repositories have
+detailed README.md files, but in many cases the documentation, what
+there is of it, is probably meaningful only to the person who wrote
+it, not because of any lack of good intent, just because what's
+written assumes that the reader knows everything that the author does
+about the other cores, the rest of the environment, and how everything
+fits together.
+
+== Builds ==
+
+At this point I have figured out how to build two different FPGA
+images for the Novena PVT1. In both cases, I'm using the Makefile
+rather than attempting to use the XiLinx GUI environment.
+
+* `core/novena` builds the current set of digest cores into a
+ framework that uses the "coretest" byte stream protocol over an I2C
+ bus.
+
+* `core/novena_i2c_simple` builds the current set of digest cores into
+ a framework that uses a simplfied write()/read() API over an I2C bus.
+
+There's a third build, `core/novena_eim`, which was only just updated
+today, and which is reported as not quite stable yet. Will try
+building it soon and report here.
+
+Both working builds (and, almost certainly, any useful build) involve
+more than just the named repository. `verilator`, when asked nicely,
+will draw a graph of Verilog module relationships. Take this with
+salt, as I am a long way from getting `verilator` to run cleanly on
+any of this, but the current graphs may still be useful in visualizing
+what's happening here.
+
+At least some of the modules that `verilator` complains about not
+being able to find appear to come from !XiLinx libraries that
+`verilator` doesn't know about.
+See [[http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/spartan6_hdl.pdf|Spartan-6 Libraries Guide for HDL Designs]] for details.
+
+=== Module relationships in core/novena build ===
+
+[[Image(novena__linkcells.svg)]]
+
+=== Module relationships in core/novena_i2c_simple build ===
+
+[[Image(novena_i2c_simple__linkcells.svg)]]
+
+=== Module relationships in core/novena_eim build ===
+
+[[Image(novena_eim__linkcells.svg)]]
+
+=== Module relationships in cores/trng build ===
+
+By special request, here's a graph for the TRNG too, even though we
+don't yet have a way to speak to it from the Novena:
+
+[[Image(trng__linkcells.svg)]]
+
+== C Code ==
+
+Most of the cores have at least minimal test frameworks, written in a
+combination of Verilog, C, and Python, but there's also a preliminary
+port of Cryptlib to the Cryptech environment, in `sw/cryptlib`. As of
+this writing, the only Cryptech-specific features of this port, other
+than a few makefile tricks, are:
+
+* A set of HALs that make use of the `core/novena` and
+ `core/novena_i2c_simple` FPGA builds, using the Linux /dev/i2c
+ device interface; and
+
+* Another Python script to test the resulting Cryptlib build, using
+ the stock Cryptlib Python bindings.
+
+No HAL for `core/novena_eim` yet.
+
+The Cryptlib Python bindings build kind of slowly on the Novena, sorry
+about that.
+
+== Hardware ==
+
+The hardware guys have done cool stuff with hardware entropy sources.
+I even have one of the noise boards, but until I have some way to
+connect C code to the TRNG, I don't have much use for it other than to
+admire the craftsmanship. Soon, I hope.
+
+== Tools ==
+
+Already mentioned `verilator`. In addition to generating !GraphViz
+input, `verilator` has a `--lint` mode which looks interesting.
+
+(JS) Verilator is fairly usable, at least as a linter. Adding `-Wall` provides more warnings.
+Since we at least uses Icarus Verilog (iverilog), Altera Quartus and Xilinx ISE one would assume that they would provide all possible warnings. That is not the case. They all seem to fins different things to warn about. And Verilator provides even more. The more parsers and checkers the better. But we will not be able to, or want to fix all warnings. Some things are by design. We should probably document what we ignore.
+
+I haven't yet figured out whether we have any real use for
+`verilator`'s core function of synthesizing Verilog into C++. I've
+been toying with the idea of a software-only development environment,
+where one simulates an embedded machine using two Unix processes: one
+would be a virtual FPGA generated by `verilator`, the other would be a
+classical deeply embedded system running as a single process. The two
+processes would communicate via a `PF_UNIX` socket or something on
+that order. It might be possible to jam everything into a single
+process, but I suspect it wouldn't be worth the trouble.
+
+Joachim has Makefiles which use `iverilog` to generate simulation
+images. Installing `iverilog` is easy enough (`apt-get install`, etc)
+but I haven't yet figured out how to do anything interesting with the
+simulation images. Joachim replies:
+
+ There is help in the Makefile. You run the targets, either as
+ make sim-foo or just ./foo.sim. Most if not all tests are self
+ testing with test cases and should report number of test cases and
+ how many passed. Which should be all.
+
+As far as I know we've done nothing yet to deal with threats to the
+tool chain (Thompson attack, etc).
diff --git a/tracwiki/SunetInitialDevelopment.trac b/tracwiki/SunetInitialDevelopment.trac new file mode 100644 index 0000000..3626c33 --- /dev/null +++ b/tracwiki/SunetInitialDevelopment.trac @@ -0,0 +1,86 @@ += Planning for SUNET funded Cryptech Work =
+The following documents the first two development steps in Cryptech
+funded by SUNET. The development is being done by Joachim Strömbergson
+from Secworks AB.
+
+== Step one (Deadline 2014-02-28) ==
+ - Acquire a FPGA development platform.
+DONE. We have a Terasic DE0 board and a Terasic Cyclone V GX starter kit board.
+
+
+ - Create a working development and verification flow from RTL design
+ downto FPGA.
+
+ - Verify the functionality of the SHA-256 core in a physical FPGA.
+
+
+=== Actions for step one ===
+ - Select FPGA development board to acquire
+ - Large enough to test sub systems and possibly a complete HSM.
+ - Good external interfaces for communication with host systems.
+ - Good external interfaces to entropy sources, memories,
+ GPIO. Arduino Shields would be good.
+
+ - Create a survey on interconnect standards usable for Cryptech
+ - Availability and market share/usage in third party cores.
+ - License
+ - Technical details - Bus, fabric, performance etc.
+
+
+ - Create base coretest functionality to allow testing of cores in the
+ FPGA on the development board. Read and write access to registers
+ over a known communication channel.
+
+ - Verify the development flow from Verilog RTL downto FPGA.
+
+ - Verifiera SHA-256 core using coretest.
+
+ - Start FPGA tool survey
+ - What is available as open tools and what is the status.
+ - What is available as open tools from the vendors.
+ - Talk to people in the industry to get their views on an open toolchain.
+
+
+== Step two (Deadline 2014-03-31) ==
+ - Produce first draft of design proposal to the Cryptech True Random Number Generator (TRNG)
+ - Security target, security model and assumptions
+ - Structure, architecture
+ - API
+ - Functionality
+ - Online test system
+ - Verification model
+ - First two entropy sources
+
+ - Complete SHA-1 core. Including functional verification in FPGA.
+
+ - First draft of SHA-256 and SHA-1 core documentation.
+
+
+=== Actions for step two ===
+ - Create template for documentation
+
+ - Collect info on known TRNGs and TRNG strategies
+
+ - Collect info on online tests being used.
+
+ - Create proposal for architecture.
+
+ - Write implementation proposal.
+
+ - Specify API.
+
+ - Write security target and security model.
+
+ - Write assumptions and limitations.
+
+ - Write verification model.
+
+ - Finalize SHA-1 core RTl.
+
+ - Build SHA-1 core in FPGA.
+
+ - Verify SHA-1 functionality in FPGA using coretest.
+
+ - Write documentation for SHA-256 core.
+
+ - Write documentation for SHA-1 core.
diff --git a/tracwiki/TRNGDevelopment.trac b/tracwiki/TRNGDevelopment.trac new file mode 100644 index 0000000..c2a4bf0 --- /dev/null +++ b/tracwiki/TRNGDevelopment.trac @@ -0,0 +1,7 @@ += TRNG Development =
+One, if not THE key functionality in the Cryptech system is the True Random Number Generator (TRNG). We therefore need to discuss, investigate and test to find a TRNG that we and the users of Cryptech can trust and can verify to be trusted.
+
+
+== Information collected ==
+* [http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Paper.pdf] (pdf) Pseudorandom Number Generation in Smart Cards:
+An Implementation, Performance and Randomness Analysis. A paper that uses Javacard to implement different TRNGs and evluates them.
diff --git a/tracwiki/UpgradeToKSNG.trac b/tracwiki/UpgradeToKSNG.trac new file mode 100644 index 0000000..1120a7b --- /dev/null +++ b/tracwiki/UpgradeToKSNG.trac @@ -0,0 +1,184 @@ +[[PageOutline]]
+
+= Upgrading Cryptech Alpha HSM to "ksng" development package =
+
+This page attempts to explain the upgrade procedure for testing out
+the new "ksng" development branch of the Cryptech Alpha firmware.
+
+== Cavats ==
+
+This particular upgrade is more complicated than we would have
+preferred, due to the interaction of two unrelated factors:
+
+1. As the name (obscurely) implies, the main feature in the ksng
+ branch is a completely new HSM keystore implementation, which makes
+ better use of the Alpha's keystore flash, allows a much larger
+ number of keys, removes the need for an SQL database on the host,
+ gets your laundry 25% brighter, and leaves your breath alone.
+
+ We did not attempt to provide any sort of backwards compatability
+ to the old minimalistic keystore implementation, so this upgrade
+ process will wipe your keystore. Sorry. More importantly (from
+ the limited viewpoint of the upgrade process), it will change how
+ the HSM stores its PINs, which complicates the upgrade process.
+
+2. The "Device Field Upgrade" (DFU) capability in the Alpha's firmware
+ was a last-minute addition before the Berlin workshop in July 2016,
+ and, as last minute additions often do, it turned out to be buggy.
+ There are three distinct pieces of software involved in the upgrade
+ process, and they were all slightly buggy, in different ways.
+ Because of this, one must perform the upgrade steps in a particular
+ order to avoid bricking the HSM. The upgrade includes fixes for
+ all the (known) bugs in the DFU process, so we hope that this will
+ be a one-time annoyance (famous last words).
+
+If something goes horribly wrong and you do somehow manage to brick
+your Alpha, don't give up, recovery is still possible, it just
+requires an ST-LINK debugger and cable (more on this below).
+
+== Overview ==
+
+Because of the tricky nature of this particular upgrade, you must
+perform these steps, in the specified order:
+
+* Install the new host software package using APT or Homebrew.
+* Wipe the HSM keystore to reset PINs back to the "factory" state.
+* Upgrade the main HSM firmware.
+* Upgrade the HSM bootloader.
+* Log in to upgraded HSM to set PINs, etc.
+
+**Upgrading the bootloader before the main firmware will brick your
+Alpha.** So don't do that.
+
+All of the operations here use the Alpha's "management" (MGMT) port,
+so that cable must be connected to your Linux or OSX host machine.
+
+This upgrade procedure was tested on Debian Jessie, with an Alpha
+whose firmware had been rolled back to the version from the Berlin
+workshop (APT/Homebrew package version 2.0.1468584175, commit
+cd445b69b2caa7205f4e1c368aa2c6bf8c2d7692 in repository
+https://git.cryptech.is/releng/alpha.git).
+
+== Install cryptech-alpha-ksng package using apt-get or Homebrew ==
+
+Binaries for the "ksng" branch are available as a separate set of
+"cryptech-alpha-ksng" packages, which replace the "cryptech-alpha"
+packages for the master branch. This seemed the simplest way of
+letting people experiment with the new code while falling back to the
+old if necessary. The "cryptech-alpha-ksng" packages are declared to
+conflict with the "cryptech-alpha" packages, because they install
+programs by the same name in the same places and you need the version
+of the host software which goes with the HSM firmware your running.
+
+APT handles package conflicts differently from the way that Homebrew
+does. If you have "cryptech-alpha" installed and try to install
+"cryptech-alpha-ksng", APT assumes you meant what you said and will
+just replace the old package with the new one. Homebrew, on the other
+hand, reports the conflict and refuses to proceed until you sort it out.
+
+The following assumes that you already had the Cryptech APT repository
+or Homebrew tap configured; if not, see [[wiki:BinaryPackages]].
+
+=== Installing cryptech-alpha-ksng package using apt-get on Debian or Ubuntu Linux ===
+
+{{{
+$ sudo apt-get update
+$ sudo apt-get install cryptech-alpha-ksng
+}}}
+
+=== Installing cryptech-alpha-ksng package using Homebrew on OSX ===
+
+{{{
+$ brew update
+$ brew uninstall cryptech-alpha
+$ brew install cryptech-alpha-ksng
+}}}
+
+== Set usual CRYPTECH_* environment variables ==
+
+The upgrade process uses the `CRYPTECH_CTY_CLIENT_SERIAL_DEVICE`
+environment variable. The easiest way to set it is by using the
+`cryptech_probe` script, just as you would for other usage of the
+Alpha.
+
+{{{
+$ eval `cryptech_probe -v`
+}}}
+
+== Clear the keystore flash ==
+
+Sorry about this. Yes, we know we need backup and restore, we'll get
+there. But for this upgrade, it's safest to wipe the keystore.
+
+{{{
+$ cryptech_miniterm
+
+Username: wheel
+Password: <your-wheel-pin-goes-here>
+
+cryptech> keystore erase YesIAmSure
+
+^]
+}}}
+
+== Upgrade the main HSM firmware ==
+
+{{{
+$ cryptech_upload --firmware --user wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+}}}
+
+== Upgrade the bootloader ==
+
+{{{
+$ cryptech_upload --bootloader --user wheel --simon-says-whack-my-bootloader
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+}}}
+
+== Log in and set PINs, masterkey, etcetera ==
+
+{{{
+$ cryptech_miniterm
+
+Username: wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+
+cryptech> keystore set pin wheel fnord
+cryptech> keystore set pin so fnord
+cryptech> keystore set pin user fnord
+cryptech> masterkey set
+
+^]
+}}}
+
+== What to do if you manage to brick your Alpha ==
+
+If the above procedure somehow goes horribly wrong and bricks your
+alpha, you can still recover, but you'll need an ST-LINK programmer.
+There's some discussion of this at [[wiki:GitRepositories/sw/stm32]].
+
+Possible sources for the ST-LINK programmer and a suitable cable:
+
+* http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyNUCLEO-F411RE
+* https://www.sparkfun.com/products/10376
+
+These are relatively cheap, you'll probably pay as much for the
+postage as for the parts themselves. If you have a better source, go
+for it.
+
+The programmer is the important part, you can use any sort of cabling
+you like so long as it connects the right pins of the programmer to
+the corresponding pins on the Alpha; the SparkFun cable just happens
+to be a tidy package which matches the relevant SWD headers.
+
+We'll include a more detailed description of the recovery process here
+if anybody needs it, but the short version is:
+
+* Install OpenOCD on your host machine.
+* Open up the Alpha's case, take the board out.
+* Connect the programmer and power the board back up.
+* Use the `flash-target` script from the `sw/stm32` repository to
+ stuff the `hsm.elf` and `bootloader.elf` files from the binary
+ firmware tarball into the HSM.
+* Power down, disconnect the programmer, put the Alpha back in its
+ case, done.
\ No newline at end of file diff --git a/tracwiki/Upgrading.trac b/tracwiki/Upgrading.trac new file mode 100644 index 0000000..d85368c --- /dev/null +++ b/tracwiki/Upgrading.trac @@ -0,0 +1,186 @@ + [[PageOutline]]
+
+= Upgrading the Cryptech Alpha HSM =
+
+This page explains how to upgrade the Cryptech Alpha firmware, bootloader,
+and FPGA bitstream (as needed).
+
+All of the operations here use the Alpha's "management" (MGMT) port,
+so that cable must be connected to your Linux or OSX host machine.
+
+== Upgrading from the stock firmware (Berlin workshop or !CrowdSupply) ==
+
+The main feature of the 3.0 firmware release is a completely new HSM
+keystore implementation, which makes better use of the Alpha's keystore
+flash, allows a much larger number of keys, and removes the need for an
+SQL database on the host. (See ReleaseNotes.)
+
+We did not attempt to provide any sort of backwards compatability to the
+original minimalistic keystore implementation, so this upgrade process
+will wipe your keystore. Sorry. More importantly (from the limited
+viewpoint of the upgrade process), it will change how the HSM stores its
+PINs, which complicates the upgrade process.
+
+Because we use the bootloader to upgrade the firmware, and the firmware to
+upgrade the bootloader, both use the PINs stored in the keystore to login,
+so both need to understand the new keystore, so both need to be upgraded.
+
+Because of the tricky nature of this particular upgrade, you must
+perform these steps, in the specified order:
+
+* Install the new host software package using APT or Homebrew.
+* Wipe the HSM keystore to reset PINs back to the "factory" state.
+* Upgrade the main HSM firmware.
+* Upgrade the HSM bootloader.
+* Log in to upgraded HSM to set PINs, etc.
+
+**Upgrading the bootloader before the main firmware will brick your
+Alpha.** So don't do that.
+
+If something goes horribly wrong and you do somehow manage to brick
+your Alpha, see DisasterRecovery.
+
+== Upgrading from 'ksng' ==
+
+A few intrepid users are already testing the 'ksng' development branch,
+using the instructions at [wiki:UpgradeToKSNG]. In this case, and with future
+upgrades, it it not necessary to either wipe the keystore or upgrade the
+bootloader.
+
+* Install the new host software package using APT or Homebrew.
+* Upgrade the main HSM firmware.
+
+== Install the cryptech-alpha package ==
+
+=== using apt-get on Debian or Ubuntu Linux ===
+
+{{{
+$ sudo apt-get update
+$ sudo apt-get install cryptech-alpha
+}}}
+
+Yes, you have to install it even if you already had it installed, because
+APT wants permission before accepting the new package dependencies.
+
+Or you could instead run:
+
+{{{
+$ sudo apt-get upgrade --with-new-pkgs
+}}}
+
+but that might upgrade unrelated stuff.
+
+If you had the '-ksng' package installed, you might then want to run:
+
+{{{
+$ sudo apt-get remove cryptech-alpha-ksng
+$ sudo apt-get autoclean
+}}}
+
+but nothing terrible is likely to happen if you omit those steps.
+
+If you're running on Debian Jessie, you may need to enable [https://backports.debian.org/Instructions/ `jessie-backports`] and make sure you're getting the `python-serial` and `python-tornado` dependencies from the backports (the versions of those packages in the base Debian Jessie distribution are too old).
+
+=== using Homebrew on OSX ===
+
+If you're upgrading from the original firmware (have not installed the `-ksng` package), a normal Homebrew upgrade cycle
+should suffice:
+
+{{{
+$ brew update
+$ brew upgrade
+}}}
+
+If you have the `-ksng` package installed, you need to tell Homebrew that you want to switch back:
+
+{{{
+$ brew update
+$ brew migrate cryptech-alpha-ksng
+$ brew update
+}}}
+
+In either case, you might then want to do something like:
+
+{{{
+$ brew cleanup
+}}}
+
+but nothing terrible is likely to happen if you omit that step.
+
+If you've tried doing this and nothing happens, you might be hitting a known old bug in Homebrew itself. Make sure your copy of Homebrew is up to date, and if that still doesn't work, try deinstalling whichever `cryptech-alpha*` package you have installed and reinstalling `cryptech-alpha`.
+
+== Set usual CRYPTECH_* environment variables ==
+
+The upgrade process uses the `CRYPTECH_CTY_CLIENT_SERIAL_DEVICE`
+environment variable. The easiest way to set it is by using the
+`cryptech_probe` script, just as you would for other usage of the
+Alpha.
+
+{{{
+$ eval `cryptech_probe`
+}}}
+
+(Note: you can use the new `cryptech_muxd` and `cryptech_console`, but
+these instructions assume you are familiar with `cryptech_miniterm`. Or
+you could be using `picocom` or `kermit` or something else. Doesn't matter
+to us.)
+
+== Clear the keystore flash ==
+
+If you are upgrading from the original firmware, you will need to wipe the
+keystore, to avoid confusing the new keystore code.
+
+The good news is that we have a utility to back up and restore the new
+keystore. The bad news is that we don't have a way to back up the old
+keystore.
+
+{{{
+$ cryptech_miniterm
+
+Username: wheel
+Password: <your-wheel-pin-goes-here>
+
+cryptech> keystore erase YesIAmSure
+
+^]
+}}}
+
+== Upgrade the main HSM firmware ==
+
+{{{
+$ cryptech_upload --firmware --user wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+}}}
+
+== Upgrade the bootloader ==
+
+{{{
+$ cryptech_upload --bootloader --user wheel --simon-says-whack-my-bootloader
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+}}}
+
+== (Optional) Upgrade the FPGA bitstream ==
+
+This upgrade includes an experimental ECDSA point multiplier in hardware,
+which the firmware will use if present.
+
+{{{
+$ cryptech_upload --fpga --user wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+}}}
+
+== Log in and set PINs, masterkey, etcetera ==
+
+{{{
+$ cryptech_miniterm
+
+Username: wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+
+cryptech> keystore set pin wheel fnord
+cryptech> keystore set pin so fnord
+cryptech> keystore set pin user fnord
+cryptech> masterkey set
+
+^]
+}}}
diff --git a/tracwiki/UsingSTLink.trac b/tracwiki/UsingSTLink.trac new file mode 100644 index 0000000..92737cc --- /dev/null +++ b/tracwiki/UsingSTLink.trac @@ -0,0 +1,98 @@ += Using ST-LINK =
+
+ST-LINK is STM's implementation of the [https://developer.arm.com/products/architecture/cpu-architecture/debug-visibility-and-trace/coresight-architecture/serial-wire-debug | Serial Wire Debug (SWD)] protocol.
+Think of it as JTAG if you're more comfortable with that.
+
+== Getting an ST-LINK programmer ==
+
+ST-LINK is built into all(?) of STM's Nucleo and Discovery evaluation
+boards, which can be had for as little as US$10 from [http://mouser.com Mouser]
+or [http://element14.com element14] ([http://newark.com Newark] in
+the Americas, [http://farnell.com Farnell] in Europe).
+
+We have tested with STM32F0DISCOVERY and STM32F4DISCOVERY (both with ST-LINK
+v2.0) and NUCLEO-F411RE (with ST-LINK v2.1).
+
+=== Connecting the ST-LINK programmer to the Alpha ===
+
+On the STM board, remove the pair of ST-LINK jumpers (CN4 on the F4DISCO,
+CN2 on the F0DISCO and NUCLEO). Then locate the 6-pin SWD header (CN3 on
+the F0DISCO, CN2 on the F4DISCO, CN4 on the NUCLEO), and connect it to J1
+on the Alpha board (top, just left of center).
+
+This photo shows the correct orientation of the cables (both boards
+oriented so that the logo is right-side up):
+
+[[Image(IMG_20170512_205557_s.jpg)]]
+
+NOTE: The STM boards have an unfortunate tendency to short unexpectedly, so
+I recommend putting them in an enclosure. In this case, I've cut holes in
+the original packaging.
+
+== Install OpenOCD and the debugger ==
+
+{{{
+$ apt-get install gdb-arm-none-eabi openocd
+}}}
+
+== Get the `debug` and `flash-target` scripts ==
+
+If you don't already have a cryptech source tree somewhere, get the source distribution, e.g.
+{{{
+$ apt-get source cryptech-alpha
+}}}
+
+The scripts are in `sw/stm32/bin`.
+
+== Re-flashing the Alpha ==
+
+=== To reflash with our binary firmware ===
+{{{
+$ tar xfz /usr/share/cryptech-alpha-firmware.tar.gz
+$ flash-target hsm
+}}}
+
+
+What you should see is something like:
+{{{
+** Programming Started **
+auto erase enabled
+Info : device id = 0x20016419
+Info : flash size = 2048kbytes
+Info : Dual Bank 2048 kiB STM32F42x/43x/469/479 found
+target halted due to breakpoint, current mode: Thread
+xPSR: 0x61000000 pc: 0x20000046 msp: 0x2002fffc
+wrote 524288 bytes from file projects/hsm/hsm.elf in 12.344705s (41.475 KiB/s)
+** Programming Finished **
+** Verify Started **
+target halted due to breakpoint, current mode: Thread
+xPSR: 0x61000000 pc: 0x2000002e msp: 0x2002fffc
+target halted due to breakpoint, current mode: Thread
+xPSR: 0x61000000 pc: 0x2000002e msp: 0x2002fffc
+verified 509100 bytes in 0.953672s (521.320 KiB/s)
+** Verified OK **
+** Resetting Target **
+Info : Unable to match requested speed 2000 kHz, using 1800 kHz
+Info : Unable to match requested speed 2000 kHz, using 1800 kHz
+adapter speed: 1800 kHz
+shutdown command invoked
+}}}
+
+
+=== To reflash with firmware you built from source ===
+
+See BuildingFromSource.
+
+== Debugging the Alpha ==
+
+This site shows several ways to use various debuggers to debug the
+firmware in an STM32:
+
+ http://fun-tech.se/stm32/OpenOCD/gdb.php
+
+There is a shell script called 'bin/debug' that starts an OpenOCD server
+and GDB:
+
+{{{
+$ sw/stm32/bin/debug projects/hsm/hsm
+}}}
diff --git a/tracwiki/WhoWeAre.trac b/tracwiki/WhoWeAre.trac new file mode 100644 index 0000000..9524aee --- /dev/null +++ b/tracwiki/WhoWeAre.trac @@ -0,0 +1,40 @@ += Who We Are =
+
+This effort was started at the suggestion of Russ Housley, Stephen Farrell, and Jari Arkko of the IETF, to meet the assurance needs of supporting IETF protocols in an open and transparent manner.
+
+But this is not an IETF, ISOC, ... project. As the saying goes, we work for the Internet.
+
+== Tech Core ==
+
+Fredrik Thulin\\
+Jakob Schlyter\\
+[[Joachim Strömbergson]]\\
+Leif Johansson\\
+Linus Nordberg\\
+Lucy Lynch\\
+Patrik Wallström \\
+Павел Шатов (Pavel Shatov)\\
+Peter Stuge\\
+[https://psg.com/~randy Randy Bush]\\
+[[https://www.hactrn.net/sra/|Rob Austein]]\\
+Steven Bellovin\\
+Basil Dolmatov\\
+
+{{{#!comment == Technical Help ==
+Bart Preneel ![0]\\
+Tero Kivinenv ![0]\\
+}}}
+
+== IETF Help ==
+
+Russ Housley\\
+Sean Turner\\
+Stephen Farrell\\
+
+== Coordination ==
+
+Leif Johansson - Administration\\
+Randy Bush - Technical\\
+Russ Housley / Lynn !StAmour - Finding Funding\\
+
+------
\ No newline at end of file diff --git a/tracwiki/WikiStart.trac b/tracwiki/WikiStart.trac new file mode 100644 index 0000000..9edbfae --- /dev/null +++ b/tracwiki/WikiStart.trac @@ -0,0 +1,66 @@ +[[PageOutline]]
+
+= Overview =
+
+Recent revelations have called into question the integrity of some of
+the implementations of basic cryptographic functions and devices used to
+secure communications on the Internet. There are serious questions about
+algorithms and about implementations of those algorithms in software and
+particularly hardware. The goal of the [https://cryptech.is CrypTech]
+project is to provide some possible answers to those questions by
+developing an open-source hardware cryptographic engine that meets the
+needs of high assurance Internet infrastructure systems that use
+cryptography.
+
+The algorithmic issues are in the domain of the heavy math cryptography
+folk; the implementation issues are the primary focus of the project.
+The open-source hardware cryptographic engine must be of general use to
+the broad Internet community, covering needs such as secure email, web,
+DNS, PKIs, etc.
+
+The intent of the project is that the final open-source hardware cryptographic
+engine can be built by anyone from public hardware specifications and
+open-source firmware. Anyone can then operate it without fees of any
+kind.
+
+= About Us =
+[https://cryptech.is CrypTech.IS] is a loose international collective
+of [WhoWeAre engineers] trying to improve assurance and privacy on the
+Internet. It is funded diversely and is administratively quartered outside
+the US.
+
+We are actively seeking use cases for an initial project which is to
+produce a design of an open and auditable Hardware Security Module (HSM)
+and supporting software.
+
+We are also considering the issues around assurance of a tool-chain,
+from compiler to operating system and as close to the hardware as we can
+reasonably get.
+
+The project solicits functional requirements from a wide range of
+organizations. It will focus on the classic low level cryptographic
+functions and primitives, and not get drawn into re-implementation of
+application protocol layers.
+
+We hope that a group of interested organizations will offer funding
+for development, and that the IACR and public sector cryptographers will
+provide algorithmic advice and wide and open review. If you or your
+organization is interested in helping this effort, please consider
+offering [https://cryptech.is/funding/ financial support] to keep the
+work flowing.
+
+= More Information =
+== [[span(style=color: brown,[QuickStart Quick Start Guide])]]
+* including pointers to the git repositories, information on how to set up and configure the board and software, and HSM requirements
+
+== [[span(style=color: brown,[DevelopersGuide Developers Guide])]]
+* including the architecture diagrams, and known information
+
+== [[span(style=color: brown,[ProjectStatus Project Status])]]
+* including information on the chip design and prototypes as well as the pilot project(s)
+
+== [[span(style=color: brown,[ProjectMetadata Project Metadata])]]
+* including information on presentations and meeting notes, technical references, and related work
+
+== [[span(style=color: brown,[ProjectArchive Project Archive])]]
+* including information on dormant and far-future work
|