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

opcard.use_se050_backend not working with NK3 mini #474

Open
rakor opened this issue Apr 6, 2024 · 17 comments
Open

opcard.use_se050_backend not working with NK3 mini #474

rakor opened this issue Apr 6, 2024 · 17 comments

Comments

@rakor
Copy link

rakor commented Apr 6, 2024

The NK3-Mini is not working with the se050 backend.

I updated the nk3-mini:
./nitropy-v0.4.46-x64-linux-binary nk3 update --version v1.6.0-test.20231218

> gpg --card-status
Reader ...........: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00
Application ID ...: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: unknown
Serial number ....: XXXXXXXXXXXXX
Name of cardholder: [nicht gesetzt]
Language prefs ...: [nicht gesetzt]
Salutation .......: 
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 0
KDF setting ......: off
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

gpg can find the device as smartcard.

Then I changed the backend to use se050:
./nitropy-v0.4.46-x64-linux-binary nk3 set-config opcard.use_se050_backend true

Now, if I run card-status gpg freezes without any output.

I have to unplug the nk3 to run nitropy again (seem it hung).

Using Debian stable I run the following gpg-version:

gpg --version
gpg (GnuPG) 2.2.40
libgcrypt 1.10.1

@sosthene-nitrokey
Copy link
Collaborator

Thank you for reporting this issue you are encountering.

Changing the configuration of an application is only applied after a reboot. To prevent new data being written with a configuration that is incompatible, we disable the application when enabling the se050 backend. IT is therefore expected that gpg --card-status will not find the device. I can indeed reproduce it freezing rather than just No such device.

I will investigate this behaviour.

I have to unplug the nk3 to run nitropy again (seem it hung).

I do not understand this sentence. Are you saying that nitropy nk3 status does not work until a power cycle ?
nitropy and fido operations should be working before a factory-reset.

@sosthene-nitrokey
Copy link
Collaborator

Which version of nitropy are you using?

A recent enough version will reboot the device automatically.

After the reboot it is possible that gpg --card-status takes a bit more time to perform the initialization of the device, up to 10 second. During that times it might look like it is hanging.

@rakor
Copy link
Author

rakor commented Apr 11, 2024

I used: Command line tool to interact with Nitrokey devices 0.4.46

I can wait 10 minutes after starting gpg --card-status and nothing happens (LED shines blue-greenish). I unplugged and replugged it to be shure nothing hangs. Even after killing the gpg with ctrl-c the led stays on.
I did the update on a NK3NFC without issues. But the NK3Mini shows this behaviour.

@sosthene-nitrokey
Copy link
Collaborator

Can you please send the output of nitropy nk3 status and nitropy nk3 test ?

@rakor
Copy link
Author

rakor commented Apr 12, 2024

Here they are:

> ./nitropy-v0.4.46-x64-linux-binary nk3 status
Command line tool to interact with Nitrokey devices 0.4.46
UUID:               9B1260C79FC442A40000000000000000
Firmware version:   v1.6.0-test.20231218
Init status:        ok
Free blocks (int):  226
Free blocks (ext):  460
Variant:            NRF52
> ./nitropy-v0.4.46-x64-linux-binary nk3 test --pin XXXX
Command line tool to interact with Nitrokey devices 0.4.46
Found 1 Nitrokey 3 device(s):
- Nitrokey 3 at /dev/hidraw1

Running tests for Nitrokey 3 at /dev/hidraw1

[1/5]	uuid     	UUID query              	SUCCESS  	9B1260C79FC442A40000000000000000
[2/5]	version  	Firmware version query  	SUCCESS  	v1.6.0-test.20231218
[3/5]	status   	Device status           	SUCCESS  	Status(init_status=<InitStatus.0: 0>, ifs_blocks=226, efs_blocks=460, variant=<Variant.NRF52: 2>)
Running SE050 test: |                                                                                                                                                                           
[4/5]	se050    	SE050                   	SUCCESS  	SE050 firmware version: 3.1.1 - 1.11, (persistent: (31432,), transient_deselect: (607,), transient_reset: (592,))
Please press the touch button on the device ...
Please press the touch button on the device ...
[5/5]	fido2    	FIDO2                   	SUCCESS  	

5 tests, 5 successful, 0 skipped, 0 failed

Summary: 1 device(s) tested, 1 successful, 0 failed

@sosthene-nitrokey
Copy link
Collaborator

Does gpg --card-status not work even after a power cycle?
What does oct give you ? You can find this tool here: https://codeberg.org/openpgp-card/openpgp-card-tools

If so, does it work after running nitropy nk3 --factory-reset-app opcard --experimental?

@rakor
Copy link
Author

rakor commented Apr 14, 2024

Yes, I unplug the NK3, plug it in again, and even then it is not responding.

As I have no oct, and don't want to mess with my working debian, I have to setup a test-machine first. Please tell me if it would be important, as this would need some time.

I run:

Command line tool to interact with Nitrokey devices 0.4.46
Please touch the device to confirm the operation

After touching the device the command exits successfully.

If running > gpg --card-status I get the following result:

gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

After unplugging the NK3 and plugging it in again, I get the same result: gpg --card-status hangs and the led stays on.

@sosthene-nitrokey
Copy link
Collaborator

Thank you. However this error message from gpg does not contain enough information for us to understand where the error is coming from. For us to get a better sense of where the error is happening, we would need to have access to the scdeamon logs, including the data transmission from gpg to the device. This can be obtained by adding the following config to ~/.gnupg/scdaemon.conf:

log-file /tmp/scdaemon.log
debug-level expert

Then run gpg --card-status and check the /tmp/scdaemon.log file.

This data can contain personal data. It would likely be better to send it through a private mean such as our support email or through Matrix.

@rakor
Copy link
Author

rakor commented Apr 15, 2024

OK, I created ~/.gnupg/scdaemon.conf with the content you provided. As expected, same result. But the log-file is not written (I have also tried to write the logfile in the home-directory, just to be sure there is no permissions-issue. Same result.).

BTW: Even if I unplug the NK3mini while gpg --card-status is running there is no logfile written. But in this case gpg returns (as expected) the following:

gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

@sosthene-nitrokey
Copy link
Collaborator

You might need to restart scdaemon too, with: pkill -9 scdaemon.

@rakor
Copy link
Author

rakor commented Apr 15, 2024

I sent you the output through Matrix.

@tlaurion
Copy link

tlaurion commented Apr 16, 2024

@rakor if possible please upload log messages here otherwise traces for this bug are lost, and I would also like to see what is happening to eventually deactivate p256 algo fallback under heads.

@sosthene-nitrokey
Copy link
Collaborator

The relevant parts, containing no private data:

DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0
DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 01
DBG: response: sw=9000 datalen=0
DBG: dump: [all zero]
DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0
DBG: PCSC_data: 00 CA 00 4F 00
DBG: response: sw=9000 datalen=16
DBG: dump: D2 76 00 01 24 01 03 04 00 0F 9B 12 60 C7 00 00
AID: D2 76 00 01 24 01 03 04 00 0F 9B 12 60 C7 00 00
DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0
DBG: PCSC_data: 00 CA 5F 52 00
DBG: response: sw=9000 datalen=10
DBG: dump: 00 31 F5 73 C0 01 60 05 90 00
Historical Bytes: 00 31 F5 73 C0 01 60 05 90 00
DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0
DBG: PCSC_data: 00 CA 00 C4 00

The commands are:

- SELECT (wrong AID)

  • SELECT (good AID, success)
  • GET DATA (AID) success
  • GET DATA (historical bytes) success, lifecycle: Operational
  • GET DATA (PwStatusBytes) -> no response

@sosthene-nitrokey
Copy link
Collaborator

sosthene-nitrokey commented Apr 16, 2024

It could be a bug in the SE05x driver crate. The led suggests that the command is still running, and that the device has not crashed. The I2C driver does not have any form of timeout so the se05x driver always needs to read the correct data length. If it reads more, the device hangs as you observe.

The command that appears to be failing would be:

                &ReadAttestObject::builder()
                    .object_id(self.se_id.pin_id())
                    .attestation_object(GLOBAL_ATTEST_ID)
                    .attestation_algo(AttestationAlgo::ECdsaSha512)
                    .freshness_random(&rng.gen())
                    .build(),

It could also be an issue with the attestation key.

If that were the case I am surprised you would be the only one encountering this issue though.

On the other hand the SE050 itself and the I2C but are working reliably since the tests work.

It's possible that the issue would also come from the automatic configuration.

@sosthene-nitrokey
Copy link
Collaborator

We have released a new Release candidate that adds support for the SE050 backend. Can you please try running

nitropy nk3 update --version v1.7.0-rc.3 and then nitropy nk3 factory-reset-app opcard --experimental ?

If this doesn't fix the issue, can you then try nitropy nk3 factory-reset --experimental

@rakor
Copy link
Author

rakor commented Apr 17, 2024

Thanks a lot.
I did the nitropy nk3 update --version v1.7.0-rc.3 and the nitropy nk3 factory-reset-app opcard --experimental

After this I had the same result: led stays on, gpg hangs.

But after doing the nitropy nk3 factory-reset --experimental it is working.

> gpg --card-status
Reader ...........: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00
Application ID ...: XXXXX
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: unknown
Serial number ....: XXXXXX
Name of cardholder: [nicht gesetzt]
Language prefs ...: [nicht gesetzt]
Salutation .......: 
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 0
KDF setting ......: off
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

And the nk3 should use the se050:

>  ./nitropy-v0.4.46-x64-linux-binary nk3 get-config opcard.use_se050_backend
Command line tool to interact with Nitrokey devices 0.4.46
true

The device is now completely reset, incl. passwords and fido2.

Next I will try to setup my gpg-key.

Thanks a lot

@sosthene-nitrokey
Copy link
Collaborator

Thank you.

This is still a concerning issue. I would have hoped it could be fixed without a full-device factory-reset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants