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:
- Prevent someone else who gets the smart card from using it if they don't know the password.
- 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:
- 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.
- the password being keylogged and reused for prompts as well as being exfiltrated over the internet to be reused persistently.
- 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.
- 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/):
- 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).
- The client and terminal computer have a preshared key used to sign and verify responses. (not sure if step is needed)
- The client computer gets a prompt to tell user to authenticate with terminal computer.
- 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.
- 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.
- Once the server deems the certificate to be valid it will message the terminal computer to prompt for password.
- Once the terminal gets the password it would give password to smart card reader to validate.
- 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:
- Malicious software on the user client computer can’t steal public key/certificate for reuse because it was sent to server to validate.
- Malicious software on the user client computer can’t keylog the password because password was entered on the terminal computer.
- 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)
- 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?