Open xloem opened 5 years ago
There is no 100% protection against such scenarios. However, you could configure the PIN to be required for each signature operation. All other protection measures would likely significantly reduce the usability and - in the worst case - give the user the false impression of security.
@jans23 thanks for your reply. Couldn't an attacker just enter the PIN each time, even automatically?
I think it would be great if the device could be configured to have delays or use counts enforced per insert.
What usability or false impression issues do you see?
Couldn't an attacker just enter the PIN each time, even automatically?
Yes. In addition we have a signature counter so that it's possible to keep track and verify the amount of performed signatures.
What usability or false impression issues do you see?
For instance when adding a delay as suggested. It wouldn't provide any security IMHO because a malware should have plenty of time to enter the captured PIN and perform malicious operations.
I see -- I think you're saying your concern with the delay is that people might feel secure, when really all that's happening is slowing down an existing problem that hasn't been stopped.
Do you see any issues with letting the user limit the number of operations that can be performed by the device when inserted?
I'd also note that if a user can determine that their device is used maliciously, this gives an opportunity for them to revoke their key and do something about the situation.
Do you see any issues with letting the user limit the number of operations that can be performed by the device when inserted?
You can configure this in software, at least in theory (in practice there might be a GnuPG issue). Still, if the malware has your PIN, this doesn't really protect you.
I guess that would be my feature request.
If the device allowed only one operation after insertion, then the user could notice either from LED activity or from their legitimate operation being denied, that their key had been misused by an attacker or rogue process, and if this was illegitimate they could release a revocation certificate.
The denial message could even warn the user of the necessity of doing this.
There is a signature counter already implemented inside the smart card, which partly solves your requests. It is visible in the card summary via the GnuPG: gpg2 --card-status
.
Thanks.
It doesn't seem to me this would solve the security issue as a compromised system could lie to the user about the value reported. But it could be halfway there!
Do you think there's any likelihood around implementing a feature providing for configuration of things like the number of times used per insert?
Such would require to peek inside the smart card <-> PC communication, and for your use-case perhaps intervene by switching off the interface. At the moment the MCU is passing the communication as is. Perhaps later in the future, if we would introduce button confirmation for the signing, then adding such feature should be easily possible.
Having a small touch button would be great :) .
In the event the system is compromised and an attacker has the pin by recording keystrokes, is there any provision against the device being used maliciously?
For example, if the device were to enforce that it only perform 1 key operation, with a delay and LED feedback, after bootup, this could significantly deter automated use by a system infection.