IETF Logo Mail Archive

Re: [Teep] My BoF impression

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 05 April 2017 13:00 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 317581293E3 for <teep@ietfa.amsl.com>; Wed, 5 Apr 2017 06:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 aMseQBq0x7bc for <teep@ietfa.amsl.com>; Wed, 5 Apr 2017 06:00:43 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8BE128B38 for <teep@ietf.org>; Wed, 5 Apr 2017 06:00:43 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 60A58203AF for <teep@ietf.org>; Wed, 5 Apr 2017 09:25:01 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A54ED636BB for <teep@ietf.org>; Wed, 5 Apr 2017 09:00:42 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: teep <teep@ietf.org>
In-Reply-To: <22756.56473.620993.718007@fireball.acr.fi>
References: <HE1PR0802MB2475515770704882F9CFBDBCFA080@HE1PR0802MB2475.eurprd08.prod.outlook.com> <22755.33183.740819.743679@fireball.acr.fi> <12099.1491314086@obiwan.sandelman.ca> <22756.56473.620993.718007@fireball.acr.fi>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 05 Apr 2017 09:00:42 -0400
Message-ID: <1633.1491397242@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/jz5qMrxguiV7cNVTzd8oHyglBfU>
Subject: Re: [Teep] My BoF impression
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, 05 Apr 2017 13:00:45 -0000

Tero Kivinen <kivinen@iki.fi> wrote:
    > The end-user and app-writers already both trust the marketplace
    > provided by the operating system and trusts them. I.e. if marketplace

In Android, this trust is optional, and isn't locked down by the
manufacturer of the device or the supplier of the operating system (at
present).
We are free to create new marketplaces, and also free to avoid all market
places.   We (or, our respective enterprises or national security agencies,
e.g: NIST, CSE, etc.) are free to create environments where all source code
is available for review.

So while all of your points about trust for an average user are true, it does
not change the point that we (the IETF) should not be creating an environment
in which code can not be audited.

    > Have you ever tried to verify for example that the application in your
    > iPhone is really same as what was given to the apple app store? Can
    > you even do that in iOS environment?

Well. There is a reason I, and many others, have chosen not to build trust
in that vertically integrated environment.

    >> I think we need to very carefully seperate signed (and auditable)
    >> code from encrypted data. And said encrypted data has to be
    >> non-executable, and the auditable code has to be verified to not
    >> include a Turing machine.... no (encrypted) data driven programming
    >> allowed.

    > That would be another good option. On the other hand, I do think
    > application developers would like to encrypt the executable also in
    > some cases. Perhaps this just means that we would need two containers
    > we are sending from the trusted marketplace to the TEE, one for code
    > and one for data, and data would always be encrypted, but code only if
    > requested by the trusted app itself.

Exactly: it's not hard to do.

As for developers who think they need to encrypt their code:  it is akin
to cryptographers who won't publish their algorithm.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email