[Cryptech Tech] "ksng" branch of Cryptech Alpha firmware now available as a binary package

[Rob Austein]

At Mon, 2 Jan 2017 21:46:04 +0000, Peter Stuge wrote:
> Rob Austein wrote:
> > We actually wrote the multiplexer daemon for this before the Berlin
> > workshop, but ended up disabling it because it doesn't run on OSX (it
> > uses PF_UNIX SOCK_SEQPACKET, which OSX doesn't support).  Sounds like
> > we ought to dust that off and get it running.
> 
> In practice PF_UNIX SOCK_DGRAM works pretty well.

In this case SOCK_STREAM turns out to be simpler (client end of
SOCK_STREAM doesn't require a socket name, no message truncation
issues, etcetera).  We're almost certainly going to have to rework
this in any case when we get around to providing an end-to-end secure
channel between RPC clients and the RPC server on the HSM, so it's not
worth a lot of timing polishing the chrome here at the moment.

> I'd like to completely understand our need for multiplexing to keep
> that in mind for anything USB.
> 
> Is it simply that different applications can use different slots?

The RPC architecture includes fields to identify both "sessions" and
"clients".  "sessions" correspond pretty closely to PKCS #11 sessions:
a single lock-step stream of queries and responses.  "clients" are
intended to allow more than one client process to use the HSM at a
time.  Conceptually, sessions are identified by a <client,session>
handle pair.

There is no reason in principal that two different clients should not
be able to use the same key in different signing cores, so no, it's
not just about different slots.  At present we don't really support
multiple "slots" in the PKCS #11 sense, we implement exactly one slot.

> > > And it seems that every interaction OpenDNSSEC has with the HSM is super
> > > slow. Logging in to the mgmt console is also slow. Like a 10 second
> > > pause after typing in your password. I feel these two are probably related?
> > 
> > C_Login() (and the underlying hal_rpc_login() which implements it) are
> > slow, to make brute force attacks on PINs unproductive.
> 
> It only needs to be slow on failure, right? Or is there a strong
> argument for artificially slowing down successful logins too?

Fair point, but it's a little more complicated than that.  There are
two basic techniques for slowing down brute force password attacks:

1) Make the password computation itself expensive; and

2) Add an artificial delay after each failed attempt.

(1) is important when one is dealing with a situation in which the
password database could be subject to offline attacks (somebody
captures whatever /etc/passwd has mutated into on your favorite Unix
dialect).  (2) is only kinder to the user but only defends against
attempts to use the login interface as an oracle, it doesn't defend
against offline attacks on PINs.

At the moment, the Cryptech code only uses technique (1): PBKDF2 with
a fairly high number of rounds, so the basic calculation is slow,
particularly on the not-particularly-fast CPU we use on the Alpha.  In
theory, we might be able to speed that up by doing PBKDF2 on the FPGA,
but that approach turns out to be somewhat problematic for PINs,
because it creates a chicken-and-egg problem with respect to any
console command which affects the FPGA.  So, at this point, I suspect
we'd be better off hard-wiring the PIN code to be software-only.

At any rate, we could change the mix of (1) and (2), but previous
attempts to get a coherent set of requirements on PIN processing from
the core team didn't really get anywhere, and we had to do
*something*, so I took the more conservative approach.