Re: [Teep] Hardware for hackathons

Michael Richardson <> Thu, 28 November 2019 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39F9C12011A for <>; Wed, 27 Nov 2019 23:19:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OoTLqTWyTO4 for <>; Wed, 27 Nov 2019 23:18:58 -0800 (PST)
Received: from ( [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AAB212008D for <>; Wed, 27 Nov 2019 23:18:58 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id 24CBC1F47D for <>; Thu, 28 Nov 2019 07:18:52 +0000 (UTC)
Received: by (Postfix, from userid 179) id 4B5CD110C; Thu, 28 Nov 2019 15:18:27 +0800 (+08)
From: Michael Richardson <>
To: "teep\" <>
In-reply-to: <>
References: <> <> <>
Comments: In-reply-to Akira Tsukamoto <> message dated "Wed, 27 Nov 2019 18:53:36 +0900."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Thu, 28 Nov 2019 08:18:27 +0100
Message-ID: <>
Archived-At: <>
Subject: Re: [Teep] Hardware for hackathons
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Nov 2019 07:19:00 -0000

Akira Tsukamoto <>; wrote:
    > For the further discussion for the future hackathon, I searched
    > information of Grapeboard and STM32MP157C-DK2 (which is STM CortexA7
    > devboard, I will abbreviate as StmA7board).

    > It is not mandatory but it would be nice to have/use unified
    > programing software stacks for the TEEP development on both TAM and
    > TEEP device.

I will admit that I'm struggling a bit to understand the value of an interop
hackathon where everyone is using the same software.  I see the point for a
tutorial on a particular stack.  (I also come at this from the RATS point of
view, of soft TPMs running in TEEs, and also TEEs attesting to relying
parties rather than other TEE applications)

I also see a point in helping people who are building other components in the
ecosystem to learn how to bring up the things that they are intending to
interoperate with.

    > *) JSON stack:
    > (1) jansson, which Dave is using
    > (2) node.js, Isobe-san`s TAM
    > (3) json parser in libwebsockets, which my prototype is using

    > *) JOSE stack:
    > (1) latchset/jose, which Dave is using
    > (2) node.js?, Isobe-san`s TAM
    > (3) libwebsockets

    > *) HTTP stack:
    > (1) from scratch?, In Dave`s
    > (2) libwebsockets, In mine

    > *) Crypto-tsl stack:
    > (1) openssl, Dave`s
    > (2) mbedtls, mine
    > Other than above, might good to use smaller libs, wolfSSL or s2n on
    > the device side?

    > *) rootfs
    > (1) Ubuntu?, Dave`s
    > (2) buildroot, mine

This is a wide variety of options, and this is great!
I think that many these are TAM code though?

    > The default rootfs of dev boards introduced by Dave and Hannes.
    > *) Grapeboard
    > Ubuntu, customizable to Yocto/OE, OpenWRT and etc
    > *) StmA7board
    > Yocto/OE (OpenSTLinux)

    > Also, we have to consider the hardware requirements of SGX, ARM
    > TrustZone and RISC-V too.
    > The SGX is pretty handy since it could use simulation mode on any pc.
    > The op-tee is able to run on qemu too.

op-tee seems like it should be a default tutorial choice.

    > I honestly do not have any preference listed above. I was late on the
    > boat and did not know what others have done in the past.

    > We do not have so much engineering resources at the moment, so I
    > thought it would be good to work on similar environment as possible to
    > able to focus on teep stack.

I guess it is this last part which caused me to reply and comment above.
I think that we need to also consider that we might want to figure out the
different roles and make a table that way.

Michael Richardson <>;, Sandelman Software Works
 -= IPv6 IoT consulting =-