1

The Home Page of the app with a Welcome message.

2

The drawer Menu of the app that slides out from the left

3

The Enroll User page where new user accounts can be created.

None of the information provided need be real/authentic; the only validation performed is to check the uniqueness of the username, e-mail address, and mobile phone number on the server side—but they can all be fake information.

4

A successfully enrolled user.

Once enrolled, select the REGISTER FIDO KEY button to generate the key pair.

If for any reason, a key fails to register (usually because the network goes to sleep and the TLS connection times out on the app), restart the app and choose FIDO Registration from the menu. The app will automatically recall the user information last saved on the mobile device.

If by any chance it does have a registered key, information about the registered FIDO key will also be retrieved from RoomDB and displayed.

5

A FIDO key successfully registered with the FIDO server.

The page displays a fair amount of useful information about the FIDO key and security capability of the mobile device:

• The relying party ID (RPID) against which the key is registered
• The credential ID of the FIDO key
• The security capability of the mobile device—in this case, TEE

Each of the highlighted lines in blue provides more detailed information; most of it is not humanly readable, but it is available for developers to see if there is any interest.

Select the AUTHENTICATE button to authenticate with the newly registered key to the back-end application.

5A

This image shows the same information as the previous image—with one difference. Since this app was executing on a phone with a SECURE ELEMENT (SE), the SACL detected this and displays this information when a key is registered.

NOTE: In reality, the SACL does not make this determination. When the FIDO keys are generated, an attestation is also generated by AndroidKeystore; this attestation—the Android Key Attestation—generates a chain of X.509 digital certificates rooted in the hardware by the manufacturer of the device (in this case, Google, the manufacturer of the Pixel 3a).

The chain of digital certificates provides information that is parsed by SKFS to determine properties of the public key that was sent for registration and the device in which the key was generated.

That information is relayed back to SACL, which is displayed by the app. This attestation is the assurance a relying party (RP) needs to affirm that they are dealing with an authentic device from the manufacturer and the attestation the manufacturer makes about cryptographic keys within that device.

While far more security capabilities are possible based on this technology, this SACL Preview Release is focused on enabling just what the FIDO2 protocol needs to satisfy business requirements.

StrongKey is committed to taking this technology and capability to its fullest potential, delivering some of the strongest security capability with its Tellaro appliance and securing some of the highest-risk business transactions. Please contact us if you would like to learn more.

6

A successfully authenticated user.

The page displays some useful information about the authentication.

One useful capability (currently not implemented in this Preview) is a prompt to SEND SECURITY KEY REGISTRATION E-MAIL.

When a user registers with a site using their mobile device, this FIDO key becomes the strongest way the user may interact with the site. Once authenticated, it will be helpful to allow users to email themselves a one-time, time-limited link that allows them to register a second FIDO key using an external Security Key.

This has the advantage of allowing the user to use the site from their desktop or laptop, or to allow them to recover their account with a new phone if they lose their current mobile device.

Once authenticated, select the GALLERY button to choose a sample product for purchase.

7

The Product Gallery displays 4 sample products in tiles that can be selected (or deselected, once selected) as part of the interaction.

8

This page shows one of the tiles selected in this demonstration.

The arrow at the bottom right advances to next page.

9

The Payment Options page displays six sample payment cards in tiles that can be selected\deselected as part of the interaction.

This assumes the app was designed with the capability to store multiple payment options with this site. In this sample app, hard-coded values are used to simulate this function.

10

This page shows one of the tiles selected in this demonstration.

The arrow at the bottom right advances to next page.

11

This is the CHECKOUT page of the sample app.

It shows which of the four products was chosen from the Product Gallery, and the Total Price the user is expected to pay to consummate this transaction.

The SUBMIT TRANSACTION is where the magic of FIDO Transaction Authorization (TXA) begins within SACL.

12

Having selected the SUBMIT TRANSACTION button, the app takes relevant information about the transaction and sends it to the back office application.

The back office application, in turn, processes that information and acquires a unique challenge from the FIDO Server, which takes this transaction’s details into account.

Upon receiving that challenge, the app calls Android’s BiometricPrompt to display a unique message—a dynamic link in PSD2 RTS parlance—that displays necessary information for regulator compliance:

• Payee information
• The amount to be paid, and
• The chosen payment option
• The transaction ID (TXID) and a Timestamp are added by the app to uniquely identify this transaction within its database.

The user is explicitly prompted to supply their fingerprint to authenticate with the device using the FIDO key to digitally sign the challenge sent by the FIDO server (through the back office application).

13

Upon successfully authenticating to the Android phone, the app—using SACL—uses the FIDO key to digitally sign the unique challenge and confirms the transaction displayed on the secure display.

This page shows the successful transaction with some useful extra information. 

The SEE TXPAYLOAD DETAILS is Base64-encoded data of a JSON object with the following details:

• Merchant name
• Currency type
• Total price
• Card brand
• Last 4 digits of the card
• The unique transaction ID
• The date/time of the transaction

The information at the bottom, referenced as FIDO Authenticator References, refers to data elements standardized by the FIDO Alliance and EMVCo to transmit FIDO-authenticated transaction confirmations over 3DS messages to Issuing Banks for authorization. The information displayed here maps to the details specified in the FIDO Alliance’s FIDO Authentication and EMV 3-D Secure—Using FIDO for Payment Authentication white paper.