Canique Climat

This battery voltage chart shows a Canique outdoor sensor sending every 30 seconds - from March 2021 until February 2024.

From looking at the chart you can conclude, that 10+ years battery lifetime should be easily achievable.
In 3 years we had a total battery voltage decrease of about 0.1V. Note that the battery cutoff voltage is somewhere < 0.9V. So we can drop another 0.1V at least 4 times before the battery is depleted. That's 4 times another 3 years, or: 12 years to go.

This battery voltage chart shows the previously shown outdoor sensor - now until 6th February 2023:

This chart shows the same sensor as in the previous log entry - now over a timespan of 13 months (until 6th February 2023)

HW rev 0.4

This is the plotted battery voltage data of a sensor (HW rev 0.4) ranging from 2021-03-11 until 2022-08-25: thus showing battery voltage over an almost 1.5 year time frame using an Alkaline 2500 mAh AA battery.

The battery voltage drops from roughly 1.57V to 1.5V after this time.

You can also see that the voltage drop is not linear - it starts fast and then stabilizes around 1.5V.

Please note that this HW rev. 0.4 has a a higher quiescent current than HW rev 0.6 - thus with HW rev 0.6 the battery voltage drop will even be smaller.

The cutoff voltage will be around 0.9V.

HW rev 0.6 / Varta Industrial

The next chart shows a HW rev 0.6 sensor with a Varta Industrial AA battery over a nearly 9 month time frame.

The battery voltage drops from 1.62V to 1.56V during that time. It has not stabilized yet and will probably do so once the nominal voltage of 1.5V is reached.

We can roughly say that within 9 months the battery voltage has decreased by 60mV. If we assume the decline is linear (which it isn't, the steepness gradually decreases), then we could expect an 80mV loss every year (=12*60/9).

After 8 years the battery voltage would reach 980mV (cutoff ~800-900mV). So even in the worst case we can expect an 8 year battery lifetime here. Note that this is with a linear approach. The battery can last longer because after reaching 1.5V the battery voltage will drop slower than currently. You can even see it in the chart if you look closely: the width of the steps is getting larger and larger. At first there are many tiny steps, and at the end the voltage stays at the same level for a longer time.

Temperature vs Voltage Reference

The reason why the second chart seems much cleaner (voltage dropping like a staircase in steps) than the first chart is probably because the first sensor is mounted outside and affected by big variations in temperature. This influences the internal voltage reference used for measuring the battery voltage. That's why sometimes the first chart has little spikes to the upside.

The Canique Climat Set can be ordered now:

• Order Canique Climat
• Order Radio Hat for Raspberry Pi
• Order Canique Gateway

The Radio Hat for Raspberry Pi is a cheaper alternative to the gateway. If you already own a Raspberry Pi, it is be a better fit.

So you can use
Canique Climat + Radio Hat to have a running system OR
Canique Climat + Gateway

What else is there to say?

• Canique Climat's bootloader is passwort protected and uses Ed25519 to verify the authenticity of the image. Firmware images are encrypted and signed. Firmware Updates are done via UART (so one need's a USB to UART converter) using a python script as of now. An update roughly takes 10 seconds.
• Canique Gateway's bootloader has no password protection but also uses Ed25519 to check the authenticity. Firmware images are again encrypted and signed. Firmware Updates can be done directly within the device - no need for any external circuit.

Web Cockpit now offers full sized charts with more details, on/off switchable temperature/humidity. 24h to 30 days time windows.

Overview:

Web Cockpit is available

1. in the local network via the IP address of the Canique Gateway (no internet access needed) and 
2. on the internet via an https URL

Sensor values (including battery status and signal strength indicator) are updated live as soon as new measurements arrive. Widgets are automatically grayed out if no values arrive for a certain period of time. 

Web Cockpit runs in all modern browsers: Tested on iPad Safari, Android Chrome, Linux Chrome

Features

• Gateway offline indicator (web version)
• Sensor outdated indicator (if no sensor values arrive for a certain period of time)
• Graph outdated indicator (if chart cannot be updated)
• Live sensor reading / battery status / signal strength / sensor label updates
• Switchable chart between temperature and humidity (by clicking on it)
• Regular automatic chart updates
• Automatic reconnect on connection loss
• Connection indicator (top right corner)
• Sophisticated configurable alarm triggers (notification via e-Mail) with javascript expressions

The latest revision 0.7 uses a Cortex M4 MCU instead of a Cortex M0+.
This even further reduces quiescent current: The total sleep consumption compared to rev 0.6 is  reduced by 1 µA under typical conditions.

Total quiescent current @ different voltages, room temperature

As far as secure firmware updates are concerned, I'd like to refer to François Baldassari to get in-depth information - https://interrupt.memfault.com/blog/secure-firmware-updates-with-code-signing

Basically you have 2 options when deploying firmware updates:
You either use
a) symmetric crytpography alone or
b) also make use of asymmetric crytpography.

As for a)
You can use an AEAD cipher again for encrypting/signing your image. The problem is: If you use the same symmetric key for all devices, then once 1 device gets hacked and the internal key extracted, an attacker can sign firmware updates for ALL devices! That's the problem with symmetric encryption: The key that's used for verifying whether an image is authentic, is also used for signing the image.

