From 23bb68fe7e9cc8af176ff60b56e8a51a70f05a89 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Sun, 14 Feb 2021 01:35:10 +0000 Subject: Now generating pages directly from sqlite3 --- raw-wiki-dump/SecureChannel.trac | 155 --------------------------------------- 1 file changed, 155 deletions(-) delete mode 100644 raw-wiki-dump/SecureChannel.trac (limited to 'raw-wiki-dump/SecureChannel.trac') diff --git a/raw-wiki-dump/SecureChannel.trac b/raw-wiki-dump/SecureChannel.trac deleted file mode 100644 index 0541a32..0000000 --- a/raw-wiki-dump/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. -- cgit v1.2.3