[Cryptech Core] Cryptech raw notes, day two

[Rob Austein]

Gaps due to sysadmin, brain melt due to topics, other distractions,
but this is what I have.


[note taking started late, distracted by sysadmin glorp]

- threat models

  - [jakob] Have we thought about threat model?  Have we thought about
    more precise control over exactly what's being signed

  - [basil] (a) What Jakob said.  (b) long description of what
    threat model might look like

  - [leif, sra] we may not have a single threat model since we're
    talking about several differnt kinds of devices built from common
    kit, each would have specific threat model

  - [basil] tamper reistance?

  - [jakob] we should pay attention to existing stuff, most of it is
    not just for show

  - [linus] this seems like we'd need a way to express policy

  - [leif] maybe audit trail helps here

  - [jakob] horse already escaped, not good in some cases

  - [fredrik] jakob's dnssec example is good: dnssec signature ok for
    almost anything so long as date is only n days or less.  this
    implies needing to understand dnssec formats down in signer.

  - [jakob] so pkcs#11 is not end all

  - [randy] we decided that yesterday

  - [leif] we're still catching up

  - [linus] model here is sort of a collection of libraries and apis,
    but eventually we have to do applications.  are we doing both?

  - [randy] yes

  - [basil] worried about people doing dumb things with this

  - [linus, sra] we can't stop them from doing dumb things.  we can
    only make it possible for them to do not dumb things.

  - [basil] can we at least nail the apis

  - [randy] let's look at use cases on wiki, some of them also have
    threat models

  [more sysadmin distractions]

  [still ratholed on threat model]

- Parking lot issue: RNG / Entropy

[Break for pgp key party]

- [Joachim uploads initial block diagram of components]

  - [Joachim] AES shows in multiple places here.  TBD whether is
    really all one AES or multiple copies for speed.

[Tea break]

- Block diagram continued

  - [Basil] Another attempt to explain why we should minimize the
    number of ways that dumb users can shoot themselves in feet.

  - [Linus] Final application has to do security analysis threat model
    etc no matter how well we build the components

- Tasks discussion (to wiki)

- Open source FPGA tool chain again

  - [Joachim] We have a mostly sort of open source path, hard part is
    the optimizer, so need comparison tools for input and output of
    optimizer

  - [Basil] Can't assume will always be on platforms where this tool
    set is available.

  - [Linus] Which is why I'm also interested in paths other than FPGA.

  - [Joachim] So more the co-processor approach when without FPGA.

  - [Linus, sra] Maybe we can provide some incentive for more open
    source FPGA tool chain?

  - [Linus] This is a bit like old open source video drivers, some
    manufacturers played along, some didn't.

  - [Peter] FPGA manufacturer profit is probably mostly about the
    chips, so in theory some of them might play along.

[lunch]

- Key backup

  - [Randy] Need to be able to back up and restore

  - [Jakob] Need UART (or something like that) for low level
    configuration

  - [Basil] Need to be able to leave out the UART in configurations
    that don't want it, or break it when one really doesn't want it.

  - [Jakob] How would one activate without UART?

  - [Fredrik] Logging via eithernet instead of UART

  - [Peter] Probably also cases where one wants only to be able to
    restore to same device originally backed up (no recovery after
    smoke)

- Activation

  - [Fredrik] Perhaps generic operation interface with code numbers
    for functions; in cases where a particular instance of the chip
    doesn't need or want to support those operations, those codes
    return error.

  - [Basil] Things like RNG should not be tweakable by clueless users.

  - [Jakob] Want an early definition of management commands needed for
    all(?) applications.  Well, OK, how about te ones that are common
    to many (most?) use cases.

  - [Linus] Maybe we should focus on Jakob's approach in the context
    of the 0.1 plan.

- [Jakob, sra, Peter] Application-specific knowledge definitely should
  be on the map, but not for 0.1.

- [sra] So since we seem not to have TLS on the use case list for 0.1,
  we have nothing using DH or ECDH, so maybe we don't want those in
  0.1 either?

- [Fredrik] Do we need a secure protocol across the green/yellow
  boundary?  Eg, if that's a USB bus?

  - [sra] This would likely involve negotiating a session key, etc.
    Authenticating that one is really talking to the right chip is a
    mess.  This does not sound like 0.1.