Re: [EAT] Introduction

[Shawn Willden <[e-mail]>]

The main action item at this point is on me, to understand the EAT draft
proposal and figure out in what ways it does or doesn't work for Keystore.
I wrote the overview so that other participants could understand my goals,
and possibly inform me if Keystore attestation is fundamentally different
from what EAT intends to accomplish. Based on Ned's reply, it sounds like
that's not the case.

On Thu, Sep 6, 2018 at 8:36 PM Suresh Marisetty <[e-mail]>
wrote:

> Hi Shawn,
>
>
>
> Good overview.  Is there an action, take away or a proposal from your end
> on the ongoing EAT effort and the direction it is on?
>
>
>
> Thanks
>
> Suresh Marisetty
>
>
>
>
>
> *From:* EAT <[e-mail]> *On Behalf Of * Shawn Willden
> *Sent:* Thursday, September 6, 2018 10:08 PM
> *To:* [e-mail]; [e-mail]
> *Subject:* [EAT] Introduction
>
>
>
> Please excuse me if I'm violating some list etiquette with this
> introduction; it seemed like the best way to jump in. It appears that
> cross-posting between RATS and EAT is fairly common, so I think I'm good on
> that front :-)
>
>
>
> My name is Shawn Willden, and I lead the Android hardware-backed security
> team at Google. I designed and implemented the Keystore attestation scheme
> that's been present in Android since 7.0 (Nougat) and required for new
> devices since 8.0 (Oreo). Laurence invited me to participate in the EAT
> effort.
>
>
>
> I'm very interested in standard attestation protocols.  Attestation in
> Keystore began as a narrow solution to a narrow problem, but it has become
> clear that there is massive demand for attestation in a wide variety of
> contexts. I'm not particularly happy with Keystore attestation, but it's
> hard to argue for changing it given that many people have implemented
> solutions on it, warty as it is. Compliance with an IETF standard would
> provide a perfect rationale for revising it -- assuming, of course, that
> the standard actually meets all of Android's needs.
>
>
>
> Since I doubt everyone is familiar with Android Keystore attestation [1],
> let me give a brief overview.
>
>
>
> Android Keystore provides a place for Android apps and system components
> to store and use cryptographic key material (RSA, ECC, AES & HMAC) in a
> trusted [2] environment. The goal is that key material should not be
> compromised even by total compromise of the Android operating system, e.g.
> kernel compromise.
>
>
>
> Further, since 6.0 (Marshmallow), various usage constraints can be
> attached to keys at key creation time, and most of these constraints are
> also enforced by the trusted environment, limiting the use of the trusted
> environment as an oracle for an attacker who has compromised Android.. The
> ways that keys can be used are expressed affirmatively as "authorizations";
> keys may only be used in ways defined by the associated authorizations.
> Perhaps the most obviously-useful of the authorizations is authentication
> binding. Authentication-bound keys may only be used when the user
> authenticates via password or fingerprint so an attacker who steals or
> finds your phone cannot use the keys.
>
>
>
> So Keystore provides a valuable tool to authors of apps that require
> strong security. For example, for a key used to authenticate an account
> holder to a banking system. But this tool is much less valuable if the
> bank's server can't verify that the secret is managed in a trusted
> environment. Hence, Keystore attestation, which allows the trusted
> environment to prove that it secures the key material, and specifies the
> authorizations that define how it may be used.
>
>
>
> Some important constraints upon Keystore derive from the fact that it is
> an implementation (some may say "subversion") of the Java Keystore API
> [3].  A result of needing to fit attestation into the standard Java APIs
> was that attestations must come in the form of an X.509 certificate chain.
> Given that it would be necessary for users of Keystore attestations to
> parse the ASN.1 DER-encoded X.509 certificate, I opted to implement
> attestation as an ASN.1 DER-encoded certificate extension, so they didn't
> have to parse two different sorts of encodings. To simplify implementation
> in resource-constrained trusted environments, I opted to structure the
> schema around the data structure that implementations already used to
> manage authorizations, namely "authorization lists".
>
>
>
> The schema has subsequently been extended to support device ID attestation
> (attesting to various device identifiers -- though this functionality is
> tightly restricted in the interest of user privacy), and attestation of
> firmware versioning data. I expect more such extensions to come in each
> release of Android, as more use cases are identified and implemented.
>
>
>
> Within the Android scheme, attestation signing keys are injected into
> devices during manufacturing and can never be rotated without returning the
> device to the manufacturer. Signing keys are also not device-unique,
> because we use standard RSA and ECDSA signatures, not a group scheme, and
> we wished to avoid providing a strong unique device identifier, again for
> user privacy reasons. Android compliance requirements specify that each
> signing key must be injected into at least 100K devices, all of the same
> model. Attestation key certificate chains are rooted in a Google-owned
> certificate for Android devices with Google Play; manufacturers of non-Play
> devices (e.g. Amazon) can provide their own root.
>
>
>
> Because this is already long I won't go into the rationale behind the
> decisions described in the last paragraph, but I'm happy to explain.
>
>
>
> [1] https://source.android.com/security/keystore/attestation
>
> [2] "Trusted" is always an interesting word. The actual security level of
> the various Android trusted execution environments (TEEs) is largely
> unknown. Based on what has happened every time security researchers looked
> hard at them, I suspect they're not very good. However, they are isolated
> from the main Android OS and the usage model generally means that it's
> necessary to first compromise Android in order to even begin attacking the
> TEE. Thus they provide a security benefit, though precisely how large is
> unknown. With Android 9.0 (Pie) we've begun supporting Android Keystore
> backed by hardware secure elements, which come with a culture of
> certification testing which is presently lacking in the TEE world.
>
> [3] https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html
>
>
>
>
>
>
>
> --
>
> Shawn Willden | Staff Software Engineer | [e-mail] |
> 801-477-4296 <(801)%20477-4296>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
-- 
Shawn Willden | Staff Software Engineer | [e-mail] | 801-477-4296