[@listener]
[@background]
{br small, saper: redundant array of security tokens https://schanze.pl/ }
<style>
// some things you might want to set here
// remember that explorer does not support rgba
#st_bottom { background: #cccccc; }
#st_bg { background: #00000; }
#st_shadow { background: rgba(100,100,100,0.5); }
// #st_shadow { background: rgba(5,78,28,0.5); }
h1 { background: rgba(100,100,5,0.5); min-height: 10%; }

/* custom styles used in these slides */
.box1 { border: solid red 1px; background: #ff8080; }
.cmd { font-weight: bold; background: #66f;}
</style>

[Redundant Array of Security Tokens]
@effect fade 400@

You can follow this presentation online at

[[https://schanze.pl/intro/]]

Just press L to automatically advance slides

[saper]
saper - Marcin Cieślak

<a href="https://mastodon.social/\@saper">saper on mastodon.social</a>

saper on [[https://github.com/saper]]

[[https://www.mediawiki.org/wiki/User:Saper]]

IRC networks like liberachat, OFTC etc. etc.,

mostly drive-by contributor to various free software projects

day, night job: freelance consultant/developer:

-, writing Python
-, writing C
-, writing JavaScript
-, writing PHP
-, writing PostScript
-, writing assembly
-, or whatever they need

[big thanks]

Big thank you to 3mdeb and Dasharo for the possibility to join today!

[firmware development]

<pre>
: my-w@  ( offset -- w )  my-space +  " config-w@" $call-parent  ;
: my-w!  ( w offset -- )  my-space +  " config-w!" $call-parent  ;

: map-regs  ( -- )
   0 0 my-space h# 0100.0010 +  h# 10  " map-in" $call-parent to regs
   4 my-w@ 1 or 4 my-w!
;

: unmap-regs  ( -- )
   regs  h# 10  " map-out" $call-parent
   4 my-w@ 1 invert and 4 my-w!
;

: probe ( -- )
   map-regs
   set-reg-property
   unmap-regs
;
</pre>

Does anybody know what this could be?

[source]

[[https://github.com/MitchBradley/openfirmware/commit/06f1bdf68556ea6e2a06657c5ed1677d3fbe782d#diff-686c410ce3c2062b1914453effc7e449ed16f95fcd181450e498ca2be98b51c2R98]]

[signing firmware]

., If I have secure boot available:
*, I want to sign my firmware releases
*, I have to protect keys

., What can I do?

*, Give the keys to developers in files
*, Give the keys on crypto tokens

[crypto tokens]

[keeping keys on tokens]

So they say I should

-, generate my key on the token
-, the key should never leave the token

.,exception

some tokens support key wrapping

- you can encrypt the key using AES on the token and get it out

., but then

- how do you protect the AES key you have got it wrapped?

[what if the token is broken]

- generate a new key
-, revoke the old key, install the new key

how to do this on tens of thousands devices in the field?

what if my signing key is in the one-time programmable memory as the only trust anchor?

[solution: buy a real HSM]

but I am a single developer and I want to keep

*= my RPM signing key
*= my debian signing key
*= my Apple signing key
*= my Microsoft signing key
*= my GPG signing key
*= my HAB signing key

somewhat secure

[solution: buy a real HSM]

or we a are group of developers and we are

*= signing firmware
*= signing bootloaders
*= signing kernels
*= signing initrd
*= use secure JTAG
*= maybe issue identities to our devices

and we want to safely share the keys

[real example: heads]

[[https://github.com/osresearch/heads/issues/771]]

[what can we do]

we can take some not so expensive devices

like https://smartcard-hsm.com

and copy keys safely between them

What is going on here:

- those devices have unique token identity signed by the vendor
- we have a so called "Key Domain" which keeps our keys safe but shared
- we have generated a "domain membership key" that is signed by the device identity
. <code>XKEK with KCV C57E89FFB9... in key domain A346FC483C</code>
- we sign device identity public key with a "domain membership key"
- this device (DENK0103778) has joined the key domain by importing it
- now we can generate keys

[how we share the key]

- we generate "domain membership key" for another device
- this device DENK0104057 joins our "Key Domain"
- we generate key exchange keys (E1, E2, E3) which can be used
  to agree a symmetric key wrapping key between the devices

- we can wrap the key on the device #1 so that only the device #2 can read it
- but we never get to see the real key wrapping key, since they
  are silently negotiated using key change keys (EC Diffie-Hellman exchange)
- <code>C57E89FF...</code> is the identifier of the negotiated key

[why the keys are safer]
<img src="hsm1.png" width="70%">
<img src="hsm2.png" width="70%">

- the devices have unique identity, cryptographically signed
- a device must be allowed to join the key domain
- only the device from the vendor root of trust can join the domain
- wrapping keys are unknown outside of the devices
- so the keys can only be imported on the devices we want

[downsides]

- only central identity
- possibly only vendor controlled
- maybe you can negotiate having your own chain of trust

- SmartCard HSM implementation runs on a closed-source applet
running on a proprietary JCOP smartcard operating system

- management of all this is very complicated
-, it took me several hours to try this out with my customers

- but this is good for a working prototype

[solution design]

- let's make this easier
- a service that knows all the tokens
- a service that knows the key domains
- automated provisioning of new tokens
- joining and leaving key domains
- retire and migrate key domains
- automated replication of keys from token to token if online
- inventory of offline tokens

- treat crypto tokens a bit like disks in the array
- single common interface for all developers signing software (via PKCS#11 etc.)
- common access control and auditing could be implemented

[management interface]

Something like HashiCorp Vault, maybe?

[can we work with this?]

Open questions:

- do we need this?
- would you use this?
- any free software tokens that we can upgrade to work like this?

Matrix:

[[https://matrix.to/#/#schanze:converser.eu]]

Fediverse:

saper on mastodon.social [[https://mastodon.social/\@saper]]

email with <a href="https://keyserver.ubuntu.com/pks/lookup?search=fed6001a83aa63fd70ac083733ca76cc50a02077&fingerprint=on&op=index">PGP rsa4096/33CA76CC50A02077 2015-02-28</a>