So you'd need to install a unique key on every single device. That again would mean that when deploying a firmware update, your update server would need to know all the keys of all the devices where you want to send updates to.
This would probably mean that your update server needs to store all device keys, which is a security risk per se.

As for b)
In scenario b) symmetric encryption is used to keep the firmware secret, and asymmetric cryptography is used to verify the authenticity of the firmware.
Encryption could still be some symmetric AES or Chacha20 cipher with a key common to all devices. The worst thing that could happen is, that once an attacker gets hold of the device internal key, he can decrypt all future images. But if the attacker has managed to extract the key already, he'll probably also manage to read the rest of the firmware anyway.

When it comes to authentication you'd go with ECDSA - a digital signature algorithm based on elliptic curves which is computationally very intensive (unlike symmetric ciphers).
You create a key pair - a public and a private key. The private key is used to sign the firmware update and should not be on a machine that is online. The public key -on the other hand- is stored on every IOT device. It's public.
Even if it is extracted from the device, it cannot be used to sign an image as is the case with a). The public key can only be used to verify an image.

An ECDSA library can be found under https://github.com/ncme/c25519
Some are using a library called micro-ecc but it has many unresolved issues - I wouldn't recommend it therefore.
While writing this, I stumbled upon an ECDSA implementation for Cortex M4 written in assembler: https://github.com/Emill/P256-Cortex-M4

Security Goals

First off, let's have a look at the security goals for this project:

1. Measurements must be authentic: they must stem from the sensor, and not be manipulated or injected by some other third party
2. Measurement data must be transmitted in a secure way: a third party who is listening to the radio traffic must not be able to conclude what has been measured

Implementation

To fulfill 1) encryption alone is not sufficient - some kind of message authentication code is required. Canique Climat uses an AEAD: Authenticated Encryption with Associated Data.
There are 2 robust AEAD ciphers: AES-GCM and Chacha20-Poly1305. Canique Climat uses the latter one. The message format looks like this:
[Message header] [Encrypted Payload] [Authentication Tag]

The message header provides information about who's sending to whom, and how to decrypt the message. The authentication tag is calculated based on the payload and the message header. To calculate the authentication tag, you need to have the secret key used to encrypt/decrypt the message.
The tag changes whenever the message header or payload changes.
If any bit is incorrect (e.g. transmission error) in the message header or payload or if the authentication tag itself has been manipulated, the authentication tag won't match the message and the receiver of the message will treat the message as a fake message.

When you want to encrypt/decrypt a message with Chacha20-Poly1305, you need 3 things: the key, the message and an IV (96 bit long initialization vector).
The IV must be unique for every single message where the same key is used. This is an absolute security requirement. So it is wise to have some sort of a counter in the IV. Sender and receiver must use exactly the same IV for successful encryption/decryption of the same message - but with every message the IV must change to some IV never used before. The IV itself is not secret. So you can transmit it or parts of it (like the counter).

Canique Climat transmits parts of the message counter in the message header. The receiver reconstructs the full IV from that counter. It is important to note here that when building the authentication tag the full IV needs to be authenticated.

So by using Chacha20-Poly1305 we can make sure that both our requirements 1) and 2) are fulfilled.

Replay attacks

Now imagine the following scenario: Your authentic device transmits the value -18.59°C at 15:00. 2 hours later an attacker retransmits the very same message, bit for bit. This is called a replay attack.
Some valid transmission recorded beforehand is replayed by a third party. The real temperature might have rosen to -12.00°C but your receiver is thinking the temperature is still -18.59°C.
The same scenario works for door status - Canique Climat can also be used as a reed sensor by the way. By using a replay attack you could fool a receiver into thinking the door is still closed/open or has just changed its state.
Canique Climat has a countermeasure against this kind of attack. It's a counter in fact. The message counter used for the IV is also used for replay attack prevention. If the receiver receives a message with a message counter that he has already received and successfully decrypted, the next message that the receiver will accept will be one with a higher message counter. The latest/highest message counter is stored and compared to the currently received one.

Hardware Cryptography in RFM69

Now let's compare Canique Climat's rather sophisticated software based approach to the hardware AES engine in the RFM69 (SX1231 transceiver)
RFM69 is said to be using AES-ECB mode - see https://forum.pjrc.com/threads/27442-interrupt-automode-driven-library-for-the-RFM69.

Quoted from that forum:
I checked the cipher mode used in the radio module, (I couldn't find it in the datasheet), the AES cipher mode turned out to be ECB unfortunately (check_crypto_mode.py). Also, as required with a block cipher, data is zero padded to multiples of the blocksize (16 bytes) so you lose the performance benefit of transmitting short messages

So RFM69 modules have a negative effect on message size, if hardware AES is used, plus their hardware AES is insecure.
AES-ECB mode in a nutshell: given a key k, the same plaintext message leads to the same encrypted output.
Just 1 example:  plain text "DOOR OPEN" => encrypted "xr2BRKm3z"
Now even if you can't decrypt the message, you know that every time this encrypted message is transmitted, the door is in state A/B. If you can e.g. see the door from outside just one single time, you can then tell based on the message whether the door is open or not - forever. You can conclude from the message content in which state the door is.
With Chacha20-Poly1305 you don't have this problem. Every encrypted message, even if the plaintext stays the same, is different - because the IV is different.
To put it short, the AES engine of the RFM69 neither fulfills requirement 1) nor 2).

Coming soon: Firmware Updates