[Cryptech Core] Raw notes from Cryptech meeting 2013-12-05

[Rob Austein]

[Insert Randy's slide deck here]

[Guy from Berlin : Peter Stugen]

- Goals for this week:
  - What is "it"?
  - Is "it" possible?

- Trying to get diverse backgrounds in hopes that this will provide
  some open scrutiny of the design

- [Leif] Sunet has agreed to admin project, working on details.  Basic plan
  is independenty-held company -- SUNET per se has to do what
  government tells it to do.

  - [Patrik] Want non-profit
  - [Leif] Will be
  - Rathole on swedish corporate law

- Existing open crypto hardware
  - [Guy from Berlin] says "open k" ?
  - [Joachim] there is some

- No open source verilog compilers that we know of

- NL.net Foundaton is running low on money so may not be viable
  funding source for us

- [Joachim] WHether you can get away with just a microcontoller
  instead of FPGA depends on tradeoffs, speed requirements.  First
  release will be basic simple functionality; decision FPGA vs
  microcontroller vs ASIC can come as later step.

- [Leif] BOF at last IETF says use cases are basically PKCS#11 with
  some extras.

  - [Peter] PKCS#11 is a bad fit, makes bad assumptions.  Seems based
    on MS-DOS.

  - [Fredrik] PKCS#11 is kind of C-specific.

  - Replacement for PKCS#11 as a task for us?  Write our open thing
    then write PKCS#11 wrapper for it?

  - [Leif] M of N key also interesting

  - [Fredrik] Sometimes you want to do conditional operations, or ask
    the HSM questions like "if you do operation foo on this input, do
    you get result X?" because this avoids leaking information.

- Speed

  - [Joachim] One can get FPGAs with fast I/O.  Not cheap, but
    available.

  - [Joachim] You can use do "soft core" to get a conventional CPU
    into the FPGA.  Other way is to add a physical core to FPGA,
    they're available for a few hundred dollars.

 - [Peter] One open source project doing bit-stream generation for
   x86, very young project.

 - [Leif] Might need protocol if we're going to support anything but
   C; [others] not necessarily.

 - [Patrik] Backup protocols are an issue.

- GOST

  - [Patrik] Hard to get support.  Guy who did GOST for OpenSSL has
    been told never to talk to Fredrik again.

- RTC on chip

  - [Fredrik] Auth token needs some time, maybe NTP good enough

  - [Randy] Needs to be authentic, not necessarily incredibly
    precise.  NTP is not as obvious as people seem to think.

- Tamper resistance

  - [Joachim] Ross Anderson's team has somebody who can hack AES keys
    out of HSMs via power-based side channel attacks.

[Coffee break]

- [Leif] We probably don't want to build a massive consortium

- [Randy] Single reference design

- [Joachim] Prototype board, proof of concept

- [Peter] Staying generic for all use cases may be expensive, may need
  to pick particular hardware for particular use cases

- [Leif] Bucket one: high assurance low speed?  Do we try to figure
  out what the other buckets are up front or as we go?

- [Fredrik] Perhaps two reference implementations : first with FPGA,
  second for something like Raspberry Pi.   Interface between green
  and blue in Randy's layer cake has to be some kind of API in any
  case, if we do it right we can implement blue in both Verilog and C.

- [Joachim] Need cipher modes.  GCM etc.  But also want to keep this
  simple for first version: one block cipher, one digest, etc.

- [Joachim] Need C implementation of blue anyway for testing; this
  will help with validation, assurance.

- FIPS
  - [Leif] Russ advised not making FIPS a goal.
  - [Randy] Keep an eye on it, don't break FIPS gratuitously.

- How many protocols

  - [All] Probably one protocol bue/green

  - [Fredrik] Possibly extensible at green/yellow: ability to add
    proprietary extensions to one's green and use it from one's
    yellow.

- [Fredrik/Leif] Need to support OATH? [?]

- [Joachim] IPR in verilog libraries, there is some, not clear whether
  it's relevant to our use cases.

- ECC

  - [All] IPR is a swamp.

  - [Randy] RFC 3717 (Bernstein) as initial target?

  - How does making the curve replacable affect the blue/green
    boundary?  Blue pokes up into green, green pokes down into blue?

- [Linus] Designing for understandability, might be willing to accept
  slower implementation to be able to understand it.

- [Linus] How do we position (publicly) initial development?  Talk
  about use case(s)?

  - [Leif] If we talk about, eg, testing with DNSSEC, people will
    assume this is just about DNSSEC, etc.  Really want abstraction
    layer.

  - [Joachim] Use cases are important for figuring out the primatives.

  - [sra] Maybe say we're doing (useful subsets of) DNSSEC and X.509
    as initial use cases.  Maybe add TLS too.

  - [Linus] Signing "the TOR consensus" as a use case.  Once an hour,
    a couple of perhpas trustworthy TOR relays get to vote on what the
    TOR network map looks like at the moment, and sign the resulting
    map.  These are working keys, regenerated every 6-12 months.

- [Fredrik] Audit log of what's signed.  HSM receives entire content
  to be signed, not just hash, and logs what it's signing out some
  kind of output device.

  - [Patrik] Also want count of how many things have been signed.

  - [Fredrik] Counter thing may be what current HSMs can do, as
    opposed to what the application code would want
  
- [Leif] Fun with fingerprinting to verify that HSM was built with our
  spec.

  - Long confusing discussion.

  - [Randy] How to do without opening side channel attack.

  - [Linus] That's what test vectors are for.

- [Joachim] When testing RNG it's nice to be able to tap the entropy
  source itself in addition to just testing the RNG output; without
  this it's difficult to be certain that there really is a hardware
  entropy source or just a good PRNG and seed.   [War stories about
  fun broken RNGs]

- [Peter] Need people to do review.

[Lunch]

- License

  - [Joachim] We're likely to be pulling in stuff we didn't write, so
    we may have to live with multiple licenses (BSD, GPL2, etc).

  - [sra] I propose BSD due to low barrier to entry.   Room proably OK
    with this.

  - [Joachim] OpenCores kind of likes GPL but existing OpenCores stuff
    is BSD [I think this is what Joachim said...].

- Components

  - SHA-256
  - AES-128
  - EC 3617 need to investigate what's available
  - RSA 2048 and 4096
  - Which of these go on which side of the blue/green boundary is a
    little unclear; side channel attack issues across blue/green
    interface.
  - MAC functions are in green
  - DH in green with exponentiation in blue, for now
  - passphrase stretching (PBKDF2)

- Verification of these pieces

  - [Peter] Can we ever dispense with the green layer?  Assuming
    OpenRISC, we now have to verify all of OpenRISC.

  - [Several] Easier to verify that a green box behaves as it should,
    well, sort of, in theory.

  - [Randy] Can't just blow RISC into an FPGA to test unless it's a
    RISC core that already exists in other forms (eg, ARM) so that you
    have something against which to verify it.

  - [Joachim] On Bunny(?)'s laptop test environment, green probably is
    not running on the FPGA, which makes blue easier to verify but
    leaves green for later.

  - [Peter] Look at 1132 (?) processor.

- [Peter] Can we use this for GPG smart card protocol in v1?

  - [Fredrik] This is an example of needing more than just PKCS#11
    across green/yellow interface

[break]

- Off-FPGA key storage inside security boundary

  - [Joachim] Flash encrypted?  Battery backed and tied into tamper
    detection circuitry?  FIPS requires that battery have enough power
    to wipe key memory rather than just powering off RAM on tamper.

  - [Fredrik] ARM with enough flash for key

  - [Randy] Or battery for tamper detection is big enough to power the
    blue/green processor to keep keys alive

- Red layer: skip OTR for chip 0.1, needs DSA and non-PGP case.

- Yellow layer:

  - PKCS:

    - [Peter] Do we even need all this PKCS#8 etc glop?

    - [sra] Long term, do we need to support things like PKCS#10 for
      chip that will only generate a certificate after inspecting the
      request?

  - Backup and private key sharing between HSMs

    - [Peter, sra] Not necessarily same operation

    - [Peter] Want ability to leave this out (composability)

    - [Randy] Propose punting this from 0.1

[Randy left to take concall]

- [Linus] Can we do ssh as another demo for 0.1.

  - [Peter] We get this for free with the things already on our list.

  - [Fredrik] If we're already supporting the OpenPGP key protocol for
    GPG, might just use that for SSH instead of PKCS#11.

  - [Fredrik] SSH client is easy, SSH server may not have hooks for
    HSM.

- More use cases (not for 0.1):

  - [Fredrik] I want a really good hardware-backed password manager.

- SoftHSM

  - [Patrik] Lot of stuff in SoftHSM, need to make sure how much of it
    that's be useful here.  C++ code.

  - [Leif] Worry about threads.

  - [Fredrik] Need some kind of concurent access control on
    green/yellow interface.

  - [Fredrik] Maybe we can use SoftHSM as our PKCS#11 and just use
    SoftHSM v2's back-end protocol to talk to our private yellow/green
    protocol?

- M of N signature

  - [Leif] Do we need to extrude knowledge of this being M of N into
    the box?  How far down?

  - [Fredrik, sra] [simultaneously invent same algorithm for
    geographically distributed m of n signature; neither of us knows
    whether anybody actually uses this]

  - [Leif] Some of these things use math rather than just a protocol.

  - [Fredrik] look at SSSS.

[Winding down]

- [Joachim] It may be possible to split Verilog stuff into two
  separate pieces: generation of the net from the Verilog source vs
  optimization of the net.  Open source likely critical for the first,
  not so much for the second if we have open source tools that will
  let us compare optimized with non-optimized to confirm they're the
  functionally equivalent.