Skip to content

Tillitis TKey Client has an Error in Protocol Implementation

Moderate severity GitHub Reviewed Published Mar 16, 2026 in tillitis/tkeyclient • Updated Mar 17, 2026

Package

gomod github.com/tillitis/tkeyclient (Go)

Affected versions

< 1.3.0

Patched versions

1.3.0

Description

Impact

Some specific (1 out of 256) User Supplied Secrets (USS) were not used,
making the resulting Compound Device Identifier (CDI) the same as if no
USS was provided.

Affected client applications: all client apps using the
tkeyclient Go module.

Patches

Upgrade to v1.3.0.

NOTE WELL: For the affected end users upgrading an app containing
tkeyclient to v1.3.0 means their key material will change. An end
user can get their old keys by not entering any USS. Please make sure
to communicate this to end users.

Affected users

The steps required to assess whether your USS is vulnerable may vary
depending on the client application. The example below shows how to
perform the check using tkey-ssh-agent and the known vulnerable USS
adl.

  1. Insert the TKey into the client
  2. Run tkey-ssh-agent -p --uss
  3. When prompted for a User Supplied Secret, enter adl
  4. Note the public key and call it pubkey-with-uss
  5. Remove the TKey from the client
  6. Insert the TKey into the client again
  7. Run tkey-ssh-agent -p
  8. Note the public key and call it pubkey-without-uss

Expected behavior:
pubkey-with-uss and pubkey-without-uss should not be equal.

Observed behavior:
pubkey-with-uss and pubkey-without-uss are equal.

Workaround

We recommend everyone using tkeyclient to update to v1.3.0 and
release new versions of the client apps using it.

However, end users that are unable to upgrade to a new version of a client
app, the recommendation is to change to an unaffected USS. Include
specific instructions for your client app.

Details

When loading the device app an optional 32 bytes USS digest is also
sent. The intention is to ask the end user to enter a USS of arbitrary
length, hash it, and then send a 32 bytes digest to TKey.

However, there was a bug when sending the digest from the client. The
index in the outgoing buffer is wrong and overwrites the boolean
defining if the USS is used or not.

This means that if the USS digest begins with a 0, the rest of the
digest is not used at all. If it begins with something else, setting
the boolean to true, the USS is used.

The exported LoadApp() function calls an internal helper function
loadApp() which contains this code:

  if len(secretPhrase) == 0 {
    tx[6] = 0
  } else {
    tx[6] = 1 // Note the 6 here
    // Hash user's phrase as USS
    uss := blake2s.Sum256(secretPhrase)
    copy(tx[6:], uss[:]) // Note that 6 is used again
  }

A side effect of this behavior is that only 31 bytes of the USS are
used. This is not considered a security issue, but an option has been
added to enforce use of the full USS. See the release notes for
details. To avoid forcing all users to roll their keys, this option is
disabled by default and must be explicitly enabled.

The fix

The fix focuses on solving the vulnerability only by: 1) use correct
index, 2) always use the last 31 bytes of the USS:

  if len(secretPhrase) == 0 {
    tx[6] = 0
  } else {
    tx[6] = 1
    // Hash user's phrase as USS
    uss := blake2s.Sum256(secretPhrase)
    copy(tx[7:], uss[1:])
  }

This change means the key material of affected end users will change
compared to earlier versions of tkeyclient. They have the choice of:

  1. Not using a USS and keep their keys.
  2. Keep using their USS and use new generated keys.
  3. Use another USS and thus new keys.

References

@dehanj dehanj published to tillitis/tkeyclient Mar 16, 2026
Published to the GitHub Advisory Database Mar 17, 2026
Reviewed Mar 17, 2026
Last updated Mar 17, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Physical
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality Low
Integrity Low
Availability Low
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:H/SI:H/SA:H

EPSS score

Weaknesses

Incorrect Implementation of Authentication Algorithm

The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect. Learn more on MITRE.

CVE ID

CVE-2026-32953

GHSA ID

GHSA-4w7r-3222-8h6v

Source code

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.