How to mitigate spoofing, keylogging password, stealing public key with smart card with external/internal smart card reader?

Question

Here is my thought process:

I want to use smartcards without passwords for my setup. We don't want to use Iris or fingerprint or voice. I only want to put in the card whenever something needs to authenticate and when I take out the card whatever lower level software layer that handles the public key/cert/whatever from the smart card wipes it from memory. Only applications that have already authenticated above that lower level software layer keeps the authentication until they need it again. I am not sure there is cross platform low level smart card software that behaves like this. From what I understand passwords are needed for smart cards to:

1. Prevent someone else who gets the smart card from using it if they don't know the password.
2. Workflows/software that encourages the keycard to always be inserted make the password serve as sort of a challenge before smart card certificate/challenge response from smartcard reader (ideally) that would prevent least amount of software (ideally) from having access to smart card public key/cert/whatever.

Because of need 1 some other people who will use this setup feels it invalidates the concept of using passwordless smart cards and they have a winning vote so we have to prompt to use password.

From what I read, for at least kerberos/tls client auth (provided root cert is preinstalled) the smart card will provide a certificate to check against a root certificate somewhere before the process gets to the part where the smart card reader validates the passphrase entered by user.

For either of the two reasons for passwords how do you mitigate:

1. the smart card public key/cert from being read by malicious software on the computer (it gained root) after it has been sent over and then exfiltrated over the internet to be reused persistently.
2. the password being keylogged and reused for prompts as well as being exfiltrated over the internet to be reused persistently.
3. the user keeping the keycard in because the infrastructure encourages it and so the malicious program that got the password and the public key/cert can keep working because it's not blocked by challenge requiring card to be inserted.
4. Let's say attacker had enough access that they could get the cert/public key from the low level software that handles it (like in 2), but not enough to make a dummy device for the smart card reader and spoof challenge response from password. They would need physical access in conjunction with the software access and be able to spoof the smart card reader password challenge response with some custom device with https://github.com/crocs-muni/APDUPlay. Please correct me if I'm wrong if this is not possible or software used to do it.

How would I mitigate this? I would imagine I would need some kind of smart card reader proxy terminal. I would want generally (much of this was informed by explanation of smart card authentication process in comments of https://www.reddit.com/r/sysadmin/comments/rhe1cd/what_exactly_happens_during_smart_card/):

1. Client and terminal computer separately authenticate with smart card proxy server with rotating keys (rotating keys generated and rotating by separate unprivileged user on each machine) and encrypted communication using combination of Kerberos/(tls, ssh, or wireguard).
2. The client and terminal computer have a preshared key used to sign and verify responses. (not sure if step is needed)
3. The client computer gets a prompt to tell user to authenticate with terminal computer.
4. The client computer communicates with server that user is prompted with password and would communicate with the terminal computer associated with the user and client that initiated this request so the terminal computer would prompt the user an authentication request has as been made (optionally include application/computer name/user) and to insert a smart card into the smart card reader attached to the terminal computer or just prompt for password if smart card already inserted.
5. After password is entered the terminal computer would give the server the certificate from the smart card to check against a root certificate on the server.
6. Once the server deems the certificate to be valid it will message the terminal computer to prompt for password.
7. Once the terminal gets the password it would give password to smart card reader to validate.
8. Once the the password is validated the terminal computer will tell the server a success response which will tell the client computer a success response (in the encrypted communication) and the server would tell the terminal computer to lock the smart card (optionally the terminal computer could have setting to ignore this request and an additional option could be a password is only used once to log into the terminal computer but a gui button is used in place of password but user could lock terminal when going away or perhaps lock on removal of smart card).

For the scenarios I wanted to mitigate against I think this is mostly adequate because:

1. Malicious software on the user client computer can’t steal public key/certificate for reuse because it was sent to server to validate.
2. Malicious software on the user client computer can’t keylog the password because password was entered on the terminal computer.
3. If a user keeps a smart card in the smart card reader connected to the terminal computer, they will be prompted for password again. (If they disable this on terminal computer they are SOL, but if they choose the login in once and gui button in place of password option they are only SOL if someone commandeers their workstation when they are away, but if lock on smart card removal it would put the issue I had with smart cards on its head)
4. Attacker would need to spoof OK response from server (this response is in communication authenticated with Kerberos and sent encrypted and as said the rotated key used for this is only known by the dedicated unprivileged user on the client machine.) If user got root they could probably find a way to spoof the OK response. Even with preshared key, if attacker gets root they could probably intercept and trick the OK listener to do something. If attacker couldn’t do that for whatever reason they would still need to spoof physical aspect, but with terminal computer.

Is this correct reasoning? Is there software/open source projects available that already does this or makes this easier?

Answer 1

First of all, I think it's worth talking about some terms. A public key is the half of a key which is public; that is, it is assumed everybody on the planet can know it without having any impact on the security. Similarly, a certificate is typically that same public key with additional metadata, signed by a certificate authority, who states that the public key (and its corresponding private key) belongs to the party who claims to control it (in whatever sense is appropriate). Thus, there is no security improvement in wiping the public key or the certificate from memory since knowing it doesn't impact security in any way.

Typically, the private key, which must be kept secure and only used by the authorized user, is stored on the smartcard when smartcards are used, and the private key's operations are performed only on the card and never sent to the host machine. Extracting the private key is typically infeasible. Some smartcards will sign a hash provided over the protocol, and some may require the data to be sent to the card to be signed. In any event, most general-purposes cryptographic smartcards use a standard interface like PKCS#11, which allow clients to use a standard interface for communicating to the card and allow software to use the same interface for requesting cryptographic operations.

The PIN which is typically used for authentication is verified on the card. There's nothing to prevent an attacker from compromising the machine and re-sending the PIN to request additional operations, but the card is required since it contains the private key. Some smart cards and security keys may require physical interaction to perform an operation (such as the physical contact in YubiKeys), which can prevent scenario 3 since an attacker will not be able to physically touch the key.

Note that scenario 1 is not possible because it is typically infeasible to extract the private key from the smartcard. For scenario 2, the PIN can be stolen, but without the card, it's useless. Scenario 3 is fixed with physical presence requirements in the smart card (or using a security key with physical presence as a smart card). Scenario 4 is precluded because the private key cannot be accessed.

If your requirements really demand that the public key and certificate be protected, then they are considered secrets, and you need a technology that is not a typical smart card. I'll also mention that there is no way on a general-purpose machine to force the wiping of the public key from memory, and the smart card cannot trigger that itself since modern CPUs have an IOMMU, which prevents peripherals from accessing memory that they don't own. But, as I said, it probably doesn't matter.