Support for U2F FIDO Tokens in Mobile Applications

Masaryk University Faculty of Informatics

Support for U2F FIDO tokens in mobile applications

Bachelor’s Thesis

Marek Hrašna

Brno, Spring 2019

Masaryk University Faculty of Informatics

Support for U2F FIDO tokens in mobile applications

Bachelor’s Thesis

Marek Hrašna

Brno, Spring 2019

This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document.

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Marek Hrašna

Advisor: RNDr. Petr Švenda Ph.D.

Acknowledgements

I would like to express my gratitude to my advisor, RNDr. Petr Švenda Ph.D. his guidance, patience, and helpful advice throughout the making of this thesis.

iii Abstract

One of the biggest security problems on the Internet is the usage of weak credentials, such as passwords, for user authentication. Second- Factor Authentication (2FA) provides a valid answer to this threat. Still, there are many 2FA schemes vulnerable to prominent web threats such as phishing attacks. The U2F protocol provides a phishing-resistant 2FA solution, optionally based on secure hardware elements. This thesis provides an analysis of the security brought by the U2F authentication scheme and shows its real-world adaptation in mobile platforms. It discusses problems that occur while using commercial tokens implementing this standard and describes the process of installing a U2F applet onto a JavaCard while discussing possible problems that may occur.

iv Keywords

U2F, FIDO, FIDO2, Bachelor thesis

Contents

Introduction 1

1 Analysis of the U2F protocol 3 1.1 Motivation for FIDO standards ...... 3 1.2 Protocols overview ...... 5 1.3 Security analysis ...... 7

2 U2F JavaCard Applet 15 2.1 Applet description ...... 15 2.1.1 Installation parameters ...... 16 2.1.2 Response status words table ...... 17 2.1.3 Attestation certificate upload ...... 18 2.1.4 Exchanged data ...... 18 2.2 Problems ...... 23 2.3 Results ...... 25

3 Testing on Android 27 3.1 Experiment setup ...... 27 3.2 Experiment results ...... 28 3.3 Analysis and summary ...... 32 3.4 Existing tokens ...... 32

4 Conclusion and future work 35

5 An appendix 37

Bibliography 39

vii

Introduction

The need for a more secure way to authenticate has been clear for years. Time and time again, you can see news of leaks of user information – and they often come from a company with millions of users. Companies and state organization have tackled this problem di- versely – from using biometrics to using hardware tokens or other means. This required costly development for the companies, but otherwise, it had worked well. That inspired an idea to create a universal standard which would not only reduce the costs for the companies, but that could bring this possibility of stronger authentication to the huge user base of the Internet.

“The specifications and certifications from the FIDO Alliance enable an interoperable ecosystem of hardware-, mobile- and biometrics- based authenticators that can be used with many applications and websites. This ecosystem enables enterprises and service providers to deploy strong authentication solutions that reduce reliance on passwords and protect against phishing, man-in-the-middle and replay attacks using stolen passwords.” (FIDO Alliance, 2013)

The idea of universal second factor protocol is to provide one authentication device that works across any number of services with no shared secrets amongst multiple servers. This enables users to be unlinkable by third parties, and thus have multiple, yet secure identi- ties. Many companies with worldwide reach have joined the alliance, which makes pushing the protocol out to the public much easier.

“The core ideas driving FIDO are (1) ease of use, (2) privacy and security, and (3) standardization. For implementing authentication beyond a password (and perhaps an OTP), companies have traditionally been faced with an entire stack of proprietary clients and protocols.“ (FIDO Alliance, 2013)

1 The U2F authentication devices can be connected using a USB port or (in some cases) using contactless interface like Bluetooth or NFC1. The aim of this thesis is to analyze the state of these tools for second- factor authentication within mobile platforms (Android). With the continuous rise of smartphone usage for many tasks that concern the user’s privacy, it is important that this U2F standard can be applied in this scenario as well.

We focus mainly on the U2F (FIDO) protocol family and hardware tokens. In the theoretical part, we cover analysis of U2F standard, consulting its strong and weak points. Next, we cover the testing of U2F tokens with a native mobile application for Android and discuss problems that we encountered. Furthermore, we provide an overview of a JavaCard applet that we used and modified so that we could usea smartcard as a U2F token. We discuss problems that we encountered along the way and modifications we had to make. The practical part consists of the said native mobile application for Android, communicating with a hardware token through NFC or Bluetooth. It also includes source codes of the JavaCard U2F Applet.

Firstly, we studied available documentation concerning U2F standard and FIDO generally. We analyzed the strong and weak points of this standard. Secondly, we have found and modified an available demo application for Android, which would allow us to register and consequently log-in using a FIDO U2F token. Thirdly, we analyzed an existing JavaCard U2F Applet and analyzed its properties when used on programmable smartcard as FIDO U2F token. Finally, we described a real use-case scenario and used both implementations to show how it works.

1. Near Field Communication

2 1 Analysis of the U2F protocol

1.1 Motivation for FIDO standards

In general, there are three factors used for authentication:

∙ Something you know - a password or a personal identifica- tion number (PIN) for example, is the most common means of authentication. It is also easiest to beat.

∙ Something you have - some form of a token or a smart card

∙ Something you are - Biometrics - fingerprint, iris scan, retina scan, face scan, handwriting, hand geometry

These factors can be combined to form multi-factor authentication.

As cited on FIDO Alliance’s documents, their goal is to change the nature of strong online authentication. With password being still the most common means of authenticating a user on the web, phishing attacks, data breaches and other forms of hacking are as dangerous as they have ever been. There are numerous problems with password - to be secure, they should be of some minimal length, contain uppercase and lowercase letters, use special symbols, and should be unique for each service. That is usually much more than an average user is able to remember, so it is understandable that they reuse them. That leads to undesirable problems -if a password is stolen from one service, the chances are that the same password can be used by the attacker with a number of other services. Strong authentication is looking to solve this problem.

