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

[Anders Rundgren <[e-mail]>]

On 2019-06-20 15:16, Shawn Willden wrote:
> On Wed, Jun 19, 2019 at 8:03 AM Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 2019-06-19 04:31, Michael Richardson wrote:
>      >
>      > Anders Rundgren <[e-mail] <mailto:[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)?

Most of all I wanted to provision "stuff" in an *atomic fashion* which was the initial motive for the session based attestation scheme.
In my particular case "stuff" also includes various key meta data like payment credential images.

And how does the addition of StrongBox make keystore worse?

I don't have much data on StrongBox so maybe I was out of line there, but the idea I had was that keys would not be stored in secure silicon, but rather encrypted in the TEE or RE environment.  In that case StrongBox would be a crypto processor with embedded keys which also would be used for provisioning/attestation:
https://github.com/ietf-teep/architecture/issues/52#issuecomment-486929941

Anders

> 
>      >      > 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] <mailto:[e-mail]> | 720-924-6645