Privakey Technical Summary

Author: Brian Ross
Last Update: November 11, 2020
Version: 2.0

What is Privakey

Consistent, Password Free Authentication (and Authorization)

Improving security without sacrificing consumer experience has been a vexing challenge for online services. While passwords and Knowledge Based Authentication (KBA) are the primary means of user identity assertion, they are also the primary vulnerability for services and users alike. There have been lots of attempts to address this fundamental deficiency of the internet.

The most common mitigation approaches to the inherent vulnerability of passwords and KBA involve adding factors or steps to authentication and identity assertion processes (multi-factor and multi-step authentication respectively). These approaches might include the retrieval of out-of-band codes via SMS messaging, biometric assertions, or asserting proof of possession of a separate hardware or security token. While many consumer-facing services offer such “enhancements”, voluntary consumer adoption has been very limited; these approaches are often too costly for services and almost always too confusing for the average user. And, sometimes they're more theater than substance; for example, a second-step assertion of "Where did you meet your spouse" after a User Name and Password authentication is, strictly speaking, meaningless security.

In order to achieve consumer adoption of stronger authentication and authorizations at scale, real enhancements to the identity assertion process must be both easier and more secure than traditional methods. That's what Privakey offers - our passwordless, multi-factor solution is easier to use and vastly more secure.

Privakey enables consistent and strong user authentication and authorization across all customer touch points, without passwords or security questions. Available for iOS and Android, Privakey technology turns mobile devices into secure authentication and authorization tools. Privakey empowered apps provide a ubiquitous and consistent user experience, regardless of the device being used, or the authorization or authentication event being processed. Whether a user is logging in to a website, confirming they are calling customer service, or, perhaps, approving a workflow, Privakey provides a consistent, easy way for users to assert a “Yes” or “No” response to critical processes and transactions.

In this article we provide an overview of the technical underpinnings of Privakey ID (or authentication offering) - a presentation of just why Privakey is more secure than the alternatives.

First - Why is it easier

But before we get into our underlying patterns and methods for securing Privakey authorizations, let us briefly explain why it is easier to use and, thereby, inherits characteristics that makes it more secure.

Privakey ID offers single-step, contextual, multi-factor authentications. Let's break that down:

Single Step

Steps, in and of themselves don't materially improve security. In fact, PCI compliance requires that multiple factors be presented in a single step for full compliance.

What's the difference. First, if the multiple steps in an authentication are of similar kind (for example, knowledge-based such as username and password, biographical data, etc, then there is no meaningful improvement over a single step. If a user's knowledge is compromised then that factor itself is rendered moot. Further, in multiple-step, multi-factor assertions of identity there is nothing is gained by breaking the interaction into multiple steps other than user frustration and the opportunity for process failure.

Providing a means of asserting a multi-factor identity assertion within a single step / transaction is tangibly better than the alternatives - this is what Privakey offers.


The factors of authentication (and user-authorization) are regularly referred to as: things one knows, things one has and things one are. For example: I know my username and password, I have my cell phone and my fingerprint is part of me. For an authentication to be multi-factor it must rely on at least two of these elements. Common multi-factor authentications include Username and Password assertion followed by the assertion of a temporary one-time pass code (OTP) generated on a device (possession of the software OTP device), sent via SMS (possession of a phone number?) or on a hardware token (possession of a bound hardware device). These are, respectively, inconvenient, vulnerable and costly.

With Privakey one gets multi-factor assertions in a single step. A cryptographically bound device is the something one possesses and the assertion of a biometric or PIN provides the additional factor. \

Contextual Messaging with Privakey Events

All of Privakey's offerings are significantly easier to use. Privakey Events goes further, offering a more intuitive and perceptibly more secure interaction by allowing personalized and contextual messaging. Every Privakey Event authorization is delivered as a personalized challenge to users. By leveraging notification frameworks and imbedded secure messaging, users of Privakey are asked to approve explicitly what they're being asked to approve. They will no longer be asked to enter the code they received by SMS. Rather, users of Privakey will be asked, for example, to confirm they are on a call with customer service. With Privakey events this authorization activity cann even be interactive - allowing users to provide information related to the transaction.


