White Paper: SkyPin Multi-factor Authentication as a Service

SkyPin:

In-browser, single sign-on, multi-factor authentication

Contents: Welcome to SkyPin About multi-factor authentication Key agreement explained Authenticated key agreement 1 2 2 3 3 3 4 5 6

About identity-based cryptography

ECC, in-browser, SSO, multi-factor authentification as a service for web, apps and mobile

Identity-based authenticated key agreement SkyPin operations SkyPin in operation in the browser client-server setting SkyPin security considerations

Why using SkyPin is more secure that traditional One-Time Password (OTP) hardware tokens 7 Code Patents 7 7

Welcome to SkyPin
SkyPin is a patented and patents-pending multi-factor authenticated key agreement protocol based on elliptic curve bilinear pairing cryptography. It was developed by CertiVox from the initial research and publication of Dr. Michael Scott in 2002 and updated in a new cryptographic research paper also available on the CertiVox Labs website. Dr. Scott is the Chief Cryptographer at CertiVox, and the head of the CertiVox Labs research team in Dublin, Ireland. The underlying protocol has been extensively peer reviewed over the last decade and no known practical flaws or attacks against it are presently known. The SkyPin Multi-Factor Authentication as a Service offering from CertiVox leverages the deployment model and distribution paradigm of the APS Authentication Protocol. The APS Authentication Protocol is a method of encapsulating identity information into an encrypted token in JSON format (based upon the IETF JOSE standard), which is uniquely encrypted for consuming relying party applications. The specification was jointly developed between Parallels and CertiVox, and is used by both the Parallels SSO server (available in PA 5.5) and the SkyPin managed service to issue identity information to a relying party post successful authentication. The main difference between protocols like Oauth and the APS Authentication Protocol is the addition of strong cryptography which includes encryption and digital signatures - to secure the identity assertions between identity providers and relying parties. Additionally, the APS Authentication Protocol is lightweight; it is truly a one-pass protocol, and requires no complex user re-directs or bandwidth intensive workflows. The APS Authentication Protocol is outside the scope of this white paper, but the reader is encouraged to find out more by downloading the APS Authentication Protocol white paper on the CertiVox Labs website and on the APS Organisation website at http://apsstandard.org/ SkyPin inherently includes techniques that support a multi-factor authentication, whereby the user authenticates via a cryptographically strong secret, associated with their identity, and issued by the Trusted Authority (TA) inside of the SkyPin Multi-Factor Authentication as a Service. The uniqueness of the protocol comes through the employment of the secret in an authenticated key agreement protocol, as the secret is divided between a conceptual physical (or virtual) token and a memorized PIN number, and (optionally) a biometric or other measurement, providing true multi-factor authentication. Further, the SkyPin authentication services are not required to store any information derived from the users secrets or PINs, so there is no equivalent of a vulnerable password file stored on the SkyPin cloud service. In fact, neither the PIN nor a biometric should be stored anywhere (other than in the users memory or as part of the users body respectively). The property of Perfect Forward Secrecy, a requirement for clients concerned about long-term privacy, is also supported. Lastly, because the solution is built on top of the MIRACL library and benefits from CertiVoxs expertise of building protocols for low

T: +44 (0)20 3191 8294 | E: info@certivox.com | www.certivox.com | 81 Rivington Street, London, UK, EC2A 3AY. Registered in England & Wales 7017635

White Paper: SkyPin Multi-factor Authentication as a Service

powered or constrained environments, the SkyPin Pin Pad can be run in browsers directly and on mobile devices through native OS SDKs. For an in-depth cryptographic analysis of the SkyPin protocol, please visit the CertiVox Labs website at certivox.com to download the research paper, Replacing Username/Password with Software-Only Two-Factor Authentication.

About multi-factor authentication

