Release version 0.10.0.

Signed-off-by: Achim Kraus <achim.kraus@cloudcoap.net>

CMakeLists.txt

@@ -147,12 +147,10 @@ if (COPY_PREBUILDS_UPDATE)
    else()
       message(NOTICE "missing ${CMAKE_BINARY_DIR}/zephyr/app_update.bin")
    endif()
-   if (NOT "${BOARD}" STREQUAL "nrf9160dk_nrf9160_ns")
-      if (EXISTS "${CMAKE_BINARY_DIR}/zephyr/app_signed.hex")
-         file(COPY_FILE ${CMAKE_BINARY_DIR}/zephyr/app_signed.hex ${CMAKE_BINARY_DIR}/../prebuild/${BOARD}_app_signed.hex)
-      else()
-         message(NOTICE "missing ${CMAKE_BINARY_DIR}/zephyr/app_signed.hex")
-      endif()
+   if (EXISTS "${CMAKE_BINARY_DIR}/zephyr/app_signed.hex")
+      file(COPY_FILE ${CMAKE_BINARY_DIR}/zephyr/app_signed.hex ${CMAKE_BINARY_DIR}/../prebuild/${BOARD}_app_signed.hex)
+   else()
+      message(NOTICE "missing ${CMAKE_BINARY_DIR}/zephyr/app_signed.hex")
    endif()
 endif()
 

README.md

@@ -4,7 +4,7 @@
 
 ## Reliable - Efficient - Encrypted
 
