![](bg2.png)
cate users, without suffering from P1, and once a user
is authenticated, they can proceed and enjoy a third-
party service. In the case of private key leakage, a
user can simply revoke their key which is known only
to our system, without being affected by P2.
Why Keybase? We build KAuth on Keybase for
two major reasons. First, Keybase offers several op-
tions for cryptographic operations. We, also, assume
that in the future Keybase can incorporate additional
cryptographic ciphers. Second, Keybase offers most
of the features through a user-friendly environment,
such a web browser. For instance, when a user needs
to authenticate with Keybase, a passphrase is used to
derive a cryptographic key that will carry out an Ed-
DSA signing process. The whole process is imple-
mented in the web browser and resembles a typical
password-base authentication routine, but it is not.
Is Keybase Secure? Keybase is a relatively new
platform and it is likely to suffer from vulnerabili-
ties that are not exploited, yet. For instance, Keybase
uses Elliptic Curves for user authentication, which are
much more under-researched than RSA. In this paper,
we use Keybase mostly as a reference implementation
and we argue that cryptographic primitives can be of-
fered in a user-friendly way, while realizing a much
more stronger authentication to users.
In fact, our vision is that authentication should be
provided with options and users should be able to be
selective. Nowadays, many authentication proposals
are never implemented because they are deemed
non friendly. Our philosophy is that users do not
fall all under the same catergory and many may be
willing to sacrifice convenience for more security.
Having said that, we view our prototype more as
complementary to other SSO implementations and
not as a competitor. For instance, currently deployed
SSO services can be inspired from Keybase and our
work, and integrate (optional) cryptographic-based
authentication schemes in addition to their typical
password-based authentication.
Contributions
1. We design and implement KAuth, a system which
provides strong PKI human-to-machine authenti-
cation.
2. We evaluate KAuth with an established frame-
work (Bonneau et al., 2012) and show how KAuth
can defend users against several password-related
attacks, such as phishing and password leakage,
without severely affecting the user’s experience.
In fact, the user is hardly aware that PKI is in
place.
2 KAuth ARCHITECTURE
One of the most popular and widely adopted mecha-
nisms that is really similar to our approach is Face-
book Connect (Miculan and Urban, 2011). Identi-
cal to KAuth, if a user wants to access a third-party
website using Facebook Connect, they follow the ex-
act same procedure. Due to the massive integration
of this feature by developers, this has led to many
different implementations, each one of them offering
different functionalities. What stays the same for all
implementations is how Facebook validates user cre-
dentials however this is where KAuth tries to make a
difference. Our system has a simple architecture as
there are two big parts that end up working together.
On one side, the OAuth server handles the token re-
quests, waits for the Keybase login procedure to be
completed, and then serves as a resource server, pro-
viding an interface to the API of Keybase.
OAuth Server. The OAuth server is split into 3 con-
trollers. The token controller, authorizer controller
and resource controller. The token controller is re-
sponsible to generate an authorization code for the
client website. This authorization code is sent to the
authorizer controller by the Client website, with the
Client ID and Client Secret, and is exchanged for an
access token. This access token is then passed to the
resource controller, in order to make API calls to Key-
base and access the user’s data. This architecture de-
fined by the library we used to apply the OAuth pro-
tocol (Brent Shaffer, 2014).
Keybase Login System. The Keybase Login Sys-
tem operates in two modes. The basic version where
the user has to enter a username and a passphrase,
and the + version where they have to enter username,
password and also sign a message using their PGP
key.
KAuth Login System. This login system procedure
starts by requesting a salt using the user’s username
or email. Then, the passphrase and the salt (unhexed)
are entered as parameters in the scrypt function which
generates a 256 byte stream. The last 32 bytes of this
stream, are handled as a private key. This private key
is used to sign a JSON blob whose structure is defined
by Keybase. An EdDSA signature is generated and
then packaged into a Keybase-style signature (Key-
base, 2018). The result is sent to the Keybase server
as the pdpka5 parameter.
KAuth+ Login System. The KAuth+ login system
differs from the Basic one as it executes an additional
KAuth: A Strong Single Sign-On Service based on PKI
479