Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a CTAP Qrexec service to allow administration of security keys #9696

Closed
ben-grande opened this issue Jan 8, 2025 · 3 comments
Closed
Labels
C: CTAP/U2F proxy Client to Authenticator Protocol (CTAP) / Universal 2nd Factor (U2F) proxy P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. R: self-closed Voluntarily closed by the person who opened it before another resolution occurred. security This issue pertains to the security of Qubes OS.

Comments

@ben-grande
Copy link

How to file a helpful issue

The problem you're addressing (if any)

chrome://security/passkeys is a web browser interface to interact with security keys.

More importantly:

Create a PIN
Protect your security key with a PIN (Personal Identification Number)

Sign-in data
Manage sign-in data stored on your security key

Fingerprints
Add and delete fingerprints saved on your security key

Reset your security key
This will delete all data on the security key, including its PIN

Even if not using chrome, other tools might implement the same management of keys chrome does, so could benefit other implementations.

What I currently use is an offline qube to manager the security keys with USB passtrough.

The solution you'd like

Create a service that allows administration commands to be executed on the key.

The value to a user, and who that user might be

Would be nice to do administration without USB passtrough to the client.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

@ben-grande ben-grande added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement labels Jan 8, 2025
@andrewdavidwong

This comment was marked as resolved.

@andrewdavidwong andrewdavidwong added C: core security This issue pertains to the security of Qubes OS. labels Jan 9, 2025
@ben-grande
Copy link
Author

That issue is not related to CTAP. CTAP obligatorily uses USB on the server, the intended product of that issue is to have a passkey virtualized in software and a way to interact with it, with Demi choosing a browser extension.

This issue is related to the existing Qubes CTAP proxy and allowing more services to be implemented for administration.

@andrewdavidwong andrewdavidwong added C: CTAP/U2F proxy Client to Authenticator Protocol (CTAP) / Universal 2nd Factor (U2F) proxy and removed C: core labels Jan 10, 2025
@piotrbartman
Copy link
Member

The purpose of the CTAP proxy is to provide controlled access to the hardware key. Key administration requires full access, so I'm not sure what role the proxy would play there. The current solution, which involves directly attaching the key to the management VM, has several advantages:

  • We have to explicitly attach the device to manage it, reducing the risk of a policy mistake that could result in an untrusted VM gaining full access to the key.
  • We don't increase the number of functions in Qubes -> KISS.
  • It doesn't require maintaining additional code.

@andrewdavidwong andrewdavidwong added the R: self-closed Voluntarily closed by the person who opened it before another resolution occurred. label Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: CTAP/U2F proxy Client to Authenticator Protocol (CTAP) / Universal 2nd Factor (U2F) proxy P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. R: self-closed Voluntarily closed by the person who opened it before another resolution occurred. security This issue pertains to the security of Qubes OS.
Projects
None yet
Development

No branches or pull requests

3 participants