[Teep] My BoF impression

Tero Kivinen <kivinen@iki.fi> Tue, 04 April 2017 11:21 UTC

Return-Path: <kivinen@iki.fi>
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 A0464129648 for <teep@ietfa.amsl.com>; Tue, 4 Apr 2017 04:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 nhb3cSiwNTVI for <teep@ietfa.amsl.com>; Tue, 4 Apr 2017 04:21:15 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6520B129644 for <teep@ietf.org>; Tue, 4 Apr 2017 04:21:12 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v34BL44K015560 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 14:21:04 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v34BL3gi010127; Tue, 4 Apr 2017 14:21:03 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <22755.33183.740819.743679@fireball.acr.fi>
Date: Tue, 04 Apr 2017 14:21:03 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: teep <teep@ietf.org>
In-Reply-To: <HE1PR0802MB2475515770704882F9CFBDBCFA080@HE1PR0802MB2475.eurprd08.prod.outlook.com>
References: <HE1PR0802MB2475515770704882F9CFBDBCFA080@HE1PR0802MB2475.eurprd08.prod.outlook.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 15 min
X-Total-Time: 15 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/AaEAX5wT7KOBYLZajlDUoJfqSXk>
Subject: [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: Tue, 04 Apr 2017 11:21:18 -0000

Hannes Tschofenig writes:
> Going fast forward to the end of the meeting, the chairs asked two questions:
> 
> Q1: “Does the group understand the work to be done?”
> 
> A: More people hummed yes than no but it was only by a bit.  Not convincing.
> 
> Q2: How many people are interested in working on this?
> 
> A: About 14-15 people.
> 
> Sitting in the plane going back to Austria I was wondering whether we should
> have asked further questions to those who said “no”. I am curious what aspect
> they didn’t understood or whether this group included also those who weren’t
> interested to do the work or, like PHB, wanted a different hardware security
> solution to begin with.

I would have liked to have bit more time at the end for these type of
questions, but the discussion before those were also good, so I did
not want to cut it too short.

My feeling that the main question what people did not understand was:

	What is the real difference between TEEP and just normal
	application download. I.e., why separate protocol is needed.
	How is this different from just having perhaps encrypted
	signed application blob from the marketplace and installing
	that.

At least that was my main question when we discussed this before the
BoF.

Of course it does not help, that when you ask that question from
different people you get different answer, as the idea of what TEEP is
different for different people...

Trying to make the architecture too generic also confuses things. It
might be better to have more concrete example with more limited scope,
that would explain things what TEEP should provide.

For example:

	1) TEEP provides a way to install software from the Secure
	trusted application marketplace to the TEE running inside
	device.

	2) The Secure trusted appliation marketplace needs to be able
	to verify that the TEE wanting to install an application is
	actual TEE, and not some fake device, for example using
	signature from the key installed by the manufacturer which is
	used to sign the installation request.

	3) The Secure trusted application marketplace can then encrypt
	the trusted application with TEE specific key, so that nobody
	else than TEE can decrypt and install it. This will prevent
	leaking out confidential material inside the application.
	Trusted application instlal package might also be personalized
	for the specific TEE. Secure trusted application marketplace
	will also sign the trusted application install package, so TEE
	can verify it is authentic.

	4) TEE will verify the signature of the trusted application
	install package, and check that signer is trusted, and then it
	will decrypt the package, and install it.

	5) The application running on the REE side might need to
	verify that the trusted application part of it has been
	properly installed to real TEE, so it can trust it doing its
	job. I am not sure if this will be part of the TEEP or not...

Is my understanding of TEEP correct? I do not know, and I assume other
people have different ideas what should or should not be part of it.
-- 
kivinen@iki.fi