Browse files

Placeholder sections/random notes

  • Loading branch information...
1 parent f42a4f2 commit 933adebe4d8bd33c39ba24959fc3f3c4cb8965c9 @ept ept committed Apr 14, 2014
Showing with 53 additions and 1 deletion.
  1. +3 −1 paper/octokey.tex
  2. +36 −0 paper/protocol.tex
  3. +4 −0 paper/provision.tex
  4. +10 −0 paper/references.bib
@@ -18,8 +18,10 @@
% TODO: OAuth-like thing by adding a third party's public key to your account
@@ -0,0 +1,36 @@
+\section{Octokey client-server protocol}
+Octokey is a user authentication protocol designed to meet the goals stated in the introduction. It
+aims to provide good security in a software-only configuration, with cryptographic hardware modules
+being an optional extra. It strives to be a \emph{trust-free} protocol: it is completely
+decentralised, there is no dependency on any identity provider, and the extent to which certificate
+authorities need to be trusted is minimised as far as possible.
+\subsection{Channel binding}
+Question: how to bind the Octokey signature to the TLS channel in a mobile app, where the TLS
+connection will probably get torn town when switching to the Octokey app? Set up OBC first (before
+Origin-Bound Certificates (OBC)~\cite{Dietz12} should be used to protect the session cookie from
+MITM attackers.
+Note that channel binding does not protect against all MITM attack scenarios. For example, in an
+e-commerce setting, an attacker who has stolen the website's private key, or who has fraudulently
+obtained a certificate from a CA trusted by the user's browser, can still impersonate the website.
+If the user does not notice the impersonation, and enters their credit card number to make a
+purchase, the attacker is able to steal the credit card number. In situations like these -- where
+the user is providing confidential information to the service -- the PKI still needs to be trusted.
+However, in situations where the flow of confidential information is from the service to the
+authenticated user, channel binding is an effective additional protection against MITM attacker
+trying to steal that information.
+Another attack vector is via JavaScript injected into the user's browser by a MITM attacker. Any
+code that executes within the context of a document in the browser has full access to the contents
+of that document. A page that is served to an authenticated user may download JavaScript code on
+separate TLS connections, for example from a content delivery network (CDN). If a MITM attacker is
+able to impersonate the CDN, they can inject arbitrary JavaScript into the browser.
+To prevent this, the page should not directly execute JavaScript that is downloaded. Instead, it
+should fetch JavaScript from the server using XMLHttpRequest over an authenticated TLS connection.
@@ -0,0 +1,4 @@
+\section{Provisioning new devices}
+Question: how does Octokey know that a certain website URL is the same service as a certain iOS
+bundle ID, which is the same service as an Android app signed with a certain public key?
@@ -109,3 +109,13 @@ @inproceedings { Parsovs14
month = {Feb},
howpublished = "\url{}"
+ author = {Dietz, Michael and Czeskis, Alexei and Balfanz, Dirk and Wallach, Dan S},
+ title = {{O}rigin-{B}ound {C}ertificates: A Fresh Approach to Strong Client Authentication for the Web},
+ booktitle = {21st USENIX Security Symposium},
+ year = {2012},
+ pages = {317--332},
+ month = {Aug},
+ howpublished = "\url{}"

0 comments on commit 933adeb

Please sign in to comment.