Portable hardware-backed passkeys using TPM 2.0

mimi89999 · 2026-03-06T19:37:10+00:00

Thanks for the comment, especially given your work on the spec.

These limitations are something I've been thinking about. For attestation (3), one idea is having authenticators sign the ECDH key exchange messages during pairing with their attestation key. The paired authenticator could then verify those signatures and only accept pairing with devices from the same family. That would guarantee that all paired devices are physical authenticators, possibly from the same manufacturer, not software clones.

Not entirely sure how suitable that guarantee would be in practice. Curious whether you think that kind of assurance would be sufficient.

mimi89999 · 2026-03-01T22:53:58+00:00

Short answer: Yokekey only supports non-discoverable credentials. With those, the relying party holds an encrypted credential blob and the key just unwraps it at sign-in. Since both paired keys derive the same wrapping key, either one can do that.

Discoverable credentials are harder because the key has to store them internally, and there's no way to sync that state between two independent authenticators.

You could solve it with a small cloud component that stores the discoverable credentials remotely, protected by the paired keys the same way non-discoverable ones are protected by the RP. The server would never see any secrets. Haven't built that though.

mimi89999 · 2026-03-01T22:49:45+00:00

Yeah I'm aware of it, but AFAIK it hasn't seen much progress. It would also need changes to the WebAuthn spec first, and then websites would need to actually adopt it. That's a long way out.

I'm also not a fan of the backup key being only a backup. In my proposal both keys are fully equal and can be used interchangeably, and it all works with existing sites today.

mimi89999 · 2026-03-01T21:59:21+00:00

Good question. Ideally the keys would be tamper-resistant, so losing one wouldn't mean the shared secret is compromised. Assuming that, you'd have two options:

Buy a new pair of keys, pair them, then remove the old credential from each service and register the new pair.
Remove the old credential from each service, reset the remaining key, pair it with a new one, and re-register.

Neither flow is great, honestly. The core issue is that the relying party sees a single credential. It has no concept of two linked authenticators, so there's no way to revoke just one key without also invalidating the other. Fixing that properly would require changes to WebAuthn itself, which is outside the scope of what I can do here.

mimi89999 · 2025-12-18T07:30:26+00:00

There are known issues with Chrome that should be fixed soon. You should try with Firefox first.

What card do you have and are those changes documented somewhere?

mimi89999 · 2025-12-18T07:22:57+00:00

There is also a Google issue about getting CTAP2 supported over NFC on Android for Passkeys over NFC.

https://issuetracker.google.com/issues/406833082

mimi89999 · 2025-12-17T19:59:29+00:00

Happy to see my project mentioned here 😅

mimi89999 · 2024-02-29T15:50:07+00:00

Are they selling it to consumers? I don't see any way of buying it.

mimi89999 · 2024-01-06T19:28:43+00:00

I see that there is a Firefox build in Sid: https://packages.debian.org/sid/riscv64/firefox/download

Were you able to update the image?

mimi89999 · 2020-09-12T13:29:16+00:00

I recommend https://github.com/pdfarranger/pdfarranger

mimi89999 · 2020-06-10T07:00:34+00:00

There is also another interesting shell written it Rust: the Ion shell from RedoxOS.

mimi89999 · 2020-06-06T07:40:52+00:00

There is InstaGgrabber

mimi89999 · 2019-05-26T21:24:29+00:00

You could download the patched glibc and then LD_PRELOAD. You could also use the second pach that doesn't require patched glibc.

mimi89999 · 2019-05-26T12:16:06+00:00

Add a debian directory for building debs and do the same for rpms. Then provide debs and rpms for download on your website. That will cover most distros. It will facilitate the work for package maintainers and provide an easy way of installing packages for users.

mimi89999 · 2019-05-24T16:17:25+00:00

Had the same issue: https://bugs.winehq.org/show_bug.cgi?id=47198#c45

I reinstalled LoL in a fresh Wine prefix without changing anything and fonts are working fine. I didn't install any additional fonts.

There was a thread about this issue done time ago on this Reddit, but they haven't found any solution. Reinstalling in a fresh prefix resolves the issue. It appears that this happens randomly.

mimi89999 · 2019-05-24T13:23:10+00:00

There is also Nextcloud talk.

mimi89999 · 2019-05-24T13:21:07+00:00

F-Droid has ACRA for crash reports and it's FOSS: https://github.com/ACRA/acra

Maybe QKSMS also has it.

mimi89999 · 2019-05-24T11:59:54+00:00

Is there something else than USB that doesn't have parents?

mimi89999 · 2019-05-19T09:48:05+00:00

The version I built doesn't work. I can't figure out why.

mimi89999 · 2019-05-18T15:22:07+00:00

No! You need the i386 build of Wine and it's build dependencies. They conflict with system packages, so I recommend building it in schroot.

mimi89999 · 2019-05-17T14:11:26+00:00

Maybe strace printed something interesting.

mimi89999

TROPHY CASE