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

[David Woodhouse]

On Fri, 2023-06-23 at 11:40 -0400, 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.
> > 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.
> 
> 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)

OK, that makes sense. So what you want to encrypt is "the" AES key
that's used to unlock the ZFS volume.

So if you encrypt the key with the Yubikey as I described, you can have
a script triggered by udev which uses the Yubikey to *decrypt* that
file, then feed it to ZFS (preferably using pipes and not actually
letting the decrypted version hit the file system at all even
temporarily).

And you can do this for as many different Yubikeys as you like.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20230623/80865a4c/attachment-0001.p7s>