Configuration

Talisman Customization

The Talisman HW Token can be customized in terms of color and logo according to customer requirements.

Localization

The Talisman token supports localization to enable adaptation of the user interface to different languages and regional requirements. The device allows the use of multiple language variants, ensuring that displayed messages and prompts are understandable to end users.

Language versions are based on predefined text resources, which can be translated and customized according to customer requirements. Additional language variants can be introduced by providing a localization file containing the required translations. These files define all user-facing texts displayed on the device and allow consistent adaptation of the interface across different deployments.

FIDO2 Configuration Constants

Talisman devices are pre-personalized with information that can help you ensure proper device model attestation and system configurations (i.e., only allowing Talisman authenticators).

Talisman uses the following AAGUID values and attestation certificates:

Wultra Authenticator 1

Visual Transaction Signing

The FIDO2 protocol is intended as an authentication protocol. As a result, it does not have a straightforward implementation of transaction signing. When used in the web browser via WebAuthn API, the challenge provided to the web browser is hashed. As a result, the challenge itself cannot be interpreted in the external authenticator. FIDO2 extensions that were intended for solving the use-case of providing visual data to the authenticator (txAuthSimple, txAuthGeneric) are not implemented in the web browser (see the discussion on Github).

Authenticator Workaround

Talisman implements a stable workaround to enable visual transaction signing with the standard FIDO2 protocol by interpreting the payload carried in the credentialId value slightly differently than usual.

Conventionally, the credentialId is simply a random ID assigned to the authenticator device. The WebAuthn-initiated activity commonly results in the CTAP2.x call to the external authenticator with the credentialId value. If the credentialId sent to the external authenticator matches the known value in the authenticator, the authenticator knows the call was intended for it.

Talisman, however, supports credenaialId value with data suffix, where the operation data for signing is appended to the authenticator identifier:

final byte[] credentialId = ByteUtils.concat(authenticator.identifier, operation.data)¨

If you provide the concatenated identifier to allowCredentials item in the WebAuthn request (non-discoverable credentials only), Talisman checks if the provided credentialId prefix matches the expected authenticator identifier, and if it does, it looks at the data after such ID (validating the inputs for length and separators, of course). If the credentialId suffix matches the expected operation data format, the authenticator displays a visual challenge and additionally signs the operation data.

Server-Side Workaround

The PowerAuth server can then validate the alternate value of the assertion/signature based on the fact that it was calculated via Talisman (evidenced by the AAGUID value), like so:

// Determine if there is expected to be a data suffix (Talisman) or not (other FIDO2 devices)
byte[] dataSuffix = null;
if (Fido2DefaultAuthenticators.isWultraModel(aaguid)) {

    // Get the challenge value from the client data
    final String challenge = clientDataJSON.getChallenge();

    // Get the operation data for the challenge
    final String operationData = service.getOperationDataForChallenge(challenge);
    if (operationData == null) { // missing operation data
        return null;
    }
    dataSuffix = operationData.getBytes(StandardCharsets.UTF_8);
    if (dataSuffix == null) { // encoding error
        return null;
    }
}

// Build signable data, including the suffix if it is present as an additional component
final byte[] signableData;
if (dataSuffix != null) {
    signableData = ByteUtils.concat(authData.getEncoded(), Hash.sha256(clientDataJSON.getEncoded()), dataSuffix);
} else {
    signableData = ByteUtils.concat(authData.getEncoded(), Hash.sha256(clientDataJSON.getEncoded()));
}

// Get authenticator's public key
final Authenticator authenticator = service.getAuthenticatorForCredentialId(credentialId);
final PublicKey publicKey = authenticator.getPublicKey();

// Validate signature provided by authenticator
return SignatureUtils.validateECDSASignature(signableData, signature, publicKey);

This alternative matching does not conflict with the FIDO2 standard, as FIDO2 supports various interpretations of the credentialId value, including use cases such as stateless authenticators. The standard uses byte[] as the credentialId value type, to ensure the value can contain any data payload.

The modified signing also does not cause any practical issues - the web browser has no way of validating that the signature value is correct, as it is the server’s responsibility. The modified signing is only applied to Talisman devices. Other FIDO2 devices follow the standard with no modifications, and the validation works as well.

Installation on Linux

Support Matrix

Ubuntu Compatibility

Ubuntu Linux ships the browser applications as a “snap” package by default and therefore, the applications themselves are sandboxed and equiped with limited access to the hardware. To make the Talisman usage possible for the Ubuntu users, administrators have to implement a workaround by updating udev allowlist.

Add an appropriate hardware identifier to per-application UDEV rules stored at /etc/udev/rules.d. For example, the following lines should be added to firefox rules:

SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a4b3", TAG+="snap_firefox_firefox"
SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a4b3", TAG+="snap_firefox_geckodriver"

We maintain a simple script that updates the rules for some well known browsers at once. You have to run that script as superuser after the browser application is updated by the snap package manager.

Firefox Compatibility

Note 1: Firefox has a bug where the userSelected flag renders the entire response invalid when returned in the response to the authenticatorGetNextAssertion command. The issue specifically affects Talisman devices with firmware version 0.6.0 and higher. It does not impact older devices or scenarios where non-discoverable credentials are used.

Issue: #343: Unexpected keys in CTAP2 responses should be ignored

Chromium Compatibility

In general, Chromium browser works very well with Talisman. We don’t see any compatibility issues so far.

Vivaldi Compatibility

In general, Vivaldi browser works very well with Talisman. We don’t see any compatibility issues so far.