Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices Paul Wagner a, Kris Heid b and Jens Heider c Fraunhofer Institute for Secure Information Technology, Rheinstraße 75, 64295 Darmstadt, Germany Keywords: FIDO2, Security, Authentication, Remote, Webauthn. Abstract: Nowadays, passwords are the prevalent authentication mechanism, even though it is proven to offer insuffi- cient protection against cyber crime. Thus, FIDO2 was released with a more secure authentication mechanism. FIDO2 enables authentification with cryptographic hardware, such as USB sticks, NFC cards or in the smart- phone integrated chips. A device with FIDO2 support is required to implement the whole FIDO2 stack and offer the required interfaces for the security hardware. However, many systems like for example Smart TVs can not make use of FIDO2 due to the lack of HW interfaces or the usage of outdated software. To overcome this, we present Remote WebAuthn, which enables secure authentification on such restricted devices through a remote authentication from a secondary, FIDO2 compatible device, such as a smartphone. We evaluate our approach to have better usability compared to FIDO2 while maintaining most security advantages. 1 INTRODUCTION leverage FIDO2 must on the one hand support the full WebAuthn protocol stack and on the other hand Passwords are already the dominating authentication also the interfaces for the security key (NFC, USB or method for over the last decades, even though they Bluetooth). Many IoT devices or Smart TVs also re- are known to provide insufficient protection(Bonneau quire authentication for online services, but have very et al., 2012; Bonneau and Preibusch, 2010). Con- restricted hardware and software interfaces hindering stantly changing passwords, long and random enough the usage and the spread of FIDO2. For such de- passwords or individual passwords for each service vices, passwords would still be required, leaving an are accepted by users, but mostly hated concepts open area for attackers. To overcome these flaws, we due to their inconvenience. Also, security enhance- present Remote WebAuthn, utilizing the central ele- ments such as two-factor-authentification are not well ments of the WebAuthn standard. As a benefit, we adopted by users (Voigt, 2019). This leads to the con- are allowing a remote authentication through a sec- clusion that many users sacrifice security for usabil- ondary device, instead of connecting the security key ity. As a way out of the password dilemma, FIDO2 to the device requiring authentication. Thus, the user authentication has been published. FIDO2 allows au- can freely choose interface requirements and use inte- thentication via a hardware security key, such as a grated hardware keys on restricted devices. This work USB stick, NFC card/tag or a Bluetooth device. Such provides a proof of concept architecture and imple- a key can be used as full authentication mechanism mentation for Remote WebAuthn in Section 3. We or as a second factor authentication together with for evaluate our concept based on sophisticated usabil- example a finger print or a pin to unlock the security ity(Bonneau et al., 2012) and security(Schneier, 1999; key1. The user connects the security key and legit- Microsoft, 1999; Kohnfelder and Garg, 1999) crite- imates the request for every authentication. In gen- ria in Section 4. The evaluation is also done with eral, FIDO2’s security is commonly well perceived password-based authentication and FIDO2, where we and handled as the successor of passwords(Lyastani compare our approach against. Finally, we are con- et al., 2020), the only stumbling block might be the cluding the pros and cons of our approach and give an usability among all devices. A device that should outlook on future work. a https://orcid.org/0000-0002-6125-574X b https://orcid.org/0000-0001-7739-224X c https://orcid.org/0000-0001-8343-6608 1https://www.w3.org/TR/webauthn/ 368 Wagner, P., Heid, K. and Heider, J. Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices. DOI: 10.5220/0010192703680375 In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 368-375 ISBN: 978-989-758-491-6 Copyright c 2021 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices 2 AUTHORIZATION METHODS gin. It can then be paired with a smartphone, run- ning Krypton’s authenticator app. In contrast, Re- Authentication can be reached by different means: mote WebAuthn does not require explicit device pair- knowledge, possession or biometric properties. Each ing and is therefore also usable on temporary devices of which can be used as a single factor authentication like kiosk terminals. Despite all components being mechanism, or they can be combined to increase the open source, Krypton is limited to their own infras- security level. tructure, hence it is not possible to use third-party au- thenticator apps. In addition, only integrated authen- Biometric properties like face recognition or fin- ticators can be used, making it mutual exclusive to the ger prints are in practice only used for non-critical au- use of external FIDO2 security keys. This paper in- thentication or as a second factor. These mechanisms stead proposes an open approach, that can be used on have been proven to be easily spoofed and also spe- both public and private infrastructure. cial hardware is required to capture these biometric properties. Password based methods represent a simple sub- type of knowledge based authentication. Because of 3 REMOTE WEBAUTHN their simplicity in implementation, they still consti- tute the predominant form of authentication on the The idea behind remote WebAuthn is to bring the se- web (Reese et al., 2019). There are several practices curity of FIDO2 to devices with limited IO interfaces to add an extra layer of security, such as time-based or software support, such as Smart TVs or public in- tokens (OTP) and hardware keys (Reese et al., 2019). ternet terminals. From the user perspective, a remote Since all of these approaches come in addition to reg- WebAuthn log in flow would look like follows: The ular password inputs and hence directly badly affect user wants to sign in to a service on the Smart TV, the usability (Florêncio and Herley, 2010; Bonneau such as a video streaming service. Instead of provid- et al., 2012), they are not further considered in this ing username and password, the TV presents a QR- work. code on its screen. The user scans the QR-code with Possession based authentication methods like his smartphone, which then opens an authentication FIDO2 can either be represented by integrated hard- app. This allows picking a key file previously asso- ware or external security keys, which connect via ciated with the service. Finally, by clicking the pre- USB, NFC or Bluetooth (FIDO-specs, 2020). In any sented allow button on the smartphone, the user grants case, each identity is stored as an individual key pair, the Smart TV to access the video streaming service. that can be verified using a challenge response algo- The described abstract behavior is highlighted from rithm. While the public key should be returned to the the technical perspective in the following. relying party upon creation, the private key must not ever leave the hardware token. On the technical side, 3.1 Concept FIDO2 is based on two pillars: CTAP specifies the communication between hardware token and client. The key principle behind Remote WebAuthn is to On the other hand, WebAuthn describes the interface separate the FIDO2 client across multiple systems: between client and application. Since this is mostly While the first part remains on the restricted device a browser-website relationship, WebAuthn endpoints on which the user wants to log into a service, the sec- are typically accessible via JavaScript. The bridge be- ond part handles any authenticator communication on tween CTAP and WebAuthn can either be divided be- a dedicated system. For demonstration, in this paper tween browser and operating system or implemented the combination of a Smart TV as service client and a in browser context completely. Since no official op- mobile phone as authentication device is used. Both erating system interface is designed, browsers relying parts communicate over an internet tunnel in back- on the first approach must offer explicit FIDO2 sup- ground, but hide that complexity from the applica- port for the concrete system they are running on. tions context. The parts in Figure 1 are defined as In both cases, FIDO2 needs explicit software sup- follows: port and at least one compatible interface (USB, NFC Relying Party Client (RP Client). The RP Client is or Bluetooth) or an integrated authenticator on the running on the system that should authenticate host system. Krypton (Krypton, 2020) is close to against a service, for instance a Smart TV. There- Remote WebAuthn in some regards. It allows users fore, it is responsible for any Relying Party (RP)- to authenticate against almost every FIDO2-capable related communication. WebAuthn commands are website with their smartphone. To do so, Krypton always structured into two parts: The request is sent requires the installation of a desktop browser plu- from RP to the authenticator and contains either a 369 ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy PUBLIC KEY PRIVATE KEY In summary, the QR code contains the following data: Relying Party Authenticator Base URL. When using an integrated scanner, the Base URL is only meant as fallback that shows up in FRONTEND case the user scans the code with a wrong scanner ap- 9. WebAuthn-resp. 1. WebAuthn-req. plication. If Remote WebAuthn by contrast relies on 3. Proxy-Server URL an external scanner, the URL should instead contain Session ID Symmetric Session Key a deep link, that is registered on the operating system 5.