Multi-factor (i.e., two or more factors) authentication is now a requirement across a range of industries ranging from financial services, to healthcare and government sectors. As an example, in the USA, the Federal Financial Institutions Examination Councils (FFIEC) issued guidance for financial institutions recommends implementing security measures to reliably authenticate customers remotely accessing their Internet-based financial services. The FFIEC identified three authentication factors as: Something the user knows (e.g., password, PIN); Something the user has (e.g., ATM card, smart card); and Something the user is (e.g., biometric characteristic, such as a fingerprint) These guidelines recommended the use of authentication methods that depend on more than one of these three factors (i.e. multifactor authentication). Note, many vendors have attempted to define multi-factor authentication as utilizing other factors such as the users behavior; however, those methods are not approved by the FFIEC. Following the above publication, numerous authentication vendors began improperly promoting challenge-questions, secret images, and other knowledge-based methods as multi-factor authentication. Due to the resulting confusion and widespread adoption of such methods, on August 15, 2006, the FFIEC published supplemental guidelines clarifying that such methods do NOT constitute multi-factor authentication: By definition true multi-factor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category at different points in the process may be part of a layered security or other compensating control approach, but it would not constitute multi-factor authentication. Multi-factor authentication is not a new concept, having been used throughout history. As an example, when a bank customer visits a local automated teller machine (ATM), one authentication factor is the physical ATM card the customer slides into the machine (something the user has). The second factor is the PIN they enter (something the user knows). Without both of these factors, authentication cannot succeed. This scenario illustrates the basic concept of most two-factor authentication systems; the something you have + something you know concept. SkyPin is more easily conceptualized if the reader understands it as the elliptic curve cryptographic analog of an ATM machine, where the user authenticates to a server with something they have (a debit card) and something they know (their 4-digit PIN). In the case of the SkyPin service, it is something they have (mathematical token) and something they know (4-digit PIN).

Key agreement explained

In order to understand how SkyPin works, its important to understand, at a high level, the underlying mechanics of what key agreement is in the field of cryptography, as the SkyPin protocol delivers multi-factor authentication through an authenticated key agreement protocol. In cryptography, a key agreement protocol is a protocol whereby two or more parties can agree on a key in such a way that both influence the outcome. Generally speaking, two or more parties can generate the

T: +44 (0)20 3191 8294 | E: info@certivox.com | www.certivox.com | 81 Rivington Street, London, UK, EC2A 3AY. Registered in England & Wales 7017635

White Paper: SkyPin Multi-factor Authentication as a Service

same secret and use it to build a session key for use in a symmetric encryption algorithm. In modern cryptography, protocols that are useful in practice also do not reveal to any eavesdropping party what key has been agreed upon. One of the best known examples of this is the Diffie-Hellman exponential key exchange, in which two parties jointly exponentiate a generator with random numbers, in such a way that an eavesdropper has no way of guessing what the agreed key is.

The gold standard, open-source, elliptic curve crypto SDK for embedded, mobile and apps

It sounds improbable; two parties trade big numbers over an insecure channel and the two parties can figure out what the right key is without sending it, or any hints about it, over the insecure channel. If an eavesdropper is listening in, they have no way of reconstructing the agreed session key. This protocol is not just a theoretical construct; you use it every day when you browse to a secured web page, as it is a critical ingredient in the HTTPS protocol. Exponential key exchange protocols in and of themselves do not specify any prior agreement or subsequent authentication between the participants. Hence, Diffie-Hellman on its own is often referred to as an anonymous key agreement protocol. The issue with anonymous key agreement protocols is that they provide no authentication of the other party, making it vulnerable to a man-in-the-middle attack. An attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. A successful attacker will be able to intercept all messages going between the two victims and inject new ones, defeating the purpose of the key-agreement protocol. Hence, the concept of authenticating the other party becomes critically important from a security standpoint when conducting a key agreement protocol session.

Authenticated key agreement

Authenticated Key Agreement (AKE) is one of the classic problems to be solved using modern methods of cryptography. A wide variety of cryptographic authentication schemes and protocols have been developed to provide authenticated key agreement to prevent man-in-the-middle and related attacks. Up to now, these methods generally mathematically bind the agreed key to other agreed-upon data using constructs like public and private key pairs (in a PKI), shared secret keys or passwords. SkyPin is a different kind of authentication key agreement protocol to the methods listed previously. SkyPin is an authenticated key agreement protocol that uses identity-based cryptography.

About identity-based cryptography

