Project Description
FIDO2 is set of specifications for multi-factor authentication. It is based on asymmetric cryptography with secrets stored in a HW token. The token must support the protocol to be usable. I own Nitrokey Start which is fundamentally similar but it speaks a different protocol (of GPG smart cards). I'm curious whether the device can serve as FIDO2 token too.
Goal for this Hackweek
There will be likely lots of impedance to match. Ideally, the secrets should never live out of the GPG smart card, however, I'm not sure if the signing protocols are compatible. (To study this is also a goal.) An alternative would be to use an established password manager (e.g. pass) and emulate the FIDO2 token in software with access to secrets in the password manager. The intention is to be able to authenticate via browser against a WebAuthn (web) service.
The goal is not to provide a more secure solution than real HW FIDO2 token.
Resources
Looking for hackers with the skills:
This project is part of:
Hack Week 21
Activity
Comments
-
over 3 years ago by jzerebecki | Reply
There are fido2 implementations for various stm32 boards, like the nitrokey start is one. But sadly I know of none that combine a fido2 and gpg implementation, though it is theoretically possible. E.g. https://github.com/solokeys/solo1 and there is also one in rust https://github.com/google/OpenSK
If you can't get your hardware key to cooperate with the fido2 protocol, then there are fido2 implementations using the tpm2 most laptops have available. E.g. https://github.com/psanford/tpm-fido
-
over 3 years ago by mkoutny | Reply
Report after Hackweek
- I started decomposition by studying FF
- the most important part is implemented in authenticator-rs
- later I found related projects
- https://github.com/ellerh/softfido
- https://blog.hansenpartnership.com/webauthn-in-linux-with-a-tpm-via-the-hid-gadget/ (Git repo)
- I've used the latter as a base for my experiment
- I decided to use GPGME library to interact with GPG (it's as convenient to use as gpg itself :-/)
- https://github.com/seiyak/GPGME-sample-code proved more useful that docs
- I manually generated nistp256 GPG subkey with Authenticate capability to honor U2F specification (that's predecessor of FIDO2 that allows only this particular signing algo)
- I suspect upstream kernel has inconsistent config definitions to build USB gadget for Tumbleweed, I applied following patch locally:
``` --- a/drivers/usb/gadget/udc/Kconfig +++ b/drivers/usb/gadget/udc/Kconfig @@ -471,7 +471,7 @@ source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig"
config USBDUMMYHCD tristate "Dummy HCD (DEVELOPMENT)" - depends on USB=y || (USB=m && USBGADGET=m) + depends on USB=y || (USB=m && USBGADGET=y) help This host controller driver emulates USB, looping all data transfer requests back to a USB "gadget driver" in the same host. The host ``` - my quickly hacked program was able to register (aka provide public key) against https://webauthn.io/ but it's not able to authenticate (aka sign challenges) - my joy was stopped by RFC4880 that defines GPG signatures as follows (highlight mine):
> The concatenation of the data being signed and the signature data > from the version number through the hashed subpacket data (inclusive) > is hashed. The resulting hash value is what is signed.
- that's where I stopped but I realize
ssh-keygen -Y sign ...is the way forward (preferred to low-level communications with ssh-agent)- the point is that gpg-agent can act as ssh-agent too
- the goal of this project should be achieved with the ssh-agent detour
- I started decomposition by studying FF
Similar Projects
Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy
Description
The Mission: Decentralized & Sovereign Messaging
FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com
In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.
However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.
Why This Matters
A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:
- Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
- Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
- Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.
By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.
Goals
As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.
Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:
- Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
- Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
- Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
- Allow the use of bind or remote mounted volumes for shared data (
/var/vmail, DKIM keys, TLS certs, etc.). - Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.
By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol
Resources
- The links included above
- https://chatmail.at/doc/relay/
- https://delta.chat/en/help
- Project repo -> https://codeberg.org/EndShittification/containerized-chatmail-relay
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !)
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. My Initial testbed is the devkit for the solokey2, the NXP LPCXpresso55S69.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
LPCXpresso55S69, tropicsquare tropic01, arm-none cross toolchain
Exploring Rust's potential: from basics to security by sferracci
Description
This project aims to conduct a focused investigation and practical application of the Rust programming language, with a specific emphasis on its security model. A key component will be identifying and understanding the most common vulnerabilities that can be found in Rust code.
Goals
Achieve a beginner/intermediate level of proficiency in writing Rust code. This will be measured by trying to solve LeetCode problems focusing on common data structures and algorithms. Study Rust vulnerabilities and learning best practices to avoid them.
Resources
Rust book: https://doc.rust-lang.org/book/
vex8s-controller: a kubernetes controller to automatically generate VEX documents of your running workloads by agreggi
Description
vex8s-controller is an add-on for SBOMscanner project.
Its purpose is to automatically generate VEX documents based on the workloads running in a kubernetes cluster. It integrates directly with SBOMscanner by monitoring VulnerabilityReports created for container images and producing corresponding VEX documents that reflect each workload’s SecurityContext.
Here's the workflow explained:
- sbomscanner scans for images in registry
- generates a
VulnerabilityReportwith the image CVEs - vex8s-controller triggers when a workload is scheduled on the cluster and generates a VEX document based on the workload
SecurityContextconfiguration - the VEX document is provided by vex8s-controller using a VEX Hub repository
- sbomscanner configure the VEXHub CRD to point to the internal vex8s-controller VEX Hub repository
Goals
The objective is to build a kubernetes controller that uses the vex8s mitigation rules engine to generate VEX documents and serve them through an internal VEX Hub repository within the cluster.
SBOMscanner can then be configured to consume VEX data directly from this in-cluster repository managed by vex8s-controller.
Resources
Looking at Rust if it could be an interesting programming language by jsmeix
Get some basic understanding of Rust security related features from a general point of view.
This Hack Week project is not to learn Rust to become a Rust programmer. This might happen later but it is not the goal of this Hack Week project.
The goal of this Hack Week project is to evaluate if Rust could be an interesting programming language.
An interesting programming language must make it easier to write code that is correct and stays correct when over time others maintain and enhance it than the opposite.
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !)
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. My Initial testbed is the devkit for the solokey2, the NXP LPCXpresso55S69.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
LPCXpresso55S69, tropicsquare tropic01, arm-none cross toolchain