aboutsummaryrefslogtreecommitdiff
path: root/pelican/content/RoughV1.md
blob: 910e977b99c7f37941137dc96febd437310ede5d (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

   

Title: RoughV1 Author: sra Date: 2016-12-15 22:43 Modified: 2021-02-14 17:33

Rough Cut at v0.01 Proof of Concept Feature Set

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. It very intentionally is not a 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

HW_sketch_v0001.png

Sketch of TRNG Chain

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 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
  • 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) :)