[tpm2] Re: Possible TPM uses in fprintd/libfprint

* [tpm2] Re: Possible TPM uses in fprintd/libfprint
@ 2020-05-29  9:27 Benjamin Berg
  0 siblings, 0 replies; 8+ messages in thread
From: Benjamin Berg @ 2020-05-29  9:27 UTC (permalink / raw)
  To: tpm2

[-- Attachment #1: Type: text/plain, Size: 6353 bytes --]

Hi,

On Thu, 2020-05-28 at 01:10 +0000, Zhu, Bing wrote:
> Given that you already have a SDCP-capable sensor (like fingerprint),
> and you also have a trusted execution environment (TEE), then SDCP
> should work perfectly for you. on MSFT windows, virtualization-based
> security (VBS) provides a TEE to allow you to do that.  In other OSs,
> you can use Intel SGX-based solution to securely talk with your
> sensor based on SDCP security protocols. 

Yeah. I don't think I need to secure the channel though. This is about
being able to fully trust the process that it has correctly verified
the Fingerprint readers authenticity, that it is not itself a vector
for a MitM attack or can simply be bypassed somehow.

The idea mentioned earlier to include the SDCP enabled device in the
boot measurements would not require any further safety precautions. It
would be perfectly viable to verify and include the devices public-key
(and firmware hash) in the measurements.

> Now, may I have a question -  what problems would you like to solve
> if you need to add TPM?

I don't really think that adding a TPM will solve an issues in itself.
If I "just" authenticate a user on an already running system, then the
entire authentication stack is trusted anyway. SDPC does add a bit more
security as it allows to verify the integrity of the reader. But I
don't think that a TPM would make a major difference in this scenario.

My primary example of a new use-case would be to enable per-user disk
encryption and password less (or multi-factor) login together with the
Fingerprint reader.
In such a scenario the Fingerprint reader does not just authenticate
the user. Instead it also enables unsealing secrets for the user after
the finger was presented (e.g. a disk encryption key). Protecting these
secrets seems like a much harder problem than only authenticating the
user.

Benjamin

> > -----Original Message-----
> > From: Roberts, William C <william.c.roberts(a)intel.com>
> > Sent: Wednesday, May 27, 2020 22:48 PM
> > To: Benjamin Berg <benjamin(a)sipsolutions.net>; tpm2(a)lists.01.org
> > Subject: [tpm2] Re: Possible TPM uses in fprintd/libfprint
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Benjamin Berg [mailto:benjamin(a)sipsolutions.net]
> > > Sent: Wednesday, May 27, 2020 9:24 AM
> > > To: tpm2(a)lists.01.org
> > > Subject: [tpm2] Possible TPM uses in fprintd/libfprint
> > > 
> > > Hi,
> > > 
> > > I was wondering if someone has ideas about integrating the TPM
> > > with
> > > Fingerprint readers.
> > > 
> > > Recently I started looking into supporting Secure Device
> > > Connection
> > > Protocol (SDCP, [1]) in libfprint. The general idea is to verify
> > > that
> > > the Fingerprint reader can be trusted, but I initially also
> > > imagined
> > > that further use-cases like unsealing data in a TPM may be
> > > possible (e.g. to
> > retrieve disk encryption keys).
> > > However, looking into it more, my current conclusion is that
> > > there is
> > > little to no advantage to use the TPM. At least not unless one
> > > also
> > > has a trusted (userspace)
> > 
> > In theory you would have a measured boot environment. This way you
> > can attest
> > the host is in a good state. You could further isolate by have a
> > segregated userspace
> > components through things like Trustlets or SGX Enclaves. The
> > general paradigm of
> > security is to take sensitive operations and move them out of band
> > to a smaller
> > execution environment, this paradigm can be extended infinitely,
> > but the
> > restrictions here lie in the realm of how much work do you want to
> > do, which is
> > determining by what you're trying to protect.
> > 
> > > program which is capable of signing TPM authorizations. One could
> > > easily offload the required parts into a small helper, but that
> > > may
> > > require ensuring it runs in a trusted execution environment.
> > > Microsoft seems to run relevant parts as trustlets that are
> > > walled off
> > > from the rest of the system. That seems sensible to me, but it
> > > also
> > > means requiring all the infrastructure for execution and signing
> > > and I doubt that is
> > feasible currently.
> > 
> > You're still sharing hardware, which means that a potentially bad
> > host, could be
> > undermining the hardware and VM protections. Granted you have
> > higher level of
> > assurances, it's not a guarantee.
> > 
> > > 
> > > Right now I'll probably go the way of not using the TPM at all.
> > > But I
> > > am really not an expert for this. So should someone see scenarios
> > > where a TPM is actually helpful in this context, then I would
> > > like to hear about
> > them.
> > 
> > You could do a measured boot scenario that included measuring the
> > state of the
> > fingerprint reader (I'm assuming SCDO would give you something like
> > that).
> > Something has to cause the measurement to get extended into a PCR
> > so you can Get
> > a quote and check later that it's all OK. If it's all OK, you can
> > then release a secret
> > From the TPM. You can couple keys/objects to this measured state.
> > 
> > There is stuff on this in the Practical Guide to TPM2.0 and is
> > available os a ODF
> > download:
> > https://link.springer.com/content/pdf/10.1007%2F978-1-4302-6584-9.pdf
> > 
> > 
> > > Benjamin
> > > 
> > > PS: A quick summary of how SDCP works:
> > >  * Device has a private ECC key that signs the firmware and
> > > ephemeral
> > >    keys during boot (and is inaccessible afterwards)
> > >  * A certificate proofs that this key was provisioned in factory
> > >  * Device builds a shared secret with the host (s)
> > >  * Device sends id, HMAC_SHA256(s, "identify" || nonce || id)
> > >    when the finger "id" was presented.
> > >  * The HMAC proofs knowledge of the shared secret and authorizes
> > > the
> > >    print.
> > > 
> > > [1]
> > > https://github.com/microsoft/SecureDeviceConnectionProtocol/wiki/Secur
> > > e-
> > > Device-Connection-Protocol
> > _______________________________________________
> > tpm2 mailing list -- tpm2(a)lists.01.org
> > To unsubscribe send an email to tpm2-
> > leave(a)lists.01.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread