Listen to this Post
The vulnerability arises from a buffer index miscalculation in the `tkeyclient` Go module when handling User Supplied Secrets (USS) . During the loading of a device app, the client sends a 32-byte USS digest derived from a user’s passphrase. The code sets a boolean flag at index 6 of the transmission buffer to indicate if a USS is provided. However, the subsequent `copy` operation also starts writing the USS digest at the same index (6), overwriting the flag . If the first byte of the USS digest is 0, it overwrites the boolean flag to 0, causing the TKey to process the request as if no USS was provided at all. Consequently, the Compound Device Identifier (CDI) is generated without the secret, making it identical to the CDI created with an empty USS . This affects approximately 1 out of every 256 possible USS values (those whose hash begins with a zero byte). The fix involves shifting the USS digest write to start at index 7, preserving the flag and always using the last 31 bytes of the digest for key derivation, ensuring the USS is always applied .
dailycve form:
Platform: Tillitis TKey
Version: < v1.3.0
Vulnerability: USS Bypass
Severity: Medium
date: March 17, 2026
Prediction: Already Patched (v1.3.0)
What Undercode Say:
Analysis
The root cause is an off-by-one buffer indexing error. The developers intended to use byte 6 as a flag and bytes 7-38 for the USS digest. The bug caused the flag and the digest to overlap. This is a classic example of protocol implementation flaws leading to state confusion. The vulnerability is particularly insidious because it does not crash the system; instead, it silently degrades security by nullifying the user’s secret, leading to key collision possibilities. The CVSS score of 4.7 reflects this partial compromise of integrity .
How Exploit
An attacker with physical access during the initial key generation could potentially persuade a user to enter a specific USS that hashes to a zero byte, resulting in a key derived without the secret. This could lead to unauthorized access if the attacker knows the “no-USS” key.
Vulnerable Code Snippet (tkeyclient < v1.3.0):
if len(secretPhrase) == 0 {
tx[bash] = 0
} else {
tx[bash] = 1 // Flag set here
uss := blake2s.Sum256(secretPhrase)
copy(tx[6:], uss[:]) // Bug: Overwrites the flag starting at index 6
}
Trigger the Vulnerability (using a USS that hashes to a leading zero):
Assuming 'adl' is a known vulnerable secret that produces a leading zero hash tkey-ssh-agent -p --uss Enter User Supplied Secret: adl (The public key generated will match the one generated without --uss)
Protection from this CVE
- Upgrade Immediately: Update the `tkeyclient` Go module to version v1.3.0 or higher .
- Rebuild Applications: All client applications (e.g.,
tkey-ssh-agent) that import the module must be recompiled with the patched version. - End-User Communication: Users must be informed that their key material will change after upgrading. They can retain their old keys by simply not providing any USS.
Fixed Code Snippet (tkeyclient v1.3.0):
if len(secretPhrase) == 0 {
tx[bash] = 0
} else {
tx[bash] = 1
uss := blake2s.Sum256(secretPhrase)
copy(tx[7:], uss[1:]) // Fixed: Flag at 6, data starts at 7, using last 31 bytes
}
Impact
- Scope: All applications using the `tkeyclient` Go module prior to version 1.3.0 .
- Key Collision: Approximately 1 in 256 User Supplied Secrets (those with a hash starting with
0x00) are ignored, resulting in the same Compound Device Identifier (CDI) as using no secret at all . - User Experience: Users upgrading to the patched version will experience a change in their cryptographic keys. They must choose between using a new secret (new keys) or no secret (old keys) .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
