1 files changed, 0 insertions, 155 deletions
diff --git a/wiki/SecureChannel.trac b/wiki/SecureChannel.trac
deleted file mode 100644
index 0541a32..0000000
--- a/wiki/SecureChannel.trac
+++ /dev/null
@@ -1,155 +0,0 @@
-= Secure Channel
-
-This is a sketch of a design for the secure channel that we want to
-have between the Cryptech HSM and the client libraries which talk to
-it.  Work in progress, and not implemented yet because a few of the
-pieces are still missing.
-
-== Design goals and constraints
-
-Basic design goals:
-
-* End-to-end between client library and HSM.
-
-* Not require yet another presentation layer if we can avoid it (so,
-  reuse XDR if possible, unless we have some strong desire to switch
-  to something else).
-
-* Provide end-to-end message integrity between client library and HSM.
-
-* Provide end-to-end message confidentiality between client library
-  and HSM.  We only need this for a few operations, but between PINs
-  and private keys it would be simpler just to provide it all the time
-  than to be selective.
-
-* Provide some form of mutual authentication between client library
-  and HSM.  This is tricky, since it requires either configuration (of
-  the other party's authenticator) or leap-of-faith.  Leap-of-faith is
-  probably good enough for most of what we really care about (insuring
-  that we're talking to the same dog now as we were earlier).
-
-  Not 100% certain we need this at all, but if we're going to leave
-  ourselves wide open to monkey-in-the-middle attacks, there's not
-  much point in having a secure channel at all.
-
-* Use boring simple crypto that we already have (or almost have) and
-  which runs fast.
-
-* Continue to support multiplexer.  Taken together with end-to-end
-  message confidentiality, this may mean two layers of headers: an
-  outer set which the multiplexer is allowed to mutate, then an inner
-  set which is protected.  Better, though, would be if the multiplexer
-  can work just by reading the outer headers without modifying
-  anything.
-
-* Simple enough that we can implement it easily in HSM, PKCS #11
-  library, and Python library.
-
-== Why not TLS?
-
-We could, of course, Just Use TLS.  Might end up doing that, if it
-turns out to be easier, but TLS is a complicated beast, with far more
-options than we need, and doesn't provide all of what we want, so a
-fair amount of the effort would be, not wasted exactly, but a giant
-step sideways.  Absent sane alternatives, I'd just suck it up and do
-this, with a greatly restricted ciphersuite, but I think we have a
-better option.
-
-== Design
-
-Basic design lifted from "Cryptography Engineering: Design Principles
-and Practical Applications" (ISBN 978-0-470-47424-2,
-http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470474246.html),
-tweaked in places to fit tools we have readily available.
-
-Toolkit:
-
-* AES
-* SHA-2
-* ECDH
-* ECDSA
-* XDR
-
-As in the book, there are two layers here: the basic secure channel,
-moving encrypted-and-authenticated frames back and forth, and a higher
-level which handles setup, key agreement, and endpoint authentication.
-
-Chapter 7 outlines a simple lower layer using AES-CTR and
-HMAC-SHA-256.  I don't see any particular reason to change any of
-this, AES-CTR is easy enough.  I suppose it might be worth looking
-into AES-CCM and AES-GCM, but they're somewhat more complicated;
-section 7.5 ("Alternatives") discusses these briefly, we also know
-some of the authors.
-
-For key agreement we probably want to use ECDH.  We don't quite have
-that yet, but in theory it's relatively minor work to generalize our
-existing ECDSA code to cover that too, and, again in theory, it should
-be possible to generalize our existing ECDSA fast base point multiplier
-Verilog cores into fast point multiplier cores (sic: limitation of the
-current cores is that they only compute scalar times the base point,
-not scalar times an arbitrary point, which is fine for ECDSA but
-doesn't work for ECDH).
-
-For signature (mutual authentication) we probably want to use ECDSA,
-again because we have it and it's fast.  The more interesting question
-is the configuration vs leap-of-faith discussion, figuring out under
-which circumstances we really care about the peer's identity, and
-figuring out how to store state.
-
-Chapter 14 (key negotiation) of the same book covers the rest of the
-protocol, substituting ECDH and ECDSA for DH and RSA, respectively.
-As noted in the text, we could use a shared secret key and a MAC
-function instead of public key based authentication.
-
-Alternatively, the Station-to-Station protocol described in 4.6.1 of
-"Guide to Elliptic Curve Cryptography" (ISBN 978-0-387-95273-4,
-https://link.springer.com/book/10.1007/b97644) appears to do what
-we want, straight out of the box.
-
-Interaction with multiplexer is slightly interesting.  The multiplexer
-really only cares about one thing: being able to match responses from
-the HSM to queries sent into the HSM, so that the multiplexer can send
-the responses back to the right client.  At the moment, it does this
-by seizing control of the client_handle field in the RPC frame, which
-it can get away with doing because there's no end-to-end integrity
-check at all (yuck).  We could add an outer layer of headers for the
-multiplexer, but would rather not.
-
-The obvious "real" identity for clients to use would be the public
-keys (ECDSA in the above discussion) they use to authenticate to the
-HSM, or a hash (perhaps truncated) thereof.  That's good as far as it
-goes, and may suffice if we can assume that clients always have unique
-keys, but if client keys are something over which the client has any
-control (which includes selecting where they're stored, which we may
-not be able to avoid), we have to consider the possibility of multiple
-clients using the same key (yuck).  So a candidate replacement for the
-client_handle for multiplexer purposes would be some combination of a
-public key hash and a process ID, both things the client could provide
-without the multiplexer needing to do anything.
-
-The one argument in favor of leaving control of this to the
-multiplexer (rather than the endpoints) is that it would (sort of)
-protect against one client trying to masquerade as another -- but
-that's really just another reason why clients should have their own
-keys to the extent possible.
-
-As a precaution, perhaps the multiplexer should check for duplicate
-identifiers, then do, um, something? if it finds duplicates.  This
-kind of violates Steinbach's Guideline for Systems Programming ("Never
-test for an error condition you don't know how to handle").  Obvious
-answer is to break all connections old and new using the duplicate
-identity, minor questions about how to reset from that, whether worth
-doing at all, etc.  Maybe clients just shouldn't do that.
-
-== Open issues
-
-* Does the resulting design pass examination by clueful people?
-
-* Does this end up still being significantly simpler than TLS?
-
-* The Cryptography Engineering protocols include a hack to work around
-  a length extension weakness in SHA-2 (see section 5.4.2).  Do we
-  need this?  Would we be better off using SHA-3 instead?  The book
-  claims that SHA-3 was expected to fix this, but that was before NIST
-  pissed away their reputation by getting too cosy with the NSA again.
-  Over my head, ask somebody with more clue.