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)
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.
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.
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.
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”.
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.