[core] OSCORE: Status Update on the C Implementation of an OSCORE Server

Jaro Fietz <jaro.fietz@aisec.fraunhofer.de> Thu, 13 December 2018 14:42 UTC

Return-Path: <jaro.fietz@aisec.fraunhofer.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6E12785F for <core@ietfa.amsl.com>; Thu, 13 Dec 2018 06:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 3syxi2_Y7BDW for <core@ietfa.amsl.com>; Thu, 13 Dec 2018 06:42:17 -0800 (PST)
Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de [153.96.1.24]) (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 586DD1252B7 for <core@ietf.org>; Thu, 13 Dec 2018 06:42:15 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2FdAAAO4PJb/xwBYJliGgEBAQEBAgEBAQEHAgEBAQGBZYFbKWZwOYN4iHeLHYFgLZkwDSUJhD4Cg24iOBIBAwEBAgEBAgICaRwMgmpNPgEBAQEBAQEBASQBAQEBAQEjAg03LQEFIw8BBTwFECMCAiYCAkcQBg0BBQIBAYMdAYIAAQ+nPoEvhUCEVwUJAYEBil0dgVc/gRABJ4I9g0kBAQIBgUgCgxiCVwKLCJRnBwKBEYEJBIRciicGGIFYiAAFhx8BiWSDVYpdgV0igVUzGiSDO4IkAxd/AQgEhSKCMIU/PgEyAQEKjASCTAEB
X-IPAS-Result: A2FdAAAO4PJb/xwBYJliGgEBAQEBAgEBAQEHAgEBAQGBZYFbKWZwOYN4iHeLHYFgLZkwDSUJhD4Cg24iOBIBAwEBAgEBAgICaRwMgmpNPgEBAQEBAQEBASQBAQEBAQEjAg03LQEFIw8BBTwFECMCAiYCAkcQBg0BBQIBAYMdAYIAAQ+nPoEvhUCEVwUJAYEBil0dgVc/gRABJ4I9g0kBAQIBgUgCgxiCVwKLCJRnBwKBEYEJBIRciicGGIFYiAAFhx8BiWSDVYpdgV0igVUzGiSDO4IkAxd/AQgEhSKCMIU/PgEyAQEKjASCTAEB
X-IronPort-AV: E=Sophos;i="5.56,253,1539640800"; d="scan'208";a="12281842"
Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2018 15:42:13 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DmAADN3/Jb/xBhWMBiGwEBAQEDAQEBBwMBAQGBZYFbgQ9PITmDeIh3jSqZMA0lhEcChA84EgEDAQECAQECbRwMhT0BBSMPAQU8BRAjAgImAgJHEAYNAQUCAQGDHQGCAQ+nPYEvhUCEVwUJAYEBil2BdD+BEAEngj2DSQEBAgGBSAKDGIJXAosIlGcHAoERgQkEhFyKJwYYgViIAAWHHwGJZINVil2BXSGBVTMaJIM7giQDF38BCASFIoIwhT8+AzABAQqMBIJMAQE
X-IronPort-AV: E=Sophos;i="5.56,253,1539640800"; d="scan'208";a="19250564"
Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP11EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/AES256-SHA; 13 Dec 2018 15:42:13 +0100
Received: from [10.144.89.145] (10.80.233.50) by FGDEMUCIMP11EXC.ads.fraunhofer.de (10.80.232.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Dec 2018 15:40:12 +0100
To: core@ietf.org
CC: Göran Selander <goran.selander@ericsson.com>, "'Christian M. Amsüss'" <christian@amsuess.com>, francesca.palombini@ericsson.com, martin.striegel@aisec.fraunhofer.de, Stefan Hristozov <stefan.hristozov@aisec.fraunhofer.de>, jaro.fietz@gmx.de
References: <bd95ea38-7425-13d6-a955-1e60a5bd0945@aisec.fraunhofer.de> <20181011110943.GE31858@hephaistos.amsuess.com> <bdb05cc8-7418-a65c-b4a1-6111e1467c13@aisec.fraunhofer.de> <3E80C9C0-E03A-4EAE-8CAD-8063DC93C1A5@ericsson.com> <2608c3f9-907f-6f22-2c9e-bef30f9c0ef3@aisec.fraunhofer.de> <53AFBD47-6D9D-47FA-82E5-F1C8F5DC6F1F@ericsson.com>
From: Jaro Fietz <jaro.fietz@aisec.fraunhofer.de>
Message-ID: <3f288e89-ea41-5da5-ddb1-f5eada5a39cc@aisec.fraunhofer.de>
Date: Thu, 13 Dec 2018 15:40:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <53AFBD47-6D9D-47FA-82E5-F1C8F5DC6F1F@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.200.1013-24278.002
X-TM-AS-Result: No--15.530200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/N74IxGpQnleRGgsfwbwVaU3b27E>
Subject: [core] OSCORE: Status Update on the C Implementation of an OSCORE Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 14:42:21 -0000

Hey everyone,

after I've received several follow-up mails about my minimal C 
implementation of an OSCORE server on top of the embedded OS Zephyr, 
I've decided to give everyone an update on my progress. I've implemented 
a subset of the OSCORE Draft Version 14 in C, leaving out most optional 
features. My implementation provides a minimal working OSCORE server for 
an embedded board (in my case the 96 Boards BLE Nitrogen). It is based 
on Zephyr as the underlying embedded operating system but should be 
easily adaptable to other needs.

The implementation is now finished feature wise. Key derivation was 
tested against the Appendix C.1.2 testcase from the specification [1]. 
Additionally, the server successfully responds to the OSCORE Test_1a [1] 
(executed with aiocoap's plugtest script). I haven't performed other 
tests, but this should be good enough to exchange simple encrypted messages.

I'm currently in the works of open sourcing the project. I expect the 
source code to be published on github mid to late January. I hope that 
this will be quick enough for RIOT. I'll write to the ML once the source 
code is available (or only to individual people in case this information 
isn't relevant to the ML).

BR,
Jaro

[1]: 
https://tools.ietf.org/html/draft-ietf-core-object-security-14#appendix-C.1.2
[2]: https://ericssonresearch.github.io/OSCOAP/test-spec5.html#test-1a

On 11/26/18 3:18 PM, Göran Selander wrote:
> Hi Jaro,
>
> Thanks for the update!
>
> I understand you can't promise anything here. The question I got was for a C-implementation which was not tailored for a particular constrained platform OS, like what exists for Contiki NG and Open WSN. For your information, the people I talked to at RIOT wants to start after the new year holidays, so anything available around that time would be very welcome.
>
> Thanks,
> Göran
>
>
> On 2018-11-26, 14:39, "Jaro Fietz" <jaro.fietz@aisec.fraunhofer.de> wrote:
>
>      Hello Göran,
>      
>      we are planning on open-sourcing the C implementation, I'm in the works
>      of filling in the paperwork. Currently I'm in the bugfixing stage, so
>      the code isn't functional quite yet. Once I have a minimal working
>      example and we have the go-ahead for open-sourcing it, I'll let you
>      know. I hope that it'll happen within the next month, but can't
>      guarantee anything.
>      
>      BR,
>      Jaro
>      
>      On 11/23/18 4:04 PM, Göran Selander wrote:
>      > Hello Jaro,
>      >
>      > I'm curious about the continued story of one of the questions from Christian, below.
>      >
>      > On 2018-10-11, 14:42, "core on behalf of Jaro Fietz" <core-bounces@ietf.org on behalf of jaro.fietz@aisec.fraunhofer.de> wrote:
>      >
>      >      Hello Christian,
>      >
>      >      thanks for your quick answer, it clarified the second of my questions.
>      >
>      >      On 10/11/18 1:09 PM, Christian Amsüss wrote:
>      >      > The expectation is that the shortest (zero-length) ID would be used in
>      >      > cases wherever that's beneficial, eg. when a constrained device
>      >      > primarily utilizes one context in which it is addressed as a server.
>      >      This is an interesting optimization. I'm not too sure about the actual
>      >      benefits though. To me this would only result in the constrained nodes
>      >      being able to shave off a few bytes of allocation when constructing the
>      >      response and saving their sender_id to persistent storage.
>      >      > You briefly had me worried I got it wrong myself -- but the
>      >      > left-trimming that's happenign is on the sequence numbers, not on the
>      >      > sender IDs.
>      >      Sorry, I must have skipped incorrectly over the tuple construction.
>      >      Reading through it again, your code is, of course, correct :)
>      >      > Slightly off topic: Would that happen to be a freely licensed
>      >      > implementation? If so, I know of an embedded operating system project
>      >      > that would love to hear about this.
>      >      I'm implementing OSCORE on top of zephyr (not integrated into it) for an
>      >      embedded board. Currently it isn't open source, but I asked my advisor,
>      >      who'll forward the request to the supervisor.
>      >      Judging from your github history I expect you ask for RIOT-OS? :)
>      >
>      > Have you decided about open source? I also got question from people working RIOT-OS __
>      >
>      > BR
>      > Göran
>      >
>      >
>      >
>      >
>      
>      
>