Re: [Fud] A few questions / observations

Brendan Moran <> Tue, 26 September 2017 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66B9013445D for <>; Tue, 26 Sep 2017 13:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4SM5tG53Kgmg for <>; Tue, 26 Sep 2017 13:54:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1FA513445E for <>; Tue, 26 Sep 2017 13:54:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KNygTNQNHjrZHqHcn3aTZy+O/TK6zhAQcht8+jdQfkU=; b=HpCniIEE0bSnW/y7lDVHpPcP/7/eJnKDlfRI3LY0Dl6E1nInkwcZpNcGqiQD54X4i60/gJ8zHJr5ueXBSB77mw0qcUY4HV50aIQiphN1YgnchUaOk08htUtyJQgZP7vWoE30PuqU4hsmlxEEbUWB9Lq0qQ3HdEHRFXUm+7RPcbg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Tue, 26 Sep 2017 20:54:54 +0000
Received: from ([fe80::d4a2:963:ba6f:fef4]) by ([fe80::d4a2:963:ba6f:fef4%13]) with mapi id 15.20.0077.011; Tue, 26 Sep 2017 20:54:54 +0000
From: Brendan Moran <>
To: "Smith, Ned" <>
CC: "" <>
Thread-Topic: [Fud] A few questions / observations
Thread-Index: AQHTLjdsLe1oeSwl+Em8FCdFITDsKqLHtvcA
Date: Tue, 26 Sep 2017 20:54:54 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3273)
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR08MB2836; 6:KvkDzCfu61s5ECXeTtvQ+CpZmqLRDwx3W45nTT3EsCuY+YrCelB0re7NJbeFQxHQBrI4/zyxvlA3g/zPqFgBOuJHJCEJ+XuMR8PpEI+omhqR/3AMv3QGE8zxTLBwgRK40mCwMqXhQkMp6/dxPtNRH2W/BK3j+A2eV+JLtMW5on+0Br6BHll22ST+AKMRmobBssylgmRJWyISsDzXTg+8EQJVwm2fy7DLnQZ/3VhZzmwyYuUFji9xzA3i48d/2iyMEyGqIurCEIvp8arewz3IOqwLIWkBdWLBTdU4sj1preRWDXAPpUA+U0BF0v6XcVgc+FYayv9w/hPXaFivmXZ7fQ==; 5:rmcvQ/jk3sD4y3Xjk/+EulBda9kODZ7u8SxcQJbUgusVjA4IUE2gt4nGVrXktChf8KzxwNxFkIUPRfuYVcKS/G3+2vcKvGy5a5e0s3wwQpxTJcpO4JSoVcFyre8M0+hWeSwn8PU8YmmMtRF+wh6Oow==; 24:AHon9MJQ4m8laZutxAQrWklYJBMjpW+pa7K+cVdCuaC0QI9+XkQoOYu2Rx6ZLGmkkoyVnnTSZg+vcONwaYZ0rcmgMhQYPv5xh1uw5LOTeeY=; 7:Z0LZJFoMlC/7sN4fx1KcwbY30pWpYLfK4fQDMIwbuqg7M8hlMYnP3ECKw+vPLvh0phAXJc0kIaRfjsIZxYG6/OYEhNr5PwEsY1tKGDb92KWwILuHIweGeDHHvZHv1NNnP/BHa2Uv1z/j/4a7ln8lgFm29rYn+r4wi5mWW8FHQk4QNhVDG3J3QptDL8RgO+RRfIdYmj/qdi4JRoDpROL5Q37MK0ywyiAjfER10FCUuyg=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 31eb80a3-711a-47db-d825-08d50520d6d6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR08MB2836;
x-ms-traffictypediagnostic: AM4PR08MB2836:
x-exchange-antispam-report-test: UriScan:(131327999870524)(788757137089)(228905959029699);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR08MB2836; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR08MB2836;
x-forefront-prvs: 0442E569BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(40434004)(199003)(24454002)(51444003)(189002)(102836003)(2950100002)(6916009)(6246003)(966005)(66066001)(478600001)(189998001)(14454004)(33656002)(57306001)(53936002)(83716003)(25786009)(86362001)(6436002)(229853002)(6486002)(2900100001)(82746002)(316002)(6512007)(5250100002)(236005)(5890100001)(99286003)(8676002)(4326008)(6306002)(6116002)(7736002)(6506006)(36756003)(54896002)(606006)(5660300001)(2906002)(3660700001)(101416001)(8936002)(50986999)(97736004)(3280700002)(105586002)(81166006)(106356001)(81156014)(50226002)(76176999)(53546010)(3846002)(72206003)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR08MB2836;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_2BF4654C42604C7C8DD5CF892628711Barmcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 20:54:54.3664 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB2836
Archived-At: <>
Subject: Re: [Fud] A few questions / observations
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Sep 2017 20:55:00 -0000

