RWoT proposals and modern portable secure hardware

Nicolas Bacca, Ledger (nicolas@ledger.fr) - https://ledger.co

RWoT Paris, April 2017

RWoT proposals can involve "non standard" algorithms - this document provides a short history of the secure hardware landscape available today, as well as typical constraints and possible integration strategies to reuse existing solutions with as little modifications as possible and achieve faster user adoption

Smartcard integration pre 2005

Smartcard integration pre 2005 on personal computers was basically non existant or fully proprietary for several reasons :

No convenient form factor - mandatory reader purchase for the end user
No common drivers - each reader uses a different communication protocol, standardized around PC/SC (see [1])
No common middleware - integration of the smartcard into the Operating System is proprietary for each application, or uses a proprietary PKCS #11 driver (see [2]) for a limited set of cryptographic operations, with no compatibility profile regarding vendors support
No high level access interface - web support achieved through proprietary ActiveX plug-ins or Java applets
No protection from common malware attacks - smartcard credentials can easily be relayed by malicious software

Smartcard integration 2005 - 2012

The standardization of the USB reader communication class CCID (see [3]) helped solving parts of the previous issues :

More convenient form factors - standardized readers, proposals to directly support the CCID class directly from the silicon (STMicroelectronics ST23) or built in solutions with an MCU acting as a CCID/USB proxy to an older generation smartcard (NeoWave, Yubico)
Common CCID drivers - slowly deployed as OS standards. In the meantime hybrid CCID / mass storage products were created to hold the drivers

However no progress was made on a common middleware or a high level access interface or the overall security - web integration was still a mix a different technologies with a life expectations of a few years at best

The FIDO Alliance proposal

The FIDO Alliance (see [4]) proposed U2F, a simple cryptographic scheme for 2FA that allowed to build on the previous improvements and deal with the remaining issues - it practically rebooted PKI.

USB form factor removing the need for readers and introducing a simple user presence scheme to confirm each operation by a physical user action
Removal of the drivers and middleware layers by switching from the USB CCID profile to the USB Generic HID profile (see [5]) which is driverless on all major platforms (Linux, OS X, Windows)
Native web support in Chrome initially through low level proprietary APIs (chrome.usb) then standardized as a set of JavaScript APIs limiting the access scope to U2F compliant devices (see [6]). It is now supported natively on Chrome, Opera and available on Firefox through a third party extension (see [7])

U2F itself can be summarized as a stateless challenge/response over prime256v1 split into two stages

Registration : a new prime256v1 key pair is generated by the device, the private key is returned encrypted to the device and bound to the parent site web origin along with the public key, held by the remote party
Authentication : the encrypted private key is sent to the device along with the parent site web origin and a challenge, which is signed by the device, and verified by the remote party

It is now the most successful personal smartcard deployment offering interoperability over hundreds of products and an open implementation used by Github, Gitlab, Dropbox, Facebook among others.

The UAF specification (extending U2F to also handle user credentials on the device itself) also supports natively secp256k1 - it is not as widely supported though and will likely be silently merged into FIDO 2.

Java Card limitations

Java Card (see [8]) is a minimalist Java VM designed for smartcard. Only minor changes were applied after it was released in 2000 (mostly additional cryptographic algorithms support) and it is the de-facto standard for uploading custom applications on off-the-shelf smartcards.

However Java Card suffers from severe limitations :

There is no focus on performance at all - it is not suitable to implement cryptographic algorithms with decent (sub couple hundreds of ms per round) speed on any platform
The cryptographic APIs are extremely limited, and cannot be extended by native code in a standard way unlike other Java VMs, typically
- Elliptic curves are supported as Weierstrass curves on Fp or F2m, with no guarantee at all that "unusual" parameters will behave properly (some internal optimizations can be used for well known curves). The key size support is also non standard (typically above 256 bits)
- Big Number Arithmetic APIs are optional and usually not implemented
- No password derivation functions are implemented
- SHA-512 is only supported on recent platforms (it can be reimplemented with poor performance, see [9]), SHA-3 is only supported on the most recent platform (3.0.5)
Available RAM size is usually between 2 and 5 Kb