Strong authentication has several unofficial definitions and isof- ten understood as multi-factor authentication. Nevertheless, it does not have to necessarily mean that, as it does not in FIDO UFA and FIDO2 standards. Here, it is rather meant as authentication based on a challenge-response protocol.

3 1. Analysis of the U2F protocol

Challenge-response protocols work in the following way: One party proposes a challenge, usually a nonce or a random value; the other party combines this value with a secret to generate a response, and sends it back. The first party can then verify the response andcon- firm that the other party possesses the secret. An example of one the earliest challenge-response protocol would be a simple password authentication - one party asks for the password, and the other must answer correctly. This method was later improved, in certain applications, by providing a password identifier within the challenge, and the other party must have responded with a correct password for a given identifier. This would spoil possible interceptor’s effort tomali- ciously authenticate against challenges with different identifiers, thus improving security. The basic idea of this method is used to this day, for example, by certain internet banking solutions - but the exchanged data is cryptographically protected. The client receives a document with different passwords for different challenges during the set upof a bank account and is challenged during the log-in process. Authentication techniques that were not cryptographically protected were usually sufficient before the Internet. The risk of the system asking for the password not being the system the user was trying to enter, or the possibility of an eavesdropper watching the communication channel were significantly lower.

Cryptographic techniques used to solve this problem were mainly mutual authentication and implementation of a cryptographic nonce. Some of the challenge-response protocols developed over the years are for example CHAP1, OCRA2, and SCRAM3[1].

FIDO aims to change strong online authentication by:

∙ Developing technical specifications defining open, scalable, interoperable mechanisms that supplant reliance on passwords to securely authenticate users of online services.

1. Challenge-Handshake Authentication Protocol 2. Open Authentication Challenge-Response Algorithm 3. Salted Challenge Response Authentication Mechanism

4 1. Analysis of the U2F protocol

∙ Operating industry programs to help ensure successful worldwide adoption of the specifications. ∙ Submitting mature technical specifications to rec- ognized standards development organization(s) for formal standardization. [2]

Motivation for the U2F standard The goal of the U2F standard is to provide strong authentication for web users whilst protecting the user’s privacy. To reach this goal, the user needs to carry a "U2F device" as a second factor.

1.2 Protocols overview

FIDO firstly presented 2 protocols that provided two basic options for user experience when dealing with Internet services. ∙ Universal 2nd Factor (U2F) protocol ∙ Universal Authentication Framework (UAF) protocol

Universal 2nd Factor (U2F) protocol This protocol is designed to strengthen the security of services’ existing infrastructure by adding a strong second-factor to user log-in. While registering or authenticating, the user needs to present the second factor. A crucial factor is that this 2nd factor device works out of the box with any modern client device owned by the user without needing an additional driver or middleware setup. Tokens use different means to communicate with the target consumer operating system. While with traditional computer operating systems, the USB which is communicating with the host computer using HID4 is the main option, for mobile devices, Bluetooth and NFC technologies are available. To pass the information from online services, browser support is needed. Nowadays, Chrome, Firefox, Opera, and Microsoft Edge all support FIDO U2F natively.

4. Human Interface Device

5 1. Analysis of the U2F protocol

Universal Authentication Framework (UAF) protocol The UAF provides passwordless security. The user chooses how they want to authenticate - face recognition, a fingerprint, or whatever else they prefer - and when registered, the user simply uses the same action to authenticate. It takes password out of the equation and works on the same public key cryptography as the U2F standard, thus is more secure. It also allows for multi-factor authentication.

FIDO2 Later, FIDO introduced FIDO2 protocol, which is essentially the passwordless evolution of FIDO U2F. FIDO2 consists of W3C’s Web Au- thentication specification (WebAuthn) and FIDO’s corresponding Client-to-Authenticator Protocol (CTAP). Collectively, they enable a user to easily authenticate to online services.

WebAuthn defines a standard web API5 that can be built into browsers and related web platform infrastructure to enable online services to use FIDO Authentication. CTAP enables external devices such as mobile handsets or FIDO Security Keys to work with WebAuthn and serve as authenticators to desktop applications and web services. Major web browsers like Google Chrome, Mozilla Firefox, and Mi- crosoft Edge have already implemented this standard, as has Android. Windows 10 will also have built-in support for FIDO authentication. The new specification complement FIDO UAF and FIDO U2F use cases and specification. Users already using FIDO compliant devices, such as FIDO U2F security keys, will be able to use them with web applications that support WebAuthn. They will not be able to, however, provide passwordless experience, they can be used only as a second factor. In the new specification, FIDO U2F protocol is named as CTAP1, while the new FIDO2 compliant devices work through CTAP2. CTAP2 can provide single factor, second-factor, and multi- factor authentication.

5. Application programming interface

6 1. Analysis of the U2F protocol 1.3 Security analysis

U2F device can communicate through different channels - it can bea USB device, Bluetooth Low Energy (BLE) device, NFC device, build- on-board the user’s client machine or combination of the aforemen- tioned.

Site-Specific Public/Private Key Pairs When the user registers the U2F device with a particular service, the device creates a new key pair usable only with that service. It does that by using a hash created by a combination of the protocol, hostname, and port of the service, which is sent to the device by the browser. The hash is then encoded into the Key Handle, which is returned to the service along with the public key to associate with the account. When the user logs in to the service after the key has been added, in addition to the username and password, the service sends the Key Handle back to the U2F device via the browser. The browser sends this Key Handle along with the hash of the origin service back to the device. The device firstly checks whether it had issued this Key Handle to that origin hash - if not, no signing operation is performed. The device then uses the Key Handle to identify the user’s private key and creates a signature which is sent back to the online service to verify the presence of the U2F device. This origin check acts as a protection against strong verification and correlation of a particular user’s identity. This may be done across as many websites as the user wishes.[2]

Test of user presence Every U2F device also has a physical "test of user presence." It is usually a button that needs to be pressed during registration and each authentication using the device. This feature ensures that these steps happen with the user’s permission and that the signature cannot be executed without the presence of the user. NFC devices do not need such a test, since the token has to be physically placed very close to the device demanding registration/authentication, and exercising the signature without the user’s presence is not viable.

7 1. Analysis of the U2F protocol

Man-In-The-Middle Protections During Authentication The U2F protocol can detect Man-In-The-Middle attacks in most situations. If a user has successfully registered a U2F device with an origin and a MITM on a different origin tries to intermediate the authentication, the U2F device will not even respond, since the MITM’s origin name does not match the Key Handle that the MITM is using from the actual origin.

U2F is also able to detect more sophisticated MITM attacks. Let us consider that the origin receives actually correctly signed log-in response. For this to happen, the MITM would have had to also intermediate the registration to get the Key Handle issued by the U2F device to match the MITM’s origin name. The response contains "client data" object, where the actual origin can check whether the origin name seen by the user was correct. If not, a MITM is present. Furthermore, if the origin used ChannelID for the SSL connection or the "client data" shows a ChannelID, if the ChannelID in "client data" does not correspond to the ChannelID the origin used, a MITM is present.

If the MITM is able to get a server certificate for the actual origin name issued by a valid Certification Authority and ChannelIDs are not supported by the browser, MITM attack is possible.[2]

Detecting device cloning The U2F device protocol includes a usage counter that allows the origin to detect device cloning in specific situations. The U2F device remembers the number of signatures it has performed (either globally, per key-pair or in another way). It sends the counter value back to the browser which forwards it to the origin after each signing operation. It also adds this value to the hash of "client data" before signing so the origin can verify that the counter value has not been tampered with. The origin can compare the counter value with counter value from earlier interactions with the same device. If the value went down, a clone of the device had been created at some point.[2]

Trust model The biggest potential trust issue with U2F devices lies the supply-

8 1. Analysis of the U2F protocol

chain. To be able to trust a U2F authenticator, one must have trust in the commercial manufacturer and that the item delivered to them is genuinely the item that they had ordered. They must trust that he manufactured a secret unique device key. There are also other problems which the manufacturer has to tackle properly. While generating the key handles, the manufacturer should choose a cipher that offers the best possible security on the given hardware. They should also use a recommended Pseudo-random number generator and a good source of entropy to provide secure key generation, that the challenge parameter sent to the client contains at least eight random bytes and correctly implement the counter that is used to detect cloning attacks. Developers of hardware or software that serves purposes beyond U2F also need to ensure that the U2F keys created during registration are used for U2F authentication only.

To prove that the manufacturer fulfills these conditions, they may obtain certifications which the relying parties may require for atoken to be usable with their services. Even if the token is certified, it could still be tampered with during manufacturing or the supply-chain process. Even if the user already has it, but somebody manages to tamper with it without the user noticing. FIDO U2F does not cover a solution to these potential risks. To add an extra security layer that would elim- inate these risks, True2F[3] was independently implemented. It provides protection against token faults or backdoors. It is also backward compatible with already existing tokens, only requiring a firmware update of the authenticator and some changes on the relying party’s side.

In case of token faults, if its source of randomness would be faulty, which is a common failure for low-cost devices, then anybody who would be able to phish user’s credentials would be able to authenticate as that user, without having access to the user’s machine. In case of an attacker who would be able to compromise a hardware token during the manufacturing or through supply-chain tampering, he would be able to withdraw the user’s cryptographic credentials or authentication history.

9 1. Analysis of the U2F protocol

A relying party also needs to be able to distinguish the type of device with which it is communicating. Then the party can recognize whether the device type has the certification characteristics they care about - some services may, for example, choose to accept every token, while others might prefer only to allow devices which are hardware-backed.

A shared attestation key pair has to be present on every U2F device. Every public key generated by the device during the registration is signed with this key. To prevent individual identifiability, the attestation key is shared amongst a large number of U2F devices made by the same vendor. This key should be stored in the secure element present on the device, and one attestation key should be used on ap- proximately one hundred thousand devices. A particular relying party might choose to only trust vendors with published certifications that they consider appropriate. The relying party is then able to choose from manufacturers that it trusts based on these public attestation keys. Every certified vendor can make all of their attestation public keys available in the public domain.

The presence of the attestation key does not mean, however, that the device is secure. It only guarantees the identity of the manufacturer. To determine whether the device is truly secure, certifications from third parties who inspect the implementation play a crucial role. Attestation is simply a strong identifier of these certifications. There is still a possibility though for a manufacturer to build a U2F compliant uncertified device whose attestation key is not published anywhere. It is entirely up to the relying party to decide whether they choose to accept such a device.

Authenticator certification FIDO servers also need to be able to check whether the device with which the user is trying to register is actually a U2F certified device. This is done in the following way: Authentication vendor provides metadata as part of FIDO certification to the metadata service. The metadata service holds a TOC6 file containing a list of metadata statements related to the certified authenticators. The TOC file is available

6. table-of-contents

10 1. Analysis of the U2F protocol

from a well-known FIDO URL7, from where the FIDO server downloads it and caches it locally. The server verifies the authenticity of this file by using the digital signature. Afterwards, it iterates through each of the entries and downloads individual metadata statements specified in the entries related to authenticator AAIDs8 relevant to the relying party. The server then checks the integrity of the individual statements using the hash value included in the related entry of the TOC file.

[4]

7. Uniform Resource Locator - a reference to a web source with its location and a protocol for retrieving it 8. Authenticator Attestation ID

11 1. Analysis of the U2F protocol

Attacker’s model

Security Assumptions: "It is not possible to declare cryptographic algorithms and computer systems as provably secure. Throughout this model, the FIDO Alliance presumes the following list to be true. If any of these assumptions should be violated, it would prevent reliable achievement of the Security Goals.

∙ There are no unknown weaknesses that would make the cryptographic algorithms and parameters inadequate for their specific purposes - authenticating, signing, or encrypting messages.

∙ Boundaries between applications, between user accounts and between user and kernel mode are securely enforced, and security principals can be mutually, securely identifiable.

∙ Applications on the user device are able to establish secure channels that provide trustworthy server authentication, and confidentiality and integrity for messages9 (TLS ).

∙ The computing environment on the FIDO user device and the and applications involved in a FIDO operation act as trustworthy agents of the user.

∙ The inherent value of a cryptographic key resides in the con- fidence it imparts, and this commodity decays with the time, irrespective of any compromise event. As a result, the effective assurance level of authenticators will be reduced over time.

∙ The computing resources at the Relying Party involved in pro- cessing a FIDO operation act as trustworthy agents of the Rely- ing Party.

"[5]

9. Transport Layer Security

12 1. Analysis of the U2F protocol

Threat analysis If the security assumptions hold true, these security measures effec- tively prevent forgery attacks, forwarding attacks, and parallel session attacks using channel binding. However, at the time of writing, support of TLS Channel ID, used in U2F for channel binding purposes, is not required. Google Accounts website and some Google test sites do deploy this countermeasure, and its effectiveness is limited toa constrained list of users. This leaves all other U2F users vulnerable to TLS MITM attacks. FIDO does not cover physical attacks on the authenticator. Those might lead to reduced security if the legitimate user uses the authenticator after the attacker having physical access to it. True2F[3] does tackle this angle of a possible threat.

Key revocation Relying Parties should provide users a means to revoke keys associated with a lost device. This can be done by registering two U2F devices with each relying party - one used as the main mean of authentication and one as a backup if the user was ever to lose his primary authenticator. Then they can log-in with the use of a backup authenticator and remove the one they have lost. This also means that the user is not able to revoke an authenticator from all the relying parties where it has been registered and thereby has to revoke them one by one in a case of a lost device.

Comparison to OTP A very popular option of implementing second-factor authentication is OTP10. OTP is a form of a password that is only valid for one online transaction. On top of the usual password, the user has to also input a dynamically generated one. To send this dynamic password to a user, there are many options used - it can be, for example, a token with a display, an SMS, or a mobile application. Here we compare some of the main advantages and disadvantages of U2F against OTP:

10. One-time password

13 1. Analysis of the U2F protocol

OTP U2F User usually has to type received User does not have to write any- codes during the process thing Provides a single point of attack Is resilient against this type of at- resulting from the storage of the tack secretes on servers Is susceptible to phishing and Is resilient against phishing and MITM attacks most of the MITM attacks Depending on the implementa- User needs a special token tion user can use a device which he already has Depending on the implementa- Relies on strong security from tion the code can be transmitted public key cryptography using less secure means (such as SMS)

14 2 U2F JavaCard Applet

We try to figure out if we can get a JavaCard to act as a U2F tokenby installing an applet on it. If yes, what are the possible limitations and properties?

We used four different cards for this experiment. They needed to support ECC1 algorithm ECDSA-SHA-256[6] and Extended APDU[7]. We also need one card-reader, a computer to send and receive data from the card while testing and an Android device with NFC to test the card in a real-world scenario. We also used an already existing U2F applet [8], AppletPlayground[9] GlobalPlatformPro [10]. We used AppletPlayground to generate a .cap file that we uploaded onto the card. Then we used GlobalPlatformPro to install the applet with appropriate install parameters. Finally, we used U2FDemo.java to send commands to the card.

2.1 Applet description

To use the U2F applet[8], you need to build the cap file and follow the following diagram:

1. Elliptic-curve cryptography

15 2. U2F JavaCard Applet

In this section, we will be using the following terminology concerning APDU:

APDU command structure Field name Length (in bytes) Description CLA 1 Class byte INS 1 Instruction byte P1 1 Parameter number 1 byte P2 1 Parameter number 2 byte Lc 0,1,3 Encodes the number (Nc) of bytes of command data to follow; if it is 3 bytes long, the first must be 0 and the combined value of the following to must be greater than 0 Data Nc Nc bytes of data Le 0,1,2,3 Encodes the maximum number Ne of response bytes expected 0 bytes - denotes 0 1 byte - denotes values in a range of 1-256 where value of 0 denotes 256 2 bytes - if extended Lc was present in the command) in the range 1 to 65 535 denote Ne of that value, or two zero bytes denote 65 536 3 bytes (if Lc was not present in the command), the first of which must be 0, denote Ne

2.1.1 Installation parameters

While installing, you have to pass in installation parameters. Those need to be provided as a string of data with the following structure:

16 2. U2F JavaCard Applet

Installation parameter data Description Length (in bytes) User presence flag 1 Length of the attestation certificate to load (Big- 2 endian2 encoded) Private key of the attestation certificate on the 32 P-256 curve

To use the JavaCard applet as an NFC token, the user presence flag has to be set to 0x01, otherwise and error 0x6985 - Conditions not satisfied will be thrown. With the applet installed, the communication with the card is performed by the way of exchanging messages through APDU. Framing of these messages is defined based on the ISO7816-4:2005 APDU format. If the command is processed successfully, a status word with the value of 0x9000 will be returned. If there is too much data to fit into one APDU command, a response informing the sender that the card is expecting more data will be returned. If there is an error, a status word with appropriate value will be returned.

2.1.2 Response status words table

Full list of possible returned status words can be found on ETFlab pages[11], here we provide a table with the ones that we encountered.

Status words Value Description 0x9000 Success 0x6982 Security conditions not satisfied 0x6881 Logical channel not supported 0x6985 Conditions not satisfied 0x6F00 Status Word undefined

17 2. U2F JavaCard Applet

2.1.3 Attestation certificate upload After providing the installation data, the attestation certificate must be uploaded onto the applet before it is usable. Without the attestation certificate successfully uploaded, a status word with the value 0x6982 - Security conditions not satisfied is returned to every other message except for the one using proprietary CLA to upload the certificate. The format of the message to upload the certificate is:

CLA INS P1 P2 Lc Data Proprietary 0x01 Offset (high) Offset (low) 0x80 Certificate APDU data chunk

The proprietary APDU was set to F0 in the original applet, but because of problems discussed later we had to change it to A0. We also send the data in chunks of 0x80 = 128 bytes, which we specify in the Lc field. When the attestation certificate is successfully uploaded, the applet is ready for usage.

2.1.4 Exchanged data Attestation certificate upload First, we needed to upload the attestation certificate. We used the following data: Attestation certificate: 3082013c3081e4a003020102020a47901280001155957352300a06082a 8648ce3d0403023017311530130603550403130c476e75626279205069 6c6f74301e170d3132303831343138323933325a170d31333038313431 38323933325a3031312f302d0603550403132650696c6f74476e756262 792d302e342e312d343739303132383030303131353539353733353230 59301306072a8648ce3d020106082a8648ce3d030107034200048d617e 65c9508e64bcc5673ac82a6799da3c1446682c258c463fffdf58dfd2fa 3e6c378b53d795c4a4dffb4199edd7862f23abaf0203b4b8911ba05699 94e101300a06082a8648ce3d0403020347003044022060cdb6061e9c22 262d1aac1d96d8c70829b2366531dda268832cb836bcd30dfa0220631b 1459f09e6330055722c8d89b7f48883b9089b88d60d1d9795902b30410 df

18 2. U2F JavaCard Applet

We used three APDU commands to upload the certificate. -->A0010000803082013C3081E4A003020102020A479012800011559573 52300A06082A8648CE3D0403023017311530130603550403130C476E75 6262792050696C6F74301E170D3132303831343138323933325A170D31 33303831343138323933325A3031312F302D0603550403132650696C6F 74476E756262792D302E342E312D34373930

<--9000

-->A00100808031323830303031313535393537333532305930130607 2A8648CE3D020106082A8648CE3D030107034200048D617E65C9508E64 BCC5673AC82A6799DA3C1446682C258C463FFFDF58DFD2FA3E6C378B53 D795C4A4DFFB4199EDD7862F23ABAF0203B4B8911BA0569994E101300A 06082A8648CE3D0403020347003044022060CD

<--9000

-->A001010040B6061E9C22262D1AAC1D96D8C70829B2366531DDA268 832CB836BCD30DFA0220631B1459F09E6330055722C8D89B7F48883B90 89B88D60D1D9795902B30410DF

<--9000

All following APDU commands used for registration and authentication use CLA = 0x00.

Registration Registration is indicated by INS = 0x01. The header is followed by 32 bytes long challenge parameter, which is a SHA-256 hash of the client data, and 32 bytes long application parameter, which is a SHA-256 hash of the UTF-8 encoded application identity of the application requesting the registration.

APDU header Challenge parameter Application parameter 0x00, 0x01, 0x00, 0x00, 32 bytes 32 bytes 0x00,0x00,0x40

19 2. U2F JavaCard Applet

Now lets consider the following client data:

{"typ":"navigator.id.finishEnrollment", "challenge":"vqrS6WXDe1JUs5_c3i4-LkKIHRr-3XVb3azuA5TifHo", "cid_pubkey":{"kty":"EC","crv":"P-256", "x":"HzQwlfXX7Q4S5MtCCnZUNBw3RMzPO9tOyWjBqRl4tJ8", "y":"XVguGFLIZx1fXg3wNqfdbn75hi4-_7-BxhMljw42Ht4"}, "origin":"https://u2fdemoapp.com"} Its SHA-256 hash, which is our challenge parameter for the registration command, has value of: bdbf84c89a7daac730017e3ecbfc91bec14d9d266a5ef56635d6262b9d 7bf409

Let our application id be https://u2fdemoapp.com, and its SHA- 256 hash, which is the application parameter for the registration command: f6f590708b71d8eeadb9da42ea325674e5b199779b38c35a0901542039 30b078

The APDU command the client sends to the token: -->00010000000040BDBF84C89A7DAAC730017E3ECBFC91BEC14D9D266A 5EF56635D6262B9D7BF409F6F590708B71D8EEADB9DA42EA325674E5B1 99779B38C35A090154203930B078

The first byte in the registration response is a legacy byte 0x05. Following it, there are 65 bytes presenting the user’s public key. The next byte is an unsigned value of a key handle length, followed by the key handle of that length. Last part of the response is signature.

Reserved User Key Handle Key Attestation Signature byte public length (value: Handle certificate key L) 0x05 65 1 byte L bytes X.509 X (71-73 bytes bytes)

<--050435655BBD66E1012A829E8A0EF7F2A4A604379B7D8CE023647E8 E6CE09A02849BF25A53F9E4E01B4741B6ACF49D4B54D04982C90C07C56

20 2. U2F JavaCard Applet

46F47E3605623A9DB71406393B718A881C20C9FADDE4D92673EB98EFB5 E3EF13F0CDCA1B94F2F9AAF57B69A498821ED8A0610552E8157BC5D1A2 527E888442C7E5EB1A53522AD1666F3463082013C3081E4A0030201020 20A47901280001155957352300A06082A8648CE3D04030230173115301 30603550403130C476E756262792050696C6F74301E170D31323038313 43138323933325A170D3133303831343138323933325A3031312F302D0 603550403132650696C6F74476E756262792D302E342E312D343739303 13238303030313135353935373335323059301306072A8648CE3D02010 6082A8648CE3D030107034200048D617E65C9508E64BCC5673AC82A679 9DA3C1446682C258C463FFFDF58DFD2FA3E6C378B53D795C4A4DFFB419 9EDD7862F23ABAF0203B4B8911BA0569994E101300A06082A8648CE3D0 403020347003044022060CDB6061E9C22262D1AAC1D96D8C70829B2366 531DDA268832CB836BCD30DFA0220631B1459F09E6330055722C8D89B7 F48883B9089B88D60D1D9795902B30410DF3045022100A94CD2161C2A5 CFDFA1410662346C7ED41C011198FDA4CA16928F29CC1389A7B0220348 25A797012E0AF8434A3A57D68746164E554300A0264BA950847F5A18F1 3999000

Authentication Authentication APDU command framing:

APDU header Challenge Application Key Handle Key parameter parameter length (value: Handle L) 0x00,0x02, 32 bytes 32 bytes 1 byte L bytes 0x03|0x07|0x08, 0x00,0x41+L

Authentication is indicated by INS = 0x02. The P1 field has different options. It can be set to three values:

Value Description 0x03 Enforce user presence and sign 0x07 Check only 0x08 Do not enforce user presence and sign

21 2. U2F JavaCard Applet

The header is followed by 32 bytes long challenge parameter and 32 bytes long application parameter, equally as in the registration command. At the end we concatenate 1 byte long value indicating the length of the key handle and the key handle itself.

Now lets consider the following client data: {"typ":"navigator.id.getAssertion", "challenge":"opsXqUifDriAAmWclinfbS0e-USY0CgyJHe_Otd7z8o", "cid_pubkey":{"kty":"EC","crv":"P-256", "x":"HzQwlfXX7Q4S5MtCCnZUNBw3RMzPO9tOyWjBqRl4tJ8", "y":"XVguGFLIZx1fXg3wNqfdbn75hi4-_7-BxhMljw42Ht4"}, "origin":"https://u2fdemoapp.com"}

Its SHA-256 hash, which is our challenge parameter for the authentication command, has a value of: b881f6e38ebaf45ed598a0c3a15064b48c5a73edbe90d6651e2a7bf389 4f1abf

Let our application id be the same, https://u2fdemoapp.com, and its SHA-256 hash, which is the application parameter for the registration command: f6f590708b71d8eeadb9da42ea325674e5b199779b38c35a0901542039 30b078

The APDU command the client sends to the token: 00020800000081B881F6E38EBAF45ED598A0C3A15064B48C5A73EDBE90 D6651E2A7BF3894F1ABFF6F590708B71D8EEADB9DA42EA325674E5B199 779B38C35A090154203930B07840275E9B54711B5976614A7E3947E96A 970FE163FE3831670228EA59D790D5CDB9604337DBCBD5BE7C9038F96C ED476AD84BA5D31B113DDE40BE99F8A331AFB18A

The first byte in the registration response is a user presence byte.If user presence could be verified, the 0 bit of the byte it is setto 1, otherwise to 0. Other bits are reserved for possible future use. Following it, there are 4 bytes representing the counter value. The last part is the

22 2. U2F JavaCard Applet

signature ECDSA3 signature on P-256 over the application parameter, user presence byte, counter and challenge parameter in the form of a byte string. The signature shall be verified by the relying party.

User presence byte Counter Signature 0x01 | 0x00 4 bytes X

APDU Response: 010000000130440220414645634CC1C8D0A02FE0470B356DC65576E251 3C8DFAADE3C40564EC347DE102207EA446130AB72A41B48CBB0A9B7245 D860CCE1145CBABA22776AA63524E5D4689000

If we change the P1 byte in the APDU command from 0x03 to 0x07, the response we get is a status word 0x6985 - conditions not satisfied[11], which is in accordance with the U2F protocol. The applet does not support the 0x08 option for signing without user presence test. If we pass this value into the command, we get an error 0x6A86 - incorrect P1/P2. We did not run into any issues in a real scenario, but the applet can be easily modified to accept this value.

2.2 Problems

Along the way, we encountered many problems. First, we could not build the cap file out of the box. We needed to download newer Java Card Development Kit 3.0.2 and set the JC_HOME variable to this downloaded directory so that it would be possible to build the file. Next problem that occurred was that we were not able to load the cap file onto our card. The error described that applet loading failed and that it could be a problem with the JavaCard version. We looked for similar problems and found a list of applets present on different versions of JavaCard. After comparing them with our card, we found that our card was version 2.2.1, which was not sufficient for the U2F applet which used algorithms that had not yet been supported on this

3. Elliptic Curve Digital Signature Algorithm

23 2. U2F JavaCard Applet version, like ALG_ECDSA_SHA_256. We solved this problem by getting a card which had a sufficient JavaCard version on-board - Infineon CJTOP 80K; following that, we were able to successfully upload the U2F applet with install parameters onto the card.

Next step was to upload the attestation certificate. Here we also ran into an issue. We were getting an error “0x6881” - SW LOGICAL CHANNEL NOT SUPPORTED. At this point, we tried to run the applet in a JavaCard simulator. The installation failed and we had to modify the install function in the applet so that it would behave differently for a simulator installation since the data provided for a real installation are complemented by additional data.

By testing, we found out that when using different CLA, the problem could be solved. Instead of the original CLA 0xF0, we used 0xA0 - with CLAs beginning with A being reserved to also specify the logical channel in the last two bits of its value. As we needed to operate on channel 0, this allowed us to successfully upload the attestation certificate.

Next error occurred when we tried to perform a registration with sample data on the real card. We were getting an unspecified error - 0x6F00 - SW UNDEFINED. This command worked fine on the simulator, so we started looking for the possible differences between the simulator and the real card. After thorough debugging, we found that the problem was in an insufficient size of the buffer on the real card. Here we also realized that this applet implements Extended APDU[7] from package javacardx.apdu, which is not widely supported on chip cards. After getting a card that supported Extended APDU, created a second buffer with a fixed size of 600 bytes, which is more thanthe longest message[12], copying the real buffer into this bigger buffer, working with the bigger buffer through handling the registration and creating a method that would send data to the card in chunks instead of trying to send them in one command, we were finally able to get a successful response to the registration request on the real card.

24 2. U2F JavaCard Applet

