That's really exciting! Please see below for some responses, and likely
some of the Mender developers can answer the more detailed questions.
This makes sense, note there is also some interest & research from the
community to support a more efficient compression algorithm, e.g. xz:
I think it would be difficult to support the Artifact format (for any
given client) if there are many different ways a file could be
compressed. However, having gz (or replace it with xz) as well as
uncompressed should work.
It sounds like this would require a new version of the Artifact format,
though? Support for v3 is currently being implemented:
> We should probably also add some kind of validation to check if there's
> more than one header or data segment with the same id.
> 2: Signing
> The auth requests are currently being signed and verified using an RSA
> public/private keypair.
> I'd like to get some information about the reasoning behind this
> decision and both present and future use of these keys.
> The way I currently understand it is that after flashing the firmware in
> the factory the device boots up, generates it's keypair and provides a
> way to extract the public key which then can be transferred to the
> mender server physically (usb flash drive) or remotely.
> The key feature of RSA which allows generating and verifying
> certificates using a CA doesn't seem to be used right now.
There are two ways to do this, which are described here:
Keys are usually not generated on the target device in production
environments, you would mass-generate keys, place the private key on the
device storage and use the preauthorize feature of Mender to trust the
public key in the server.
The reason the client signs the auth request at all is to prove to the
server it possesses the private key corresponding to the public key the
server believes the client has.
> The problem is that generating an RSA keypair takes quite some time on a
> MCU which is not desirable when considering time-based manufacturing costs.
> While the keypair could theoretically be generated on another device and
> then provisioned to the device, this process would be less secure.
The expectation is that you already have a secure channel established
when placing the private key on the device, such as physical access
during manufacturing/provisioning of the storage.
If you have a device that just "shows up" without any trust set up
securely in advance, then nothing can be assured about the device
(anyone can generate a RSA key).
> If you don't plan to use any RSA-specific feature of these keys in
> future, my proposed solution would be to add support for alternative
> signature algorithms like ed25519. The type of algorithm to use could be
> selected by an additional HTTP header field.
Makes sense, would love to see support for this both for signing auth
requests and artifacts. The reason ed25519 is not yet implemented is
that the tooling and libraries mostly lack support. When this was
researched earlier this year, openssl even did not support it properly
(it had some internal code, but not possible to use it):
(note this is for signing
artifacts, but same algorithm).
Have you tested ed25519? Which libraries/tools did you use? Is it
portable to Golang (for aritfact library, server)?
> I'm looking forward to your feedback to these points.
> Some key features of the design of our code:
> - no dynamic memory allocations(this also means that the server has to
> take into account the capabilities of the client, e.g. increasing the
> JWT size with an update could end up in clients being unable to communicate)
> - abstractions for system includes and device/platform specific
> implementations(e.g. keystore, logging, etc)
> - tests using cmocka
> IOTΛ Data Marketplace Member· MS Azure IoT Gold Partner · Apple MFi
> Developer · Bluetooth SIG · zigbee Alliance · LoRa Alliance · Thread Group
> grandcentrix GmbH · Holzmarkt 1 · 50676 Köln · Deutschland
> | t <https://twitter.com/grandcentrix
> | f
> | in
> | phone:
> +49-221-677-860-0 | email: he...@grandcentrix.net
> Amtsgericht Köln | HRB 70119 | Geschäftsführer: R. Rottmann, M. Willnow
> | USt.-IdNr.: DE266333969
> You received this message because you are subscribed to the Google
> Groups "Mender List mender.io
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mender+un...@lists.mender.io
> To post to this group, send email to men...@lists.mender.io
> Visit this group at