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

[Carl Wallace <[e-mail]>]

inline...

On Fri, Jul 5, 2019 at 2:47 PM Michael Richardson <[e-mail]>
wrote:

>
> Carl Wallace <[e-mail]> wrote:
>     >> 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.
>
>     > Re: more use cases, the ability to encrypt a key attestation in
> TEE/SE
>     > for a specific provisioning end point would be nice to have (to
> conceal
>     > a challenge password while in transit, for example).
>
> You have asked for a specific ability/feature: the ability to encrypt
> a claim using trusted code.  I don't know if that's a symmetric or
> asymmetric encryption.  I don't know who you need to hide the claim from.
> It
> seems that it can't be done by an app.
>

> Can you explain this in terms of the problem that you are trying to solve,
> or the threat you are trying to mitiate rather than a solution?
>
[CW] The problem that motivated the question is establishment of trust in a
public key associated with a specific device (i.e., the device in my hand
not any authentic XYZ device). The suggestion is to use an attestation
encrypted for a given relying party to convey something the relying party
can verify (i.e., a challenge password or TOTP value) along with the key
attestation. This could establish trust more conveniently than more manual
mechanisms like verifying hashes. An app could certainly perform this
function given an attestation but there may be value in performing this
step at a lower level, depending on whether the lower level validated the
key at all (else just doing encryption in the app would be equivalent).


>
> When you say challenge password, I think you mean some kind of nonce
> a relying party might send to the device in order to maintain freshness.
> That also seems like a solution to a problem, the nature of which I'm
> unclear
> about.

[CW] In the solution that motivated the question two TOTP values are used
to establish trust in a device key. The first used to present a fresh key
to a portal, the second used to capture affirmation of a person that the
hash check was performed and the device key is trusted. If the first OTP
was encrypted with an attestation, the second is potentially unnecessary.




> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>