Also the lack of an interoperability profile for Java Card can harm vendor interoperability for "non standard" (not part of the proprietary test suite) operations (see [10])

Recent smartcards limitations

The biggest limitations of recent smartcards are the performance for general purpose algorithms and RAM. Cryptographic algorithms can usually be accelerated by a faster co-processor offering a big numbers arithmetic API

The available RAM shoud be considered between 10 Kb and 32 Kb for high end cards

Most recent secure elements are based on hardened ARM cores provided by the SecureCore IP blocks (see [11]). For performance evaluation and emulation purposes they can be considered equivalent to an ARM Cortex M0+ (for SC000) or ARM Cortex M3 (for SC300) clocked between 20 and 40 MHz

U2F modding

The U2F implementation has already been modded in the field (heavily in the Bitcoin community) to offer additional features :

Key recovery based on BIP 39 mnemonics (see [12]), key derivation based on the BIP 32 (see [13]) and BIP 44 (see [14]) standards (TREZOR, Ledger)
Use of the fixed web origin to offer additional information to the user about the service performing the registration or authentication request (TREZOR, Ledger)
Using U2F as a one step login mechanism rather than a second factor mechanism by remembering the login (Facebook)
Using U2F as a transport tunnel to offer a portable transport interface to other smartcard services (Ledger, initially deployed by MyEtherWallet and BitGo, see [15])

WebUSB

The WebUSB proposal (see [16]) is supported by the W3C to offer a generic low level USB transport layer to web applications (basically equivalent to the Chrome proprietary APIs used to implement the early U2F pilots). It is currently being tested in Chrome.

GlobalPlatform Web API

The GlobalPlatform Web API (see [17]) is supported by GlobalPlatform is promoting a low level abstract transport API to access different Secure Elements. It is mainly tailored towards PC/SC support and proprietary vendor interfaces, similar to the (poorly supported on vanilla devices) Android SEEK API (see [18])

WebAuthN

The WebAuthN proposal (see [19]) is supported by the W3C to offer a high level API for credentials management, building upon the FIDO specifications. Hardware solutions are set to be natively supported as Authenticators with a scope similar to U2F, with support for vendor defined extensions, for example to identify the credential being accessed on device

PIV

The PIV (FIPS 201, HSPD-12) standard (see [20]) is the most recent attempt before FIDO to unite PKI standards on legacy smartcard technology, based on the existing work performed on PKCS #11 smartcard implementations such as PKCS #15 (see [21]) or the WIM (see [22]). It has been designed for high security and government compliance rather than ease of use by the general public, but bridges are getting established between it and the more modern FIDO/W3C specifications (see [23])

Mobile devices support

Mobile device support of portable secure hardware is still quite diverse :

The portable secure hardware can be used as a SIM or SD-card and semi-proprietary access APIs, although this trend seems to be slowing down significantly (and is not really compatible with a desktop use case)
Support for USB portable secure hardware is not officially supported by FIDO, but technically doable on Android platforms with significant user inconvenience (use of USB OTG cables) (see [24])
Support for Bluetooth Low Energy (BLE) based portable secure hardware is gaining momentum on the different specifications, and is the easiest to support on all mobile platforms. However it increases the cost, complexity and maintenance of the device significanty compared to a USB based device, and supposes that the implemented algorithms have a significantly low bandwidth (optimistic 10 kb/s considering the high variety of chipsets in the wild)

Enclaves support is not considered as it doesn't create any significant restriction to the algorithms being implemented.

Recommendation to the group

Evaluate whether compatibility of the proposed signature / key derivation schemes with Java Card is achievable. Ledger Bitcoin wallet implementation (see [9]) can be used as a generic benchmark for SHA-512 and BIP 32 derivation. If not achievable, ensure that compatibility with regular smartcards performance / RAM size wise can be achieved.
Implement the communication interface and general user experience as a superset of FIDO / WebAuthN : a plug and play interface accessible from a web browser
Evaluate whether the bandwidth requirement of the authentication protocols guarantee an acceptable user experience over a BLE bearer under pessimistic pairing scenarios