After successfully running both registration and authentication commands with sample data, we tried to use the card with OnePlus 6T through NFC. Here we ran into an issue that we also experienced with our other NFC tokens - the NFC has to communicate twice in a small time window (about 1.5 seconds), otherwise, the request proves unsuccessful, and we get an error with the code 1 - low level. The card we were using was not able to communicate this quickly. We tried to install the applet onto another card - NXP JCOP 3 SECID P60 and we were able to complete both registration and authentication requests.

We tried to make the card work as a USB token, but a USB token needs to implement HID4, which we found impossible to do with our card reader, which does not conform to this specification.

2.3 Results

With our NXP JCOP 3 SECID P60 card, we were able to complete registration and authentication requests with a statistically same success rate as with our other NFC tokens. However, if we take a look at how many problems we had to get through to make this applet work - and even if it works correctly with sample data, one needs to have a card that is able to communicate within the small time window for the card to be usable - this does not seem to be an option for the general public. The problem we had with the buffers occurred most probably because the card that this applet was tested on had bigger default buffers, so if one was to purchase a card that they tested it on, itwould work fine. With the changes we made, the applet works on a wider range of cards, but you still need to find out whether the NFC on your card is fast enough. Considering this, the option to use this applet is viable if the user already has a card which meets all requirements or to buy a card that does. There are options to buy a card with the applet already installed from sellers such as SurePassID, but they are currently unavailable. Overall, the U2F JavaCard applet is a way to save money if one possesses a card that meets the requirements, but for the broader non-technical public, other options are more viable.

4. Human Interface Device[13] 25

3 Testing on Android

In the following tests, we are trying to establish whether a random FIDO U2F token is ready to work out of the box with a generic Android device.

3.1 Experiment setup

We tested each core functionality (registration of a token and user authentication) 20 times with each device and each token over each connection type (NFC and Bluetooth) to discover any errors and inconsistencies which might be occurring. We also try if the "re-registration" feature is working properly - if it is on, it should be possible to go through the registration process with an already registered token without any problem. If it is off, we should get an error. For the experiment, we used two of the most popular U2F tokens, one by Feitian, Feitian MultiPass, and one by Yubico, YubiKey NEO, and tried the registration and authentication process with three random devices supporting both NFC and Bluetooth functionality: OnePlus 5 (Oxygen OS 9.0.3), OnePlus 6T (Oxygen OS 9.0.13) and Samsung Galaxy S5 (Android 6.0.1). We also used a demo application[14] provided by Google, which we installed on our devices. It provides a basic interface where one logs in with their Google account and can register and authenticate U2F tokens. It displays already registered tokens with some basic info and shows a toast1 with an error if it occurs. The application uses Google’s public API for the U2F protocol, which also takes care of connecting (or pairing) the token with the mobile device.

1. Toast - a type of message on the Android OS that displays on the bottom of the screen for a short amount of time

27 3. Testing on Android 3.2 Experiment results

Bluetooth Registration with Feitian token Device name Errors/Tries OnePlus 5 3/20 OnePlus 6T 4/20 Samsung Galaxy S5 3/20

Bluetooth Authentication with Feitian token Device name Errors/Tries OnePlus 5 2/20 OnePlus 6T 2/20 Samsung Galaxy S5 3/20

NFC Registration Device combination Errors/Tries OnePlus 5 + Feitian 1/20 OnePlus 5 + Yubico 1/20 OnePlus 6T + Feitian 1/20 OnePlus 6T + Yubico 0/20 Samsung Galaxy S5 + Feitian 1/20 Samsung Galaxy S5 + Yubico 7/20

NFC Authentication Device combination Errors/Tries OnePlus 5 + Feitian 1/20 OnePlus 5 + Yubico 0/20 OnePlus 6T + Feitian 0/20 OnePlus 6T + Yubico 0/20 Samsung Galaxy S5 + Feitian 1/20 Samsung Galaxy S5 + Yubico 1/20

28 3. Testing on Android

Bluetooth errors:

∙ When we were pairing a new token, if we waited long enough during the process ( 20 seconds), we would get a timeout error from the API even though the key had been registered correctly and we could see it on our registered keys screen.

∙ When we were trying to pair a new token and the token was not set to a pairing mode, we got a message challenging us to set the token into the pairing mode and other times we got simply a timeout error.

∙ When we were trying to pair a new token, during the pairing process when we were challenged to enter the pairing key from the token into the device, if it took us more than 20 seconds, the operation would time out.

NFC errors

∙ When using the NFC, one has to keep the token close to the device for two vibrations - if they take it away after just one, a low-level error with code one or two is thrown. When using the Yubico key, their build in web-page was opened on the device as a side effect. The 7 errors on Samsung Galaxy S5 and Yubico key, which we tested first, happened because we were not sure where exactly on the phone the NFC chip is. After we located the position of the antenna, the Authentication tests were very similar to other devices, as was the whole process with the Feitian token.

Inconsistencies

∙ There is an inconsistency where if we send a registration request with an already registered token when re-registration is not allowed, the message that comes back says low level with a code, which does not give much information, and the error code is sometimes 1 and sometimes 2. We think that the reason

29 3. Testing on Android

is that if the card does communicate, we get an error code 2, and if it does not communicate twice in a short time window successfully, it returns error with code 1; but there is no clear way of distinguishing it from the user perspective, and the error codes do not say anything useful.

Other errors

∙ When re-registration is not allowed, if we try to register with a token that is already registered, we get an error with the code 2,

30 3. Testing on Android

which should indicate a bad request[15]. Instead, we should get an error with the code 4, which indicates an ineligible device. We do get the code 4 if we try to use a JavaCard which does not have the necessary applet installed.

∙ Using an experiment from external sources, a very common problem that occurred when using the token with a not reliable network was a timeout error when connecting to the provider’s

31 3. Testing on Android

servers. This user experience could be improved by setting the timeout to a higher value.

3.3 Analysis and summary

