Question regarding storage, and on safety of typing in pin on the host system?

Could someone please explain why the method of typing in your pincode at the actual computer ( or clicking the numbers ) is not super unsecure? a screengrab or keylogger would be able to grab your pin ? and if the computer is compromised already, now even the NitroKey is in the computer, and the attacker has te pin?

Other than that I was wondering; will there be a 3NFC version with extra storage capabilities? I would love hidden partition, and even more room for certificates would be a welcome addition, and worth the cost in my opinion.

If the PIN for a security token is grabbed by a keylogger, the security of the token is partially defeated. This is because the security token relies on the secrecy of the PIN to protect the stored key. If an attacker gains access to the PIN, he can use the security token to access the key and perform actions such as decryption or signing on behalf of you.

However, the secret material itself is still protected. As soon as you remove the token, any further information that has been encrypted with that token would stay confidential from that moment and the attacker would not be able to continue to impersonate you. The token reduces the impact of a successful attack.

On the other hand, GPG keys that are stored on the filesystem can be copied by an attacker and your only option would be to revoke the key (if you are able to use a revocation certificate to inform your communication partners)

Therefore it is crucial to safeguard your key and also remove it when not in use.

Most people would agree that it is already game over when an attacker is able to install a physical or software keylogger.

Some time ago I used the STRIDE framework to identify potential threats of a Nitrokey:

  • Spoofing: An attacker could spoof the Nitrokey token by creating a fake device that looks identical to a real Nitrokey token or modify software on a system that fakes interactions. This could be used to trick users into entering sensitive information (like User PIN or Admin PIN) which could then be stolen by the attacker.
  • Tampering: An attacker could tamper with the Nitrokey token by physically modifying the device to bypass its security measures. This could allow the attacker to access sensitive information stored on the device in order to bypass brutefore protection.
  • Repudiation: An attacker could gain access to the PIN while the token is still present on a system. An attacker accessing a system using someone else’s credentials (e.g. via SSH using gpg-agent) could cover up malicious activities or shift blame onto someone else.
  • Information Disclosure: An attacker could obtain sensitive information from the Nitrokey token by intercepting communication with the device or by exploiting vulnerabilities in the firmware. This could be used to steal sensitive data (e.g. the PIN) or exfiltrate Data Objects on the token.
  • Denial of Service: An attacker could launch a denial of service attack against the Nitrokey token by exhausting the PIN retries or wearing out the EEPROM/Flash storage (e.g. by increasing the signature counter). This could render the device unusable or cause it to malfunction, preventing users from accessing their data especially when there is no backup available of the key.
  • Elevation of Privilege: An attacker could elevate their privileges on a system by exploiting vulnerabilities in the Nitrokey firmware or by brute forcing the PINs protecting the device to gain access to sensitive data.

If you are concerned about this, using a card reader with a built-in PIN pad could be an option. Cryptographic smartcards used in the Nitrokey projects are available separately on the market.