Start restructuring for Pelican

1 files changed, 0 insertions, 155 deletions

diff --git a/tracwiki/SecureChannel.trac b/tracwiki/SecureChannel.trac
deleted file mode 100644
index 0541a32..0000000
--- a/tracwiki/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.