aboutsummaryrefslogtreecommitdiff
path: root/content/AlphaBoardComponents.md
blob: b963bb8a0df24ed16da67eb58faa2ddbfa654f7d (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305

   

Title: CrypTech Alpha Board BOM and PCB design requirement sketch Authors: Joachim Strömbergson, Fredrik Thulin Date: 2015-03-09 Modified: 2015-03-25 Category: AlphaBoard

This document contains a list of component level description and requirements for the Crypteh Alpha board.
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.
The block diagram for the Alpha board can be seen at: Hardware

The Alpha board basically consists of three major sub systems:
1. The FPGA Sub System
Used to implement CrypTech crypto/security cores accessible by the CPU as coprocessors.

  1. The CPU Sub System
    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.

  2. The Tamper Detect Sub System
    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 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.

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

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, 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

  • 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 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.

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.

Real Time Clock

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?