FIDO2 emulation
a project by mkoutny
Updated over 2 years ago. 4 hacker ♥️. 5 followers.

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

Join this project

Looking for hackers with the skills:

cryptography security gpg mfa

This project is part of:

Hack Week 21

Activity

  • over 2 years ago: ybonatakis liked this project.
  • over 2 years ago: mkoutny joined this project.
  • over 2 years ago: jzerebecki liked this project.
  • over 2 years ago: jzerebecki left this project.
  • over 2 years ago: jzerebecki joined this project.
  • over 2 years ago: jzerebecki left this project.
  • over 2 years ago: jzerebecki joined this project.
  • over 2 years ago: toe liked this project.
  • over 2 years ago: Coelacanthus started this project.
  • over 2 years ago: szarate liked this project.
  • over 2 years ago: mkoutny added keyword "cryptography" to this project.
  • over 2 years ago: mkoutny added keyword "security" to this project.
  • over 2 years ago: mkoutny added keyword "gpg" to this project.
  • over 2 years ago: mkoutny added keyword "mfa" to this project.
  • over 2 years ago: mkoutny originated this project.


    • Comments

    • jzerebecki
      over 2 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

    • mkoutny
      over 2 years ago by mkoutny | Reply

      Report after Hackweek

      • I started decomposition by studying FF
      • 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

    Similar Projects

    Bot to identify reserved data leak in local files or when publishing on remote repository by mdati

    Description

    Scope here is to prevent reserved data or generally "unwanted", to be pushed and saved on a public repository, i.e. on Github, causing disclosure or leaking of reserved informations.

    The above definition of reserved or "unwanted" may vary, depending on the context: sometime secret keys or password are stored in data or configuration files or hardcoded in source code and depending on the scope of the archive or the level of security, it can be either wanted, permitted or not at all.

    As main target here, secrets will be registration keys or passwords, to be detected and managed locally or in a C.I. pipeline.

    Goals

    • Detection:

      • Local detection: detect secret words present in local files;
      • Remote detection: detect secrets in files, in pipelines, going to be transferred on a remote repository, i.e. via git push;

    • Reporting:

      • report the result of detection on stderr and/or log files, noticed excluding the secret values.

    • Acton:

      • Manage the detection, by either deleting or masking the impacted code or deleting/moving the file itself or simply notify it.

    Resources

    • Project repository, published on Github (link): m-dati/hkwk24;
    • Reference folder: hkwk24/chksecret;
    • First pull request (link): PR#1;
    • Second PR, for improvements: PR#2;
    • README.md and TESTS.md documentation files available in the repo root;
    • Test subproject repository, for testing CI on push [TBD].

    Notes

    We use here some examples of secret words, that still can be improved.
    The various patterns to match desired reserved words are written in a separated module, to be on demand updated or customized.

    [Legend: TBD = to be done]

    OIDC Loginproxy by toe

    Description

    Reverse proxies can be a useful option to separate authentication logic from application logic. SUSE and openSUSE use "loginproxies" as an authentication layer in front of several services.

    Currently, loginproxies exist which support LDAP authentication or SAML authentication.

    Goals

    The goal of this Hack Week project is, to create another loginproxy which supports OpenID Connect authentication which can then act as a drop-in replacement for the existing LDAP or SAML loginproxies.

    Testing is intended to focus on the integration with OIDC IDPs from Okta, KanIDM and Authentik.

    Resources

    Model checking the BPF verifier by shunghsiyu

    Project Description

    BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

    One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

    For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

    Goal for this Hackweek

    Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

    Resources

    Migrate from Docker to Podman by tjyrinki_suse

    Description

    I'd like to continue my former work on containerization of several domains on a single server by changing from Docker containers to Podman containers. That will need an OS upgrade as well as Podman is not available in that old server version.

    Goals

    • Update OS.
    • Migrate from Docker to Podman.
    • Keep everything functional, including the existing "meanwhile done" additional Docker container that is actually being used already.
    • Keep everything at least as secure as currently. One of the reasons of having the containers is to isolate risks related to services open to public Internet.
    • Try to enable the Podman use in production.
    • At minimum, learn about all of these topics.
    • Optionally, improve Ansible side of things as well...

    Resources

    A search engine is one's friend. Migrating from Docker to Podman, and from docker-compose to podman-compose.

    VulnHeap by r1chard-lyu

    Description

    The VulnHeap project is dedicated to the in-depth analysis and exploitation of vulnerabilities within heap memory management. It focuses on understanding the intricate workflow of heap allocation, chunk structures, and bin management, which are essential to identifying and mitigating security risks.

    Goals

    • Familiarize with heap
      • Heap workflow
      • Chunk and bin structure
      • Vulnerabilities
    • Vulnerability
      • Use after free (UAF)
      • Heap overflow
      • Double free
    • Use Docker to create a vulnerable environment and apply techniques to exploit it

    Resources

    • https://heap-exploitation.dhavalkapil.com/divingintoglibc_heap
    • https://raw.githubusercontent.com/cloudburst/libheap/master/heap.png
    • https://github.com/shellphish/how2heap?tab=readme-ov-file