I want to use a FIPS certified Opal drive on Windows to implement a system with at least one restricted encrypted partition. I want to use the band authentication feature of Opal to restrict access to a particular partition to a single service account. I would like the TPM to seal the band authentication key to that service account. I have been searching TCG and Microsoft documentation for days now and don't see anything to tell me if this is possible.
Asked
Active
Viewed 2,063 times
2 Answers
1
I don't know for sure, but I'll go with "no, that's not going to work".
First, I'm not sure whether "seal the band authentication key to that service account" is even something that makes sense to do with a TPM. The OS has no way of proving to the TPM that a specific user is performing the access, and an administrator could impersonate any other user ID – especially "service account" user IDs that the OS already needs to use without credentials.
Also, the TPM's PCRs are append-only and represent strictly-ordered events, but file access within the OS does not have a guaranteed order – so if the OS tried extending a PCR with the current UID for every file access, it would almost never succeed at arriving at the same PCR value twice.
(Alternatively, the OS could generate e.g. an EFS keypair on the TPM and use its own facilities to make sure only the specific account could access it – this is already very easy with interactive user accounts as there is a TPM-backed CNG key provider – but service accounts don't have DPAPI available to them, there's really nothing that could protect their keypairs from being stolen by an administrator armed with mimikatz.)
Moreover, in a multi-user OS, once a hardware device is unlocked, it remains unlocked regardless of what happens in the OS. So even if Windows was capable of unlocking a particular Opal drive when a specific account first tried to access it, from that point on it would still remain the OS responsibility to prevent the same drive from being accessed by other users.
In other words, as soon as your service was started there would still be no difference in using a service-specific key, versus using typical OS-wide BitLocker encryption and relying on NTFS file permissions. (If you can't trust the OS to enforce file permissions, would you really trust it to enforce the per-user Opal access restriction?)
grawity
- 501,077
-1
I'm coming to believe that what Windows is doing is defining only two bands on the Opal drive one for admin and one for user data. It gives Bitlocker both keys and then proceeds to manage the user data band as a raw volume that can be partitioned however the user likes. This would mean that there is no way that a user could access the band authentication functions of the drive. All user access control must be via NTFS.
hkc
- 47