Re: [Teep] Hardware for hackathons

[Hannes Tschofenig <[e-mail]>]

Hi Michael, Hi Akira,

The goals for the participants are likely going to be different with each of the involved groups. A Hackathon does not necessarily imply that we only focus on interoperability tests but also to get concepts evaluated. IMHO it makes sense to re-use some common building blocks for our TEEP protocol evaluations.

Ciao
Hannes

-----Original Message-----
From: TEEP <[e-mail]> On Behalf Of ???
Sent: Wednesday, December 4, 2019 6:37 AM
To: [e-mail]
Subject: Re: [Teep] Hardware for hackathons



On 2019/11/28 16:18, Michael Richardson wrote:
>
> Akira Tsukamoto <[e-mail]> 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.

Of course, it would be more beneficial to have variety of hardware and software working and ready for interop testing.

At the moment, I really do not have both otrp and teep protocol over http between TAM side and device side implemented on the real device, at least at my place. We are still in the middle of developing it.

It would make me helpful to have some kind of consolidation to get to the point of having working code and reflect the learning to the draft.

And then start porting to their software stacks and devices and having variety of hardware and software would be really nice.

The objective is the same, I just was thinking of one step forward of current situation.

>
>      > *) JSON stack:
>      > (1) jansson, which Dave is using
>      > https://github.com/akheron/jansson
>      > (2) node.js, Isobe-san`s TAM
>      > (3) json parser in libwebsockets, which my prototype is using
>      > https://github.com/warmcat/libwebsockets/tree/master/lib/jose
>
>      > *) JOSE stack:
>      > (1) latchset/jose, which Dave is using
>      > https://github.com/latchset/jose
>      > (2) node.js?, Isobe-san`s TAM
>      > (3) libwebsockets
>
>      > *) HTTP stack:
>      > (1) from scratch?, In Dave`s
>      > https://github.com/dthaler/OTrP/blob/master/TeepTamBrokerLib/HttpServer.cpp
>      > (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?

Yes, it is great.
My prototype device is on ARM board using op-tee.
It is able to install and delete TA on the device with my own TAM but the message format is not compliant yet.
Do not use the strings written in the draft yet.

At the IETF 106 hackathon, it was my first time to try connecting to the Dave's TAM and Isobe-san's TAM.
While I was tweaking the otrp message, I end up most of the time fixing the http and json parser which is working underneath.

This is the reason I thought it will be good to focus on consolidate and not have to much fragmentation of developing effort.

>
>      > 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 prefer having reference of all sgx, optee and others but starting from one by one.

-Akira

>
>      > 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 <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> TEEP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teep
>
_______________________________________________
TEEP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teep
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.