Re: [EAT] Introduction

Suresh Marisetty <> Fri, 07 September 2018 02:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1CB5130E12; Thu, 6 Sep 2018 19:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id efGbLjbKDSx9; Thu, 6 Sep 2018 19:36:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10423130DC9; Thu, 6 Sep 2018 19:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fMOWERJ8uW9Vnz54mAuwqe/WX7EBk7XHNTnJ4GQuYtQ=; b=dbMvP1cbM+nPPM4J6/DfDzpBvnnPmnBruerwV+dXODX0qyRhpT+/2O1wWerP6zekbfRHkZr30kRqfbtX8hZYHjJiD47R/SQEsrY7zL4m4IC1NtPGHMxaj/xmt7bKNFzs+F92aL+/KI4uGUL35xXnGAtdFxnerklvEKJlUZ1QEmU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.18; Fri, 7 Sep 2018 02:36:15 +0000
Received: from ([fe80::9505:6d7c:35e9:cd92]) by ([fe80::9505:6d7c:35e9:cd92%4]) with mapi id 15.20.1122.009; Fri, 7 Sep 2018 02:36:15 +0000
From: Suresh Marisetty <>
To: Shawn Willden <>, "" <>, "" <>
Thread-Topic: [EAT] Introduction
Thread-Index: AQHURgRbR1UTNBxvRUGQteuagp1ntqTkGpaQ
Date: Fri, 7 Sep 2018 02:36:15 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR08MB3353; 6:DSydZ6HCtbexE4PwrFHJzc+5ytFma9AZ+LfmW4wX1/WgQhMVP8CSF9J0lXzxI6gO7IyW9MEoapo22RiGW3UGpVJ3R8eFI9w6rRbWYRoRv/qvKy4ZxmivlUlNF9U8vLyDya9BdOPC/FYwBYKkqdfoVAIptc7GRU3LE3gCOkC1Ge1gKOlL72MYVkvEhCwq7nRiUMDF9X0GhW6OKO1+rwXhrwQHg2Teh4D0BalA/lvUxnvjuGgW1vXpfOtm+3mOF39tWorkXjXXNIp5oYn4znCGmJyTmhMpxb8EWMnaSl91wuVIaEyjNgMAHmkRsPcD92uZ49+wOBj9qqJZqzKjAWG8iqDBe5+b86Ae/X6yo3PhQKRw3k7psIMW/iegHoZuxPU8K91fpfy+8SiaBiIqmNWF/juqBpb1evCBTKIWab8uvCCUajkXKLUGeegHKLLFcY0U7QdrcqHCp8CUhhr5eT+X4A==; 5:CPiQaC+YWtWk8HSqTRqiACkZyYC5bkbn1wnhQiHk7Ooj8mXPGo2VfcYT5+FLZxUN1pr+LNnbj9ApQ44JNL4HrglQV/v1Z5YZdm6c5EsdurepamoeEGHV8PbBQaZt1z0tLh5L7GAy9aYodcpdRMfVTOYqfZU7rcTYrs+Ldp5crXE=; 7:w7R2cn96B+7hGenlBPswKnBeaAo5qK5r9e8H7BJeZwWJJLyRIo3RJRzQnFEH5sNvFTP/zaG+Wnp1C+dqVhEVsXENsne/ST96P+JDxW2srporWBP4JN3TqHTMYHjRbiNF9Lg9DjSunODApqVrPp1uSFcI12A4lDc8i91VNhmvzxIOORmghZf61TkT4PZELtjYhEPpBPhisvTK0zleWBF3nFEcgWdfawgZVggvuwV83FKY2ti0G5j5ExCrS4H7A57V
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9eec680f-a284-4832-8f86-08d6146aaf1a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB7PR08MB3353;
x-ms-traffictypediagnostic: DB7PR08MB3353:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(131327999870524)(103651359005742)(211936372134217)(21748063052155)(105169848403564)(146099531331640)(37804248451712);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:DB7PR08MB3353; BCL:0; PCL:0; RULEID:; SRVR:DB7PR08MB3353;
x-forefront-prvs: 07880C4932
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(346002)(376002)(396003)(189003)(199004)(40434004)(55016002)(6306002)(53936002)(2501003)(10750500005)(606006)(790700001)(6116002)(3846002)(551544002)(9326002)(2906002)(102836004)(26005)(81166006)(81156014)(8936002)(6436002)(68736007)(7736002)(66066001)(2900100001)(86362001)(561944003)(5250100002)(6246003)(8676002)(74316002)(555904003)(106356001)(446003)(11346002)(486006)(21615005)(476003)(966005)(14454004)(236005)(9686003)(6506007)(33656002)(5024004)(7696005)(186003)(316002)(229853002)(5660300001)(76176011)(25786009)(110136005)(99286004)(54896002)(478600001)(14444005)(256004)(105586002)(72206003)(53546011)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR08MB3353;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: NXe16K/fRuJFqxjZS7ZZyCZng31xIMCzHD94hTczAtidPpH9HzdCAWVTEArZgu0EnsJu8ziEEBaL6z1r5OHLAR30Bx9udaTAnaV0kpLJMkrNSoOUZrm1rL/kOqHai5MfOkQ++7qaTMC6afxKqr7BpSgyPdI703Vj0ekZmhJRR2jFIQHT0HzfJFCJzmbz2erlZ30KkxTjzRfF+OnuDNvzR3AwGx4WKrDfFtqv8Ldrv2fhVfgiGLAMeGIpkbEP9V6XruSC7V0PqPEX9fly8W0UMx6QoHDnfftcUDnbM6bdkJBXCH2Lr4HYmvdhQDK71olhC9m+cXZSBZBzb+W52WzWx1RpgpUzinjEj23HMMPekm0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB7PR08MB340199674A965A9BB202E51097000DB7PR08MB3401eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9eec680f-a284-4832-8f86-08d6146aaf1a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2018 02:36:15.6033 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3353
Archived-At: <>
Subject: Re: [EAT] Introduction
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Sep 2018 02:36:23 -0000

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?

Suresh Marisetty

From: EAT <> On Behalf Of Shawn Willden
Sent: Thursday, September 6, 2018 10:08 PM
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.

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

Shawn Willden | Staff Software Engineer |<> | 801-477-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.