The results prove that if the network is reliable, the most common problem is the timeout. It also shows that NFC seems to be a more reliable and faster choice, but this may depend on the choice of a particular device. If the NFC chip inside the device is strong enough, or if you know exactly where it is, it works very reliably. If you do not know where the chip is, or if the chip is feeble, errors will occur. In our opinion, this is the main hurdle with user-experience with NFC. For users who do not know where on their device the chip is located, the experience may be frustrating if they are unable to register or authenticate using the token. While executing the experiment, we discovered two bugs within the test application provided by Google. The first one was that the application would crash if one tried to start the authentication process without any devices already registered to their account. The second one was that in the application, there is a possibility to enable re-registration of a token. Even if you could select this option, the registration request sent from the application would always set the parameter "re-registration allowed" to false. We repaired the first one, created a push request, and it was added to Google’s official git repository. We kept the second one implemented locally since the official repository moved onto the newer FIDO2 implementation and does not offer re-registration at all.

3.4 Existing tokens

Most popular choices are tokens by Yubico and Feitian, both used by the Google Titan project, which combines the two tokens, one from each manufacturer. However, there are many more manufacturers who passed the FIDO certification and can sell their tokens. The range of possible connection types differs for each model - from only USB tokens, to tokens that support USB, NFC and Bluetooth - but since we are focusing on mobile applications, we are focusing on tokens that

32 3. Testing on Android provide at least one of the NFC or Bluetooth connectivity. We can also use a JavaCard, on which we install a U2F applet, which is possibly the cheapest option and we tested it in the last chapter.

4 Conclusion and future work

In conclusion, it seems that the U2F protocol serves as a valid resolu- tion to the current threats linked with the user authentication on the Internet, discussed in the beginning. With the arrival of FIDO2, which incorporates this protocol, it is not a standalone protocol anymore but is a part of this new project. This thesis demonstrates that even though it is already adopted by major internet services, the tokens themselves can pose problems that could discourage many people. The major advantage of FIDO2 and WebAuthn is that it can take advantage of bio-metric sensors built-in the devices with all major OS - not only Android but for example also Windows and Mac OS. This promises much more convenient adaptation for the general populace; though as a passwordless authentication, not necessarily as a second factor. From the results of our testing, we conclude that the best way to use a U2F token with a mobile device is through NFC, even with the possible inconveniences if the NFC chip is feeble on the device’s side. Future work could be done for example by analyzing the new FIDO2 standard, discovering possible challenges connected with up- dating the firmware on existing tokens to conform to the aforemen- tioned True2F or making a database of cards that are able to communicate fast enough through the NFC to work as a U2F token.

5 An appendix

∙ Android application source code

∙ Android application file

∙ U2F Applet source files

∙ U2F Applet demo

∙ U2FApplet.cap - file to be installed onto a real card

Bibliography

1. Challenge-response protocol [online]. Brno: Wikipedia, 2019 [visited on 2019-05-19]. Available from: https://en.wikipedia.org/wiki/ Challenge%E2%80%93response_authentication. 2. FIDO U2F Overview [online]. Brno: FIDO Alliance, 2017 [visited on 2018-12-12]. Available from: https://fidoalliance.org/specs/ fido- u2f- v1.2- ps- 20170411/fido- u2f- overview- v1.2- ps- 20170411.html. 3. True2F: Backdoor-resistant authentication tokens [online]. Brno: Emma Dauterman, Henry Corrigan-Gibbs, David Mazières, Dan Boneh, Dominic Rizzo, 2018 [visited on 2018-12-12]. Available from: https: //arxiv.org/pdf/1810.04660.pdf. 4. FIDO architecture [online]. Brno: FIDO Alliance, 2018 [visited on 2018-10-08]. Available from: https://fidoalliance.org/specs/ fido - u2f - v1 . 2 - ps - 20170411 / img / fido - security - ref - architecture.png. 5. FIDO security reference [online]. Brno: FIDO Alliance, 2017 [visited on 2018-12-12]. Available from: https://fidoalliance.org/specs/ fido- u2f- v1.2- ps- 20170411/fido- security- ref- v1.2- ps- 20170411.html. 6. Javacard Signature [online]. Brno: Oracle, 2019 [visited on 2019-05-10]. Available from: https://docs.oracle.com/javacard/3.0.5/api/ javacard/security/Signature.html#ALG_ECDSA_SHA_256. 7. ExtendedApdu [online]. Brno: Oracle, 2019 [visited on 2019-05-10]. Available from: https://docs.oracle.com/javacard/3.0.5/ prognotes/extended_apdu_format.htm#JCPCL169. 8. Ledger U2F javacard [online]. Brno: Ledger, 2017 [visited on 2018-12-12]. Available from: https : / / github . com / LedgerHQ / ledger - u2f - javacard. 9. U2F sample application [online]. Brno: Martin Paljak, 2019 [visited on 2019-03-12]. Available from: https://github.com/martinpaljak/ AppletPlayground.

39 BIBLIOGRAPHY

10. GlobalPlatformPro [online]. Brno: Martin Paljak, 2018 [visited on 2018-12-12]. Available from: https://github.com/martinpaljak/ GlobalPlatformPro. 11. Complete list of APDU responses [online]. Brno: EFTLab, 2019 [visited on 2019-05-19]. Available from: https://www.eftlab.com/index. php/site-map/knowledge-base/118-apdu-response-list. 12. U2F raw message formats specification [online]. Brno: FIDO Al- liance, 2017 [visited on 2018-12-12]. Available from: https : //fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido- u2f-raw-message-formats-v1.2-ps-20170411.html. 13. USB Human Interface Devices Information [online]. Brno: USB, 2019 [visited on 2019-05-19]. Available from: https://www.usb.org/hid. 14. U2F sample application [online]. Brno: Google, 2019 [visited on 2019-03-12]. Available from: https://github.com/googlesamples/ android-fido. 15. FIDO Error codes [online]. Brno: Yubico, 2018 [visited on 2018-10-08]. Available from: https://fidoalliance.org/specs/fido- u2f- v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api. html#idl-def-ErrorCode.