Identity-based cryptographic systems allow any party to generate the primitives used in cryptography (generally a public key) from a known identity value such as an ASCII string. A trusted third party, called the private key generator (PKG), generates the corresponding private keys, usually also using an ACSII string of a unique identifier. In the case of the SkyPin multi-factor authentication service, the unique identifier is the users email address. To operate, the PKG first publishes a master public key, and retains the corresponding master private key (referred to as master key). In the most commonly known example of an identity based systems using a master public key, any party can compute a public key corresponding to the identity ID by combining the master public key with the identity value. To obtain a corresponding private key, the party authorized to use the identity ID contacts the PKG, which uses the master private key to generate the private key for identity ID.

Identity-based authenticated key agreement

The intention behind SkyPin was to provide a method of authenticated key agreement using identity based encryption. By doing so, SkyPin advances the concept of multi-factor authentication and provides an alternative to expensive (and expensive to replace) smartcard or one-time password hardware tokens and password-only AKE schemes require that a unique password be shared between every pair of correspondents. Identity-based methods for authenticating key exchanges have a long history, going back to an original proposal by Okamoto in the 1980s. An interesting variant of identity based authenticated key agreement is authenticated key exchange in the client-server setting. A client-server authenticated key-agreement protocol should ideally authenticate the client to the server, and the server to the

T: +44 (0)20 3191 8294 | E: info@certivox.com | www.certivox.com | 81 Rivington Street, London, UK, EC2A 3AY. Registered in England & Wales 7017635

White Paper: SkyPin Multi-factor Authentication as a Service

client, and should result in both of them able to negotiate strong encryption keys suitable for further communication. Note that this can be regarded as a specialized subset of the more general problem of peer-to-peer authenticated key exchange. However it is in a many-to-one setting, where the roles of clients and servers are quite different and clearly understood, where the SkyPin protocol is currently designed for efficient operation.

SkyPin operations
The following section describes the most commonly deployed method of SkyPinTM; whereby a third party website, deploy SkyPinTM as the front of house authentication solution to their users by embedding the PIN PAD into an iframe on their website and web service to web service communication is secured using the APS Authentication Protocol. Other scenarios, such as using SkyPin inside of a native application (mobile or desktop) can be supported with the SkyPin SDKs for those various platforms. Those operations, while distinct, are not sufficiently different from the workflows described below, and will be documented in the SDKs for native and mobile OS as they are made available for those platforms. The SkyPin service takes advantage of the deployment model and distribution paradigm of the APS Authentication Protocol, as the SkyPin service is an Identity Provider (IDP). SkyPin has unique properties that support multi-factor authentication in a client to server setting; that is, the client authenticates via a protocol that utilizes a cryptographically strong secret, associated with their identity. Note that the users strong secret is not presented as proof of identity; the users strong secret is used in an authenticated key agreement protocol. The strong secret, when initialized by the user, is further divided into a mathematical token (which can be stored insecurely) and a memorized PIN number, and could include a biometric measurement as well to provide a third factor of authentication. If this reads like a familiar every day operation, it should. As stated previously, the real world analogue is an ATM network debit card, where the mathematical token is in your ATM card (actually on the magnetic stripe). To initialize the ATM debit card, you decided on your 4-digit PIN at your local bank branch.

THE US

R THENTICATIO E AU N
vince.noir@gmail.com

THE A

User Identity Cross Infrastructure Boundaries IEEE and IETF Standards Based One-pass Protocol Maximum Security

ATION LIC PP

Enter your SkyPinTM

1 4 7

2 5 8 0

3 6 9

SE

RVIC

E PR

VI O

APS Authentication Protocol

T: +44 (0)20 3191 8294 | E: info@certivox.com | www.certivox.com | 81 Rivington Street, London, UK, EC2A 3AY. Registered in England & Wales 7017635

ER
D

AT I

ON

AU

EN

TH

TIC

AT I O N

AUTHE

NT

IC

TH

White Paper: SkyPin Multi-factor Authentication as a Service

The SkyPin service employs the concept of a trusted authority (TA). The trusted authority generates a master secret and then issues identity-based private keys to servers and clients utilizing the system. The server in this instance is the server that is authenticating the clients who use the SkyPin service, and the clients are the users who enroll and receive a SkyPin. As stated previously, the clients use their email address as the unique identifier (as an ASCII string). Using identity based elliptic curve cryptography, the ASCII string is hashed to a point on the elliptic curve to produce each client and servers identitybased secret (a numerical string); for a client, this is representing his or her identity on the system by way of an email address. When the user registers their identity, it is the TA that provides them this cryptographic secret, not the authentication server. During the initialization process, the users secret is sent over HTTPS to the users browser. The user is asked to initialize the cryptographic secret into a token by entering their 4-digit pin via the SkyPin pin pad JavaScript application, also served down over HTTPS, with the domain secured by DNSSEC to prevent cache poisoning. Note that only the user will know the 4-digit PIN, as the pin pad runs locally, and sends no communication about the pin pad to the SkyPin service. By selecting a 4-digit PIN, the SkyPin pin pad JavaScript application initializes the users cryptographic secret into a token, one that can be stored insecurely. Why? Without the 4-digit pin, its impossible to re-assemble the strong secret. Utilizing the capabilities of HTML5 browsers and their ability to lock stored data objects to domains, the SkyPin pin pad JavaScript application stores the token in the HTML5 browsers storage area locking the token to the domain of the SkyPin pin pad JavaScript application. Again, picture this as analogous to writing a number onto a mag stripe of an ATM debit card. When the user attempts to authenticate to the SkyPin service, the SkyPin pin pad is served to the users browser over HTTPS, with the domain secured by DNSSEC. In the following description of the operation, you can think of the pin pad as analogous to the pin pad on an ATM terminal, authenticating the holder of a debit card when the debit card is inserted into the ATM machine. A mathematical process utilizes the information on the magnetic stripe of the ATM debit card (something you have), and the users 4 digit PIN (something you know) to create the correct credentials to authenticate the user and enable them to access their account. In order for the user to authenticate to the SkyPin service, the user enters their 4-digit PIN into the pin pad that is now running locally on the users machine, inside of their browser. Since this pin pad was served from the same SkyPin service domain that originally served up the users strong secret and then stored it in the users browser storage, (after being initialized with the users PIN), only the SkyPin service domain can access the token stored in the users browser with the SkyPin pin pad. When the SkyPin pin pad is served up again to authenticate the user, the pin pad runs locally on the users machine, accesses the users token in their browsers storage, accepts as input the users 4-digit PIN, and reassembles their strong secret from the combination of the token and the 4-digit PIN.

SkyPin in operation in the browser client-server setting

T: +44 (0)20 3191 8294 | E: info@certivox.com | www.certivox.com | 81 Rivington Street, London, UK, EC2A 3AY. Registered in England & Wales 7017635

White Paper: SkyPin Multi-factor Authentication as a Service

As described previously, once the SkyPin pin pad reassembles the users secret, it is ready to be used in the authenticated key agreement protocol. Note that this is not simply presenting the users secret to the authentication service. What actually occurs is that the users secret is used exponential key exchange, augmented by the underlying elliptic curve bilinear pairing cryptosystem employed in the SkyPin service. As written in the preceding section, anonymous key agreement occurs where two parties jointly exponentiate a generator with random numbers; with SkyPin, the numbers are not random, but instead are ascertained through the employment of the identity based cryptosystem. A detailed cryptographic paper is available on the CertiVox Labs website which illustrates its construction; Replacing Username/Password with Software-Only Two-Factor Authentication.

SkyPin in operation in the browser client-server setting

Put in simple terms: SkyPin running in a standalone mode delivers true two-factor authentication using nothing more than your HTML5 browser! Coupled with additional factors, it becomes a multi-factor solution. SkyPin achieves this with no additional client software or hardware required.

SkyPin security considerations

