OpenSK is an open-source implementation for security keys written in Rust that supports both FIDO U2F and FIDO2 standards.

Overview

OpenSK logo

markdownlint pylint Cargo check Cargo format Coverage Status

OpenSK

This repository contains a Rust implementation of a FIDO2 authenticator. We developed OpenSK as a Tock OS application.

We intend to bring a full open source experience to security keys, from application to operating system. You can even 3D print your own open source enclosure! You can see OpenSK in action in this video on YouTube!

FIDO2

The stable branch implements the CTAP2.0 specification and is FIDO certified. OpenSK supports U2F, and non-discoverable credentials created with either protocol are compatible with the other.

If you want to use features of the newer FIDO 2.1, you can try our develop branch. This version is NOT certified and less thoroughly tested though. If you plan to add features to OpenSK, you should switch to develop.

⚠️ Disclaimer

This project is proof-of-concept and a research platform. It is NOT meant for a daily usage. The cryptography implementations are not resistent against side-channel attacks.

We're still in the process of integrating the ARM® CryptoCell-310 embedded in the Nordic nRF52840 chip to enable hardware-accelerated cryptography. Our placeholder implementations of required cryptography algorithms (ECDSA, ECC secp256r1, HMAC-SHA256 and AES256) in Rust are research-quality code. They haven't been reviewed and don't provide constant-time guarantees.

Hardware

You will need one the following supported boards:

Installation

To install OpenSK,

  1. follow the general setup steps,
  2. then continue with the instructions for your specific hardware:

To test whether the installation was successful, visit a demo website and try to register and login. Please check our Troubleshooting and Debugging section if you have problems with the installation process or during development. To find out what else you can do with your OpenSK, see Customization.

Contributing

See Contributing.md.

Reporting a Vulnerability

See SECURITY.md.

