The Trac Wiki that used to hold this site has been converted to a\nwiki-like setup using git, Markdown, Pelican, and m.css.<\/p>\n
The git repository is configured to generate the web content from the\nMarkdown automatically upon receiving a \u2026<\/p>","content":"
The Trac Wiki that used to hold this site has been converted to a\nwiki-like setup using git, Markdown, Pelican, and m.css.<\/p>\n
The git repository is configured to generate the web content from the\nMarkdown automatically upon receiving a linkchecker<\/a> may also be\nuseful in validating the generated content.<\/p>","category":{"@attributes":{"term":"misc"}}},{"title":"External Project Tor HSM","link":{"@attributes":{"href":"https:\/\/wiki.cryptech.is\/ExternalProjectsTorHSM","rel":"alternate"}},"published":"2018-09-17T10:26:00+00:00","updated":"2018-10-01T14:38:00+00:00","author":{"name":"Linus Nordberg"},"id":"tag:wiki.cryptech.is,2018-09-17:\/ExternalProjectsTorHSM","summary":" The Tor network<\/a> is defined by a small number, about ten, of special relays called Directory Authorities (DAs).<\/p>\n Directory Authorities sign the critical The Tor network<\/a> is defined by a small number, about ten, of special relays called Directory Authorities (DAs).<\/p>\n Directory Authorities sign the critical Authority signing keys are currently kept on the same general purpose computer that runs the Directory Authority and are thus subject to a large number of network threats.<\/p>\n Move The CrypTech project has created an open source (BSD licensed) The minimum viable product (MVP) at MS3 is a system where the authority signing key is no longer accessible by the DA system while not making any part of the process worse from a security perspective.<\/p>\n The system at MS6 (to MS8) does not make any part of the process worse from a \/\/usability\/\/ perspective (subjective) and also adds rate limiting.<\/p>\n External projects using CrypTech<\/a> technology.<\/p>\n This is a sketch of a design for the secure channel that we want to\nhave between the Cryptech HSM and the client libraries which talk to\nit. Work in progress, and not implemented yet because a few of the\npieces are still missing.<\/p>\n Basic design \u2026<\/p>","content":" This is a sketch of a design for the secure channel that we want to\nhave between the Cryptech HSM and the client libraries which talk to\nit. Work in progress, and not implemented yet because a few of the\npieces are still missing.<\/p>\n Basic design goals:<\/p>\n End-to-end between client library and HSM.<\/p>\n<\/li>\n Not require yet another presentation layer if we can avoid it (so,\n reuse XDR if possible, unless we have some strong desire to switch\n to something else).<\/p>\n<\/li>\n Provide end-to-end message integrity between client library and HSM.<\/p>\n<\/li>\n Provide end-to-end message confidentiality between client library\n and HSM. We only need this for a few operations, but between PINs\n and private keys it would be simpler just to provide it all the\n time than to be selective.<\/p>\n<\/li>\n Provide some form of mutual authentication between client library\n and HSM. This is tricky, since it requires either configuration\n (of the other party's authenticator) or leap-of-faith.\n Leap-of-faith is probably good enough for most of what we really\n care about (insuring that we're talking to the same dog now as we\n were earlier).<\/p>\n Not 100% certain we need this at all, but if we're going to leave\nourselves wide open to monkey-in-the-middle attacks, there's not\nmuch point in having a secure channel at all.<\/p>\n<\/li>\n Use boring simple crypto that we already have (or almost have) and\n which runs fast.<\/p>\n<\/li>\n Continue to support multiplexer. Taken together with end-to-end\n message confidentiality, this may mean two layers of headers: an\n outer set which the multiplexer is allowed to mutate, then an\n inner set which is protected. Better, though, would be if the\n multiplexer can work just by reading the outer headers without\n modifying anything.<\/p>\n<\/li>\n Simple enough that we can implement it easily in HSM, PKCS #11\n library, and Python library.<\/p>\n<\/li>\n<\/ul>\n We could, of course, Just Use TLS. Might end up doing that, if it\nturns out to be easier, but TLS is a complicated beast, with far more\noptions than we need, and doesn't provide all of what we want, so a\nfair amount of the effort would be, not wasted exactly, but a giant\nstep sideways. Absent sane alternatives, I'd just suck it up and do\nthis, with a greatly restricted ciphersuite, but I think we have a\nbetter option.<\/p>\n Basic design lifted from \"Cryptography Engineering: Design Principles\nand Practical Applications\" (ISBN 978-0-470-47424-2,\nhttp:\/\/www.wiley.com\/WileyCDA\/WileyTitle\/productCd-0470474246.html),\ntweaked in places to fit tools we have readily available.<\/p>\n Toolkit:<\/p>\n As in the book, there are two layers here: the basic secure channel,\nmoving encrypted-and-authenticated frames back and forth, and a higher\nlevel which handles setup, key agreement, and endpoint authentication.<\/p>\n Chapter 7 outlines a simple lower layer using AES-CTR and\nHMAC-SHA-256. I don't see any particular reason to change any of\nthis, AES-CTR is easy enough. I suppose it might be worth looking\ninto AES-CCM and AES-GCM, but they're somewhat more complicated;\nsection 7.5 (\"Alternatives\") discusses these briefly, we also know\nsome of the authors.<\/p>\n For key agreement we probably want to use ECDH. We don't quite have\nthat yet, but in theory it's relatively minor work to generalize our\nexisting ECDSA code to cover that too, and, again in theory, it should\nbe possible to generalize our existing ECDSA fast base point multiplier\nVerilog cores into fast point multiplier cores (sic: limitation of the\ncurrent cores is that they only compute scalar times the base point,\nnot scalar times an arbitrary point, which is fine for ECDSA but\ndoesn't work for ECDH).<\/p>\n For signature (mutual authentication) we probably want to use ECDSA,\nagain because we have it and it's fast. The more interesting question\nis the configuration vs leap-of-faith discussion, figuring out under\nwhich circumstances we really care about the peer's identity, and\nfiguring out how to store state.<\/p>\n Chapter 14 (key negotiation) of the same book covers the rest of the\nprotocol, substituting ECDH and ECDSA for DH and RSA, respectively.\nAs noted in the text, we could use a shared secret key and a MAC\nfunction instead of public key based authentication.<\/p>\n Alternatively, the Station-to-Station protocol described in 4.6.1 of\n\"Guide to Elliptic Curve Cryptography\" (ISBN 978-0-387-95273-4,\nhttps:\/\/link.springer.com\/book\/10.1007\/b97644) appears to do what\nwe want, straight out of the box.<\/p>\n Interaction with multiplexer is slightly interesting. The multiplexer\nreally only cares about one thing: being able to match responses from\nthe HSM to queries sent into the HSM, so that the multiplexer can send\nthe responses back to the right client. At the moment, it does this\nby seizing control of the client_handle field in the RPC frame, which\nit can get away with doing because there's no end-to-end integrity\ncheck at all (yuck). We could add an outer layer of headers for the\nmultiplexer, but would rather not.<\/p>\n The obvious \"real\" identity for clients to use would be the public\nkeys (ECDSA in the above discussion) they use to authenticate to the\nHSM, or a hash (perhaps truncated) thereof. That's good as far as it\ngoes, and may suffice if we can assume that clients always have unique\nkeys, but if client keys are something over which the client has any\ncontrol (which includes selecting where they're stored, which we may\nnot be able to avoid), we have to consider the possibility of multiple\nclients using the same key (yuck). So a candidate replacement for the\nclient_handle for multiplexer purposes would be some combination of a\npublic key hash and a process ID, both things the client could provide\nwithout the multiplexer needing to do anything.<\/p>\n The one argument in favor of leaving control of this to the\nmultiplexer (rather than the endpoints) is that it would (sort of)\nprotect against one client trying to masquerade as another -- but\nthat's really just another reason why clients should have their own\nkeys to the extent possible.<\/p>\n As a precaution, perhaps the multiplexer should check for duplicate\nidentifiers, then do, um, something? if it finds duplicates. This\nkind of violates Steinbach's Guideline for Systems Programming (\"Never\ntest for an error condition you don't know how to handle\"). Obvious\nanswer is to break all connections old and new using the duplicate\nidentity, minor questions about how to reset from that, whether worth\ndoing at all, etc. Maybe clients just shouldn't do that.<\/p>\n Does the resulting design pass examination by clueful people?<\/p>\n<\/li>\n Does this end up still being significantly simpler than TLS?<\/p>\n<\/li>\n The Cryptography Engineering protocols include a hack to work\n around a length extension weakness in SHA-2 (see section 5.4.2).\n Do we need this? Would we be better off using SHA-3 instead? The\n book claims that SHA-3 was expected to fix this, but that was\n before NIST pissed away their reputation by getting too cosy with\n the NSA again. Over my head, ask somebody with more clue.<\/p>\n<\/li>\n<\/ul>","category":{"@attributes":{"term":"FutureWork"}}},{"title":"Release Notes","link":{"@attributes":{"href":"https:\/\/wiki.cryptech.is\/ReleaseNotes","rel":"alternate"}},"published":"2017-05-13T19:06:00+00:00","updated":"2017-05-13T19:18:00+00:00","author":{"name":"Rob Austein"},"id":"tag:wiki.cryptech.is,2017-05-13:\/ReleaseNotes","summary":" Getting started with 3.0:<\/p>\n At this point, you should be able to use the PKCS #11 library, the Everything you need to build our software, firmware, and FPGA\nbitstreams from source yourself is publicly available, but the process\nis a bit complicated. Overall, there are two methods, one of which\nour developers use while writing this stuff, the other of which we use\nfor the automated reproducible builds \u2026<\/p>","content":" Everything you need to build our software, firmware, and FPGA\nbitstreams from source yourself is publicly available, but the process\nis a bit complicated. Overall, there are two methods, one of which\nour developers use while writing this stuff, the other of which we use\nfor the automated reproducible builds which go into our binary\ndistributions. Both methods eventually boil down to \"get the source\ncode then run make\", but the details differ.<\/p>\n We check out copies of all the several dozen separate repositories and\ncarefully arrange them in a tree structure which matches the official\nnaming scheme. Yes, really. It's tedious, but we have\na script to automate this<\/a>.\nThis works by parsing the Once you have this tree, you can hop around within it, building\nwhichever bits are of interest to you. So if you want to rebuild just\nthe HSM firmware (the C code that runs on the ARM), you would go to\n Reproducible builds use the same tree structure (as they must for the\nvarious Makefiles to work properly), but the entire tree is embedded\nin a git \"superrepository\" which also contains the release engineering\ngoo necessary to make the whole thing work. Do git push<\/code>. <\/p>\nProblem<\/h2>\n
status votes<\/code> and consensus status<\/code> documents using SHA-1 and SHA-256 together with RSA-2048 or RSA-3072 once per hour, using medium-term on-line authority signing keys<\/code> signed by \u2026<\/p>","content":"Problem<\/h2>\n
status votes<\/code> and consensus status<\/code> documents using SHA-1 and SHA-256 together with RSA-2048 or RSA-3072 once per hour, using medium-term on-line authority signing keys<\/code> signed by their individual off-line long-term authority identity keys<\/code>. Authority signing keys typically have a lifetime of three to twelve months.<\/p>\nProposed solution<\/h2>\n
authority signing keys<\/code> away from the general purpose computer onto an external device which can sign the consensus document without exposing key material to the networked computer system.<\/p>\nAlpha<\/code> hardware which would be especially suitable, because the open software and hardware offers unprecedented transparency while also enabling a simple, efficient and legacy-free solution.<\/p>\nCurrent typical key roll-over procedure<\/h3>\n
\n
authority signing key<\/code> on offline system<\/li>\nauthority identity key<\/code> on offline system<\/li>\nauthority signing key<\/code> and key certificate<\/code> on USB stick<\/li>\nauthority signing key<\/code> and key certificate<\/code> to DA system via network<\/li>\n<\/ul>\nThe key roll-over procedure becomes<\/h3>\n
\n
authority signing key<\/code> on HSM\n
authority signing key<\/code> initially remains inactive and unavailable for use<\/li>\nauthority signing key<\/code> is exported from HSM onto the DA system<\/li>\n<\/ul>\n<\/li>\nauthority signing key<\/code> to USB stick<\/li>\nauthority identity key<\/code> on offline system<\/li>\nkey certificate<\/code> on USB stick<\/li>\nkey certificate<\/code> to DA system via network and make available to DA<\/li>\nkey certificate<\/code> to HSM<\/li>\nkey certificate<\/code>, manual without key certificate<\/code> verification)<\/li>\n<\/ul>\nMilestones<\/h2>\n
MS1 -- PoC using OpenSSL
PKCS#11<\/code> engine<\/h3>\n\n
MS2 -- Using CrypTech RPC instead of OpenSSL<\/h3>\n
\n
sw\/libhal\/hal.h<\/code>, definitions in sw\/libhal\/rpc_*.c<\/code><\/li>\nMS3 (MVP) -- HSM configuration I<\/h3>\n
\n
\n
\n
MS4 -- HSM configuration II<\/h3>\n
\n
MS5 -- Enforcing key validity HSM side<\/h3>\n
MS6 -- Rate limiting of signatures<\/h3>\n
MS7 -- New Shiny Crypto Hardware API using CrypTech RPC<\/h3>\n
MS8 -- Getting entropy from HSM<\/h3>\n
MS9 -- Support for more protocols in New Shiny Crypto Hardware API<\/h3>\n
References<\/h2>\n
\n
\n
Design goals and constraints<\/h2>\n
Design goals and constraints<\/h2>\n
\n
Why not TLS?<\/h2>\n
Design<\/h2>\n
\n
Open issues<\/h2>\n
\n
3.0, May 2017<\/h2>\n
\n
3.0, May 2017<\/h2>\n
\n
hal_rpc_pkey_match()<\/code>, hal_rpc_pkey_set_attributes()<\/code>, etc).<\/li>\ncryptech_backup<\/code> to drive the process.<\/li>\ncryptech_muxd<\/code> which allows multiple clients to talk to the HSM at once (packages such as OpenDNSSEC which uses multiple daemons talking to the same HSM need this). Software can still be built for direct connection to HSM but it is no longer the default.<\/li>\ncryptech_console<\/code> to talk to the HSM's management port via the multiplexer daemon; cryptech_upload<\/code> now supports both direct connection and connection via the multiplexer daemon.<\/li>\ncryptech.libhal<\/code> and cryptech.py11<\/code>, respectively.<\/li>\npkcs11-spy<\/code> debugging tool.<\/li>\n\n
cryptech_probe<\/code>.<\/li>\ncryptech_muxd<\/code>.<\/li>\n<\/ul>\ncryptech_backup<\/code> script, and so forth.<\/p>","category":{"@attributes":{"term":"Releases"}}},{"title":"Building Cryptech Software\/Firmware\/Bitstream From Source","link":{"@attributes":{"href":"https:\/\/wiki.cryptech.is\/BuildingFromSource","rel":"alternate"}},"published":"2017-05-13T17:47:00+00:00","updated":"2021-10-10T23:43:00+00:00","author":{"name":"Rob Austein"},"id":"tag:wiki.cryptech.is,2017-05-13:\/BuildingFromSource","summary":"What developers do<\/h2>\n
.gitmodules<\/code> file in the releng\/alpha<\/code>\nrepository (see \"reproducible builds\", below).<\/p>\nsw\/stm32<\/code> and run make<\/code> there.<\/p>\nWhat we do for reproducible builds<\/h2>\n
git help submodule<\/code>\nfor an introduction to git's submodule mechanism.<\/p>\n