Sometimes P256 signing can fail. See details:

• ycrypto/p256-cortex-m4#4

Even with just release firmware version 1.0.4 it is not possible to use the nk3a as a fido2 passwordless authenticator for microsoft.com.
With the newly released version it is possible to register the nk3a at microsoft without any issues (was flawky with prior versions) but it wont be accepted on a subsequent login flow. The site argues that the device is unknown.

Side note: I had no issues to use a Yubikey for the same scenario. Also the nk3a can be used as a fido2 passwordless authenticator for my nextcloud instance and as u2f for numerous sites like google, github or gitlab.

It looks like the scaling factor for the intensity of the red LED is a bit too low, reducing the red part of RGB colors. We should try to find better scaling factors.

Use official SDK source for building the bootloader code.
Making a ticket just to not forget about this later.
cc @daringer

Make LED signals more distinct between operations.
Connected:

• https://docs.nitrokey.com/fido2/windows/index.html#touch-button-and-led-behavior
• #18
• solokeys/solo2#112

Make the development FIDO2 certificate similar to the production one, or at least similar in size, to make issues reproduction on development firmware more reliable.

Connected: #36

There is no clear documentation on which firmware version to use for the Nitrokey 3A NFC or any of its variants. I recently purchased a 3A NFC and would like to know what is the correct firmware file to flash.

Symptoms from the user POV are: not reacting to the touch button press after a browser monit

Reproduction scenario

1. Run browser in log taking mode
2. Open https://webauthn.bin.coffee
3. Run both operations

The CCID operations in progress are unknown. PC was rebooted after the first issue occurrence, which has not helped.
Browser log shows that the CTAPHID channel was reported BUSY, thus browser could not communicate with the device.

Potential cause

Timing out the channel ID in CTAP / handling multiple channels implementation seems to not work properly.

Workaround

After power cycle (reinsertion of the device to the USB socket) it is working again.

While testing against fido2-tests I got multiple errors claiming the attestation certificate is invalid. To check and retest.

• Nitrokey 3 CN, LPC55, v1.0.3-24-ge0b4461, with no-reset-time-window.
• fido2.attestation.InvalidData: Attestation certificate must have CA=false!
• trussed-dev/fido2-tests@591d3d2

Only occurs with FEATURES=alpha on the lpc55, probably caused by a compiler bug related to LTO. rust-lang/rust#66118 suggests that replacing fat LTO with thin LTO should fix this, but that causes a hardfault for me. Should be investigated and reported upstream.

Dwarf Error: Cannot find DIE at 0x53752 referenced from DIE at 0xae6b4

Related tickets:

• rust-lang/rust#41775
• rust-lang/rust#66118

Prepare test suite with load tests

#123

The admin-app could have a command that checks whether the FIDO2 and Trussed certificates and keys are present and can be used successfully.

This is partly to supplement this post and also to respond to the official documentation.

Windows 10 support is very spotty to non-existent. After weeks of following the instructions in the previous links and getting rewarded with "This security key can't be used. Please try a different one," in Windows 10, it (very briefly) started working today when I tried using it in Edge (after failing with Firefox and Chrome). If I unplugged it, plugged it back in, did the right tap sequence and Hermes smiled upon me, Windows would recognise the key. However, I couldn't get it working consistently enough to actually try doing any useful work with it (like logging in to GitHub with it).

The Internet consensus is that Windows support should work, as there are no warnings to say that it's not. Given that the key briefly worked with Edge open, I'm guessing that there is some protocol issue where the communication between the Nitrokey and Windows is out of sync and Windows gives up. However, I don't know where in Event Viewer to start looking for the source of the problem, so I would be grateful for guidance to help troubleshoot.

My system is dual boot and, notwithstanding KDE's limited support for U2F, the exact same hardware works on Linux, so replacing my computer or Nitrokey is currently unnecessary.

UPDATE

This can be produced with only libfido2 (latest) #94 (comment)

ORIGINAL REPORT

enrolling a NK3ANFC works like a charm:

➜  ~ sudo systemd-cryptenroll --fido2-device=auto /dev/nvme0n1p3
🔐 Please enter current passphrase for disk /dev/nvme0n1p3: ******
Initializing FIDO2 credential on security token.
👆 (Hint: This might require confirmation of user presence on security token.)
🔐 Please enter security token PIN: ********              
Generating secret key on FIDO2 security token.
👆 In order to allow secret key generation, please confirm presence on security token.
New FIDO2 token enrolled as key slot 1.

But if I wipe the slot, and retry with a NK3AM all I get is being stuck and just hangs (setting systemd debug doesn't show anything either):

➜  ~ sudo systemd-cryptenroll --fido2-device=auto --wipe-slot=fido2 /dev/nvme0n1p3
🔐 Please enter current passphrase for disk /dev/nvme0n1p3: ******
Initializing FIDO2 credential on security token.
👆 (Hint: This might require confirmation of user presence on security token.)
🔐 Please enter security token PIN: **********              
Generating secret key on FIDO2 security token.
👆 In order to allow secret key generation, please confirm presence on security token.

<just hangs here forever w/o any journal or dmesg logs>

I've correctly touched the 3AM twice too, and inserted the correct pin too
Since cryptenroll is following a standard, I believe there must be a difference (or bug) between the NFC and Mini variants

I don't know if it's useful but the 3AM works the very same when used for MFA on Fedora with pamu2fcfg - so it seems at least there, they work the same (they should both be fido2 capable)

Also, while the process hangs above, what happens is that if I just ctrl-c the whole process, the 3AM is just in some state that requires me to unplug and plug it again to make it work (again) - operations like gpg --card-status just hangs too while the device is busy with cryptenroll

both cards are running firmware 1.2.2 and the 3AM also has the opcard firmware too

I cannot find the NK3 hardware repository. Is there one? If not, will it be released open source in the same way as the NK Pro? Also, is it possible to order a 'hacker' version with pins exposed that could be used to develop/ test the firmware?

here's what i did:

1. register the authenticator via fido2/webauthn on 5 sites
2. set a pin
3. update firmware from 1.1.0 to 1.2.2
4. store a resident ssh ed25519 key (generated with ssh-keygen -t ed25519-sk -O application=ssh:git -O resident)
5. store another resident ssh ed25519 key with a different name

here's the issues i encountered:

1. after the last action, chrome settings page stopped being able to read out 'sign in data', i.e. the two resident ssh keys.
   
2. at an unknown point after step 2 the webauthn login on one site intermittently stopped working. this can very well be a bug in that application, but i can't be sure. feel free to ignore this until i got to a reliable way to reproduce this
3. nitropy nk3 test reports no errors

i'd love to help debugging this, but i have no idea how, pointers would be helpful.

Google's 2FA is reported to not be working (1). Similarly Nextcloud's (2). To investigate.
Firmware: 1.0.1
Browsers: Firefox 96, Chromium 97.0.4692.99

Details:

• https://support.nitrokey.com/t/nitrokey-3c-nfc-and-google-2fa-not-working/3592/7
• https://support.nitrokey.com/t/firmware-update-nitrokey-3/3804/6

Currently, the wink command of the admin app only sets a flag but does not cause a UI change.

The opcard application provides an OpenPGP smart card. This is a tracking issue for its integration into the Nitrokey 3 firmware. For issues regarding the application itself, see the opcard issue tracker.

Current status:

• 2022-10-13: v0.1.0 alpha release (app, firmware, only nrf52)
• 2022-11-18: v0.2.0 alpha release (app, firmware)
• 2023-02-24: v0.3.0 alpha release (app, firmware)
• 2023-04-13: v0.4.0 test release (app, firmware)
• 2023-04-27: v1.0.0 stable release (app, firmware)

To do:

• set manufacturer to 0x000F (Nitrokey)
• set proper serial number

As a user I cannot remove RK using the Chrome interface for managing FIDO2 Security Key (non-Windows OS only).
Firmware version: v1.0.1, v1.0.2 (market samples).
Reproduction:

1. Create RK, e.g. using OpenSSH
2. Try to remove it using Chrome
3. See error:

Security key sign-in data. Your sign-in data couldn't be deleted

OpenPGP support missing

The information seems to be more or less available on the forum and in some update blog posts.

But it'd be really nice to have a place to subscribe to the progress or just being informed the moment support for use with gpg is released.

Would be nice if the issue could be confirmed and updated or at least closed when support for OpenPGP / gpg arrives.

We should update the quickstart documentation to use the embedded runner and the NK3ANH.

Dear All,

I just tried to upgrade my 3A Mini from the first alpha with support for OpenGPG card.
After the upgrade GnuPG is unable to recognize the NK 3A Mini.

14:17:29 ✔ comio@smo-mantel:~ $ nitropy nk3 update ~/Scaricati/alpha-nk3am-nrf52-v1.2.2-alpha.20221130.zip
Command line tool to interact with Nitrokey devices 0.4.31
Firmware image variant (lpc55, nrf52): nrf52
Current firmware version:  v1.2.2
Updated firmware version:  v1.2.2
The version of the firmware image is the same as on the device.  Do you want to continue anyway? [y/N]: y

Please do not remove the Nitrokey 3 or insert any other Nitrokey 3 devices during the update. Doing so may damage the Nitrokey 3.
Do you want to perform the firmware update now? [y/N]: y

Please press the touch button to reboot the device into bootloader mode ...

Perform firmware update: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 412k/412k [00:23<00:00, 17.8kB/s]

Successfully updated the firmware to version v1.2.2.
14:19:01 ✔ comio@smo-mantel:~ $ gpg --card-status
gpg: Scheda OpenPGP non disponibile: Operazione non supportata

GnuPG is able to recognize my other OpenGPG keys (like a Nitrokey Pro).

I'm not sure about the root of the issue.

ciao

luigi

Hardware: nk3am 1.2.2 + opcard 0.1.0

Absolutely nothing happened afaict, certainly I haven't resetted my key and it's now "empty", I'm on Fedora 37 if it matters:

Reader ...........: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00
Application ID ...: [redacted]
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: test card
Serial number ....: [redacted]
Name of cardholder: [not set]
Language prefs ...: [not set]
Salutation .......: 
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
KDF setting ......: off
UIF setting ......: Sign=off Decrypt=off Auth=off
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Within two seconds after boot, we should not require a button press to confirm FIDO2 Get Assertion or Authenticate requests as the device insertion already is a user presence indicator. This is consistent with the behavior of the Nitrokey FIDO2.

Hi, do you support, or plan to support sr25519 to handle polkadot and other substrate based crypto ?

Would be nice if its possible to keep the user data stored after a firmware update

working branch: https://github.com/Nitrokey/nitrokey-3-firmware/tree/embedded-runner-lpc55

Open issues:

• data migrations (FIDO2 cert)

  nitrokey-3-firmware/runners/lpc55/src/initializer.rs

  Line 764 in e0b4461

  pub fn perform_data_migrations(&self, basic: &stages::Basic, filesystem: &stages::Filesystem) {

• CFPA update

  nitrokey-3-firmware/runners/lpc55/src/initializer.rs

  Line 202 in e0b4461

  fn validate_cfpa(pfr: &mut Pfr<hal::Enabled>, current_version_maybe: Option<u32>, require_prince: bool) -> u32 {

• Buttons
• NFC
• no-encrypted-storage feature: should be enabled for NRF52, disabled for LPC55
• implement Reboot::locked

  nitrokey-3-firmware/runners/embedded/src/soc_lpc55/types.rs

  Line 96 in 5c1f730

  todo!()

• external flash, cf. https://github.com/Nitrokey/nitrokey-3-firmware/blob/main/runners/embedded/src/soc_nrf52840/extflash.rs
• ...

Trying to use the authenticatorGetAssertion command with the hmac-secret extension causes a CTAP2_ERR_INVALID_CBOR error.

For example using the hmac-secret.py example from python-fido2:

$ python3 hmac_secret.py 
no pin

Touch your authenticator device now...

New credential created, with the HmacSecret extension.
Authenticate with salt: b'9b17deb11321cdb10b56d8b75c85125a0e5627440892ef067fdd9f052c1ffd22'

Touch your authenticator device now...

Traceback (most recent call last):
 File "/home/robin/reps/python-fido2/fido2/client.py", line 690, in get_assertion
   assertions, used_extensions = self._do_get_assertion(
 File "/home/robin/reps/python-fido2/fido2/client.py", line 754, in _ctap2_get_assertion
   assertions = self.ctap2.get_assertions(
 File "/home/robin/reps/python-fido2/fido2/ctap2/base.py", line 857, in get_assertions
   first = self.get_assertion(*args, **kwargs)
 File "/home/robin/reps/python-fido2/fido2/ctap2/base.py", line 829, in get_assertion
   return self.send_cbor(
 File "/home/robin/reps/python-fido2/fido2/ctap2/base.py", line 675, in send_cbor
   raise CtapError(status)
fido2.ctap.CtapError: CTAP error: 0x12 - INVALID_CBOR

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "/home/robin/reps/python-fido2/examples/hmac_secret.py", line 113, in <module>
   result = client.get_assertion(
 File "/home/robin/reps/python-fido2/fido2/client.py", line 704, in get_assertion
   raise _ctap2client_err(e)
fido2.client.ClientError: (<ERR.BAD_REQUEST: 2>, CtapError('CTAP error: 0x12 - INVALID_CBOR'))

Steps to reproduce:

1. Plug in a Nitrokey 3 (C NFC in my case)
2. Plug in a different FIDO2 token
3. Log into a FIDO2 secured account and use the different token for FIDO2 authentication
4. Note that the LED of Nitrokey remains the same as if it was waiting for a touch

I tried this with the following different tokens:

• Yubikey Nano
• Token2 Security Key FIDO2 & U2F

Both different tokens stop blinking when I use the Nitrokey for authentication, so I think the Nitrokey's LED should get back to normal use (green) when the FIDO2 process is over and another token was used.

In upstream solo2, the T1 intermediate key is a 32-byte Ed255 key. In 8e70f9d, we changed it to a 64-byte P256 key. We should have a more flexible solution that allows 32 or 64 bytes and lets the user specify the key type.

In the embedded runner for the lpc55 soc, the provisioner hangs when reconfiguring the SPI interface after performing the hardware checks.

What is the difference between the Nitrokey 3 and the Solo key 2? In terms of both software and hardware? What should decide me to use one rather than the other? (I already have a couple of Nitrokey Pro 2, Nitrokey FIDO, and a Nitrokey Nextbox, so I am very positive to Nitrokey, but want to understand what the value proposition is with the NK3).

To make it easier to diagnose issues like #49 without a debugger, we should add a custom panic handler that adds a visual panic indicator, probably a red LED.

User reports, that RK feature use on NK 3 AM causes data lost.

ssh-add -K returned

Provider "internal" returned failure -1
Unable to load resident keys: invalid format

1. Tried to delete the resident key with chromium, just to learn there is no PIN setup, but he is sure he did setup a pin weeks ago
2. Added a new pin and tried to login to github but it didnt work
3. Reinstalled the firmware and the x5c bug occurs when testing

Nitrokey 3 crashes on receiving FIDO2 request. Device is unusable until power-cycle is performed.

It looks like fido-authenticator does not have all errors properly handled, hence the behavior.
I think it would be best to at least restart in the case of the error, if it cannot be gracefully handled. Otherwise should return error (general one, if not more apt available) to the caller.

Nitrokey 3 CN, LPC55, v1.0.3-24-ge0b4461, with no-reset-time-window.
Tested against: Nitrokey/CTAP2-test-tool@4b0aaff

#0  panic_halt::panic (_info=<optimized out>) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-halt-0.2.0/src/lib.rs:32
#1  0x0001ba20 in core::panicking::panic_fmt () at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a//library/core/src/panicking.rs:116
#2  0x0001c050 in core::result::unwrap_failed () at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a//library/core/src/result.rs:1690
#3  0x000113d8 in core::result::Result<fido_authenticator::credential::CredentialId, ctap_types::ctap2::Error>::unwrap<fido_authenticator::credential::CredentialId, ctap_types::ctap2::Error> (self=...) at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/result.rs:1018
#4  fido_authenticator::credential::Credential::id<trussed::client::ClientImplementation<runner::types::Syscall>> (self=<optimized out>, trussed=<optimized out>, key_encryption_key=..., rp_id_hash=...) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/fido-authenticator-0.1.0/src/credential.rs:255
#5  0x000067e6 in fido_authenticator::ctap2::{impl#0}::make_credential<fido_authenticator::Conforming, trussed::client::ClientImplementation<runner::types::Syscall>> (self=0x2003c800 <runner::APP::apps>, parameters=<optimized out>) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/fido-authenticator-0.1.0/src/ctap2.rs:368
#6  0x0000dd74 in ctap_types::ctap2::Authenticator::call_ctap2<fido_authenticator::Authenticator<fido_authenticator::Conforming, trussed::client::ClientImplementation<runner::types::Syscall>>> (self=0x2b <__EXCEPTIONS+35>, request=<optimized out>) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/ctap-types-0.1.2/src/ctap2.rs:458
#7  0x0000fc70 in fido_authenticator::dispatch::try_get_ctap2_response<trussed::client::ClientImplementation<runner::types::Syscall>, fido_authenticator::Conforming> (authenticator=0x2003c800 <runner::APP::apps>, data=...) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/fido-authenticator-0.1.0/src/dispatch.rs:173
#8  0x0000fb7a in fido_authenticator::dispatch::try_handle_ctap2<trussed::client::ClientImplementation<runner::types::Syscall>, fido_authenticator::Conforming> (authenticator=<optimized out>, data=..., response=<optimized out>) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/fido-authenticator-0.1.0/src/dispatch.rs:144
#9  0x0000fa4a in fido_authenticator::dispatch::handle_ctap2<trussed::client::ClientImplementation<runner::types::Syscall>, fido_authenticator::Conforming> (authenticator=0x3efde <.Lanon.b7f9711851ba8db6fe8fed9a6c5d3f8f.81>, data=..., response=0x200341c4 <ctaphid_dispatch::types::HidInterchange::split::INTERCHANGES+8>) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/fido-authenticator-0.1.0/src/dispatch.rs:69
#10 0x0000f570 in fido_authenticator::dispatch::ctaphid::{impl#0}::call<fido_authenticator::Conforming, trussed::client::ClientImplementation<runner::types::Syscall>> (self=0x3efde <.Lanon.b7f9711851ba8db6fe8fed9a6c5d3f8f.81>, command=..., request=0x20030b60, response=0x3c500) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/fido-authenticator-0.1.0/src/dispatch/ctaphid.rs:36
#11 0x00021c02 in ctaphid_dispatch::dispatch::Dispatch::call_app (self=0x2003c7f8 <runner::APP::ctaphid_dispatch>, app=..., command=..., request=0x20030b60) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/ctaphid-dispatch-0.1.0/src/dispatch.rs:50
#12 0x00021b6c in ctaphid_dispatch::dispatch::Dispatch::poll (self=0x2003c7f8 <runner::APP::ctaphid_dispatch>, apps=...) at /home/sz/.cargo/registry/src/github.com-1ecc6299db9ec823/ctaphid-dispatch-0.1.0/src/dispatch.rs:67
#13 0x000025ba in runner::idle::{closure#2} (apps=...) at src/main.rs:166
#14 runner::types::Apps::ctaphid_dispatch<runner::idle::{closure#2}, bool> (self=<optimized out>, f=...) at src/types.rs:287
#15 0x000015b6 in runner::idle (c=...) at src/main.rs:166
#16 0x0000feac in runner::APP::main () at src/main.rs:35
(gdb) 

-------------------------
Please touch your security key!                                                                                       
Test successful: Tests if MakeCredential works with parameters of the wrong type.                                     
Expected error code `CTAP2_ERR_CBOR_UNEXPECTED_TYPE`, got `CTAP2_ERR_INVALID_CBOR`.                                   
Test successful: Tests if MakeCredential works with missing parameters.                                               
Failed test: Tests bad parameters in RP entity parameter of MakeCredential. - Optional entry icon not recognized.     
A prompt was expected, but not performed. Sometimes it is just not recognized if performed too fast.                  
The failing error code is `CTAP2_ERR_INVALID_CBOR`.                                                                   
Please touch your security key!                                                                                       
Test successful: Tests bad parameters in user parameter of MakeCredential.                                            
A prompt was expected, but not performed. Sometimes it is just not recognized if performed too fast.                  
                                                                                                                      

This causes build issues when running cargo update

Upstream issue: trussed-dev/fido-authenticator#10

Reported to work on NK3AM (NRF52) with openssh 9.0p1-1, libfido2 1.11.0-1 by @daringer. We should check again after #46 is merged.

Hello, I'm working on getting this repository work with dream2nix (see nix-community/dream2nix#219). I've hit an issue that can't be solved unless either the issue is fixed here or in cargo (see nix-community/dream2nix#223 (comment)). Essentially the issue is that duplicate versions of the same dependency (in this case, trussed) is not supported by cargo vendor, which means dream2nix can't build it because it will vendor the dependencies for cargo but can't vendor two same versions of a dependency. So I wanted to ask if there is any chance that this duplicate version usage is removed? Or at least one of the sources changed to a different version so this does not happen. I'm testing it on the runners/lpc55 primarily, which is where I have seen this duplicate versions issue.

The admin app’s UUID command is only available over CCCID, not CTAPHID.

We should have reproducible builds. I tried remapping the the working directory and cargo home using --remap-path-prefix but that caused cargo objcopy to crate empty files.

See also:

• https://github.com/cbeuw/lotus/blob/master/cargo-build.sh

one curious thing is that I get the prompt to touch the device in the 3A NFC but it doesn't prompt with 3A mini
It seems if status == STATUS.UPNEEDED: # Waiting for touch this call in python-fido2 isn't called on the 3aMini

Nitrokey/pynitrokey#274

GnuPG card list stalls (for 30-60 seconds) while Nitrokey 3 is connected, blocking work with other user's smart cards. Further listing is cached, hence the delay is noticeable only the first time during given user session.

From the user POV, GnuPG operations should not be delayed.

OS: Linux Fedora 33

$ gpg2 --version
gpg (GnuPG) 2.2.25
libgcrypt 1.8.8

• deny warnings
• run cargo fmt -- --check, at least for the embedded runner
• run cargo clippy, at least for the embedded runner

Just flashed the file alpha-nk3xn-lpc55-v1.2.2-alpha.opcard.0.2.0.oath.0.3.0.sb2 via nitropy nk3 update alpha-nk3xn-lpc55-v1.2.2-alpha.opcard.0.2.0.oath.0.3.0.sb2 onto a 3A NFC and a 3C NFC. Update went up to 100% and after a few seconds a critical error occurred.
Another timeout(?) later the application quitted.

Both, the 3A and the 3C aren't even recognized anymore. dmesg reports

[  +6,892544] usb 4-2: device descriptor read/64, error -110
[ +15,570511] usb 4-2: device descriptor read/64, error -110
[  +0,239442] usb 4-2: new full-speed USB device number 82 using xhci_hcd
[ +15,546919] usb 4-2: device descriptor read/64, error -110
[ +15,573089] usb 4-2: device descriptor read/64, error -110
[  +0,106692] usb usb4-port2: attempt power cycle
[  +0,406841] usb 4-2: new full-speed USB device number 83 using xhci_hcd
[  +0,901844] usb 4-2: Device not responding to setup address.
[  +0,204628] usb 4-2: Device not responding to setup address.
[  +0,207172] usb 4-2: device not accepting address 83, error -71

lsusb hangs until I remove both keys.

This might be related to #44 :

I'm currently implementing CTAP2 into Firefox using this branch. As the branch-name suggests, I just added device selection, when multiple devices are found.
The way this is done (also in Chromium) is to send a 'fake' MakeCredentials-request to every device, making them blink (using pinAuth with zero length, as described in the CTAP2.0 spec. In CTAP2.1 we got a dedicated command for that.)
Once, one of them gets selected by the user, a CTAPHID_CANCEL-command is sent to all other devices, which cancels the pending transaction (and makes the blocking read return).

Since updating to v1.0.3 (I think it was not there before, but I might be wrong here), when I do this and select some token that is NOT the NK3, my code sends CTAPHID_CANCEL to NK3. Then on the next Init, I'm getting ERR_CHANNEL_BUSY from NK3.
So NK3 might not handle a cancel correctly?
This code works fine for other tokens (such as YubiKey, but also other vendors).

To test, clone the above branch of the repo and run cargo run --features crypto_openssl --no-default-features --example ctap2. In case you want to have more info on what is sent/received, run with RUST_LOG=trace (this is very verbose!)

The NK3A NFC blinks when waiting for user input but the NK3AM shines. It should blink when it is waiting for user input.

• Add all artifacts to sha256sum
• Sign checksums – @LennardBoediger can we give the CI server a private key?
• Append git describe to artifacts and use proper naming
  • lpc55: #78
  • nrf52
• Remove unneeded artifacts
  • @daringer do we need both bin and ihex for nrf? should we rename ihex to hex?
  • remove NK3AM lpc55 binaries
    • #78
• Automatically generate commands.bd
  • #73

Dear All,

I'm sorry for this request, maybe something is not clear to me.
I noticed that the 1.2.0 release doesn't provide the sb2 image to use with nitropy.

Thanks in advance for your attention.

Luigi