aboutsummaryrefslogtreecommitdiff
path: root/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob%2Ftamper.md
blob: b0531ad367240265228b013c0a6a36a3352bc5c5 (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

   
#!htmlcomment

This page is maintained automatically by a script.  Don't modify this page by hand,
your changes will just be overwritten the next time the script runs.  Talk to your
Friendly Neighborhood Repository Maintainer if you need to change something here.
#!html
<h1>Cryptech tamper detection</h1>

<p>This is software for the Atmel AVR ATtiny828 MCU on the Cryptech alpha
board, rev02, implementing tamper detection and master key erasure.</p>

<h2>Overview</h2>

<pre><code>   *************
   * P A N I C *
   *   button  *
   *************
    /
   /
  /
AVR ---- SPI mux ---- FPGA
            |          |
            |         ARM
           MKM

AVR -- Atmel MCU
FPGA -- FPGA
MKM -- Master Key Memory, 23K640 SRAM
SPI mux -- 2 x MC74AC244DW
ARM -- ARM CPU
</code></pre>

<p>The MKM holds the master key for the device.</p>

<p>The AVR, MKM and the mux are all battery powered.</p>

<p>The AVR and the FPGA are both sharing access to the MKM through the
mux, with the AVR connected to the pins used for deciding who's in
control of the memory. If the AVR doesn't actively grab control of the
MKM, the FPGA is in control.</p>

<p>When the panic button is pressed, the AVR takes control over the MKM
and writes zeros to it as quickly as possible. In idle mode, i.e. when
the panic button is not pressed, the AVR tries to consume as little
power as possible.</p>

<h2>Building the software</h2>

<p>To build a .hex file suitible for uploading to a board with a
ATTiny828, a C compiler for AVR is needed, as wells a objcopy. On a
Debian system, the following command can be used for installing both:</p>

<pre><code>apt-get install gcc-avr binutils-avr avr-libc
</code></pre>

<p>To build tamper.hex, type 'make' in this directory.</p>

<p>To upload a .hex file to a board, the program avrdude can be used. On
a Debian system, the following command can be used for installing
avrdude:</p>

<pre><code>apt-get install avrdude
</code></pre>

<p>If configuration for ATtiny828 is missing, the file attiny828.conf in
this directory could be appended to avrdude.conf:</p>

<pre><code>cat attiny828.conf &gt;&gt; /etc/avrdude.conf
</code></pre>

<p>Often, a piece of hardware called "SPI programmer" is needed in order
to upload the .hex file to the target system. The one I've been using
has "sparkfun.com" printed on it. This small board has a mini-USB port
to connect to a host system and a header with SPI pins to connect to a
board with an AVR on it.</p>

<p>To upload a .hex file to a board, use the upload.sh shell script in
this directory with the name of the file as the only argument:</p>

<pre><code>./upload.sh tamper.hex
</code></pre>

<p>Depending on permissions on your host system you might want to run the
upload script as root.</p>

<h2>GPIO on Cryptech HSM rev.03</h2>

<p>The GPIO ports are located on JP5 (AVR_GPIO). From left to right, as seen when the marking is above the connector, the ports are:</p>

<ol>
<li>3V3</li>
<li>PORTC0</li>
<li>PORTC1</li>
<li>PORTC2</li>
<li>PORTC3</li>
<li>PORTC4</li>
<li>PORTC5</li>
<li>PORTC6</li>
<li>PORTC7
<ol>
<li>GND</li>
</ol></li>
</ol>

<h2>Dependencies</h2>

<h3>Debian</h3>

<ul>
<li>apt-get install gcc-avr binutils-avr avr-libc avrdude</li>
</ul>

<h3>Fedora</h3>

<ul>
<li>dnf install avrdude avr-gcc avr-libc</li>
</ul>

[[RepositoryIndex(format=table,glob=user/jakob/tamper)]]

Clone https://git.cryptech.is/user/jakob/tamper.git