Security Principles of Privakey

Privakey relies on several approaches to ensure the integrity of the Authentication and authorization ecosystem.

Privakey Component Architecture

Privakey is comprised of three key components:

Request OriginsRequest Origins are the current processes and workflows of an application or service that would benefit from strong and definitive user authorizations. Multiple different services can connect to a single Privakey instance.
Auth ServiceThe Auth Service is a lightweight application that exposes a secure API. It is a RESTful service that acts as a central hub that can be called by any Request Origin to invoke user-specific challenge-messages. The Privakey Auth Service can be licensed or access via our Privakey Cloud Auth Service deployment.
Mobile ApplicationsPrivakey relies on mobile device applications for end-user interaction. Privakey offers libraries that can be leveraged to develop apps or extend the capabilities of existing apps to enable Privakey Authentication and Authorization Challenges. Alternatively, Privakey has their own Auth Wallet application for use with the Privakey Cloud Auth Service.

These components interact during binding, delivery to Privakey Authorization and Authentication challenges and in the receipt of responses from users over a variety of channels, leveraging general TLS and specific device and user encryption to enure the integrity and non-repudiation of messages.

Request Origins connect to the Privakey Auth Service via basic header authentication of HMAC authentication.


Multi-Factor Authorizations

Privakey’s simple process for approving authentication and authorization challenges rests in the inherent strength of multi-factor identity assertion. By combining something the user has (their cyptographically bound Privakey enhanced app on their mobile device) with something they know (a PIN) or something they are (a fingerprint or face biometric), Privakey enables strong, password-free challenge responses.

Asymmetric Cryptography

Asymmetric Cryptography is leveraged in Privakey to strongly bind a device to a user and to digitally sign (within the Privakey App ) and verify (within the Privakey Auth service) request challenge responses. During the Privakey App initialization a number of asymmetric key pairs are generated on the device. These

Device Biometrics

Privakey leverages the native device biometrics of modern mobile devices to ensure user-familiarity, edge processing of biometric challenges and to ensure deep access to device hardware security elements.

PINs are better than Passwords

Privakey allows services to rapidly enable authentication and authorizations without shared-secrets — no need for passwords or knowledge based authorizations.

The PIN used by Privakey (when biometrics are unavailable, not configured or failed) is never stored on the user’s device or the Privakey Auth Service. Nor is it shared with the Privakey Auth Service. The PIN is used computationally to protect and gain access to the private key store on the device. The methods leveraged depend on whether or not the device has a hardware key store. If a hardware key store is available, the PIN s used natively in the framework to access the key store and the private key generated by the Privakey library.

If no key store is available (for older devices and many computers), the Privakey Library encrypts the private key in memory using the PIN and two long strings of data generated by the Auth Service. To counteract transit vulnerabilities, these Auth Service generated strings are delivered to the Privakey empowered app via two different channels: (1) in an encrypted, direct connection from the Auth Service and (2) encrypted, as a payload in an out-of-band notification. As a further protection, this encryption material is rotated every authentication. This approach allows Privakey to securely facilitate authorizations and authentications a wide array of user devices.

No PII Storage

Privakey does not store any personal information related to a users behavior, biographical information, passwords or PINs. We go to pains to provide a secure framework for authorizations without infringing on individuals privacy. Instead of storing this information anywhere, Privakey relies of secure protocols, models and methods to ensure the integrity of each transaction. It is important to note - Privakey does store the content of challenges to ensure services can re-query the results and verify digital signatures used to provide non-repudiation. However, in our cloud service this data is store encrypted at rest (leveraging IBM's Hyperprotect Services) and cannot be accessed by operators or administrators.