RoughV1.md « content « pelican - wiki - Cryptech developers pseudo-wiki source, see https://wiki.cryptech.is/

about summary refs log blame commit diff

path: root/pelican/content/RoughV1.md

blob: 19e15d338fb999a38b33e3aa6aa79b4a2ca0063f (plain) (tree)

2
3

5
6

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
7   
Title: RoughV1
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

Sketch of TRNG Chain

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

/span> (status == MKM_STATUS_SET) return LIBHAL_OK; if (status == MKM_STATUS_NOT_SET) return HAL_ERROR_MASTERKEY_NOT_SET; return HAL_ERROR_MASTERKEY_FAIL; } hal_error_t hal_mkm_volatile_write(const uint8_t * const buf, const size_t len) { hal_error_t err; if (len != KEK_LENGTH) return HAL_ERROR_MASTERKEY_BAD_LENGTH; if (buf == NULL) return HAL_ERROR_MASTERKEY_FAIL; if ((err = hal_mkm_volatile_init()) != LIBHAL_OK || (err = hal_mkmif_write(core, MKM_VOLATILE_STATUS_ADDRESS + 4, buf, len)) != LIBHAL_OK || (err = hal_mkmif_write_word(core, MKM_VOLATILE_STATUS_ADDRESS, MKM_STATUS_SET)) != LIBHAL_OK) return err; return LIBHAL_OK; } hal_error_t hal_mkm_volatile_erase(const size_t len) { uint8_t buf[KEK_LENGTH] = {0}; hal_error_t err; if (len != KEK_LENGTH) return HAL_ERROR_MASTERKEY_BAD_LENGTH; if ((err = hal_mkm_volatile_init()) != LIBHAL_OK || (err = hal_mkmif_write(core, MKM_VOLATILE_STATUS_ADDRESS + 4, buf, sizeof(buf))) != LIBHAL_OK || (err = hal_mkmif_write_word(core, MKM_VOLATILE_STATUS_ADDRESS, MKM_STATUS_NOT_SET)) != LIBHAL_OK) return err; return LIBHAL_OK; } /* * hal_mkm_flash_*() functions moved to ks_flash.c, to keep all the code that * knows intimate details of the keystore flash layout in one place. */ hal_error_t hal_mkm_get_kek(uint8_t *kek, size_t *kek_len, const size_t kek_max) { if (kek == NULL || kek_len == NULL || kek_max < bitsToBytes(128)) return HAL_ERROR_BAD_ARGUMENTS; const size_t len = ((kek_max < bitsToBytes(192)) ? bitsToBytes(128) : (kek_max < bitsToBytes(256)) ? bitsToBytes(192) : bitsToBytes(256)); hal_error_t err = hal_mkm_volatile_read(kek, len); if (err == LIBHAL_OK) { *kek_len = len; return LIBHAL_OK; } #if HAL_MKM_FLASH_BACKUP_KLUDGE /* * It turns out that, in every case where this function is called, * we already hold the keystore lock, so attempting to grab it again * would deadlock. This almost never happens when the volatile MKM * is set, but there's a race condition that might drop us here if * hal_mkm_volatile_read() returns HAL_ERROR_CORE_BUSY. Whee! */ if (hal_mkm_flash_read_no_lock(kek, len) == LIBHAL_OK) { *kek_len = len; return LIBHAL_OK; } #endif /* * Both keystores returned an error, probably HAL_ERROR_MASTERKEY_NOT_SET. * I could try to be clever and compare the errors, but really the volatile * keystore is the important one (you shouldn't store the master key in * flash), so return that error. */ return err; } /* * "Any programmer who fails to comply with the standard naming, formatting, * or commenting conventions should be shot. If it so happens that it is * inconvenient to shoot him, then he is to be politely requested to recode * his program in adherence to the above standard." * -- Michael Spier, Digital Equipment Corporation * * Local variables: * indent-tabs-mode: nil * End: */