├── .gitignore ├── papers ├── authentication-and-authenticated-key-exchanges.pdf ├── cachetiming-20050414.pdf ├── capability-myths.pdf ├── coolnacl.pdf ├── new-directions-in-cryptography.pdf ├── paper-chosen-protocol.pdf ├── sigma.pdf └── skeme.pdf ├── shs.bib ├── shs.pdf ├── shs.tex └── shs.tex.bak /.gitignore: -------------------------------------------------------------------------------- 1 | *.aux 2 | *.bbl 3 | *.log 4 | *.dvi 5 | *.blg 6 | -------------------------------------------------------------------------------- /papers/authentication-and-authenticated-key-exchanges.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/authentication-and-authenticated-key-exchanges.pdf -------------------------------------------------------------------------------- /papers/cachetiming-20050414.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/cachetiming-20050414.pdf -------------------------------------------------------------------------------- /papers/capability-myths.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/capability-myths.pdf -------------------------------------------------------------------------------- /papers/coolnacl.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/coolnacl.pdf -------------------------------------------------------------------------------- /papers/new-directions-in-cryptography.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/new-directions-in-cryptography.pdf -------------------------------------------------------------------------------- /papers/paper-chosen-protocol.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/paper-chosen-protocol.pdf -------------------------------------------------------------------------------- /papers/sigma.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/sigma.pdf -------------------------------------------------------------------------------- /papers/skeme.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/papers/skeme.pdf -------------------------------------------------------------------------------- /shs.bib: -------------------------------------------------------------------------------- 1 | 2 | @misc{unicap, 3 | author = {Slominski, Tristan}, 4 | title = {Towards a Universal Implementation of Unforgeable Actor Addresses}, 5 | month = {Oct}, 6 | year = {2013}, 7 | howpublished = {\url{http://www.dalnefre.com/wp/2013/10/towards-a-universal-implementation-of-unforgeable-actor-addresses/}}, 8 | note = {Accessed: 2015-06-10} 9 | } 10 | 11 | @misc{tahoe, 12 | author = {Zooko Wilcox-O'Hearn and Brian Warner}, 13 | title = {Tahoe – The Least-Authority Filesystem}, 14 | howpublished = {Cryptology ePrint Archive, Report 2012/524}, 15 | year = {2012}, 16 | } 17 | 18 | @misc{curvecp, 19 | author = {Bernstein, Daniel}, 20 | title = {CurveCP: Usable security for the Internet}, 21 | month = {Feb}, 22 | year = {2011}, 23 | howpublished = {\url{http://curvecp.org/index.html}}, 24 | note = {Accessed: 2015-06-10} 25 | } 26 | 27 | @INPROCEEDINGS{cpa, 28 | author = {John Kelsey and Bruce Schneier and David Wagner}, 29 | title = {Protocol Interactions and the Chosen Protocol Attack}, 30 | booktitle = {In Proc. 1997 Security Protocols Workshop}, 31 | year = {1997}, 32 | pages = {91--104}, 33 | publisher = {Springer-Verlag} 34 | } 35 | 36 | @MISC{ndic, 37 | author = {Whitfield Diffie and Martin E. Hellman}, 38 | title = {New Directions in Cryptography}, 39 | year = {1976} 40 | } 41 | 42 | @MISC{aake, 43 | author = {Whitfield Diffie and Paul C. van Oorschot and Michael J. Wiener}, 44 | title = {Authentication and Authenticated Key Exchanges }, 45 | year = {1992} 46 | } 47 | 48 | @INPROCEEDINGS{sigma, 49 | author = {Hugo Krawczyk}, 50 | title = {SIGMA: the SIGn-and-MAc Approach to Authenticated Diffie-Hellman}, 51 | booktitle = {SIGMA, full version. http://www.ee.technion.ac.il/~hugo/sigma.html}, 52 | year = {2003} 53 | } 54 | 55 | @inproceedings{nacl, 56 | author = {Bernstein, Daniel J. and Lange, Tanja and Schwabe, Peter}, 57 | title = {The Security Impact of a New Cryptographic Library}, 58 | booktitle = {Proceedings of the 2Nd International Conference on Cryptology and Information Security in Latin America}, 59 | series = {LATINCRYPT'12}, 60 | year = {2012}, 61 | isbn = {978-3-642-33480-1}, 62 | location = {Santiago, Chile}, 63 | pages = {159--176}, 64 | numpages = {18}, 65 | url = {http://dx.doi.org/10.1007/978-3-642-33481-8_9}, 66 | doi = {10.1007/978-3-642-33481-8_9}, 67 | acmid = {2406735}, 68 | publisher = {Springer-Verlag}, 69 | address = {Berlin, Heidelberg}, 70 | keywords = {confidentiality, integrity, security, simplicity, speed}, 71 | } 72 | 73 | @misc{ccp_review, 74 | author = {CodesInChaos}, 75 | title = {CurveCP Review - Part 1 Crypto}, 76 | howpublished = {\url{https://codesinchaos.wordpress.com/2012/09/09/curvecp-1/}}, 77 | month = {Sept}, 78 | year = {2012}, 79 | } 80 | 81 | @inproceedings{otr, 82 | title = {Off-the-record communication, or, why not to use PGP}, 83 | address = {New York, NY, USA}, 84 | author = {Borisov, Nikita and Goldberg, Ian and Brewer, Eric}, 85 | booktitle = {Proceedings of the 2004 ACM workshop on Privacy in the electronic society}, 86 | doi = {10.1145/1029179.1029200}, 87 | isbn = {1-58113-968-3}, 88 | location = {Washington DC, USA}, 89 | pages = {77--84}, 90 | posted-at = {2006-10-07 03:06:21}, 91 | priority = {0}, 92 | publisher = {ACM}, 93 | series = {WPES '04}, 94 | url = {http://dx.doi.org/10.1145/1029179.1029200}, 95 | year = {2004} 96 | } 97 | 98 | @misc{textsecure, 99 | author = {Marlinspike, Moxie}, 100 | title = {Simplifying OTR deniability}, 101 | howpublished = {\url{https://whispersystems.org/blog/simplifying-otr-deniability/}}, 102 | year = {2013}, 103 | month = {July}, 104 | } 105 | 106 | @misc{noise, 107 | author = {Perrin, Trevor}, 108 | title = {noise}, 109 | howpublished = {\url{https://github.com/trevp/noise/blob/master/noise.md}}, 110 | year = {2014}, 111 | month = {Aug}, 112 | } 113 | 114 | @TECHREPORT{capmyths, 115 | author = {Mark Miller and Ka-Ping Yee and Jonathan Shapiro and Combex Inc}, 116 | title = {Capability Myths Demolished}, 117 | year = {2003} 118 | } 119 | 120 | @TECHREPORT{aestiming, 121 | author = {Daniel J. Bernstein}, 122 | title = {Cache-timing attacks on AES}, 123 | year = {2005} 124 | } 125 | 126 | @misc{underhanded, 127 | title = {Underhanded Crypto Contest}, 128 | author = {Caudill, Adam and Hornby, Taylor}, 129 | howpublished = {\url{https://underhandedcrypto.com/}}, 130 | year = {2014} 131 | } 132 | -------------------------------------------------------------------------------- /shs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dominictarr/secret-handshake-paper/99fbbdf23995236025bfee0552b99e8b778cb9b4/shs.pdf -------------------------------------------------------------------------------- /shs.tex: -------------------------------------------------------------------------------- 1 | \documentclass[12pt]{article} 2 | \usepackage{amsmath} % great math stuff 3 | \usepackage{amsfonts} % for blackboard bold, etc 4 | \usepackage{amsthm} % better theorem environments 5 | \usepackage{graphicx} 6 | 7 | \newtheorem{proto}{Protocol} 8 | 9 | \begin{document} 10 | \title{Designing a Secret Handshake: Authenticated Key Exchange as a Capability System} 11 | \author{Dominic Tarr} 12 | 13 | 14 | \maketitle 15 | 16 | \begin{abstract} 17 | Capability Based Security is a conceptual framework for designing 18 | decentralized access control systems, yet there is no widely 19 | implemented protocol for establishing secure two-way communication 20 | that also forms a capability system. 21 | We examine the ways various key exchange protocols aren't 22 | capability systems, and then present a secure key 23 | exchange protocol designed with capability systems in mind. 24 | In this protocol, the server's public key forms an access capability. 25 | Using a preauthentication step, we authenticate the client before 26 | the server, but still accomplish mutual authentication within 4 passes. 27 | All long term keys are kept secret from any unauthenticated actors. 28 | 29 | \end{abstract} 30 | 31 | \section{Introduction} 32 | 33 | The development of key exchange algorithms marked the dawn of 34 | modern cryptography\cite{ndic}. Their development was motivated 35 | by the desire for secure communications between two parties---yet 36 | designing a practical and secure protocol for exchanging 37 | a shared key between two authenticated parties is non-trivial\cite{aake}. 38 | 39 | Much of the research into key exchange has produced whole ``families'' of 40 | protocols \cite{sigma}. Protocols currently in widespread 41 | use tend to be layered and configurable (TLS, SSH). This is not 42 | to the benefit of application developers---gaining a sufficiently 43 | nuanced understanding of such cryptosystems takes considerable study. 44 | Providing the developer with \emph{more options} is to provide them 45 | with \emph{more opportunities} to add critical security flaws to their 46 | application. Thus, recent thought has steered towards providing simple constructions 47 | with security properties that are easy to understand and use safely 48 | \cite{nacl}. We apply this philosophy to the design of an authenticated 49 | key exchange - a secret handshake. Since a key exchange can be designed 50 | with so many possible properties, we adopt the framework of capability 51 | systems\cite{unicap} and allow that to drive the design. 52 | Tahoe-LAFS\cite{tahoe} is the inspiration for this decision. 53 | We find that no currently available handshake protocol adequately meets 54 | the needs of a capability system. Interestingly, a capability system 55 | demands a higher degree of privacy than is provided by other available 56 | protocols. 57 | 58 | We will describe various key exchange protocols and examine why their 59 | design does not form a capability system. We will discuss these 60 | protocols abstractly, giving sufficient details to demonstrate their 61 | cryptographic properties. In some cases, this means ignoring details 62 | required for their actual implementation, for example the handling of 63 | nonces. Finally, we will describe our capability based key exchange 64 | protocol. 65 | 66 | \section{Capability Systems} 67 | 68 | In a capability system, the right to access a resource is granted 69 | to the bearer of a \emph{capability} (cap). Capability 70 | Based Security predates modern cryptography, but its concepts 71 | map cleanly to the decentralized access control systems 72 | enabled by cryptography. \footnote{ 73 | There are limitations to a cryptographic capability system. 74 | It is possible to implement what \emph{Capability Myths Demolished}\cite{capmyths} 75 | describes as the \emph{Capabilities as Keys} model. In this model, 76 | actors may delegate via any channel they can write to. 77 | Contrast this with the \emph{Object Capability} model, which incorporates 78 | a strict type system that can distinguish between data and capabilities, 79 | and thus prevent capabilities from being mistakenly written as data. 80 | } 81 | 82 | For example, possessing the key to decrypt a file means you have 83 | the \emph{capability} to \emph{read} that file. This can be implemented 84 | in a decentralized fashion: An encrypted file is widely distributed 85 | via a peer to peer network, but the read-cap is delegated 86 | only to a trusted few. Contrast this with an Access 87 | Control List (ACL), the file is kept on a server, and only those 88 | who can correctly authenticate can access the file: Like a bouncer 89 | at a nightclub, a trusted gatekeeper is required to administer the 90 | access list. A decentralized ACL is not possible. 91 | 92 | 93 | \textsc{Delegation} is the act of granting one of your access 94 | rights to another actor by sending them a capability. 95 | In a well behaved capability system, there is no way to gain a 96 | particular access right except through delegation. 97 | 98 | \textsc{Unintended Delegation}. If you give your car keys to a valet 99 | to park your car, that is delegation. If you leave your keys in your 100 | car and it is stolen--that is an \emph{unintended delegation}, 101 | or a \emph{misdelegation}. It is not the same as if someone forcibly 102 | gained entry to your car and hot-wired it. If someone ``steals'' your 103 | car because you mistakenly gave them the keys, it is your own fault. 104 | It is our responsibility as protocol designers to not build 105 | misdelegations into the protocol itself.\footnote{ 106 | AES is an example of a protocol that has been shown to contain a 107 | misdelegation\cite{aestiming} (secure AES implementations are possible, 108 | but suffer from poor performance). 109 | A good protocol design cannot prevent a malicious implementer, 110 | but it can mitigate the effects of 111 | an incompetent one. Thus, a good protocol design at least prevents 112 | a malicious implementer from \emph{feigning incompetence}\cite{underhanded}. 113 | Thankfully, maliciousness is not as common as incompetence. 114 | } If a system has unintended delegations at the protocol level, 115 | it is not a well behaved capability system. 116 | 117 | \textsc{Wildcard}. In some card games there is a designated ``wildcard'' 118 | that can be played as any other card. A token is called a \emph{wildcard} 119 | if it enables a set of rights that should have to be delegated 120 | individually. 121 | I know of no cryptosystem that was intentionally designed to contain 122 | wildcards. Presence of an unintended wildcard in a capability 123 | system should be considered a design failure. 124 | 125 | \textsc{Well Behaved}. A capability system is 126 | \emph{well behaved} if it supports delegation but lacks unintended 127 | delegations and wildcards. 128 | 129 | \section{Notation} 130 | 131 | $A \to B$ signifies a message passed from client to server, and 132 | $A \gets B$ signifies a response. It's important to understand 133 | at what point a party becomes authenticated, and at what point 134 | that party knows it. If $A$ or $B$ is replaced with $?$ it 135 | means that party is not yet authenticated, to the knowledge 136 | of the receiver. If Alice receives a message $? \gets B$ it means 137 | she now knows who Bob is, but Bob doesn't know who she is. 138 | A handshake is not complete until both parties know who they are 139 | talking to, and know the other party also knows. Thus a handshake 140 | does not end until two passes marked $A \to B$ and $A \gets B$ 141 | are exchanged. 142 | 143 | When a key pair is an argument to a function, 144 | it's represented as a subscript. When a key is sent in a message, 145 | only the public key is used, to be explicit I write that as $A_{p}$. 146 | None of the protocols studied in this paper ever send a secret key 147 | over the wire. 148 | 149 | Long term keys for Alice and Bob are represented by $A,B$, 150 | and ephemeral keys are $a,b$. $a \cdot b$ denotes a shared key derived 151 | from $a$ and $b$. Again, when this is a function argument it is shown 152 | as the subscript, $Box_{[a\cdot b]}(msg)$. Note that 153 | $Box$ is authenticated encryption, it has the 154 | properties of a mac as well as of encryption. $|$ denotes concatenation. 155 | 156 | Finally, whenever a message is received it is immediately verified 157 | and if invalid the handshake is aborted. 158 | 159 | \section{Prior Art} 160 | 161 | \subsection{Authenticated Key Exchange - STS, TLS, SSH} 162 | 163 | Station to Station\cite{aake} is simple, and is the basis of several 164 | popular protocols\footnote{ 165 | TLS (when used with ciphersuites that contain DHE or ECDHE), 166 | and SSH share their basic design with STS, but using 167 | a hmac to prove they know $a\cdot b$ instead of encryption. 168 | }. 169 | 170 | \begin{samepage} 171 | \begin{proto}[Station to Station] 172 | 173 | $$ 174 | \begin{align*} 175 | ? \to \;?\; &: a_{p} \\ 176 | ? \gets B &: b_{p}, Box_{[a\cdot b]}(B_p | Sign_B(a_{p}|b_{p})) \\ 177 | A \to B &: Box_{[a\cdot b]}(A_{pub} | Sign_A(a_{p} | b_{p})) \\ 178 | A \gets B &: Box_{[a\cdot b]}(okay) \\ 179 | \end{align*} 180 | $$ 181 | 182 | Alice sends a fresh ephemeral key to Bob, who creates one too, 183 | signs both keys and sends them back with his public key. 184 | Alice then boxes her public key and a signature to prove her identity. 185 | Finally, Bob boxes a standard message to show his acceptance\footnote{ 186 | Often the description of a handshake protocol ends as soon 187 | as each party is authenticated, but before the client \emph{knows} 188 | it is authenticated. If this is the case, the client could receive 189 | an authentication error (or dropped connection) at the application 190 | layer, which is awkward. Thus, they do not know they've been accepted 191 | until receiving the first encrypted message. For this reason 192 | I've presented STS as a 4 pass protocol, even though the original 193 | paper describes it as a 3 pass protocol. 194 | }. 195 | 196 | \end{proto} 197 | \end{samepage} 198 | 199 | Neither party can be assured of the freshness of a message 200 | unless it is a cryptographic reply to a known fresh value, 201 | i.e. a value they freshly created. Hence, it is pointless for Alice 202 | to send her identity in the first pass. Bob cannot be sure it is truly her 203 | until the third pass at the earliest. 204 | 205 | However, Alice can know Bob's first message is fresh, so STS and many 206 | other protocols send the server authentication as the second pass. 207 | To resist an identity misbinding attack we require proof that the 208 | other party possesses the shared secret $a\cdot b$. Authenticated encryption, 209 | $Box_{[a\cdot b]}$, or a mac accomplishes that \cite[section 3.1]{sigma} 210 | 211 | 212 | Is STS suitable for a capability system? No. The first thing STS 213 | does is authenticate the server, but the first question a capability 214 | system should ask is whether the client has the capability to 215 | this resource. Since Alice needs to know $B_p$ to authenticate 216 | Bob \emph{anyway}, it makes an excellent candidate for an access cap. 217 | 218 | However, by authenticating Bob first, and sending his public key to 219 | an unauthenticated client, the public keys are delegated to anyone 220 | who initiates the protocol with Bob. Because of this unnecessary 221 | delegation, STS is not very useful as a capability system\footnote{ 222 | Readers familiar with SSH will know the typical workflow for setting 223 | up a new server and accessing it for the first time. A server is 224 | created (on a cloud service such as AWS), with the user's public 225 | key in the \texttt{authorized\_keys} file. The user connects with the 226 | ssh command, and since this is the first connection, they will be 227 | prompted to accept the server's \emph{key fingerprint}. 228 | Most users will just hit \texttt{Y}, since that is easier than 229 | checking. This allows a window for a man-in-the-middle attack, 230 | rendering ssh effectively a \emph{trust on first use} system. 231 | On the other hand, if SSH was a capability system, the user would 232 | need to copy/paste the cap, completely avoiding this weakness. 233 | The user is likely to copy/paste the IP address anyway, so if the 234 | address and key were combined into one token it would be no more 235 | awkward. 236 | SSH requires an inconvenient security discipline, only 237 | followed by the most paranoid users, but a capability system 238 | would provide naturally better security at the same level of 239 | convenience. 240 | }. 241 | 242 | \subsection{Encrypted Key Exchange - CurveCP} 243 | 244 | CurveCP\cite{curvecp} implements authentication relying only on 245 | nacl's\cite{nacl} $Box$ primitive, which uses curve25519 keys. 246 | curve25519 keys are combined via scalar multiplication to produce 247 | shared keys, like Diffie Helman keys\cite{ndic}, not signing keys. 248 | CurveCP authenticates each party by showing they are able to produce 249 | the shared key, and it uses nested boxes to protect that authentication 250 | from eavesdroppers. 251 | 252 | \begin{proto}[CurveCP] 253 | 254 | $$ 255 | \begin{align*} 256 | ? \to B &: a_{p}, Box_{[a\cdot B]}(okay) \\ 257 | ? \gets B &: Box_{[a\cdot B]}(b_{p}) \\ 258 | A \to B &: Box_{[a\cdot b]}(A_p||Box_{[A \cdot B]}(a_{p}))\\ 259 | A \gets B &: Box_{[a\cdot b]}(okay) \\ 260 | \end{align*} 261 | $$ 262 | 263 | Alice sends her ephemeral key, $a_p$, and a boxed standard message to Bob. 264 | Bob boxes his ephemeral key back to Alice's ephemeral key. 265 | This convinces Alice of Bob's identity, a man in the middle fails 266 | at this point. Alice boxes (to $[a\cdot b]$) her long term key, $A_p$, 267 | with another box (to $[A\cdot B]$) containing her ephemeral key. 268 | If Bob is satisfied with this he responds with a standard message, 269 | boxed to the ephemeral keys\footnote{ 270 | Again, actually a 4 pass protocol. 271 | }. 272 | 273 | \end{proto} 274 | 275 | In CurveCP knowing Bob's public key functions as a capability 276 | to access Bob. Unfortunately, this protocol has some problems. 277 | 278 | \begin{enumerate} 279 | \item If Bob moves to a different address, a replay attack can 280 | confirm where, without knowing his public key. 281 | Since the first pass is encrypted only Bob will be able to respond, 282 | if it is replayed to a new server and that server responds, 283 | it suggests that server is Bob. 284 | Having this information could encourage the replay attacker 285 | to look for other security weaknesses. 286 | 287 | \item Worse, 288 | step 3 fails to include a fresh value from both sides of the 289 | exchange. Thus $(a, Box_{[A \cdot B]}(a_{p}))$ forms a reusable capability 290 | to authenticate to Bob as Alice\cite{ccp_review}. See also 291 | \cite{aake}[section 5.1, signing only one's own exponential]. 292 | 293 | \item Worst, CurveCP contains a wildcard capability. 294 | Because a curve25519 key is used for authentication, 295 | an actor who knows $B_{secret}$ \cite{ccp_review} can 296 | impersonate \emph{anyone} to Bob--In the literature 297 | this is called a Key Compromise Impersonation (KCI). 298 | If Conrad gains 299 | $B_{secret}$ he can impersonate \emph{anyone} to Bob. 300 | To impersonate Alice, Conrad would connect to Bob, 301 | create an ephemeral key $a$, box it to Bob, and when Bob responds, 302 | create $Box_{[a\cdot b]}(A_p||Box_{[A \cdot B]}(a_{p}))$, 303 | except using $(A_{public}, B_{secret})$, 304 | as Bob would when opening the box, not $(A_{secret}, B_{public})$ as 305 | Alice would when sealing it. If Conrad possesses $B_{secret}$ he can 306 | impersonate arbitrary keys to Bob. Thus, $B_{secret}$ is a wildcard 307 | capability, and CurveCP is not a well behaved capability system. 308 | 309 | \end{enumerate} 310 | 311 | \subsection{Deniable Key Exchange - OTR, Noise, TextSecure} 312 | 313 | There is a class of key exchange protocols which make deniability 314 | a design goal\cite{otr, textsecure, noise}. The argument for this 315 | is that when you engage in casual communication you do not create 316 | evidence that you said what you did. 317 | 318 | These protocols are unsuitable for a capability system for the same 319 | reason as STS---An unauthenticated client learns the server key in 320 | the second pass. This would be simple to fix, so whether a deniable 321 | key exchange can be a well behaved capability system deserves closer study. 322 | TextSecure\cite{textsecure} supersedes OTR\cite{otr}, but 323 | uses a 3rd party introducer and is thus not directly analogous to 324 | a key exchange, so we will examine the noise\cite{noise} protocol 325 | instead. 326 | 327 | Here we will extend the notation for shared keys to express keys shared 328 | between multiple pairs of keys. $a \cdot b | a \cdot B$ denotes 329 | the hash of $a \cdot b$ concatenated with $a \cdot B$. Only a party 330 | that can construct both the component keys can construct the composite 331 | key. 332 | 333 | \begin{proto}[noise] 334 | 335 | $$ 336 | \begin{align*} 337 | ? \to \;?\; &: a_{p} \\ 338 | ? \gets B &: b_{p}, Box_{[a\cdot b]}(B_{p}), Box_{[a\cdot b|a\cdot B]}(okay) \\ 339 | A \to B &: Box_{[a\cdot b]}(A_{p}), Box_{[a\cdot b|A\cdot b]}(okay) \\ 340 | A \gets B &: Box_{[a \cdot b | a \cdot B | A \cdot b]}(a_{p}|b_{p})\\ 341 | \end{align*} 342 | $$ 343 | 344 | Alice sends Bob her ephemeral key. Bob replies with his ephemeral key, 345 | a box containing his long term key, and a multi-keyed box as 346 | evidence he is Bob. Alice replies with 347 | a multi-key box as evidence she knows $a_{secret}$ and $A_{secret}$. 348 | Bob then sends back a boxed message showing he was also able 349 | to derive that shared secret\footnote{ 350 | like STS, it's really a 4 pass protocol 351 | } 352 | 353 | \end{proto} 354 | 355 | Note that unlike CurveCP, a shared key is not derived between long term 356 | keys, but instead only between an ephemeral key and a long term key, 357 | thus $B_{secret}$ is not a wildcard. 358 | 359 | Even if Alice suspects that Conrad may have compromised her long term 360 | key, $A$, she trusts that he surely cannot know her ephemeral key, $a$. 361 | Without knowing $a_{secret}$ Conrad cannot construct $a\cdot B$, unless 362 | it really \emph{is} Bob. To provide the same assurance to Bob, 363 | they end up with the three way key $a \cdot b | a \cdot B | A \cdot b$, 364 | as in TextSecure\cite{textsecure}. This seems reasonable, 365 | except $b_{secret}$ is now a wildcard! (though, since it is ephemeral, 366 | hopefully more difficult to gain) 367 | 368 | \begin{enumerate} 369 | \item The handshake is protected from eavesdroppers -- but 370 | anyone who connects to the server will be sent the public key, 371 | so $B_p$ is not useful as a capability. 372 | 373 | \item Key Compromise Impersonation is still possible, but harder -- To impersonate an 374 | arbitrary key to Bob you have to know Bob's ephemeral \emph{and} long 375 | term secret keys. This would be possible for anyone who had 376 | passive read access to Bob's memory -- at first 377 | glance this may seem like a unlikely proposition, but in fact 378 | if Bob is running on a rented virtual machine that 379 | is precisely the situation he would be in. 380 | In a well behaved system, knowing Bob's secret key \emph{should} 381 | give you the ability to authenticate \emph{as Bob}, but not as Alice. 382 | \end{enumerate} 383 | 384 | Problem 2 would be avoided if the protocol was only ever run on 385 | physical hardware---but this is unreasonable. 386 | Since it still contains a wildcard this protocol 387 | fails to form a well behaved capability system. Also, the property 388 | of deniability feels difficult to reason about. Will the higher level 389 | protocol introduce evidence of the communication? In any case, a secure 390 | channel is used for a lot more than casual social communications, 391 | and deniability does not appear to offer any special advantage 392 | to a capability system. 393 | 394 | \section{A New Design} 395 | 396 | If we take some ideas from the noise and TextSecure handshakes, 397 | but turn it around so that Alice authenticates first, 398 | then we get something that starts to look like a capability system. 399 | 400 | If Alice \emph{preauthenticates} Bob, then Bob can authenticate 401 | Alice using one more pass. With two initial passes to prevent 402 | replay attacks, we have a 4 pass protocol. This is no worse 403 | than the above, even though we do not authenticate anyone 404 | until the third pass. 405 | 406 | To ``preauthenticate'', Alice sends a proof of both her identity, 407 | and her intention to connect to Bob. Preauthentication can be 408 | implemented with both encryption and signatures. 409 | 410 | \begin{proto}[Deniable Capability Handshake] 411 | 412 | $$ 413 | \begin{align*} 414 | ? \to \;?\; &: a_{p} \\ 415 | ? \gets \;?\; &: b_{p} \\ 416 | A \to B &: Box_{[a \cdot b | a \cdot B]}(A_{p}) \\ 417 | A \gets B &: Box_{[a \cdot b | a \cdot B | A \cdot b]}(okay)\\ 418 | \end{align*} 419 | $$ 420 | 421 | Alice sends her ephemeral key to Bob, who responds with his. 422 | Then Alice boxes her long term key to Bob so that only he can open it. 423 | Bob shows his acceptance by boxing a standard message 424 | so that only Alice or Bob can read it. 425 | 426 | \end{proto} 427 | 428 | Requiring Alice to authenticate first is unusual, but 429 | I think this is a fair deal. Bob has already put himself 430 | at a disadvantage by allowing himself to be publicly 431 | addressable. It's only fair that Alice authenticates first. 432 | By encrypting her authentication she need not reveal her 433 | identity to anyone but the one true Bob. Likewise, if Bob chooses 434 | not to accept the call, then Alice won't be able to deduce 435 | whether or not it was really Bob. Maybe it was but he did not wish 436 | to speak to her? Maybe it was just a wrong number? This protects 437 | Bob from harassment. 438 | 439 | If Bob is unconcerned with the identity of his clients, 440 | he may allow anyone knowing $B_p$ to authenticate. A client can 441 | remain anonymous by using a second ephemeral identity. 442 | 443 | In this design Bob's public key is a capability, 444 | but it still has the wildcard (KCI) problem that 445 | noise and TextSecure have. 446 | 447 | Key exchange is required for confidentiality and 448 | forward security, but signatures are required to avoid wildcards. 449 | With signatures, we'll have a truly well behaved capability system. 450 | 451 | Since we will need both exchange and signing keys, 452 | an identity could be represented by a pair of signing and exchange keys. 453 | nacl uses ed25519 keys for signatures, and 454 | curve25519 keys for exchange. However, nacl also provides 455 | functions to convert signing to exchange keys, 456 | so an identity could be represented as a signing key, 457 | which would be converted to an exchange key when necessary. 458 | 459 | \begin{samepage} 460 | \begin{proto}[Capability-based Handshake] 461 | 462 | $$ 463 | \begin{align*} 464 | ? \to ? &: a_{p} \\ 465 | ? \gets ? &: b_{p} \\ 466 | H &= A_{p}|Sign_A(B_{p}|hash(a \cdot b)) \\ 467 | A \to B &: Box_{[a \cdot b | a \cdot B]}(H)\\ 468 | A \gets B &: Box_{[a \cdot b | a \cdot B | A \cdot b]}(Sign_B(H) )\\ 469 | \end{align*} 470 | $$ 471 | 472 | Alice and Bob exchange ephemeral keys, then Alice 473 | preauthenticates privately to Bob. Bob demonstrates his acceptance 474 | by privately signing her preauthentication. 475 | Note, that $a_{secret}$ and $b_{secret}$ are capabilities to decrypt 476 | the handshake, but since they are not wildcards we still have a well 477 | behaved capability system. 478 | 479 | \end{proto} 480 | \end{samepage} 481 | 482 | The design is getting much better. We resist eavesdropping, replay, 483 | man-in-the-middle, KCI attacks, and provide forward secrecy. 484 | There are no wildcards, nor unintended delegations. 485 | But there are still a few small issues to clear up. 486 | 487 | Implementations change, and so it is often helpful to have a protocol 488 | id and version associated with a handshake. 489 | Also, if either of the two initial passes are tampered with, it would 490 | be undetected until the first authenticated pass is received. 491 | It might also be nice to prevent different applications 492 | built on this protocol from interfering with each other. 493 | 494 | Most importantly, we must be careful to avoid creating a vulnerability 495 | to a Chosen Protocol Attack\cite{cpa}. If the signing keys are also used 496 | elsewhere, it's possible that a signature from this protocol could be 497 | reused, possibly creating an unintended delegation. 498 | All of these issues can be addressed via an application key ($K$) 499 | which is a capability to the protocol. The ephemeral keys can be 500 | authenticated by using the $K$ as the key to an $hmac$. By including 501 | $K$ in each signature it is demonstrated that the signature belongs 502 | within this protocol, mitigating CPA. It is vital that if there are any 503 | other cases where a signing key is used, then a similar level of care is 504 | taken to ensure unambiguous interpretation of signatures. 505 | 506 | $K$ is a capability to access \emph{an instance of this protocol}\footnote{ 507 | i.e. an application which is built on it. 508 | $K$ should be updated if the implementation of the application changes 509 | incompatibly. If backwards compatibility is required, the new protocol 510 | version could be used on a new port, until the legacy version is fully 511 | deprecated. For an openly specified application $K$ may be publicly 512 | known. For a private application it may be a closely guarded secret. 513 | } 514 | An eavesdropper cannot extract $K$ from the cipher-text, but it can 515 | confirm a correct guess at $K$. In the case where $K$ is widely known, 516 | and an attacker that knows $K$ tampers with an initial pass but creates 517 | avalid $hmac_K$, their interference will still be detected when the 518 | third pass is received. 519 | 520 | \begin{samepage} 521 | \begin{proto}[Secret Handshake] 522 | 523 | $$ 524 | \begin{align*} 525 | ? \to \;?\; &: a_{p}, hmac_{K}(a_{p}) \\ 526 | ? \gets \;?\; &: b_{p}, hmac_{[K|a\cdot b]}(b_{p}) \\ 527 | H&=A_{p}|Sign_A(K|B_{p}|hash(a\cdot b)) \\ 528 | A \to B &: Box_{[K|a \cdot b | a \cdot B]}(H)\\ 529 | A \gets B &: 530 | Box_{[K|a \cdot b | a \cdot B | A \cdot b]}(Sign_B(K|H|hash(a\cdot b)) )\\ 531 | \end{align*} 532 | $$ 533 | 534 | The same as the previous, but the shared key starts 535 | as $K$, and is extended as more public keys are learned. 536 | Alice's authentication, $A_{p}|sign_A(K|B_p|hash(a\cdot b))$, 537 | proves that she possesses $A$, and that the proof is for this protocol 538 | (via $K$) and this handshake (via $hash(a\cdot b)$). 539 | In case Bob does not yet have Alice's key, we delegate it to him 540 | (obviously we want Bob to have that capability, or Alice would not have 541 | contacted him). 542 | \end{proto} 543 | \end{samepage} 544 | 545 | For Bob to authenticate back to Alice, he could just sign the proof 546 | Alice sent him, and send it back. $H$ is already cryptographically 547 | linked to the preceding passes. On the other hand, it is easier to 548 | persuade ourselves that signing $K$ mitigates CPA\cite{cpa} than that 549 | $A_p$ is never the application key in another protocol. 550 | 551 | Alice and Bob can now use their shared secret, 552 | $K|a \cdot b|a \cdot B|A \cdot b$, with a bulk encryption protocol 553 | to secure a two-way communication channel. 554 | 555 | \section{Future Work} 556 | 557 | The latency of a 4 pass protocol may be prohibitive for some 558 | applications. A mechanism to prearrange a single-use 559 | key for the next session may enable a two pass protocol, at least 560 | once a given pair of actors have established contact. 561 | 562 | Some readers will be wondering how Alice is to learn Bob's public key? 563 | The conceptual framework of capability systems has a simple answer: 564 | someone delegates it to her. In practice, there is a large design space 565 | in the how and why. 566 | Briefly, there could be a centralized registry, a DHT, a gossip network, 567 | or access caps could be configured in files. Various combinations of 568 | the above are likely, or different systems entirely. 569 | 570 | \section{Conclusion} 571 | 572 | I have described a highly private 4 pass handshake protocol 573 | that is suitable for capability systems. It does not suffer 574 | from replay, eavesdropping, man in the middle, 575 | or key compromise impersonation. 576 | Capability Systems provide a conceptual framework for both 577 | distributing and restricting access, thus it is a helpful 578 | guide when justifying decisions. 579 | In cryptographic capability systems like this protocol, public and 580 | private keys are simply \emph{access rights}. This allows us to 581 | think otherwise unthinkable thoughts, such as the notion of a 582 | \emph{secret public key} or a \emph{shared private key}. 583 | With concepts like these, we can create dynamic 584 | layers of access and restrictions. Since \emph{Secret Handshake} is 585 | otherwise unopinionated, and secure two-way communication is fundamental, 586 | if it was combined with a suitable streaming bulk encryption protocol, 587 | it could be a powerful building block for decentralized access 588 | control systems. 589 | 590 | \section*{Acknowledgements} 591 | 592 | I would like to thank Tristan Slominski, Paul Frazee, James Haliday, 593 | and David Stainton for reading drafts of this paper and useful comments. 594 | 595 | \bibliographystyle{plain} 596 | 597 | \bibliography{shs} 598 | 599 | \end{document} 600 | 601 | 602 | 603 | 604 | -------------------------------------------------------------------------------- /shs.tex.bak: -------------------------------------------------------------------------------- 1 | \documentclass[12pt]{article} 2 | \usepackage{amsmath} % great math stuff 3 | \usepackage{amsfonts} % for blackboard bold, etc 4 | \usepackage{amsthm} % better theorem environments 5 | \usepackage{graphicx} 6 | 7 | \newtheorem{proto}{Protocol} 8 | 9 | \begin{document} 10 | \title{Designing a Secret Handshake: Authenticated Key Exchange as a Capability System} 11 | \author{Dominic Tarr} 12 | 13 | 14 | \maketitle 15 | 16 | \begin{abstract} 17 | Capability Based Security is a logical framework for designing 18 | access control systems, yet there is no widely implemented protocol 19 | for establishing 20 | secure two-way communication that also forms a capability system. 21 | We examine the ways various key exchange protocols fail to 22 | form capability systems, and then present a secure key 23 | exchange protocol designed with capability systems in mind. 24 | In this protocol, the server's public key forms an access capability. 25 | Using a preauthentication step, we authenticate the client before 26 | the server, but still accomplish mutual authentication within 4 passes. 27 | Included is a discussion of how the overall framework of capability 28 | systems guides the design process and simplifies many of the decisions 29 | involved in making a key exchange system. 30 | 31 | \end{abstract} 32 | 33 | \section{Introduction} 34 | 35 | The development of key exchange algorithms marked the dawn of 36 | modern cryptography\cite{ndic}. Their development was motivated 37 | by the desire for secure communications between two parties---yet 38 | designing a practical and secure protocol for exchanging 39 | a shared key between two authenticated parties is non-trivial\cite{aake}. 40 | 41 | Much of the research into key exchange has produced whole ``families'' of 42 | protocols \cite{sigma}. Protocols currently in widespread 43 | use tend to be layered and configurable (TLS, SSH). This is not 44 | to the benefit of application developers---gaining a sufficiently 45 | nuanced understanding of such cryptosystems takes considerable study. 46 | Providing the developer with \emph{more options} is to provide them 47 | with \emph{more opportunities} to add critical security flaws to their 48 | application. Thus, recent thought has steered towards providing simple constructions 49 | with security properties that are easy to understand and use safely 50 | \cite{nacl}. We apply this philosophy to the design of an authenticated 51 | key exchange - a secret handshake. Since a key exchange can be designed 52 | with so many possible properties, we adopt the framework of capability 53 | systems\cite{unicap} and allow that to drive the design. 54 | TahoeLAFS\cite{tahoe} is the inspiration for this decision. 55 | We find that no currently available handshake protocol adequately meets 56 | the needs of a capability system. Interestingly, a capability system 57 | demands a higher degree of privacy than is provided by other available 58 | protocols. 59 | 60 | We will describe various key exchange protocols and examine why they 61 | are not suitable for a capabality system. We will discuss these 62 | protocols abstractly, giving sufficient details to demonstrate their 63 | cryptographic properties. In some cases, this means ignoring details 64 | required for their actual implementation, for example the handling of 65 | nonces. Finally, we will describe our capability based key exchange 66 | protocol. 67 | 68 | \section{Capability Systems} 69 | 70 | In a capability system, the right to access a resource is granted 71 | to the bearer of a \emph{capability} (cap). Capability 72 | Based Security predates modern cryptography, but its concepts 73 | map cleanly to the decentralized access control systems 74 | enabled by cryptography. \footnote{ 75 | There are limitations to a cryptographic capability system. 76 | It is possible to implement what \emph{Capability Myths Demolished}\cite{capmyths} 77 | describes as the \emph{Capabilities as Keys} model. In this model, 78 | the user cannot be prevented from performing a delegations through any 79 | channel they can write data to. 80 | Contrast this with the \emph{Object Capability} model, which incorporates 81 | a strict type system that can distinguish between data and capabilities, 82 | and thus prevent capabilities from being written as data. 83 | } 84 | 85 | For example, possessing the key to decrypt a file means you have 86 | the \emph{capability} to \emph{read} that file. This can be implemented 87 | in a decentralized fashion: An encrypted file is widely distributed 88 | via a peer to peer network, but the read-cap is delegated 89 | only to a trusted few. Contrast this with an Access 90 | Control List (ACL), the file is kept on a server, and only those 91 | who can correctly authenticate can access the file: Like a bouncer 92 | at a nightclub, a trusted gatekeeper is required to administer the 93 | access list. A decentralized ACL is not possible. 94 | 95 | 96 | \textsc{Delegation} is the act of granting an one of your access 97 | rights to another actor by sending them a capability. 98 | In a well behaved capability system, there is no way to gain a 99 | particular access right except through delegation. 100 | 101 | \textsc{Unintended Delegation}. If you give your car keys to a valet 102 | to park your car, that is delegation. If you leave your keys in your 103 | car and it is stolen--that is an \emph{unintended delegation}, 104 | or a \emph{misdelegation}. It is not the same as if someone forcibly 105 | gained entry to your car and hotwired it. If someone ``steals'' your 106 | car because you mistakenly gave them the keys, it is your own fault. 107 | It is our responsibility as protocol designers to not build 108 | misdelegations into the protocol itself.\footnote{ 109 | AES is an example of a protocol that has been shown to contain a 110 | misdelegation\cite{aestiming} (secure AES implementations are possible, 111 | but suffer from poor performance). 112 | A good protocol design cannot prevent a malicious implementer, 113 | but it can mitigate the effects of 114 | an incompetent one. Thus, a good protocol design at least prevents 115 | a malicious implementer from \emph{fiening incompetence}\cite{underhanded}. 116 | Thankfully, maliciousness is far less common than incompetence. 117 | } If a system has unintended delegations at the protocol level, 118 | it is not a well behaved capability system. 119 | 120 | \textsc{Wildcard}. In some card games there is a designated ``wildcard'' 121 | that can be played as any other card. A token is called a \emph{wildcard} 122 | if it enables a set of rights that should have to be delegated 123 | individually. 124 | I know of no cryptosystem that is designed intentionally to contain 125 | wildcards. Presence of an unintended wildcard in a capability 126 | system should be considered a design failure. 127 | 128 | \textsc{Well Behaved}. A capability system is 129 | \emph{well behaved} if it supports delegation but lacks unintended 130 | delegations and wildcards. 131 | 132 | \section{Notation} 133 | 134 | $A \to B$ signifies a message passed from client to server, and 135 | $A \gets B$ signifies a response. It's important to understand 136 | at what point a party becomes authenticated, and at what point 137 | that party knows it. If $A$ or $B$ is replaced with $?$ it 138 | means that party is not yet authenticated, to the knowledge 139 | of the receiver. If Alice receives a message $? \gets B$ it means 140 | she now knows who Bob is, but Bob doesn't know who she is. 141 | A handshake is not complete until both parties know who they are 142 | talking to, and know the other party also knows. Thus a handshake 143 | does not end until two passes marked $A \to B$ and $A \gets B$ 144 | are exchanged. 145 | 146 | When a key pair is an argument to a function, 147 | it's represented as a subscript. When a key is sent in a message, 148 | only the public key is used, to be explicit I write that as $A_p$. 149 | 150 | Long term keys for Alice and Bob are represented by $A,B$, 151 | and ephemeral keys are $a,b$. $a \cdot b$ denotes a shared key derived 152 | from $a$ and $b$. Again, when this is a function argument it is shown 153 | as the subscript, $Box_{[a\cdot b]}(msg)$. Note that 154 | $Box$ is authenticated encryption, it has the 155 | properties of a mac as well as of encryption. $|$ denotes concatenation. 156 | 157 | Finally, whenever a message is received it is immediately verified 158 | and if invalid the handshake is aborted. 159 | 160 | \section{Prior Art} 161 | 162 | \subsection{Authenticated Key Exchange - STS, TLS, SSH} 163 | 164 | Here I will describe the Station To Station (STS) protocol\cite{aake}. 165 | This design forms the basis of most popular protocols (TLS, SSH) 166 | except without encrypting the keys or signatures (remember that $Box$ 167 | is authenticated so $Box_k(msg)$ can be replaced with $mac_k(msg)$, 168 | and it will still constitute a proof of possession of the secret $k$.) 169 | 170 | \begin{proto}[Station to Station] 171 | 172 | $$ 173 | \begin{align*} 174 | \\ 175 | ? \to \;?\; &: a_p \\ 176 | ? \gets B &: b_p, Box_{[a\cdot b]}(B_p | Sign_B(a_p|b_p)) \\ 177 | A \to B &: Box_{[a\cdot b]}(A_p | Sign_A(a_p | b_p)) \\ 178 | A \gets B &: Box_{[a\cdot b]}(okay) \\ 179 | \\ 180 | \end{align*} 181 | $$ 182 | 183 | Alice sends a fresh ephemeral key to Bob, who creates one too, 184 | signs both keys and sends them back with his public key. 185 | Alice then boxes her public key and a signature to prove her identity. 186 | Finally, Bob boxes a standard message to show his acceptance. 187 | 188 | \end{proto} 189 | 190 | Neither party can be assured of the freshness of a message 191 | unless it is a cryptographic reply to a known fresh value, 192 | i.e. a value they freshly created. Hence, it is pointless for Alice 193 | to send her identity in the first pass. Bob cannot be sure it truly her 194 | until the third pass at the earliest. 195 | 196 | However, Alice can know Bob's first message is fresh, so STS and many 197 | other protocols send the server authentication as the second pass. 198 | To resist an identity misbinding attack we require proof that the 199 | other party possesses the shared secret $a\cdot b$. Authenticated encryption, 200 | $Box_{[a\cdot b]}$, or a mac accomplishes that \cite[section 3.1]{sigma} 201 | 202 | Often the description of a handshake protocol ends as soon 203 | as each party is authenticated, but before the client \empf{knows} 204 | it is authenticated. If this is the case, the client could receive 205 | an authentication error (or dropped connection) at the application 206 | layer, which is awkward. Thus, they do not know they've been accepted 207 | until receiving the first encrypted message. For this reason 208 | I've presented STS as a 4 pass protocol, even though the original 209 | paper describes it as a 3 pass protocol. 210 | 211 | Is STS suitable for a capability system? No. The first thing STS 212 | does is authenticate the server, but the first question a capability 213 | system should ask is whether the client has the capability to 214 | this resource. Since Alice needs to know $B_p$ to authenticate 215 | Bob \emph{anyway}, it makes an excellent candidate for an access cap. 216 | 217 | However, by authenticating Bob first, and sending his public key to 218 | an unauthenticated client, the public keys are delegated to anyone 219 | who initiates the protocol with Bob. Because of this unnecessary 220 | delegation, STS is not very useful as a capability system. 221 | 222 | \subsection{Encrypted Authenticated Key Exchange - CurveCP} 223 | 224 | CurveCP\cite{curvecp} implements authentication relying only on 225 | nacl's\cite{nacl} $Box$ primitive, which uses curve25519 keys. 226 | curve25519 keys are combined via scalar multiplication to produce 227 | shared keys, like Diffie Helman keys\cite{ndic}, not signing keys. 228 | CurveCP authenticates each party by showing they are able to produce 229 | the shared key, and it uses nested boxes to protect that authentication 230 | from eavesdroppers. 231 | 232 | \begin{proto}[CurveCP] 233 | 234 | $$ 235 | \begin{align*} 236 | \\ 237 | ? \to \;?\; &: a_p, Box_{[a\cdot B]}(okay) \\ 238 | ? \gets B &: Box_{[a\cdot B]}(b_p) \\ 239 | A \to B &: Box_{[a\cdot b]}(A_p||Box_{[A \cdot B]}(a_p))\\ 240 | A \gets B &: Box_{[a\cdot b]}(okay) \\ 241 | \\ 242 | \end{align*} 243 | $$ 244 | 245 | Alice boxes an ephemeral key, $a_p$ and a standard message to Bob, 246 | Because it may be a replay It's marked as $? \to \;?$. 247 | Bob boxes his ephemeral key back to Alice's ephemeral key. 248 | This convinces Alice of Bob's identity, a man in the middle fails 249 | at this point. Alice boxes (to $[a\cdot b]$) her long term key, $A_p$, 250 | with another box (to $[A\cdot B]$) containing her ephemeral key. 251 | If Bob is satisified with this he responds with a standard message, 252 | boxed to the ephemeral keys. 253 | 254 | \end{proto} 255 | 256 | In CurveCP knowing Bob's public key functions as a capability 257 | to access Bob. Unfortunately, this protocol has two problems. 258 | 259 | \begin{enumerate} 260 | \item If Bob moves to a different address, a replay attack can 261 | confirm where, without knowing his public key. 262 | Since the first packet is encrypted only Bob will be able to respond, 263 | so a response suggests it \emph{is}. 264 | Having this information could encourage the replay attacker 265 | to look for other security weaknesses. 266 | 267 | \item Worse, 268 | step 3 fails to includes a fresh value from both sides of the 269 | exchange. Thus $(a, Box_{[A \cdot B]}(a_p))$ forms a reusable capability 270 | to authenticate to Bob as Alice\cite{ccp_review}. See also 271 | \cite{aake}[section 5.1, signing only one's own exponential]. 272 | 273 | \item Worst, CurveCP contains a wildcard capability. 274 | By using curve25519 key sharing for authentication, CurveCP 275 | enables Key Compromise Impersonation (KCI) by someone who 276 | knows $B_{secret}$ \cite{ccp_review}. If Conrad gains 277 | $B_{secret}$ he can impersonate \emph{anyone} to Bob. 278 | To impersonate Alice, Condrad would connect to Bob, 279 | create an ephemeral key $a$, box it to Bob, and when Bob responds, 280 | create $Box_{[a\cdot b]}(A_p||Box_{[A \cdot B]}(a_p))$, 281 | except using $(A_{public}, B_{secret})$, 282 | as Bob would when opening the box, not $(A_{secret}, B_{public})$ as 283 | Alice would when sealing it. If Conrad possesses $B_{secret}$ he can 284 | impersonate arbitary keys to Bob. Thus, $B_{secret}$ is a wildcard 285 | capability, and CurveCP is not a well behaved capability system. 286 | 287 | \end{enumerate} 288 | 289 | \subsection{Deniable Authenticated Key Exchange - OTR, Noise, TextSecure} 290 | 291 | There is a class of key exchange protocols which make deniability 292 | a design goal\cite{otr, textsecure, noise}. The argument for this 293 | is that when you engage in casual communication you do not create 294 | evidence that you said what you did. 295 | 296 | These protocols are unsuitable for a capability system for the same 297 | reason as STS---An unauthenticated client learns the server key in 298 | the second pass. This would be simple to fix, so whether a deniable 299 | key exchange can be a well behaved capability system deserves closer study. 300 | TextSecure\cite{textsecure} supercedes OTR\cite{otr}, but 301 | uses a 3rd party introducer and is thus not directly analogous to 302 | a key exchange, so we will examine the noise\cite{noise} protocol 303 | instead. 304 | 305 | Here we will extend the notation for shared keys to express keys shared 306 | between multiple pairs of keys. $a \cdot b | a \cdot B$ denotes 307 | the hash of $a \cdot b$ concatenated with $a \cdot B$. Only a party 308 | that can construct both the component keys can construct the composite 309 | key. 310 | 311 | \begin{proto}[noise] 312 | 313 | $$ 314 | \begin{align*} 315 | \\ 316 | ? \to \;?\; &: a_p \\ 317 | ? \gets B &: b_p, Box_{[a\cdot b]}(B_p), Box_{[a\cdot b|a\cdot B]}(okay) \\ 318 | A \to B &: Box_{[a\cdot b]}(A_p), Box_{[a\cdot b|A\cdot b]}(okay) \\ 319 | A \gets B &: Box_{[a \cdot b | a \cdot B | A \cdot b]}(a_p|b_p)\\ 320 | \\ 321 | \end{align*} 322 | $$ 323 | 324 | Alice sends Bob her ephemeral key. Bob replies with his ephemeral key, 325 | a box containing his long term key, and a multikeyed box as 326 | evidence he is Bob. Alice replies with 327 | a multikey box as evidence she knows $a_{secret}$ and $A_{secret}$. 328 | Bob then sends back a boxed message showing he was also able 329 | to derive that shared secret (like STS, it's really a 4 pass protocol) 330 | 331 | \end{proto} 332 | 333 | Note that unlike CurveCP, a shared key is not derived between long term 334 | keys, but instead only between an ephemeral key and a long term key, 335 | thus $B_{secret}$ is not a wildcard. 336 | 337 | Even if Alice suspects that Conrad may have compromised her long term 338 | key, $A$, she trusts that he surely cannot know her ephemeral key, $a$. 339 | Without knowing $a_{secret}$ Conrad cannot construct $a\cdot B$, unless 340 | it really \emph{is} Bob. To provide the same assurance to Bob, 341 | they end up with the three way key $a \cdot b | a \cdot B | A \cdot b$, 342 | as in TextSecure\cite{textsecure}. This seems reasonable, 343 | except $b_{secret}$ is now a wildcard! (though, since it is ephemeral, 344 | hopefully more difficult to gain) 345 | 346 | \begin{enumerate} 347 | \item The handshake is protected from eavesdroppers -- but 348 | anyone who connects to the server will be sent the public key, 349 | so $B_p$ is not useful as a capability. 350 | 351 | \item KCI is still possible, but harder -- To impersonate an 352 | arbitary key to Bob you have to know Bob's ephemeral \emph{and} long 353 | term secret keys. This would be possible for anyone who had 354 | passive read access to Bob's memory -- at first 355 | glance this may seem like a unlikely proposition, but in fact 356 | if Bob is running on a rented virtual machine that 357 | is precisely the situation he would be in. 358 | In a well behaved system, knowing Bob's private key \emph{should} 359 | give you the ability to authenticate \emph{as Bob}, but not as Alice. 360 | \end{enumerate} 361 | 362 | Problem 2 would be avoided if the protocol was only ever run on 363 | physical hardware---but this is unreasonable. 364 | Since it still contains a wildcard this protocol 365 | fails to form a well behaved capability system. Also, the property 366 | of deniability feels difficult to reason about. Will the higher level 367 | protocol introduce evidence of the communication? In any case, a secure 368 | channel is used for a lot more than casual social communications, 369 | and deniability does not appear to offer any special advantage 370 | to a capability system. 371 | 372 | \section{A New Design} 373 | 374 | If we take some ideas from the noise and TextSecure handshakes, 375 | but turn it around so that Alice authenticates first, 376 | then we get something that starts to look like a capability system. 377 | 378 | If Alice \emph{preauthenticates} Bob, then Bob can authenticate 379 | Alice using one more pass. With two initial passes to prevent 380 | replay attacks, we have a 4 pass protocol. This is no worse 381 | than the above, even though we do not authenticate anyone 382 | until the third pass. 383 | 384 | To ``preauthenticate'', Alice sends a proof of both her identity, 385 | and her intention to connect to Bob. Preauthentication can be 386 | implemented with both encryption and signatures. 387 | 388 | \begin{proto}[Denyable Capability Handshake, flawed] 389 | 390 | $$ 391 | \begin{align*} 392 | \\ 393 | ? \to \;?\; &: a_p \\ 394 | ? \gets \;?\; &: b_p \\ 395 | A \to B &: Box_{[a \cdot b | a \cdot B]}(A_p) \\ 396 | A \gets B &: Box_{[a \cdot b | a \cdot B | A \cdot b]}(okay)\\ 397 | \\ 398 | \end{align*} 399 | $$ 400 | 401 | Alice sends her ephemeral key to Bob, who responds with his. 402 | Then Alice boxes her long term key to Bob so that only he can open it. 403 | Bob shows his acceptance by boxing a standard message 404 | so that only Alice or Bob can read it. 405 | 406 | \end{proto} 407 | 408 | Requiring Alice to authenticate first is unusual, but 409 | I think this is a fair deal. Bob has already put himself 410 | at a disadvantage by allowing himself to be publically 411 | addressable. It's only fair that Alice authenticates first. 412 | By encrypting her authentication she need not reveal her 413 | identity to anyone but the one true Bob. Likewise, if Bob chooses 414 | not to accept the call, then Alice won't be able to deduce 415 | whether or not it was really Bob. Maybe it was but he did not wish 416 | to speak to her? Maybe it was just a wrong number? This protects 417 | Bob from harassment. 418 | 419 | If Bob is unconcerned with the identity of his clients, 420 | he may allow anyone knowing $B_p$ to authenticate. A client can 421 | remain anonymous by using a second ephemeral identity. 422 | 423 | In this design Bob's public key forms as a capability, 424 | but it still has the wildcard (KCI) problem that 425 | noise and TextSecure have. 426 | 427 | Key exchange is required for confidentiality and 428 | forward security, but signatures are required to avoid wildcards. 429 | With signatures, we'll have a truly well behaved capability system. 430 | 431 | Since we will need both exchange and signing keys, 432 | an identity could be represented by a pair of signing and exchange keys. 433 | nacl uses ed25519 keys for signatures, and 434 | curve25519 keys for exchange. However, nacl also provides 435 | functions to convert signing to exchange keys, 436 | so an identity could be represented as a signing key, 437 | which would be converted to an exchange key when necessary. 438 | 439 | \begin{proto}[Capability-based Handshake] 440 | 441 | $$ 442 | \begin{align*} 443 | \\ 444 | ? \to ? &: a_p \\ 445 | ? \gets ? &: b_p \\ 446 | H &= A_{p}|Sig_A(B_p|hash(a \cdot b)) \\ 447 | A \to B &: Box_{[a \cdot b | a \cdot B]}(H)\\ 448 | A \gets B &: Box_{[a \cdot b | a \cdot B | A \cdot b]}(Sig_B(H) )\\ 449 | \\ 450 | \end{align*} 451 | $$ 452 | 453 | Alice and Bob exchange ephemeral keys, then Alice 454 | preauthenticates privately to Bob. Bob demonstrates his acceptance 455 | by privately signing her preauthentication. 456 | Note, that $a_{secret}$ and $b_{secret}$ are capabilites to decrypt 457 | the handshake, but since they are not wildcards we still have a well 458 | behaved capability system. 459 | 460 | \end{proto} 461 | 462 | The design is getting much better. We resist eavesdropping, replay, 463 | man-in-the-middle, KCI attacks, and provide forward secrecy. 464 | There are no wildcards, nor unintended delegations. 465 | But there remain a few minor niggles to tidy up. 466 | 467 | It is often helpful to have a protocol id and version associated 468 | with a handshake. Currently, we have no way to know if Alice and 469 | Bob are not speaking exactly the same protocol. 470 | Also, if either of the two initial passes are tampered with, it would 471 | be undetected until the first authenticated pass is received. 472 | It might also be nice to prevent different applications 473 | built on this protocol from interfering with each other. 474 | 475 | Most importantly, we must be careful to avoid creating a vulnerability 476 | to a Chosen Protocol Attack\cite{cpa}. If the signing keys are also used 477 | elsewhere, it's possible that a signature from this protocol could be 478 | reused elsewhere, possibly creating an unintended delegation. 479 | All of these issues can be addressed via an application key ($K$) 480 | which forms a capability to the protocol. The ephemeral keys can be 481 | authenticated by using the $K$ as the key to an $hmac$. By including 482 | $K$ in each signature it is demonstrated that the signature belongs 483 | within this protocol, mitigating CPA. It is vital that if there are any 484 | other cases where a signing key is used, then a similar level of care is 485 | taken to ensure unambigious interpretation of signatures. 486 | 487 | $K$ is a capability to access all actors that speak this protocol 488 | (or an application built on it). It should be updated if the 489 | implementation of the application or protocol changes incompatibly. 490 | If backwards compatibility is required, the new protocol version could 491 | be used on a new port, until the legacy version is fully deprecated. 492 | For an openly specified application $K$ may be publicly known. 493 | For a private application it may be a closely guarded secret. 494 | An eavesdropper cannot extract $K$ from the ciphertext, but it can 495 | confirm a correct guess at $K$. In the case where $K$ is widely known, 496 | and an attacker tampers with an initial pass but creates a valid hmac, 497 | their interference will still be detected once the third pass is received. 498 | 499 | \begin{proto}[Secret Handshake] 500 | 501 | $$ 502 | \begin{align*} 503 | \\ 504 | ? \to \;?\; &: a_p, hmac_{K}(a_p) \\ 505 | ? \gets \;?\; &: b_p, hmac_{[K|a\cdot b]}(b_p) \\ 506 | H&=A_{p}|sign_A(K|B_p|hash(a\cdot b)) \\ 507 | A \to B &: box_{[K|a \cdot b | a \cdot B]}(H)\\ 508 | A \gets B &: 509 | box_{[K|a \cdot b | a \cdot B | A \cdot b]}(sign_B(K|H|hash(a\cdot b)) )\\ 510 | \\ 511 | \end{align*} 512 | $$ 513 | 514 | The same as the previous, but at each pass, the shared key starts 515 | as $K$, and is extended as more public keys are learned. 516 | Alice's authentication, $A_{p}|sign_A(K|B_p|hash(a\cdot b))$, 517 | proves that she possesses $A$, and that the proof is for this protocol 518 | (via $K$) and this handshake (via $hash(a\cdot b)$). 519 | Incase Bob does not yet have Alice's key, we delegate it to him 520 | (obviously we want Bob to have that capability, or Alice would not have 521 | contacted him). 522 | \end{proto} 523 | 524 | For Bob to authenticate back to Alice, he could just sign the proof 525 | Alice sent him, and send it back. $H$ is already cryptographically 526 | linked to the preceding passes. On the other hand, it is easier to 527 | persuade ourselves that signing $K$ mitigates CPA\cite{cpa} than that 528 | $A_p$ is never the application key in another protocol. 529 | 530 | Alice and Bob can now use their shared secret, 531 | $K|a \cdot b|a \cdot B|A \cdot b$, with a bulk encryption protocol 532 | to secure a two-way communication channel. 533 | 534 | \section{Future Work} 535 | 536 | The latency of a 4 pass protocol may be prohibitive for some 537 | applications. A mechanism to prearrange a single-use 538 | key for the next session may enable a two pass protocol, at least 539 | once a given pair of actors have established contact. 540 | 541 | Some readers will be wondering how Alice is to learn Bob's public key? 542 | The conceptual framework of capability systems has a simple answer: 543 | someone delegates it to her. In practice, there is a large design space 544 | in the how and why. 545 | Briefly, there could be a centralized registry, a DHT, a gossip network, 546 | or access caps could be configured in files. Various combinations of 547 | the above are likely, or different systems entirely. 548 | 549 | \section{Conclusion} 550 | 551 | I have described a highly private 4 pass handshake protocol 552 | that is suitable for capability systems. It does not suffer 553 | from replay, eavesdropping, man in the middle, 554 | or key compromise impersonation. 555 | Capability Systems provide a conceptual framework for security 556 | based not on distributing access, but by restricting it. 557 | In a cryptographic capability system like this one, public and 558 | private keys are simply \emph{access rights}. This allows us to 559 | think otherwise unthinkable thoughts, such as the notion of a 560 | \emph{secret public key} or a \emph{shared private key}. 561 | With concepts like these, we could create dynamic 562 | layers of access and restrictions. Since \emph{Secret Handshake} is 563 | otherwise unopinionated, and secure two-way communication is fundamental, 564 | if it was combined with a suitable streaming bulk encryption protocol, 565 | it could form a powerful building block for decentralized access 566 | control systems. 567 | 568 | \bibliographystyle{plain} 569 | 570 | \bibliography{shs} 571 | 572 | \end{document} 573 | 574 | 575 | 576 | 577 | --------------------------------------------------------------------------------