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

[Michael StJohns]

On 6/23/2023 7:30 PM, Michael Conrad wrote:
>
> The normal operating state of the server is to have the volume 
> unlocked.  If the yubikey is lost or stolen, the only danger is that 
> someone steals the server and then has both pieces.  They'd have to 
> pull the harddrives out and attach to another computer and then read 
> the scripts to figure out how to apply the yubikey to decrypt the 
> volume and get the data.  But if the owner knows they lost the 
> yubikey, they can tell me and I can revoke it easily, by deleting the 
> encrypted file for that key.
>
> I was planning to identify which encrypted file goes with which key 
> just by using the key's serial number, but I could even just attempt 
> decrypting all files and see if any successfully decrypts.
>
> The AES key would be encrypted multiple ways, including a manual 
> password that I could enter while logged into the server over SSH.  In 
> fact this is the current status-quo, that I have to log into the 
> server after any reboot in order to get things running again by 
> entering a password.  The yubikey is just a convenient and relatively 
> safe means of giving someone the ability to unlock the secure data 
> without logging into the server.  The backups are also encrypted, 
> currently with a password.  If we switch to this new idea, we will 
> also make a backup of the password-encrypted AES key in a safe place.
>
> It sounds like the biggest obstacle to using a user-provided yubikey 
> is that there are a lot of configuration variables that could make it 
> unusable for the script, unless maybe I ask them for their pin and 
> store that alongside the encrypted file.  Maybe we'll need to provide 
> a pre-configured yubikey.  (or maybe I can find something cheaper that 
> meets the requirements)


Hi -

Sorry for going off in a slightly different direction:

For the encryption of your volumes have you looked at OPAL TCG self 
encrypting drives?   And pairing that with TPM?   OPAL encrypts the data 
on the OPAL drive always, so erasing the drive is as simple as 
generating a new the OPAL drive encryption key. The use of that key may 
be password protected - the key itself never leaves the OPAL hardware.

Next step would be to encrypt the password under a TPM key that is tied 
both to the TPM and to a particular PCR regime.  E.g. the TPM will only 
decrypt the password if and only if the PC is in a very specific state 
(e.g. bios pre-boot).

The main thing with the protection scheme is that you can't just walk 
off with the drives, you have to walk off with the TPM as well, AND you 
have to be able to get the PCRs for that TPM to end up in the same state 
as they were on the previous device.

In this scheme, you could use the yubikey to store an encrypted master 
or user password for the drive as a backup to the TPM encrypted one.

Lastly, yubico is now providing biometric yubikeys - they won't work 
without a specific fingerprint - but that will limit the exposure of 
leaving a yubikey plugged in to the machine for boot.

Mike