Hi Ned,
I’ve placed my comments inline.

Thanks for your feedback!

Best Regards,

On 15 Sep 2017, at 16:29, Smith, Ned <<>> wrote:

•         Is it possible for the image type to be an existing “manifest” such as “packages” or “bundles”?

I don’t see why not. The manifest is a pretty generic wrapper.

•         Is the push model supported (cloud storage pushes update file proactively)?

Certainly. This is one of the expected use-cases, however manifest must precede payload.

•         Why was ASN.1 selected as the encoding format? (Why not COSE?)

ASN.1 was used for a few reasons.

  1.  It is the default format for certificates. Most tools use DER rather than COSE for packing certificates, so this reduces the number of parsers in the target. Where interwork with HSMs is involved, using a format the HSM supports is beneficial.
  2.  PCKS7 / CMS / RFC5652 are widely supported. For example, OpenSSL’s smime command handles CMS signing/validation directly. This makes the custom tooling required simpler. This will also, hopefully, improve compatibility with existing HSMs
  3.  Direct code generation. In a scenario where the parser does not create a document object model, but extracts or validates specific fields, ASN.1 provides a grammar that makes it possible to generate a parser programatically.
  4.  The meaning of “length” for composite types. In DER, the length of a field is unambiguous. It is always the length, in bytes, of the contained object. This allows a parser that understands the document being parsed to skip large chunks of a deeply nested tree. In CBOR, the “length” of an array or map is the number of elements it contains. This makes it impossible for the parser to “skip” anything. It has to parse the entire structure. It is possible to circumvent some of these limitations using tagging, in particular tag 24 (encoded CBOR data item), but this has the downside of breaking translatability to JSON, which is a key advantage of CBOR. Consistent TLV representation makes parsing in a constrained environment offers a notional performance improvement, but this is minor and may not play out in practice.

Never the less, I think that CBOR/COSE would be perfectly serviceable for this use. I’m not even certain that ASN.1 can’t be used as a schema for CBOR (see 3 above). That being the case, I can see a case for DER manifests with CMS, and CBOR manifests with COSE.

•         It isn’t clear how the manifest and the image (package / bundle) will share the available A /B storage area. Possibly it is assumed the manifest related operations are to be integrated into an existing SW update capability and be taught to understand the manifest structure. Consider the case where version 1 of a SW update tool understands bundles but it receives a file that contains a manifest. Is it expected that the v1 tool will be able to process the update nevertheless (ignoring the manifest). This assumes the encryption option isn’t being applied of course.

The expectation was that manifest would be stored into a separate key/value store.

•         The arch didn’t mention integrity as a requirement. Maybe it is implied but it seems possible for a clever attacker to replace one cipher text with a different cipher text unless integrity were mentioned as a goal and steps taken to allow only cipher suites that achieve both objectives.

This is an interesting point. We may have drafted it as an implicit requirement. I have made the assumption that integrity is a prerequisite for authenticity and authenticity is an expressly stated goal. However, you are correct, this should be made explicit.

•         There is no mention of which crypto algorithms will be supported.

The current expectation is SHA256, AES128-CTR, and ECC secp256r1. There is an argument to be made for SHA512, AES256-CTR, and an equivalent ECC algorithm. We have also discussed using ed25519.

•         There are still a few typos.

I have a few updates coming, so I will review the draft at the same time.

Fud mailing list<>

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.