Subject: [Ace] ACE Implementation for Disadvantaged Environments

From: Grace A Lewis <[email-masked]>
Date: Wed, 23 Jan 2019 18:12:23 +0000

Hello,

I just wanted to make the group aware of our ACE implementation (SEI-ACE), which includes an implementation for a resource-constrained server.

Details available in this news article: https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184

Article includes the link to our Git repo.

Enjoy!

- Grace Lewis

______________________________________________
Grace A. Lewis, Ph.D.
Principal Researcher and TTG Initiative Lead
Carnegie Mellon Software Engineering Institute
Software Solutions Division (SSD)
Tactical Technologies Group (TTG)

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851
http://www.sei.cmu.edu/staff/glewis

“A change in perspective is worth 80 IQ points” --- Alan Kay

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Jan 2019 10:05:34 +0000

Congrats to the work. Could you say a little bit the (constrained) resource server implementation?

Ciao
Hannes

From: Ace <[email-masked]> On Behalf Of Grace A Lewis
Sent: Mittwoch, 23. Januar 2019 19:12
To: [email-masked]
Subject: [Ace] ACE Implementation for Disadvantaged Environments

Hello,

Enjoy!

- Grace Lewis

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851

“A change in perspective is worth 80 IQ points” --- Alan Kay
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: Sebastian Echeverria <[email-masked]>
Date: Mon, 28 Jan 2019 15:06:17 +0000

Hello,

