[Pcsclite-muscle] Directly using RSA key of a smartcard

[Douglas E Engert]

On 6/23/2023 10:40 AM, Michael Conrad wrote:
> On 6/23/23 07:57, David Woodhouse wrote:
>> On Wed, 2023-06-21 at 13:08 -0400, Michael Conrad wrote:
>>> Thanks, and if you want some stackexchange credit I have the question at
>>>
>>> https://unix.stackexchange.com/questions/749431/is-there-a-tool-that-can-perform-direct-rsa-decryption-with-a-yubikey
>> I've just spotted from the preamble on your StackExchange question that
>> what you asked about here isn't what you want to do at all :)
>>
>>> The use case I'm looking for is that I walk up to a headless server
>>> and "unlock" it using a hardware key, where scripts on the server
>>> recognize that I've plugged it in and automatically use it without a
>>> pin or password or additional factors.

On PIV including Yubico, the 9D key can be used for decryption but requires a user PIN. The 9E key is meant for card authentication and does not need a pin, but the  default key usage is for 
authentication. See my other response on how to set KeyUsage in the certificate to allow decryption. The certificates could be self signed in your use case but for better tracking should have some CA 
instead.

>> I think you want http://opensc.github.io/pam_pkcs11/doc/pam_pkcs11.html
>>
>> Make your own CA for pam_pkcs11 to trust. Generate a key on the Yubikey
>> and a corresponding cert signed with your CA. Configure pam_pkcs11
>> accordingly.
>
> I'm pretty sure PAM isn't what I want actually.  Remember its a *headless* server so the only logging in would be over SSH.  The point of the yubikey is to unlock a cache of secrets after machine 
> reboot, by anyone holding the key, which is kept separate from the server.  So in other words, I could unlock it with passwords from remote, and (in a yet-unrealized future) it could be unlocked 
> automatically by a key server if it passes some checks, but if I'm not around and the internet is down, I'd like anyone in the office to be able to grab the yubikey out of a physically locked drawer 
> and unlock the server after a reboot simply by plugging it into a USB port and nothing else.  And, this "locking" is not just an auth check, it needs to guard against extracting data from physical 
> theft of the server.  (but, we don't encrypt the entirety of the server because that's a different hassle.  We just encrypt the sensitive parts.)  The AES key I would be decrypting would get passed 
> to ZFS to unlock a sub-volume, and maybe also store some applications' keys to remote services if they aren't in the encrypted volume.  I have some other vague ideas for using this that would be 
> nice not needing root permissions.
>
> Basically, the thing that sent me on this quest was that ZFS only supports *one* unlock method (as opposed to LUKS that holds the AES key itself and allows you to unlock that AES key using a variety 
> of methods that you can change after the fact, including yubikeys) and so I was trying to come up with some scripts that would do a similar thing as LUKS.  I started with gpg, but it brings a lot of 
> extra baggage with it, and I was thinking "RSA is pretty basic, there must be a way to do this without all the extra certificate keyring baggage".  The end result of the scripting will be one 
> command that says "encrypt this small secret with whatever key is plugged in right now" and a second script that says "can the key plugged in right now successfully decrypt my small secret".  The 
> second one needs to run without any interactive steps because it will be called from a udev rule. Also, if people already have yubikeys that they use for other purposes, I'd like to use their 
> existing RSA key rather than overwrite it.

If you want to have no PIN required and have use their existing RSA key rather than overwrite it. Some problems:

  * If their Yubikey is lost, stolen or borrowed, it could be used by someone else with access to the computer room.
  * Each of the users would have to have a file on server with the same AES key encrypted with their RSA pubic key (in the certificate), so script would have to identify the user to match the file
    they encrypted. Should be easy by using the certificate name.
  * If the locked up yubikey breaks, you will need a backup copy(s) on another (Yubikey like you propose) or some way to retrieve and use the AES key.
  * Do you do disaster backups?  Does the backup have the encrypted or unencrypted part of the ZFS in backup? If encrypted, you will need way to get the AES key.

I think the best lead so far is this example from PyCKS11: https://github.com/LudovicRousseau/PyKCS11/blob/master/samples/encrypt.py
>
> (So far I haven't had much luck getting the python modules to work, or even getting half the yubikey software to work, and I might have to come back when I have more time)
>
> Meanwhile, thanks everyone for all the advice!  This is way more than what I could find googling.
>
> -Mike
>
>
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle

-- 

  Douglas E. Engert  <DEEngert at gmail.com>