Comments
  • Requests for USB dongle  without additional hardware.

    Requests for USB dongle without additional hardware.

    Very excited about yesterday's update。 I very much expect to get rid of the hardware (jlink) dependency。 I have one usb dongle (52840 dongle),and have a try with nrfutil.

    ./deploy.py --board=nrf52840_dongle --opensk --programmer=nordicdfu fatal: This board doesn't support flashing over DFU.

    then I checked deploy.py file.Then changed parameters: ./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=nordicdfu

    I see ,it needs nrfutil command with version 5.1. AttributeError: 'dict' object has no attribute 'iteritems'。

    Can you tell me if my operation is correct,and nrfutil's version.

    Thanks !

    Specifications

    • Version:
    • Platform: ubuntu 16.04 i686 ,python 3.5.
    opened by xaqfan 30
  • Cannot generate ssh keys with ed25519-sk

    Cannot generate ssh keys with ed25519-sk

    I'm trying to create ssh keys with ed25519-sk instead of ecdsa-sk but I receive this error: Key enrollment failed: requested feature not supported . This is my Openssh version: **OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k **

    I'm using a nrf52840 dongle with the last updates of the stable branch.

    Any idea why is this happening? Thanks in advance.

    enhancement 
    opened by gelintonx 28
  • Is there a way to store a key/secret in the dongle?

    Is there a way to store a key/secret in the dongle?

    Is there an API in the OpenSK that I can use to store a secret string mapped to a username and retrieve it later on?

    If not, can I exploit the FIDO register call to store a secret string mapped to a username? Is there any field in the FIDO2 protocol that is stored on the authenticator and is returned during authentication? I need it for the research prototype, so any hack/ideas would help.

    question 
    opened by tarun14110 20
  • OpenSK does not work properly on Microsoft Edge

    OpenSK does not work properly on Microsoft Edge

    Expected Behavior

    I can register the OpenSK key on my Google account

    Actual Behavior

    When I try to register the OpenSK key on my Google account, it gets stuck on the confirmation page Here are the logs:

    two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
    two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
    two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
    two-step-verification?rapt=***:1 Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
    

    Steps to Reproduce the Problem

    1. Flash the OpenSK firmware to nRF52840-Dongle
    2. Open https://myaccount.google.com/signinoptions/two-step-verification on Microsoft Edge
    3. Click "Add security key", and click "Next"
    4. Tap the button on the OpenSK key

    Specifications

    • Version: latest stable
    • Platform: Windows
    opened by ghost 18
  • Add Feitian USB Dongle

    Add Feitian USB Dongle

    Feitian created an hardware dongle according to nRF52840 design, please refer to https://feitiantech.github.io/OpenSK_USB/hardware/ . There is no need to change anything to Google OpenSK source code, download the OpenSK firmware to Feitian Dongle, and it can work.

    documentation cla: yes 
    opened by geofli 18
  • nRF52840 USB dongle can not work with source code from stable and develop branches

    nRF52840 USB dongle can not work with source code from stable and develop branches

    Expected Behavior

    nRF52840 USB dongle should work with source code on stable branch or develop branch

    Actual Behavior

    Neither stable nor develop branch work.

    Following below steps

    1. ./reset.sh
    2. ./setup.sh
    3. ./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=nordicdfu
    Have switched nrf52840 usb dongle to bootloader mode.
    4. ./tools/configure.py \
        --certificate=crypto_data/opensk_cert.pem \
        --private-key=crypto_data/opensk.key
    

    If I use source code from stable branch, step 4 reports error 0xF2.

    info: Private key is valid.
    info: Certificate is valid.
    DEBUG:fido2.hid.macos:Found CTAP device: 4295020873
    DEBUG:fido2.hid:SEND: ffffffff8600084859dd5c0a590e2f
    DEBUG:fido2.hid:RECV: ffffffff8600114859dd5c0a590e2f00000001020100000500000000000000000000000000000000000000000000000000000000000000000000000000000000
    DEBUG:fido2.hid:SEND: 0000000190000104
    DEBUG:fido2.hid:RECV: 00000001900001f20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    Traceback (most recent call last):
      File "./tools/configure.py", line 204, in <module>
        main(parser.parse_args())
      File "./tools/configure.py", line 134, in main
        for authenticator in tqdm(get_opensk_devices(args.batch)):
      File "./tools/configure.py", line 72, in get_opensk_devices
        return [ctap2.CTAP2(dev)]
      File "/Users/gaofeng/.pyenv/versions/3.8.8/lib/python3.8/site-packages/fido2/ctap2/base.py", line 643, in __init__
        self._info = self.get_info()
      File "/Users/gaofeng/.pyenv/versions/3.8.8/lib/python3.8/site-packages/fido2/ctap2/base.py", line 695, in get_info
        return self.send_cbor(Ctap2.CMD.GET_INFO, parse=Info)
      File "/Users/gaofeng/.pyenv/versions/3.8.8/lib/python3.8/site-packages/fido2/ctap2/base.py", line 675, in send_cbor
        raise CtapError(status)
    fido2.ctap.CtapError: CTAP error: 0xF2 - UNKNOWN
    

    If I checkout code to develop branch, after step 3, nrf52840 usb dongle behaves like

    https://user-images.githubusercontent.com/10238809/126742034-fdf49cec-d0c0-4173-aeb3-64b33207f636.mp4

    Even if I perform ./deploy.py --board=nrf52840_dongle_dfu --erase_storage --programmer=nordicdfu before step 3, behavior is same.

    What's the matter?

    Steps to Reproduce the Problem

    1. ./reset.sh
    2. ./setup.sh
    3. ./deploy.py --board=nrf52840_dongle_dfu --opensk --programmer=nordicdfu
    Have switched nrf52840 usb dongle to bootloader mode.
    4. ./tools/configure.py \
        --certificate=crypto_data/opensk_cert.pem \
        --private-key=crypto_data/opensk.key
    

    on either stable or develop branch.

    bug 
    opened by geofli 16
  • lost access to bootloader on makerdiary nRF52840 MDK USB Dongle after flash

    lost access to bootloader on makerdiary nRF52840 MDK USB Dongle after flash

    Expected Behavior

    Holding button while plugging to computer enter UF2 flash mode ( ie presenting a mass storage device to the host )

    Actual Behavior

    Holding button while plugging to computer does nothing

    Steps to Reproduce the Problem

    1. generate firmware with ./deploy.py --board=nrf52840_mdk_dfu --programmer=none --opensk
    2. convert hex file to uf2 with uf2conv.py firmware.hex -c -f 0xADA52840
    3. flash by copying the resulting uf2 file to the mass storage device presented.

    Specifications

    • Version: b0c1b73897816edb757a163943f7b36a55f76a19
    • Platform: linux

    Comments/Questions

    Apologies if I missed something, I chose nrf52840_mdk_dfu as the board since it was the only one mentioning mdk and I tried before nrf52840_dongle but the button was not recognized ( I was able though to enter UF2 mode with that firmware flashed ).

    The dongle works perfectly as is, webauthn.io test is successful. I just can't set it back to bootloader mode to flash or update something else. Just want to confirm I need a debugger probe at that point to be able to update opensk and/or change the firmware running at that point. Thank you in advance for your pointers.

    opened by gled-rs 14
  • Failed to load

    Failed to load "resident" ssh key generated by OpenSK device

    Expected Behavior

      After successfully generating the residential ssh keys by ssh-keygen -t ecdsa-sk -O resident, the private key should can be load to another computer via the OpenSK devices by ssh-add -K, but it failed to load.

    Actual Behavior

      Generation step on residental key seems to be successful, but when I tried to load the key to anthoer PC, by pluging in the OpenSK device and ssh-add -K, it shows Enter PIN for authenticator: Provider "internal" returned failure -1 Unable to load resident keys: invalid format   (the PIN was set correctly.)   After enable verbose mode by ssh-add -K -v, it shows Enter PIN for authenticator: debug1: start_helper: starting /usr/lib/ssh/ssh-sk-helper debug1: sshsk_load_resident: provider "internal", have-pin debug1: sk_probe: 1 device(s) detected debug1: sk_probe: selecting sk by touch debug1: ssh_sk_load_resident_keys: trying /dev/hidraw5 debug1: check_sk_options: option uv is unknown debug1: read_rks: get metadata for /dev/hidraw5 failed: FIDO_ERR_MISSING_PARAMETER debug1: ssh_sk_load_resident_keys: read_rks failed for /dev/hidraw5 Provider "internal" returned failure -1 debug1: ssh-sk-helper: sshsk_load_resident failed: invalid format debug1: main: reply len 8 debug1: client_converse: helper returned error -4 Unable to load resident keys: invalid format   which makes me confused.

    Steps to Reproduce the Problem

    1. Generate a pair of residental ssh key by ssh-keygen -t ecdsa-sk -O resident.
    2. Plug the OpenSK device to another PC.
    3. Try to load the key generated to that PC ssh-add -K -v

    Specifications

    • Device: Nordic nRF52840 Dongle
    • Version: c6d3f51 of develop branch
    • Platform: Arch Linux

      I would appreciate it if you could do me a favour to solve that problem. Looking forward to your reply on your earliest convenience.

    opened by JunASAKA 13
  • Support ed25519 crypto algorithm

    Support ed25519 crypto algorithm

    Fixes #335

    This PR uses external ed25519-dalek crate for crypto implementation, which lead to several changes I'd like to get feedback on:

    1. ed25519-dalek requires Rust 2021. For that, I've made some changes to third-party/libtock-rs submodule, which are commited in https://github.com/egor-duda/libtock-rs/tree/ed25519. They change rust-toolchain channel to nightly-2021-10-21 and update asm code to use numbered labels due to enabled #[deny(named_asm_labels)].
    2. This change also causes new warnings about llvm_asm! macro being deprecated, and I don't know ARM assembly that well to be able to properly migrate from llvm_asm! to asm!. As a temporary workaround, I've removed -D warnings in deploy.py
    3. Crypto structs in ed25519-dalek do not implement Clone and Eq, so instead of deriving those traits for PrivateKey, I've implemented them explicitly. Not sure if that is correct way to do that.

    I've added --with-ed25519 option to deploy.py, and tested on nrf52840_dongle with openssh (ssh-keygen -t ed25519-sk) with PIN both enabled and disabled. I'm not sure is there is some webauthn test site which allows selecting specific crypto algorithm, would appreciate any pointers.

    opened by egor-duda 12
  • Should clear all credentials/PIN after flashing the new firmware?

    Should clear all credentials/PIN after flashing the new firmware?

    Currently, after you flash a new firmware to OpenSK, existing PIN/credentials (resident or non-resident) are still valid, you can still use them to authenticate to online services.

    Should OpenSK clear all existing Credentials(resident or non-resident), PIN and other security parameters if it has been updated to the new firmware?

    question 
    opened by geofli 12
  • OpenSK firmware can not work well with nRF52840 dongle after 2e419fe77b37255778fe13166cdc891caee3b334

    OpenSK firmware can not work well with nRF52840 dongle after 2e419fe77b37255778fe13166cdc891caee3b334

    Expected Behavior

    Before (include) 2e419fe77b37255778fe13166cdc891caee3b334, when insert nRF52840 USB dongle to USB port, LEDs are off. When receiving CTAP2/U2F command, LEDs will blink and wait for user presence. After user press the button, it response correctly.

    Actual Behavior

    Now (after 2e419fe77b37255778fe13166cdc891caee3b334), after insert to USB port, LEDs are blinking even if it is in idle. OpenSK does not work after user presses button.

    Steps to Reproduce the Problem

    1. Download firmware to nRF52840 dongle as usual.
    2. Replug it to USB port, take a look at the LED status, they are blinking, different from before.
    3. Test it on https://webauthn.io/ or other test website.
    4. Make credential and press button.

    I tested source code from 752bf47ed5caa2265e1d3884a40798fd7a2e95d6 to latest. It has same behavior.

    bug 
    opened by geofli 12
  • NRF52840 moduł RF E104-BT5040U

    NRF52840 moduł RF E104-BT5040U

    Expected Behavior

    This board on aliexpress NRF52840 moduł RF E104-BT5040U

    Actual Behavior

    Wsl doesn't recognize DFU mode. I was pressed resset and was plug into usb. I trying with VirtualBox with xubuntu ans WSL also and result is the same. image image

    • Platform: DFU
    opened by Firemanpl 6
  • Easier porting to other architectures

    Easier porting to other architectures

    Despite I know ESP32-C3/C2 is magnitude slower than nRF52840, but I want to port this there. Right now OpenSK seems like very centric to nRF52840, but I guess this can be traded with time. There is one thing about ESP32-C3/C2 though, that they don't have official atomic support, and I believe changing it to use atomic_polyfill can have some, say like timing consequences. Wonder if we can make something relaxed so we can port things easier?

    opened by stevefan1999-personal 3
  • RUSTSEC-2022-0063: Multiple vulnerabilities resulting in out-of-bounds writes

    RUSTSEC-2022-0063: Multiple vulnerabilities resulting in out-of-bounds writes

    Multiple vulnerabilities resulting in out-of-bounds writes

    | Details | | | ------------------- | ---------------------------------------------- | | Package | linked_list_allocator | | Version | 0.8.11 | | URL | https://github.com/advisories/GHSA-xg8p-34w2-j49j | | Date | 2022-09-07 | | Patched versions | >=0.10.2 |

    • The heap initialization methods were missing a minimum size check for the given heap size argument. This could lead to out-of-bound writes when a heap was initialized with a size smaller than 3 * size_of::&lt;usize&gt; because of metadata write operations.
    • When calling Heap::extend with a size smaller than two usizes (e.g., 16 on x86_64), the size was erroneously rounded up to the minimum size, which could result in an out-of-bounds write.
    • Calling Heap::extend on an empty heap tried to construct a heap starting at address 0, which is also an out-of-bounds write.
      • One specific way to trigger this accidentally is to call Heap::new (or a similar constructor) with a heap size that is smaller than two usizes. This was treated as an empty heap as well.
    • Calling Heap::extend on a heap whose size is not a multiple of the size of two usizes resulted in unaligned writes. It also left the heap in an unexpected state, which might lead to subsequent issues. We did not find a way to exploit this undefined behavior yet (apart from DoS on platforms that fault on unaligned writes).

    See advisory page for additional details.

    opened by github-actions[bot] 0
  • Pinned rust toolchain (nightly-2021-03-25) from libtock-rs causes linking errors on aarch64-apple-darwin

    Pinned rust toolchain (nightly-2021-03-25) from libtock-rs causes linking errors on aarch64-apple-darwin

    Expected Behavior

    Compiling OpenSK should work fine on platforms like aarch64-apple-darwin (e.g. with cargo build --features std)

    Actual Behavior

    Compiling with the pinned toolchain from libtock-rs causes linking errors on aarch64-apple-darwin. I assume that rust support for apple silicon chips was not ready yet at this point.

    Steps to Reproduce the Problem

    1. Run cargo build --features std on aarch64-apple-darwin and observe the following C++ linking errors (watch out, very long).

    Compiling libtock_core v0.1.0 (/Users/yk/Documents/Coding/opensk_fork/third_party/libtock-rs/core) error: linking with cc failed: exit status: 1 | = note: "cc" "-arch" "arm64" "-L" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.0.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.1.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.10.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.11.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.12.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.13.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.14.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.15.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.2.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.3.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.4.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.5.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.6.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.7.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.8.rcgu.o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.build_script_build.z8vntg2w-cgu.9.rcgu.o" "-o" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e" "/Users/yk/rust-artifacts/debug/build/proc-macro2-f3cf9a69785a363e/build_script_build-f3cf9a69785a363e.3hj9l8a3kvh4kb7e.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/yk/rust-artifacts/debug/deps" "-L" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-c74e6b3de522962e.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-c93ea4d419dae922.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libobject-d002150646c82cc7.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libaddr2line-08d0962d65625914.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgimli-19ddd96688ea0319.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd_detect-d8646d3f69dbb0b4.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_demangle-53d2a1a1245eee83.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-66a22362d0e1778d.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_alloc-ad006e595a77ae48.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunwind-0d9b6902b79f5775.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcfg_if-b94ae0abe03da051.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liblibc-e1883bf629bf5f4b.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liballoc-43a6bd8ab40401f6.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_core-309925a076418223.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcore-4ce201db55ae746f.rlib" "/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-226f06aaeebfc929.rlib" "-lSystem" "-lresolv" "-lc" "-lm" "-liconv" = note: ld: in /Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-c93ea4d419dae922.rlib(lib.rmeta), archive member 'lib.rmeta' with length 35728 is not mach-o or llvm bitcode file '/Users/yk/.rustup/toolchains/nightly-2021-05-25-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-c93ea4d419dae922.rlib' for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

    Possible Solution

    Updating the pinned nightly toolchain to a later version like 2021-06-25 and hence updating the specified submodule. With simple overwriting I found out that for example nightly 2021-05-25 does not seem to work yet but the June version one month later indeed does (meaning the above compile command passed without any errors).

    Since the toolchain is propagated through the libtock-rs version we need to be careful not break any (runtime) functionality with later versions.

    opened by L0g4n 2
  • APDU parser has multiple errors

    APDU parser has multiple errors

    I found a couple of bugs while reviewing the OpenSK APDU parser, because while writing a FIDO client library, I noticed many FIDO implementations have buggy ISO 7816 implementations. I haven't run this on "real hardware" to try it out properly.

    1. APDU parser does not handle extended form with Nc = 0 and Ne > 0 ("Case 2E"). It would error out with WRONG_LENGTH.

      Example request, where Nc = 0 and Ne = 0x1234:

      CLA INS P1 P2 0x00 0x12 0x34
      

      U2F GET_VERSION is impacted by this, other U2F commands and CTAP2 (over an ISO 7816 transport) always have command payloads.

      The parser appears to only handle "Case 2S" (short form Nc = 0 and Ne > 0), but supporting extended form is required for all transports, and supporting short form is only required over NFC.

    2. APDU parser accepts malformed 3 byte Lc + 3 byte Le.

      Per ISO 7816-4:2005 Section 5.1 (Command-response pairs), when Nc > 0 and Ne > 0 and using extended form ("Case 4E"), the correct representation is:

      CLA INS P1 P2 0x00 {Nc as uint16_be} {command bytes} {Ne as uint16_be}
      

      The implementation here appears to also incorrectly accept malformed requests of the form:

      CLA INS P1 P2 0x00 {Nc as uint16_be} {command bytes} 0x00 {Ne as uint16_be}
      

      The only reason Le should be prefixed with 0x00 is if the Lc field is absent and Le is in extended form ("Case 2E").

      Accepting malformed requests can cause implementers "testing against OpenSK" to make mistakes which are only exposed when testing with another FIDO implementation which follows ISO 7816 correctly. I've already seen subtle differences in existing FIDO certified devices with malformed inputs.

    Note: "Case 2E", "Case 2S" and "Case 4E" references to ISO 7816-3:2006 section 12.1.3 (Decoding conventions for command APDUs); S = short form, E = extended form.

    Case | Command Data Field | Response Length Field | Total length ----- | ------ | ---- | ----- Case 1 | None | None | 4 bytes Case 2S | None | Present (1 byte) | 5 bytes Case 2E | None | Present (3 bytes) | 7 bytes Case 3S | Present (1 byte) | None | 5 + (command data length) bytes Case 3E | Present (3 bytes) | None | 7 + (command data length) bytes Case 4S | Present (1 byte) | Present (1 byte) | 6 + (command data length) bytes Case 4E | Present (3 bytes) | Present (2 bytes) | 9 + (command data length) bytes

    bug 
    opened by micolous 1
  • --debug output not printingon nrf52840dk

    --debug output not printingon nrf52840dk

    Hi,

    I am hoping to do some work based on OpenSK but am having some difficulty getting the debug printouts to work. Is there something that I am missing in this process?

    When I use an unmodified (non-opensk) version of tock, I am able to see the "Initialization complete. Entering main loop'" printout as well as extra printouts made by userspace apps (such as the libtock-c button-print example). Using OpenSK, when I do not have the OpenSK connected to my computer via the USB peripheral cable, I can see this message as well as an explicit print statement that I added in the main loop. When I have the USB peripheral cable connected, I cannot see any of these printouts.

    edit: I am now thinking that the issue may be just that pressing the reset button (even without the peripheral usb attached) stops the console writes from showing up. Is this expected behavior?

    Expected Behavior

    When I start a server in one terminal with:

    JLinkExe -device nrf52 -if swd -speed 1000 -autoconnect 1
    

    And a client in another with:

    JLinkRTTClient
    

    and then deploy opensk to my board with:

    ./deploy.py --board=nrf52840dk --opensk --debug --panic-console
    

    I see the Tock initialization printout and additional opensk debug output when going through an example setup flow.

    Actual Behavior

    There is no output in the RTT terminal beyond the following when the peripheral USB cable is connected and after pushing the reset button to connect:

    SEGGER J-Link V7.80b - Real time terminal output
    J-Link OB-nRF5340-NordicSemi compiled Dec  3 2021 15:46:49 V1.0, SN=1050271190
    Process: JLinkExe
    

    When the peripheral USB cable is not connected, I can see other outputs but cannot see debug print statements (though this could be because I am not able to initiate an authentication flow without the second USB connected)

    Steps to Reproduce the Problem

    As above.

    Specifications

    • Version: stable branch 1b70583
    • Platform: x1 carbon gen 6 running manjaro linux
    documentation 
    opened by bkettle 11