Here is some more information about it:

  *   We used Contiki as the base/OS for the code. More specifically, we forked from the 6lbr project (https://github.com/cetic/6lbr), as that version already had some code for handling DTLS connections and AES encryption in it.
  *   We are using the TI CC2538dk board as our constrained target platform.
  *   The implementation has support for the DTLS profile, using pre-shared keys, as this was enough for our use case.
  *   The implementation handles CWT tokens.
  *   We modified the Erbium CoAP server in 6lbr to be able to simultaneously listen for CoAP and CoAPs connections (using TinyDTLS underneath).
  *   The implementation uses the cn-cbor library for decoding CBOR data.
  *   The implementation supports receiving tokens at the authz-info endpoint, and then giving access to a couple of sample resources based on the claims from the received tokens.
  *   The implementation has some additional optional features related to our disadvantaged network environments, such as bootstrapping of the PSK credentials, and detecting revoked tokens through introspection.
  *   The current binary is around 300 kb, which is good enough for the 512 kb flash on the TI boards, though it may be a bit too large for a class II device. We can probably make it a bit smaller. In terms of RAM, it fits in the 32 KB available on the TI boards.

Best,

---
Sebastian Echeverria
Tactical Technologies Group (TTG)
Software Engineering Institute
Carnegie Mellon University

From: Hannes Tschofenig <[email-masked]>
Date: Monday, January 28, 2019 at 5:05 AM
To: Grace Lewis <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: ACE Implementation for Disadvantaged Environments

Ciao
Hannes

Hello,

Enjoy!

- Grace Lewis

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Jan 2019 15:18:59 +0000

Hi Sebastian,

Thanks for the details. How easy do you think would it be to port the code to some other OS? (or in other words: how tightly have you coupled it to Contiki?)

Is the COSE/CWT parsing library separable from the rest?

For the 300 Kb flash: does this contain the firmware update mechanism?

Ciao
Hannes

From: Sebastian Echeverria <[email-masked]>
Sent: Montag, 28. Januar 2019 16:06
To: Hannes Tschofenig <[email-masked]>
Cc: Grace A Lewis <[email-masked]>; [email-masked]; Dan Klinedinst <[email-masked]>
Subject: Re: ACE Implementation for Disadvantaged Environments

Hello,

Best,

---
Sebastian Echeverria

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 28, 2019 at 5:05 AM
To: Grace Lewis <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: ACE Implementation for Disadvantaged Environments

Ciao
Hannes

From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Grace A Lewis
Sent: Mittwoch, 23. Januar 2019 19:12
To: [email-masked]<mailto:[email-masked]>
Subject: [Ace] ACE Implementation for Disadvantaged Environments

Hello,

Enjoy!

- Grace Lewis

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851

---

From: Sebastian Echeverria <[email-masked]>
Date: Mon, 28 Jan 2019 20:19:50 +0000

Hi Hannes,

Regarding your questions:

1. “How easy do you think would it be to port the code to some other OS? (or in other words: how tightly have you coupled it to Contiki?)”

-          Most of the code is called by Contiki processes, so it is not that coupled, and the cn-cbor and TinyDTLS dependencies are independent from Contiki. The code depends on two main things from Contiki: the Erbium CoAP server, and the CFS file system. The coupling with Erbium is not that strong, but wherever the code is ported, it would need a CoAP/CoAPs server on that OS, or the actual porting of a subset of Erbium (which I guess is doable, but it may be substantial work). The dependency on the CFS file system is for storing keys and tokens, and that would need to be adapted to whatever another OS offers, though this dependency is fairly contained in one module, and changes should not be that hard.

2. “Is the COSE/CWT parsing library separable from the rest? “

-          Yes, it is fairly separable from the rest, other than the fact that it uses cn-cbor for cbor parsing, and TinyDTLS for AES decryption. However, at the moment it is very limited in terms of COSE parsing, only supporting the COSE wrapper and cypher suites we are actually using/supporting in our implementation.

3. “For the 300 Kb flash: does this contain the firmware update mechanism?”

-          No, this does not include the firmware update mechanism.

Any more questions, just let me know.

Thanks,

Sebastian

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Monday, January 28, 2019 10:19 AM
To: Sebastian Echeverria <[email-masked]>
Cc: Grace A Lewis <[email-masked]>; [email-masked]; Dan Klinedinst <[email-masked]>
Subject: RE: ACE Implementation for Disadvantaged Environments

Hi Sebastian,

Ciao
Hannes

From: Sebastian Echeverria <[email-masked]<mailto:[email-masked]>>
Sent: Montag, 28. Januar 2019 16:06
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: Grace A Lewis <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dan Klinedinst <[email-masked]<mailto:[email-masked]>>
Subject: Re: ACE Implementation for Disadvantaged Environments

Hello,

-          We used Contiki as the base/OS for the code. More specifically, we forked from the 6lbr project (https://github.com/cetic/6lbr), as that version already had some code for handling DTLS connections and AES encryption in it.
-          We are using the TI CC2538dk board as our constrained target platform.
-          The implementation has support for the DTLS profile, using pre-shared keys, as this was enough for our use case.
-          The implementation handles CWT tokens.
-          We modified the Erbium CoAP server in 6lbr to be able to simultaneously listen for CoAP and CoAPs connections (using TinyDTLS underneath).
-          The implementation uses the cn-cbor library for decoding CBOR data.
-          The implementation supports receiving tokens at the authz-info endpoint, and then giving access to a couple of sample resources based on the claims from the received tokens.
-          The implementation has some additional optional features related to our disadvantaged network environments, such as bootstrapping of the PSK credentials, and detecting revoked tokens through introspection.
-          The current binary is around 300 kb, which is good enough for the 512 kb flash on the TI boards, though it may be a bit too large for a class II device. We can probably make it a bit smaller. In terms of RAM, it fits in the 32 KB available on the TI boards.

Best,

---
Sebastian Echeverria

Ciao
Hannes

Hello,

Enjoy!

- Grace Lewis

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851

---

From: Sebastian Echeverria <[email-masked]>
Date: Wed, 30 Jan 2019 17:11:05 +0000

Hello Michael,

Thanks! Answers to your questions here:

 - We used plain Contiki, since we forked from 6lbr, which itself forked from plain Contiki (we did this since 6lbr already had CoAPs functionality implemented). We have given thought to migrating to Contiki-ng, so that could happen at some point.

- By disadvantaged networks we do mean something similar to constrained networks as defined in RFC 7228. In the past we've mostly focused on DIL (Disconnected, intermittent, and limited bandwidth) environments mostly due to the mobility of the devices involved and the environmental conditions of our use cases. But most of the constraints are similar.

 - We are striving to get it down to around 250 kb, but we haven't spent that much time yet trimming it down. With some work, we should probably be able to get there.

Thanks for your comments!

Sebastian

On 1/28/19, 6:51 PM, "Michael Richardson" <[email-masked]> wrote:

    Thanks for the report!
    
    Sebastian Echeverria <[email-masked]> wrote:
        > * We used Contiki as the base/OS for the code. More specifically, we
        > forked
    
    Contiki, or contiki-ng?
    
        > from the 6lbr project (https://github.com/cetic/6lbr), as that version
        > already had some code for handling DTLS connections and AES encryption in
        > it.

        > as this was enough for our use case.
    
    Yes, but often not really enough for a deployment where we need certificates
    or raw public keys, and this may have significant affects on packet sizes :-(
    
        > * We modified the Erbium CoAP server in 6lbr to be able to simultaneously
        > listen for CoAP and CoAPs connections (using TinyDTLS underneath).
    
    That's an interesting and useful change.
    
        > * The implementation has some additional optional features related to our
        > disadvantaged network environments, such as bootstrapping of the PSK
        > credentials, and detecting revoked tokens through introspection.
    
    When you say "disadvantaged", I think that you mean "constrained",
    as per RFC7228?
    
        > * The current binary is around 300 kb, which is good enough for the 512 kb
        > flash on the TI boards, though it may be a bit too large for a class II
        > device. We can probably make it a bit smaller. In terms of RAM, it fits in
        > the 32 KB available on the TI boards.
    
    The key number is 256K, so that one can double buffer the firmware image.
    
    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [