Design ideas

Jump to bottom Edit New page

Michał Nowak edited this page Dec 22, 2015 · 11 revisions

Glossary:

in-EEPROM - an internal EEPROM of the ATTiny µC,
ex-EEPROM - an EEPROM in an external chip (AT24C...),
EK - an encryption key, generated at bootstrap and stored in an in-EEPROM,

Hardware:

an Attiny85 + quite large I2C EEPROM (AT24C1024?),
a 3.3V LDO,
a LED (or two) and a button for the UI.

Software:

V-USB (https://www.obdev.at/products/vusb/index.html, GPLv2) for an USB stack,
micro-ecc (https://github.com/kmackay/micro-ecc, BSD 2-clause) or nano-ecc (https://github.com/iSECPartners/nano-ecc, BSD 2-clause) for a key-pair generation and signing (secp256r1),
The Entropy library (https://sites.google.com/site/astudyofentropy/project-definition/timer-jitter-entropy-sources/entropy-library, GPLv3) for a TRNG,
a "factory supplied" encryption key in an ATTiny's EEPROM (locked),
whole content of an external EEPROM encrypted using the key (possibly with the NOEKEON algorithm?) (https://github.com/jim17/memtype/blob/master/noekeon.S, GPL),
a free USB VID/PID obtained from pid.codes (http://pid.codes/pids/).

Doubts:

Will all the software fit in a tiny's 8k of flash???
Is 512 bytes of RAM enough for all subsystems?
Does adding an EEPROM encryption give any real advantage?

Alternatives:

Generate private keys ahead of time and store in the ex-EEPROM at the begining (by the means of a bootstrap firmware, later replaced by a final FW) - we won't need the TRNG and key generation routines in the final firmware. There will be two firmwares on the ATTiny:
- a bootstrap firmware, which will:
  - generate a random EK (16 bytes) and store it in the in-EEPROM,
  - generate a pool of private keys and fill the external EEPROM with it (this will take some time),
  - the content of the ex-EEPROM will be encrypted using the EK,
  - write a status byte to the (in or ex)-EEPROM, marking the bootstrap process as completed.
- a final firmware:
  - handle the whole U2F/HID protocol,
  - doesn't need a TRNG,
  - derive public keys from private keys at the runtime,
  - U2F key-handles will not be stored, instead they will map directly to a key index in an ex-EEPROM (TODO: find a suitable int <-> dword algorithm),
  - application-ids must be remembered in the ex-EEPROM, alongside keys.

See also: