PIN not required to access the content

Nitrokeys
1

Hi, according to the FAQ user PIN is required to get access to the content of the Nitrokey Pro 2. I’ve noticed though that I can get access to significant amount of data stored on the Nitrokey without being challenged to enter my user PIN, by invoking gpg --card-status. In particular key identifying information is leaked then:

Signature key ....: 1F56 442D 13C1 EFF1 E0D6  5A25 FF41 D60B 15B1 801B
      created ....: 2023-02-27 15:37:40
Encryption key....: 79A6 4283 6D50 C486 74B2  5ED4 A5E2 3BBF 077B A645
      created ....: 2023-02-27 15:37:40
Authentication key: 08D8 A089 09DE 584F 32B2  0722 9119 DA13 B817 75C3
      created ....: 2023-02-27 15:37:40

Is there a way to lock it down?

2

gpg --card-status only displays public information of the smartcard used for identification purposes so that the system is able to use / interoperate with the device. I’m not sure what you mean with “significant amount of data”, but just having these information won’t enable an attacker to complete any gpg operation that require your secret key (decrypt, authenticate, sign)

3

I’m aware it’s not a key security issue but a privacy issue. For example a human rights activist or a journalist who established a separate digital identity may get exposed when their Nitrokey gets into wrong hands. I was expecting that user PIN needs to be entered upon inserting Nitrokey for that identifying information to become readable.

4

I’d just avoid inputting information that can be tied to the real or digital identity (name, email, url to public key, …) in the first place if the smartcard is being used for the purpose you described.
Obviously this doesn’t guarantee total anonymity (this doesn’t exist and I guess GPG isn’t the best tool for anonymity anyways), but under regular circumstances there shouldn’t be enough information to tie the gpg --card-status to the public key you share with others using the digital identity.

edit: my last sentence was incorrect

5

The key fingerprints can be used to tie the identities. A fingerprint is after all a hash of a public key. Moreover when shared via a key server, a full public key retrieval can be done by its fingerprint. Also key fingerprints (or their tail: key ID) are commonly being shared within digital profiles (to establish that identity/trust in the key) so OSINT search can also match the fingerprint to the digital identity, indeed just simple search engine search may be enough.

6

I guess you are correct. I’m not sure though if the gpg --card-status can be pin-protected on smartcards without breaking interoperability with gpg. That would be indeed good to know

7

after skimming through the specs it sounds like the user PIN should guard retrieval of data, the relevant part of point 4.3:

PW1 is used as access condition for the command …, GET DATA

8

You might want to check chapter 5 Security Architecture, which describes which PIN is needed to access which data object, and why.

9

Thanks for pointing that out! Indeed the specs state in chapter 5 that those data pieces should be available without PIN challenge. It is quite odd though as whilst 4.3 state “PW1 is used as access condition for the command …, GET DATA” there’s actually just a single data object that requires PW1… moreover a custom data object. The specs also seem inconsistent as PW3 (admin PIN) is required for reading another custom data object but in 4.3 it’s only mentioned that PW1 is used for GET DATA…

Anyway it sounds that unfortunately solutions that follow that specs are not suitable for use cases where privacy is important.

Nitrokey docs should be however corrected as now they provide misleading statement that may give false sense of privacy protection and put certain users at risk. The docs should state as the specs (in point 4.3) that user PIN is “used for signing and decryption operations”, not that it’s “used to get access to the contect of the Nitrokey”.

10

This scenario most likely was not part of the threat model for the implementation of the OpenPGP Card. In my interpretation the goal was to protect the key material and the exchanged secret message not the metadata and identities that communicate with each other.

Solution could be two token. One with your day2day identity and a second with ephemeral keys that are re-generated periodically. A trusted third-party then signs your ephemeral key and provides access to the public key. Alternatively, the trusted third-party could distribute a shared and frequently updated key that could be imported to the second token. Over a secure channel, the communication partners agree on the key ids that should be used.

gpg allows for --hidden-recipient so that the keyid will not be embedded in the message. If the key is rolled frequently, there is no possibility for traffic analysis.

The two communication partners never use their main identity to communicate but always the ephemeral one that is validated by the third party.

2 Likes