Re: [Teep] use case document comments
Dapeng Liu <maxpassion@gmail.com> Wed, 15 March 2017 12:08 UTC
Return-Path: <maxpassion@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7E012E852 for <teep@ietfa.amsl.com>; Wed, 15 Mar 2017 05:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xMxnUIvW6Fv for <teep@ietfa.amsl.com>; Wed, 15 Mar 2017 05:08:56 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FFF129C34 for <teep@ietf.org>; Wed, 15 Mar 2017 05:08:56 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id x75so7181235vke.2 for <teep@ietf.org>; Wed, 15 Mar 2017 05:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wDr0JvaYD1Ax6lLSN0KEoi5CO80l4Ewcum9vIyeF4mA=; b=sQ71HrKHVyvLijEh3Xfj5iavTIa7Wr7P4vKCx92eUemwmu+HOnXTsZnuzf3LYICxeJ RyQrEtC4sdvHM+NJN/FdrZsub4WFkUzQCdsPhD7OM+4n/vdrJswHL8hYwYNx1I/ONZKa JcaEMqeB3pZZob3CU+yS3x17qKNdmKBfFKYYmFIr5/KichHRv8VssT88FFvi5FrQmuwA bijAPFXKyIfeAR3yk8q2jfA9JAzBCvyV8AwqXvLJbbkP7+j8v6dvtDcgQcKmzdcOdqY9 Z0GRmSbUuDpiGDD0nGj2rUg2yOGrmSh/at644eGiyy0NrtXUkEr2ZKydlHNLrss5zNOS OlsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wDr0JvaYD1Ax6lLSN0KEoi5CO80l4Ewcum9vIyeF4mA=; b=LXTaLPH9m2faxmq6KDjOfefK0Af8GY0QYngEJ/+f4kUW9LQRaQhJqpqTCgFwgL79Bx 2u4ZvhvXFxyGvejEK3QgrmopL7FmcHtVcxGh+mY4Ixsiq1rXpH3X/HzekbjFOLmqJlPB QPK+10Ap8jZ8aUiS1jN5ILdQJ5iD3yhj1zxWJu53ujSnFodXzgrTac30qeYHZqaO++Zv zufB0Qpm32WlxNaPuszJLpDuT/klZ4EF9abDW8LR8TD3ydIPFV570GLZrpqyfL2965yG dCbII92EqrH96GSQetmEvhiy2FJ8TWfgWQR6RKSiHLDZXRDvU74tsaufpLWazLUAg6eR ZPxQ==
X-Gm-Message-State: AFeK/H3LMPSTj9TKpV2Yz4T7GniSQwW8ls1fmZT/M1Wx/RNaKFQd+BMqeu49ELTYzmRpWZCgZ+/kSi9RoiP/UA==
X-Received: by 10.31.106.198 with SMTP id f189mr815751vkc.149.1489579735414; Wed, 15 Mar 2017 05:08:55 -0700 (PDT)
MIME-Version: 1.0
References: <19661.1489540019@obiwan.sandelman.ca> <2C2F51E2-34DA-4394-94E7-9F9E9E38F330@qti.qualcomm.com>
In-Reply-To: <2C2F51E2-34DA-4394-94E7-9F9E9E38F330@qti.qualcomm.com>
From: Dapeng Liu <maxpassion@gmail.com>
Date: Wed, 15 Mar 2017 12:08:44 +0000
Message-ID: <CAKcc6AcF0O2mxiY3jti7QtFtucZgCTWYE61gvuz-CU813eJD_g@mail.gmail.com>
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: teep <teep@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c09506afe7d18054ac3cec1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/2UWrM8d60K9vm9vM775ABsxLM2c>
Subject: Re: [Teep] use case document comments
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 12:09:00 -0000
Hi Jeremy, Thanks for the clarification and comments. We will update the draft soon. Thanks, Dapeng Liu On Wed, Mar 15, 2017 at 6:49 PM Jeremy O'Donoghue <jodonogh@qti.qualcomm.com> wrote: > Hi Michael, Teep group, > > I have tried to clarify some of Michael’s questions/comments below. I > generally agree with his assertion that the use cases lack detail about: > > - What assets are involved and who owns them. > - What attacks are envisaged. > - What are the security assumptions. > > > I see no use of requirements (RFC2119) language in the document, so it is > unclear how requirements derive from this document - perhaps this reflects > my unfamiliarity with IETF processes. RFCs 7515, 7516, 7517, 7518 are not > referred to in the document - they should be removed from the list of > normative references. > > On 15 Mar 2017, at 01:06, Michael Richardson <mcr+ietf@sandelman.ca> > wrote: > > > Thank you for the use case document. > I think that there is a need in the use case document to explain who owns > the > code inside the TEE. (It seems that a device like a smartphone would need > a > multitude of TEEs) > > > Current generations of Smartphones contain a single TEE (I am unaware of > any current deployment of multiple TEE in a single device, although it is > theoretically possible). > > As a generalisation, OTrP is addressing an execution environment in which > there are multiple actors contributing code. Typically > > - Secured boot loader and firmware (e.g. device drivers). This is > typically supplied by the SoC vendor and/or device OEM. The use case > document uses two terms for this: SBM (Secure Boot Module) and TFW (Trusted > Firmware). Personally I prefer SBM as “Trusted Firmware” may be confused > with a specific ARM technology. > - The TEE kernel and application level APIs (TEE). This may be > supplied by a third party of by an SoC vendor, depending on the device. > - Trusted Applications (TAs) - these are supplied by Service Providers. > > > TAs have to trust the code provided by the TEE and SBM. They must also > trust the sandboxing between TAs that is assured by the TEE. This can be > assessed by independent security evaluations such as that offered by > GlobalPlatform <https://www.globalplatform.org/teecertification.asp> or > under the Common Criteria, if the use case requires it. > > OTrP organises TAs under Security Domains (SDs). An SD is simply a > representative of a Service Provider or (usually) its delegate. It is > basically a set of keys and permissions. > > 3.1. Use Case 1 - Payment > > So on the one hand the document suggests that the TEE will contain personal > information relating to payment, so be securely unlocked by the end user > via > some kind of SecureAttentionKey interface. A private key, or perhaps an > anchor for a blockchain signer.... > So the end user needs to intimately control what code is inside (i.e: be > able > to delegate that trust to a party that they trust). > > Then the document says: > For the development of the relevant TA of SP, the > use of OTrP can easily send the latest trusted application to the > device. > > I get the impression that the bank is going to send updates to the trust > application. But, it's the bank that I'm going to dispute a payment with, > so in fact, I can't let them create the audit trail at my end. > > > The assumption is that the end user trusts their bank. TA updating here > should be seen more as a matter of updating for new features and/or > security fixes. It is similar to the Smartphone “App Store” model of > updates. You do need to trust that your bank will not destroy any audit > trail in the device as part of an update. > > If the TEE being controlled implements the GlobalPlatform APIs (this is > true for many deployed TEE implementations), there is a set of trusted > storage APIs which provide mechanisms allowing persistence of secure data > across TA updates. > > No use case was given for media, yet that was mentioned. > Nor Enterprise. > > In each case, I think that the contents of the TEE are controlled by a > different party. And each party seems to want to control the screen and > keyboard. > > > There are many use cases which do not require user interactions to be > under the control of the TEE - for example if signing and/or encrypting > data which was generated in the REE (e.g. Android, Windows, Linux). > > GlobalPlatform compliant TEE implementations can implement APIs supporting > secured control of display, touchscreen input and biometric authentication > if these use cases are required. The GP APIs essentially guarantee that > only one TA controls the relevant peripherals using a transaction, and > provides mechanisms to indicate this to the user. There are commercial > deployments of all of these APIs. > > It is probable that components such as secured input and/or display > contain significant components in all of the TEE kernel, SBM and REE (due > to the need to orchestrate ownership of peripherals). > > Since OTrP explicitly manages only TAs, it is not obvious to me that a > large class of potential security bugs can be fixed using OTrP alone. A > good example is at > https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking.pdf. > This type of exploit can probably only be fixed with a complete system > update. I am uncomfortable with any use case implying that OTrP can be used > to patch system level vulnerabilities such as keyboard and display. > > 3.2. Use Case 2 - IoT > > The only example here given is smart door locks. > I think that this is really confused. The most important thing the TEE > can > do is to provide original bootstrap process, and then yes, storage and > update > of session keys. After putting all that in the TEE, what's actually left? > > > I believe the intention here is to indicate that the session keys are > stored and owned in a TA rather than in the TEE itself. This might allow > e.g. a hotel chain to use multiple vendors of door-locks and manage them > from a single system (TSM) of its own. > > ==== > > Based upon what I have read so far, I can't see a role for the IETF, but I > continue to read with an open mind. > > > Best regards > Jeremy > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep >
- [Teep] use case document comments Michael Richardson
- Re: [Teep] use case document comments Jeremy O'Donoghue
- Re: [Teep] use case document comments Dapeng Liu