Subject: Re: [Teep] Hardware for hackathons

From: 塚本明 <[email-masked]>
Date: Wed, 4 Dec 2019 05:36:50 +0000

On 2019/11/28 16:18, Michael Richardson wrote:
> 
> Akira Tsukamoto <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Dec 2019 13:17:05 +0000

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 <[email-masked]> On Behalf Of ???
Sent: Wednesday, December 4, 2019 6:37 AM
To: [email-masked]
Subject: Re: [Teep] Hardware for hackathons

On 2019/11/28 16:18, Michael Richardson wrote:
> 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.

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.

-Akira

> I think that we need to also consider that we might want to figure out
> the different roles and make a table that way.
>
> --
_______________________________________________
TEEP mailing list
[email-masked]
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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Dec 2019 16:28:52 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > 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.

I am not really complaining about having common hardware, btw!!!

I'm just saying that I think we need to be a bit clearer about how different
groups might have different goals, so let's be clear about the differences.

If we are trying to push the envelope for certain aspects, then I think it is
useful to be up-front about those goals.

I'm glad we are specing the hardware now, as I think that a few people will
want to "hit the ground running"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [