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

[Michael Richardson <[e-mail]>]

Carl Wallace <[e-mail]> wrote:
    > [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).

Some other emails and slides went back and forth privately.

Carl is looking at a self-service SCEP situation where a Time-base One-Time
Password (TOTP) is used to validate an enrollment process.

If he were using a strictly online mechanism like EST(RFC7030), then the TOPT
could be used to authenticate the TLS connection (using some EAP method, for
instance).

But, my understanding is that this goal is a mechanism which can operate with
some kind of store and forward situation such that an object-based security
for the PKCS10 CSR.

I'm not convinced this is in scope as a RATS use case.
Please tell me otherwise.

    >> 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.

So the trusted base of the system would be attesting that the hash check was
displayed to the user?    Maybe I don't understand what is being checked by a
human that could be skipped.


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