One of the obvious questions is the security of the token itself. SkyPin tokens leak no information about the actual identity based secret issued from the TA to the client once they have been initialized with the 4-digit PIN. This is important to avoid off-line dictionary attacks from a practical standpoint. Simply put, this is where an attacker typically captures the token and enough other information (perhaps by eavesdropping a transaction) to go back to her own computer and quickly search through all possible PIN numbers until she finds the unique PIN consistent with the captured information. To this end we must assume that an attacker has access to some cipher text encrypted with the finally agreed key, which, when decrypted with the correct key, results in something instantly recognizable. In other words, an attacker will know when they have hit on the right key. SkyPin negates this attack because it leaks no information about the token in a way that could be used to reverse engineer the pin. The SkyPin service itself also employs a number of counter measures, such as a strict three strikes rule, whereby the user is only allowed three chances to authenticate to the service before their account is de-activated. A number of other fraud detection and real-time analysis techniques are also implemented, including geo-location awareness. Another top security consideration is whether SkyPin can withstand man-in-the-middle (MITM) or man-in-the-browser (MITB) attacks. In the scenario where an attacker is intercepting traffic between the authentication service and the client (a man-in-the-middle or MITM), SkyPin employs HTTPS to encrypt the traffic and DNSSEC to prevent any cache poisoning from malicious DNS servers. Further, the SkyPin pin pad reveals no information about the token, the users 4-digit pin (which is never sent over the wire) or the agreed session key over the connection, completely negating any potential attack vectors. In the scenario where an attacker has malware installed on a users machine to perform a MITB attack, the malware and level of compromise would have to be severe and directly targeted; the malware would have to compromise the browsers integrity, removing and exporting the users token out of the browsers storage, in effect, re-writing the code of the HTML5 browser to enable some kind of token export (without the user knowing). Of course, thats only one part of the equation. In order to get the users 4-digit PIN, the malware would also have to screen capture or screen record the users computer. Note that traditional key logging will not capture a 4-digit PIN as SkyPin pin pad rejects any input not directly from the mouse pad or touch input device. Finally, the elliptic curve cryptographic code would need to be run independently from the pin pad, in effect, performing the functions of the SkyPin pin pad exactly; this is not a trivial undertaking in and of itself. Finally, the attacker would need to circumvent the other counter measures employed within the SkyPin service to detect such attacks.

Why using SkyPin is more secure that traditional One-Time Password (OTP) hardware tokens
Employing an OTP hardware token during a simple 1-way authentication with the presence of a MITM or MITB is like showing your ID (passport, fingerprints) to a fake police officer. In fact, the user is strongly authenticated but to the wrong person because the incoming and outgoing data channels can be controlled by the hacker. For example, when a user attempts to log into a bank website with a username, password and an OTP, the hacker can spoof the IP address of the end-user to fool the bank, he can perform sniffing to know whatever is sent to the end-user, he can redirect the traffic of the user to fake sites that

T: +44 (0)20 3191 8294 | E: info@certivox.com | www.certivox.com | 81 Rivington Street, London, UK, EC2A 3AY. Registered in England & Wales 7017635

White Paper: SkyPin Multi-factor Authentication as a Service

he controls (via the host file or DNS hack). In this attack, the OTP that would be transmitted to the bank is actually sent to a malicious attacker, along with other credentials, enabling the attacker to gain access to the users bank website immediately. By offloading the authentication function to a multi-factor 3rd party authentication as a service like the SkyPin and communicating the identity credentials using the APS Authentication Protocol, the vectors of possible attack surfaces are minimized and the scope of the attack would need to be much more targeted, and require more dedicated resources.

Code
The cryptography described herein is powered by MIRACL, an open-source cryptographic library available for download at www.certivox.com. If you require a commercial license outside of the scope of the AGPL license, please contact sales@certivox. com.

Patents
SkyPin utilizes a number of patent-pending and patented technologies of which CertiVox is the exclusive licensee; EP Patent No. 1 730 88 (EP Application No. 05718824.5) granted by the European Patent Office on 13th October 2010 for Verification of Identity Based Signatories and US Patent No. 7,860,247 granted on December 28th 2010 for Identity Based Encryption.

T: +44 (0)20 3191 8294 | E: info@certivox.com | www.certivox.com | 81 Rivington Street, London, UK, EC2A 3AY. Registered in England & Wales 7017635