Releases(ctap2.0)
  • ctap2.0(Jun 23, 2021)

    Except for some bugfixes that we applied after and which don't alter the CTAP2 behavior, this is the firmware that we had certified by the FIDO Alliance running on the Nordic nRF52840 dongle board.

    Source code(tar.gz)
    Source code(zip)
Owner
Google
Google ❤️ Open Source
Google
A Rust implementation of the Message Layer Security group messaging protocol

Molasses An extremely early implementation of the Message Layer Security group messaging protocol. This repo is based on draft 4 of the MLS protocol s

Trail of Bits 109 Dec 13, 2022
MimiRust - Hacking the Windows operating system to hand us the keys to the kingdom with Rust.

MimiRust - Hacking the Windows operating system to hand us the keys to the kingdom with Rust. MimiRust is a program based on the wdigest attack vector

Thotty 0 Nov 29, 2022
🕵️‍♀️ Find, locate, and query files for ops and security experts ⚡️⚡️⚡️

Recon Find, locate, and query files for ops and security experts Key Features • How To Use • Download • Contributing • License Key Features Query with

Rusty Ferris Club 11 Dec 16, 2022
Minimal and persistent key-value store designed with security in mind

microkv Minimal and persistent key-value store designed with security in mind. Introduction microkv is a persistent key-value store implemented in Rus

Alan 17 Jan 2, 2023
Rslide - A web service that allows you to move through multiple html pages in the browser like a slide, even without focusing on the app console or the browser. Currently only supports Windows.

rslide rslide is a web service that allows you to move through multiple html pages in the browser like a slide, even without focusing on the app conso

Jason Dongheng Lee 3 Jan 1, 2022
Applied offensive security with the Rust programming language

Black Hat Rust Applied offensive security with the Rust programming language Buy the book now! While the Rust Book does an excellent job teaching What

Sylvain Kerkour 2.2k Jan 8, 2023
Security advisory database for Rust crates published through crates.io

RustSec Advisory Database The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via https://crates.

RustSec 682 Jan 1, 2023
Automate device security provisioning with edge intelligence.

UNiD Automate device security provisioning with edge intelligence Features Decentralized PKI(DPKI), DIDs, DKMS, and Credential Management End-to-End E

UNiD 101 Oct 21, 2022
A utility like pkg-audit for Arch Linux. Based on Arch Security Team data.

arch-audit pkg-audit-like utility for Arch Linux. Based on data from security.archlinux.org collected by the awesome Arch Security Team. Installation

Andrea Scarpino 316 Nov 22, 2022
The Swiss Army Knife for Binary (In)security

binsec Swiss Army Knife for Binary (In)security binsec is a minimal static analysis utility for detecting security capabilities in ELF/PE/Mach-O execu

Alan 15 Dec 16, 2022
Bindings to the macOS Security.framework

macOS/iOS Security framework for Rust Documentation Bindings to the Apple's Security.framework. Allows use of TLS and Keychain from Rust. License Lice

Kornel 172 Jan 2, 2023
Audit Cargo.lock files for dependencies with security vulnerabilities

RustSec Crates ?? ??️ ?? The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via crates.io. The a

RustSec 1.2k Jan 5, 2023
irulescan is a static security analyzer for iRules

irulescan is a tool to scan iRules for unexpected/unsafe expressions that may have undesirable effects like double substitution.

Simon Kowallik 2 Dec 18, 2022
An esoteric language/compiler written with Rust and Rust LLVM bindings

MeidoLang (メイドラング) A not so useful and esoteric language. The goal of this project was to contain some quirky or novel syntax in a stack-style program

null 0 Dec 24, 2021
Lightweight slowloris (HTTP DoS) implementation in Rust.

slowlorust Lightweight slowloris (HTTP DoS) implementation in Rust. Slowloris is a denial-of-service attack program which allows an attacker to overwh

Michael Van Leeuwen 6 Sep 29, 2022
A paseto implementation in rust.

Paseto Rust Paseto is everything you love about JOSE (JWT, JWE, JWS) without any of the many design deficits that plague the JOSE standards. This is d

Instructure, Inc. 145 Nov 7, 2022
Userspace WireGuard® Implementation in Rust

BoringTun BoringTun is an implementation of the WireGuard® protocol designed for portability and speed. BoringTun is successfully deployed on millions

Cloudflare 4.8k Jan 4, 2023
Rust implementation of The Update Framework (TUF)

rust-tuf A Rust implementation of The Update Framework (TUF). Full documentation is hosted at docs.rs. Warning: Beta Software This is under active dev

heartsucker 152 Dec 11, 2022
A pure-Rust implementation of various threshold secret sharing schemes

Threshold Secret Sharing Efficient pure-Rust library for secret sharing, offering efficient share generation and reconstruction for both traditional S

Snips 137 Dec 29, 2022