-Version 0.9.0 - January 2024
+Version 0.10.0 - August 2024
 
 This [zephyr](https://www.zephyrproject.org/) client demonstrates to use coaps ([CoAP](https://tools.ietf.org/html/rfc7252) over [DTLS 1.2](https://tools.ietf.org/html/rfc6347)) with the [Eclipse/TinyDtls Library](https://github.com/eclipse/tinydtls). In combination with [Eclipse/Californium](https://github.com/eclipse/californium) as Cloud-Server, it enables a device to use [DTLS 1.2 Connection ID](https://tools.ietf.org/html/rfc9146), which obsolete the commonly used frequently DTLS handshakes and eliminates that expensive overhead.
 Reducing the messages exchange mostly down to two ip-messages (one request, one response), it enables your device for
@@ -19,7 +19,7 @@ In combination with cellular LTE-M/NB-IoT technolopy, CoAP / DTLS 1.2 CID enable
 - zero-install and 
 - high cost-efficiency.
 
-The demo client itself is in development stage. In "good and normal weather", the `Thingy:91` runs from battery for 7 months and more, exchanging every hour a message. In "storm" it may require to be switched off and on again in very rare exceptions.
+The demo client itself is in development stage. In "good and normal weather", the `Thingy:91` runs from battery for 7-15 months, exchanging every hour a message. In "storm" it may require to be switched off and on again in very rare exceptions.
 
 The demo client is intended as groundwork for your own ideas. "Out-of-the-box" this application is useful to easily check, if cellular IoT works at the locations and environment you want to use it. The demo reports also some details about the cellular network functions. 
 To build products and applications on this protocol stack requires to implement a production client and to adapt the coap-server for your function. The demo targets therefore people, which are already common with [zephyr](https://www.zephyrproject.org/), or, even better, common with the development for the [Thingy:91](https://www.nordicsemi.com/Products/Development-hardware/Nordic-Thingy-91) itself.

VERSION

@@ -1,5 +1,5 @@
 VERSION_MAJOR = 0
 VERSION_MINOR = 10
-PATCHLEVEL = 105
-VERSION_TWEAK = 1
+PATCHLEVEL = 0
+VERSION_TWEAK = 0
 EXTRAVERSION = 

docu/BUILDTRACK.md

@@ -173,6 +173,104 @@ The solves only a part of the issue with the credentials. If the credentials are
 
 [prov-prj.conv](../prov-prj.conv) to see the configuration value, which are supported by the settings service. 
 
+## Credentials
+
+Starting with version 0.10.0 ECDSA certificates are also supported. Not x509 certificates but the slim **R**aw **P**ublic **K**ey variant (see [RFC 7250](https://www.rfc-editor.org/rfc/rfc7250)). This requires also support on ther server-side (e.g. as with Californium).
+
+The RPK certificates are intended to be provisioned ahead. Usually a key pair is created with
+
+```sh
+openssl ecparam -genkey -name prime256v1 -noout -out privkey.pem
+```
+
+or
+
+```sh
+openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out privkey.pem
+```
+
+You will need one key pair for the server, and one key pair for each device. To make the device and server trust each other, they need to exchange their `public key`s ahead. Therefore extract the `public key` from the key pair using
+
+```sh
+openssl pkey -in privkey.pem -pubout
+
+-----BEGIN PUBLIC KEY-----
+MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAENTGXGkhc7gL614R4HBOkXoESM98Y
+IXP3yts4VG7wpRlsIxYFFXVez3I3VE7oGaOpLlAMMhFa4Myq/4OIRMvauQ==
+-----END PUBLIC KEY-----
+```
+
+That prints the `public key` in ASN.1 (including the algorithm information) in base 64 encoding. for the device side, copy the base 64 part of the server's `public key` into a single line and paste that in the `CONFIG_DTLS_ECDSA_TRUSTED_PUBLIC_KEY` value of the [prov-prj.conf](../prov-prj.conf) file.
+
+```
+CONFIG_DTLS_ECDSA_TRUSTED_PUBLIC_KEY="MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAENTGXGkhc7gL614R4HBOkXoESM98YIXP3yts4VG7wpRlsIxYFFXVez3I3VE7oGaOpLlAMMhFa4Myq/4OIRMvauQ=="
+```
+
+The device also requires it's own `key pair`, therefore extract the `private key` with
+
+
+```sh
+openssl ec -no_public -in privkey.pem 
+
+read EC key
+writing EC key
+-----BEGIN EC PRIVATE KEY-----
+MDECAQEEIMjsiXRzR3OYtELs+9tWYHB4/nT9x3LAXFzA8ezR8iVLoAoGCCqGSM49
+AwEH
+-----END EC PRIVATE KEY-----
+```
+
+and copy again the base 64 part as single line into `CONFIG_DTLS_ECDSA_PRIVATE_KEY` value of the [prov-prj.conf](../prov-prj.conf) file. 
+
+```
+CONFIG_DTLS_ECDSA_PRIVATE_KEY="MDECAQEEIMjsiXRzR3OYtELs+9tWYHB4/nT9x3LAXFzA8ezR8iVLoAoGCCqGSM49AwEH"
+```
+
+If you use the [cf-cloud-demo-server](https://github.com/eclipse-californium/californium/tree/main/demo-apps/cf-cloud-demo-server) or the [cf-s3-proxy-server](https://github.com/eclipse-californium/californium/tree/main/demo-apps/cf-s3-proxy-server) [Device Credentials](https://github.com/eclipse-californium/californium/tree/main/demo-apps/cf-cloud-demo-server#device-credentials) shows how to add the keys to the server side.
+
+### Credentials Auto Provisioning
+
+Though the above process requires a couple of manual steps, there is also an automated way to provide the device credentials to the server.
+
+This approach uses a special `auto-provisioning key pair` on the device to provide the generated credentials to the server. Create a `key pair` as above and extract the `private key` as also explained above. Instead of copy the base 64 part to `CONFIG_DTLS_ECDSA_PRIVATE_KEY`, copy it to `CONFIG_DTLS_ECDSA_AUTO_PROVISIONING_PRIVATE_KEY` 
+
+```
+CONFIG_DTLS_ECDSA_AUTO_PROVISIONING_PRIVATE_KEY="MDECAQEEIMjsiXRzR3OYtELs+9tWYHB4/nT9x3LAXFzA8ezR8iVLoAoGCCqGSM49AwEH"
+```
+
+Additional apply the configuration as follow:
+
+```
+# ECDSA credentials
+# ascii in 'ascii', hexadecimal with prefix ":0x", or base64
+CONFIG_DTLS_ECDSA_TRUSTED_PUBLIC_KEY="<server's public key in base 64>"
+CONFIG_DTLS_ECDSA_PRIVATE_KEY_GENERATE=y
+# ascii in 'ascii', hexadecimal with prefix ":0x", or base64
+CONFIG_DTLS_ECDSA_PRIVATE_KEY=""
+
+# Auto provisioning
+CONFIG_PROVISIONING_GROUP="Demo"
+CONFIG_DTLS_ECDSA_AUTO_PROVISIONING=y
+# ascii in 'ascii', hexadecimal with prefix ":0x", or base64
+CONFIG_DTLS_ECDSA_AUTO_PROVISIONING_PRIVATE_KEY="MDECAQEEIMjsiXRzR3OYtELs+9tWYHB4/nT9x3LAXFzA8ezR8iVLoAoGCCqGSM49AwEH"
+```
+
+- fill the server's `public key` in the field `CONFIG_DTLS_ECDSA_TRUSTED_PUBLIC_KEY`
+- set `CONFIG_DTLS_ECDSA_PRIVATE_KEY_GENERATE` to `y`
+- clear `CONFIG_DTLS_ECDSA_PRIVATE_KEY`
+- set `CONFIG_DTLS_ECDSA_AUTO_PROVISIONING` to `y`
+- fill the `auto-provisioning private key` in the field `CONFIG_DTLS_ECDSA_AUTO_PROVISIONING_PRIVATE_KEY`
+
+On the server side create a device entry with `public key` of the `auto-provisioning private key` and add the field `.prov=1` to indicate the "auto-provisioning" function for that entry.
+
+```
+Provisioning1=Admin
+.rpk=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAENTGXGkhc7gL614R4HBOkXoESM98YIXP3yts4VG7wpRlsIxYFFXVez3I3VE7oGaOpLlAMMhFa4Myq/4OIRMvauQ==
+.prov=1
+```
+
+You may now apply the same resulting "..._full.hex" image to a set of devices. Each will generate it's own `key pair` and will provide that to the server using the `auto-provisioning private key`. After that, the devices starts their communication using their own generated `key pair`.
+
 ## Configuration
 
 The application comes with a [KConfig](../Kconfig) to configure some functions. Use

docu/CFBROWSER.md

@@ -4,12 +4,12 @@
 
 # Cf-Browser
 
-If you want to check, what the server has received, download the [cf-browser-3.7.0](https://repo.eclipse.org/content/repositories/californium-releases/org/eclipse/californium/cf-browser/3.7.0/cf-browser-3.7.0.jar). It requires to install a java runtime and javafx, please refer to [github - cf-browser](https://github.com/eclipse/californium.tools/tree/main/cf-browser).
+If you want to check, what the server has received, download the [cf-browser-3.12.0](https://repo.eclipse.org/content/repositories/californium-releases/org/eclipse/californium/cf-browser/3.12.0/cf-browser-3.12.0.jar). It requires to install a java runtime and javafx, please refer to [github - cf-browser](https://github.com/eclipse/californium.tools/tree/main/cf-browser).
 
 Cf-browser is a simple client tool to demonstrate CoAP.
 
 ```
-java --module-path /usr/share/openjfx/lib --add-modules javafx.controls,javafx.fxml -jar cf-browser-3.7.0.jar coaps://californium.eclipseprojects.io/echo
+java --module-path /usr/share/openjfx/lib --add-modules javafx.controls,javafx.fxml -jar cf-browser-3.12.0.jar coaps://californium.eclipseprojects.io/echo
 ```
 
 (Start for Ubuntu using java 11.)
@@ -19,4 +19,4 @@ java --module-path /usr/share/openjfx/lib --add-modules javafx.controls,javafx.f
 Press the "GET" button to read the list of available devices. Then select your device by the IMEI (label on the `Thingy:91` under the orange cover) and press the "GET" button again. The cf-browser response window shows the last sent request of your device.
 If you press the "N" button on the Thingy:91 again, and then the "GET" button again, the displayed text is modified slightly. Press the "OBSERVE" button and you will see the update automatically, if you press the "N" button on the `Thingy:91` again.
 
-The cf-browser is a tool to easily explore coap, but it's not a intended application.
+The cf-browser is a tool to easily explore coap, but it's not a intended application.

prebuild/README.md

@@ -2,9 +2,13 @@
 
 # Zephyr - Coaps Demo Client with Eclipse/TinyDtls
 
-## Prebuild binaries v0.8.0
+## Prebuild binaries v0.10.0
 
-This folder contains 8 prebuild binaries intended to be used to get a first impression of CoAP / DTLS 1.2 CID. The compiled in destination server is californium.eclipseprojects.io. To gather more experience, please build and modify this example on your own.
+This folder contains 9 prebuild binaries intended to be used to get a first impression of CoAP / DTLS 1.2 CID. The compiled in destination server is californium.eclipseprojects.io. To gather more experience, please build and modify this example on your own.
+
+Starting with 0.10.0, the "..._full.hex" binaries are required to be applied first using Jlink. That's required to initialize the new introduced settings service. Afterwards the update binaries may be used to update the device with new functions. 
+
+Also starting with 0.10.0, the prebuild binaries doesn't longer support updates via the serial bootloader interface. It's still supported using XMODEM or FOTA. For custom builds it may be reenabled using [mcuboot.conf](../../../raw/main/child_image/mcuboot.conf). 
 
 ## License
 
@@ -24,10 +28,14 @@ Therefore, before you start, ensure, that you're common with the tools in order
 
 ## [nrf9160 feather](https://www.jaredwolff.com/store/nrf9160-feather/)
 
-- [full image: circuitdojo_feather_nrf9160_ns_full.hex](../../../raw/main/prebuild/circuitdojo_feather_nrf9160_ns_full.hex) using a debug probe, this is the preferred approach
-- [signed app image: circuitdojo_feather_nrf9160_ns_app_signed.hex](../../../raw/main/prebuild/circuitdojo_feather_nrf9160_ns_app_signed.hex) app signed with the demo keys. May be used without debug probe via USB and [bootloader with newtmgr](https://docs.jaredwolff.com/nrf9160-programming-and-debugging.html#bootloader-use). You need to ensure also, that "\~/.zephyrtools/newtmgr/" and "\~/.zephyrtools/zephyr-tools/" are added to your `PATH`. 
-- [signed app update: circuitdojo_feather_nrf9160_ns_app_update.bin](../../../raw/main/prebuild/circuitdojo_feather_nrf9160_ns_app_update.bin) app signed with the demo keys. May be used for FOTA (CoAP) or XMODEM updates.
+- [full image: circuitdojo_feather_nrf9160_ns_full.hex](../../../raw/main/prebuild/circuitdojo_feather_nrf9160_ns_full.hex) using a debug probe, this is the preferred approach and since 0.10.0 required as initial step.
+- [signed app image: circuitdojo_feather_nrf9160_ns_app_signed.hex](../../../raw/main/prebuild/circuitdojo_feather_nrf9160_ns_app_signed.hex) app signed with the demo keys. May be used for updates using a debug probe after the initial full image.
+- [signed app update: circuitdojo_feather_nrf9160_ns_app_update.bin](../../../raw/main/prebuild/circuitdojo_feather_nrf9160_ns_app_update.bin) update app signed with the demo keys. May be used FOTA (CoAP) or XMODEM updates after the initial full image.
+
+If the serial bootloader interface is enabled again for custombuilds, the "..._app_signed.hex" may be used for updates without debug probe via USB and [bootloader with newtmgr](https://docs.jaredwolff.com/nrf9160-programming-and-debugging.html#bootloader-use). You need to ensure also, that "\~/.zephyrtools/newtmgr/" and "\~/.zephyrtools/zephyr-tools/" are added to your `PATH`.
 
+In difference to the original mcuboot loader of the feather, which uses a baudrate of 1000000, the contained bootloader uses a baudrate of 115200, in line with the baudrate of the later logging and sh-communication.
+
 For automatic bootloader support on linux, please ensure, that the permissions are granted by
 
    SUBSYSTEM=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60" GROUP="users", MODE="0666"
@@ -38,11 +46,16 @@ For Windows you still need to switch on the bootloader mode manually by pressing
 
 ## [nrf9160 Thingy:91](https://www.nordicsemi.com/Products/Development-hardware/Nordic-Thingy-91)
 
-- [full image: thingy91_nrf9160_ns_full.hex](../../../raw/main/prebuild/thingy91_nrf9160_ns_full.hex) using a debug probe, this is the preferred approach
-- [signed app image: thingy91_nrf9160_ns_app_signed.hex](../../../raw/main/prebuild/thingy91_nrf9160_ns_app_signed.hex) app signed with the demo keys. May be used without debug probe via USB and [nRF Connect Programmer](https://infocenter.nordicsemi.com/index.jsp?topic=/struct_nrftools/struct/nrftools_nrfconnect.html).
-- [signed app update: thingy91_nrf9160_ns_app_update.bin](../../../raw/main/prebuild/thingy91_nrf9160_ns_app_update.bin) app signed with the demo keys. May be used for FOTA (CoAP) or XMODEM updates.
+- [full image: thingy91_nrf9160_ns_full.hex](../../../raw/main/prebuild/thingy91_nrf9160_ns_full.hex) using a debug probe, this is the preferred approach and since 0.10.0 required as initial step.
+- [signed app image: thingy91_nrf9160_ns_app_signed.hex](../../../raw/main/prebuild/thingy91_nrf9160_ns_app_signed.hex) app signed with the demo keys. May be used for updates using a debug probe after the initial full image.
+- [signed app update: thingy91_nrf9160_ns_app_update.bin](../../../raw/main/prebuild/thingy91_nrf9160_ns_app_update.bin) app signed with the demo keys. May be used for FOTA (CoAP) or XMODEM updates after the initial full image.
+
+If the serial bootloader interface is enabled again for custombuilds, the "..._app_signed.hex" may be used without debug probe via USB and [nRF Connect Programmer](https://infocenter.nordicsemi.com/index.jsp?topic=/struct_nrftools/struct/nrftools_nrfconnect.html).
 
 ## [nrf9160 DevKit](https://www.nordicsemi.com/Products/Development-hardware/nrf9160-dk)
 
-- [full image: nrf9160dk_nrf9160_ns_full.hex](../../../raw/main/prebuild/nrf9160dk_nrf9160_ns_full.hex) using the onboard debug probe of the devkit.
-- [signed app update: nrf9160dk_nrf9160_ns_app_update.bin](../../../raw/main/prebuild/nrf9160dk_nrf9160_ns_app_update.bin) app signed with the demo keys. May be used for FOTA (CoAP) or XMODEM updates.
+- [full image: nrf9160dk_nrf9160_ns_full.hex](../../../raw/main/prebuild/nrf9160dk_nrf9160_ns_full.hex) using the onboard debug probe of the devkit. Since 0.10.0 required as initial step
+- [signed app update: nrf9160dk_nrf9160_ns_app_signed.hex](../../../raw/main/prebuild/nrf9160dk_nrf9160_ns_app_signed.hex) app signed with the demo keys. May be used for updates using a debug probe after the initial full image.
+- [signed app update: nrf9160dk_nrf9160_ns_app_update.bin](../../../raw/main/prebuild/nrf9160dk_nrf9160_ns_app_update.bin) app signed with the demo keys. May be used for FOTA (CoAP) or XMODEM updates after the initial full image.
+
+