Re: [Rats] Android attestations: Re: draft-richardson-rats-usecases-00 comments

[Shawn Willden <[e-mail]>]

On Wed, Jun 19, 2019 at 8:03 AM Anders Rundgren <
[e-mail]> wrote:

> On 2019-06-19 04:31, Michael Richardson wrote:
> >
> > Anders Rundgren <[e-mail]> wrote:
> >      > Here you have another link:
> >      >
> https://developer.android.com/training/articles/security-key-attestation
> >
> >      > As an application developer I find this scheme and the associated
> >      > "AndroidKeyStore" quite impractical.  The recent addition of
> >      > "StrongBox" makes it worse.
> >
> > Interesting. What is it that you find that you can not do?
>
> A mechanism that only attests keys cannot (securely) be used for
> provisioning anything but keys.
>

What else do you wish to provision? Anything other than TAs (addressed
below)?  And how does the addition of StrongBox make keystore worse?


> >      > With a two-level TEE/SE session-key based scheme you only need to
> >      > attest the session permitting you to perform any number of secure
> >      > operations and close the session with a "commit" which in turn
> responds
> >      > with a (session signed) message to the SP that everything went
> right.
> >
> > Or is this what you wish you had?
>
> In the absence of installable TA support, I have implemented this in
> Android as a SW emulator [1]. It is a part of the Saturn [3] payment
> authorization system I'm working on.
>

The Android platform security team considers this an anti-goal.  We're very
concerned that the scope of functionality being installed in TEEs is
exploding to a degree that the TEEs are becoming less trustworthy, not more
(and they haven't been particularly good).  Not only do we not want to
enable field-installation of TAs, we'd like to constrain factory/OTA
installation to smaller sets (some devices ship with upwards of 40 TAs
today), though our ability to do that is very limited.

There's a tension here between enabling more use cases and maintaining /
increasing the security of existing use cases. We recognize that GP and
many others disagree with us on how to balance the issues, and that perhaps
we're wrong, but we have to respond to the Android ecosystem as we see it.


> As I have tried to describe [2], this concept also relieves you from (IMO)
> unwanted/unnecessary dependencies on provisioning protocol formats.


> Anders
> 1]
> https://github.com/cyberphone/webpkisuite-4-android/blob/master/app/src/main/java/org/webpki/mobile/android/sks/AndroidSKSImplementation.java
> 2] https://github.com/ietf-teep/architecture/issues/52
> 3] https://cyberphone.github.io/doc/two-visions-4-mobile-payments.pdf


-- 
Shawn Willden | Staff Software Engineer | [e-mail] | 720-924-6645