There are a few ways to get time onto devices in the field - mostly dependent on communication devices. GPS is a good way to get time but if your product has no GPS and just LoRaWAN, how do you get time transferred? There is MAC-layer support for transferring time to devices, however this is not universally supported on the network side, nor supported on popular LoRaWAN networks like Helium. We've implemented an IoT time transfer scheme over LoRaWAN at the application layer and this works with Helium (and any other LoRaWAN network).
Our solution achieves millisecond accuracy for time transfer using Helium networks (relative to the time of the receiving gateway) by this method:
1. Sending a request to our application server using our open source Measurement Earth Low Power Protocol with a request ID (incrementing counter).
2. Recoding the device's internal time at the time of the LoRaWAN radio's TxComplete interrupt after transmitting that request. This will align very closely to the Helium hotspot/gateway's 'reported_at' time. We record the request ID and local internal time into a circular queue with some depth to handle delays and missed downlinks.
3. On the server, receive the HTTP POST and JSON from Helium, recording the time request ID and the gateway's 'reported_at' time, then forwarding a downlink with this request ID and gateway time back to the device.
4. On the device's next uplink, it may receive this queued downlink. Upon doing so, it looks up the request ID in the local time request queue to find the matching local timestamp. The actual time is computed as the downlink's gateway 'reported_at' time plus the difference between the current device time and the timestamp aligned with TxComplete interrupt, which aligns with the gateway's Rx time.
We've implemented a reference design of this concept in a server for forwarding sensor measurement transactions to the AntelopeIO blockchain in our open source protocol engine.
The stm32-secure-patching-bootloader targets SMEs that don't have time, money and/or expertise to allocate to getting X-CUBE-SBSFU integrated and ready to ship with their product firmware, or for SMEs that want the additional features that are not available with X-CUBE-SBSFU.
The key differences of the stm32-secure-patching-bootloader solution are:
1. Ready-to-go binary means customer does not need integration and maintenance of additional bootloader projects "SBSFU" and "SECoreBin" into application project workspace as X-CUBE-SBSFU does.
2. Supports firmware difference patching while X-CUBE-SBSFU does not. With firmware patching capability built into the tooling and the bootloader core, a small change to a 200K firmware binary can be delivered OTA as a 2K patch instead.
3. Supports TouchGFX large application firmware update, treating application content (GUI assets) that are placed onto external flash as part of one single binary using the same firmware image signing and patching capability. Customers using TouchGFX need this feature to deliver a firmware update as one file. X-CUBE-SBSFU does not have this capability.
4. USB flash drive update built into bootloader for products that have USB OTG host. Your customers can put firmware onto a USB flash stick and plug it into your product to update the firmware. X-CUBE-SBSFU does not have this capability.
5. The stm32-secure-patching-bootloader understands the needs of customers shipping real products. The stm32-secure-patching-bootloader core has been locked down and stable for over 3 years and is not tinkered with. The same core has been deployed to 7 STM32 families (L0, L4, L5, F4, F7, WL, G0) and to shipping products worldwide. In contrast, X-CUBE-SBSFU is a constantly evolving product and there might be unpleasant surprises waiting in the latest releases.
6. The stm32-secure-patching-bootloader is backed by an experienced firmware and product development expert who will work with you to ensure the solution meets your needs.
All of these features could be developed by experienced personnel within your organization but the cost and time to do so would be far far greater than getting the stm32-secure-patching-bootloader, a tested, stable and ready-to-ship solution now, for just $5000 CAD.
The business case should be obvious.
We have free demos on our GitHub. Contact Us for more details.
]]>
Using the stm32-secure-patching-bootloader as the back-end firmware update engine, this design feeds digitally signed and encrypted firmware update patch or full-image files through the HTML multipart/form-data file upload method. This method is natively supported in most browsers. The back-end multipart form processing has been integrated into an existing FreeRTOS and LwIP-netconn-enabled web server application.
This designs runs on a NUCLEO-F429ZI development board. It is inexpensive, readily available and includes USB OTG and Ethernet ports.
You can find the design sources right here.
The following HTML code is inserted into a webpage and served up to a browser. The browser automatically generates a file chooser button and binds another button to a form submit action (generates the POST request when pressed). No javascript is required.
<form id="form" action="upload" method="post" enctype="multipart/form-data">
<input id="file" type="file" name="binary" accept=".sfb,.sfbp"/>
<button type="submit">upload</button>
</form>
The server will see an HTTP POST request at the /upload URL. There are a few of the usual HTTP protocol headers in the request including the expected length (file octet data plus HTTP data), and Content-type indicators. Each "part" that came from the form will have its own Content-type indicator in the header. What we're looking for is the Content-Type: application/octet-stream followed by the HTTP header terminator of "\r\n". All data received in the LwIP buffers after this are firmware update file bytes and consumed as such.
POST /upload HTTP/1.1\r\n
...
Content-Length: 129773\r\n
...
Content-Type: multipart/form-data;
...
Content-Type: application/octet-stream\r\n
\r\n
In the web server source code (httpserver-netconn.c), I've built a state machine that parses this data stream and uses the SE_PATCH_Init and SE_PATCH_Data APIs appropriately.
Essentially, when the HTTP header has been found and verified, the SE_PATCH_Init function is called. This function just resets and readies the patching engine internal state machine. Then all bytes received thereafter as part of the "octet-stream" are fed into the SE_PATCH_Data function. The patching engine manages the byte counters and all of the details of erasing and writing to flash and performing the patching (if using an.sfbp file) so there's really nothing to do for updating firmware beyond correctly parsing the received network packets within the web server processing loop.
The patching engine first verifies the firmware update file header (256 bytes) with ECDSA signature verification before it will accept any further bytes. When it is satisfied that a valid firmware update file is on its way, it will accumulate bytes and either write them to the download slot (using.sfb file) or combine them with the existing firmware image to re-create the new firmware image in the download slot (using.sfbp file) in internal flash.
When all bytes have been correctly received and processed, the patching engine can either reboot immediately or manually by the user. I've chosen to reboot manually so that a "success" message can be delivered back to the client browser and the connection closed before rebooting. The "success" page has a redirect timer included to reload the firmware update page automatically after a delay to show the updated firmware version.
The reboot is required because it is the stm32-secure-patching-bootloader that actually takes the update image candidate in the download slot (SLOT1) and overwrites the active firmware image in SLOT0. It only does this if all the signatures, decryptions and SHA256 hashes all check out, making it super robust and great for any packetized delivery framework like ethernet, wifi, bluetooth, lora, lorawan, CAN, modbus, UART and so on.
In the repository, you can use pre-built files in the bin directory to test the update immediately or you can build the update files yourself with STM32CubeIDE and the included project files. More instructions on how to do that is in the project readme.txt.
[ 0.000] Bootloader starting up.STM32 Secure Patching Bootloader. github.com/firmwaremodules/stm32-secure-patching-bootloader Build: v1.3.0Registered to: unregisteredTarget: NUCLEO-F429ZIUID: 175053388a356f20Clock:HSE,8,168 Crypto:SW UART:3,115200,N81SLOT0:08020000 SLOT1:08060000 SIZE:40000APP RAMSTART:20002700 VTOR:08020200[ 0.029] Target check: CPUID:410FC241 IDCODE:20036419 FLASHSZ:0800 .. OK.[ 0.288] Verify bootloader.[ 0.315] SHA256: 3e8790d4724c52e5f5f2352bc6b132f1c8320134e0c89de983b98904c80e73a5 Valid[ 0.323] UART loader check trigger.[ 1.328] Check USB flash media.[ 2.330] No valid firmware found on flash media, status=1[ 2.336] Verify slot 1 header.[ 2.339] Slot 1 is empty.[ 2.341] Verify slot 0.[ 2.343] Verify slot 0 header.[ 2.484] Verify slot 0 signature.[ 2.535] Verify slot 0 ready.[ 2.538] Verify slot 0 fw ver.[ 2.679] Slot 0 has valid active firmware version 1.0.0[ 2.684] Preparing to launch application in slot 0.LwIP_HTTP_Server_Netconn_RTOS - NUCLEO-F429ZI Built FW_UPDATE_VERSION=1Firmware Version: 1.0.0Bootloader Version: v1.3.0State: Looking for DHCP server ...IP address assigned by a DHCP server: 192.168.1.75
This release has a key improvement of making it compatible with the latest STM32CubeIDE 1.9 or greater. In addition we've supported some STM32L4+ and STM32L5 boards.
See it here: https://github.com/firmwaremodules/stm32-secure-patching-bootloader
Customize it here: https://www.firmwaremodules.com/products/stm32-secure-patching-bootloader
]]>The public blockchain platform is used for two key purposes - to ingest and authenticate the sensor data source. With dozens of access points geographically distributed around the world, regular HTTP requests can be used to access the blockchain to submit data. The blockchain authenticates the data source due to the very nature of blockchain itself - only transactions digitally signed by the data sources can be accepted onto the chain. In our case the data sources are our sensors and they securely store a secret key known only to them while performing the transaction generation and signing process on-board.
The public blockchain we're using is called Telos, based on EOSIO blockchain technology launched in 2018 and recently forked into something called Antelope. We chose this blockchain because of its compatibility with low-power IoT devices: standard cryptography for which small C-based libraries are available and a staking-based blockchain resource allocation model. This means that a small fee is paid once and a device can send data to the blockchain indefinitely. This feature is attractive compared to alternatives like Ethereum that require a fee (gas) per transaction (i.e. sensor measurement).
The functionality of the platform, that is, maintaining a list of registered AQ sensor device accounts and the collection and authentication of AQ sensor data, is implemented by so-called smart contracts (aka dApps). The dApp for the AQ sensor system is registered to the airv11.meas account and hosts several actions (akin to functions) and tables. Of most interest is the submitv1 action that is encoded by each AQ sensor in their signed blockchain transactions. It is through this action that data gets onto the chain. Once on the chain, it is permanently part of the blockchain record. There exists REST APIs that allow user applications, like our Measurement Earth website, to collect the sensor data for presentation. We also run a TestNet website that allows access to most of our active test sensors. These websites run simple handcrafted HTML and Javascript and were initially deployed to IPFS. However due to IPFS's persistently long load times we have recently re-hosted the pages on GitHub pages.
The following infographic offers a high-level view of the entire system.
Our devices use STM32 MCUs at their core and LoRa radios to communicate indirectly with the blockchain. Since blockchain requires HTTP protocol access, we need an intermediary technology to move data between a LoRa radio link and an HTTP cloud endpoint which I discuss below.
The project began using STM32L072Z MCUs bundled with Semtech SX1272 radios in the Murata Type-ABZ modules. For these, we also built a custom over-the-air LoRa protocol and single-channel gateway using NUCLEO-F429ZI boards with Ethernet. The gateway has the same Murata Type-ABZ module attached that runs our LoRa "gateway" firmware to forward packets to/from the F429ZI over UART. The F429ZI acts as a LoRa-to-ethernet bridge, using the LwIP stack to make the HTTP requests to forward the AQ device's signed transactions received over LoRa directly to the blockchain. This solution is still operating to this day for a few of our AQ sensors. For this solution we don't need the Helium network nor the Helium->Telos bridge server, but this tradeoff requires a costlier and more complex rollout than a solution that could use existing gateways.
In early 2022 we took a closer look at the Helium network. Under the hood, Helium differs very little from a LoRaWAN network like The Things Network (TTN). However, Helium has a much smoother onboarding process through their slick Console application, don't impose any "community" limits on data throughput beyond standard regulatory, and has vastly more coverage. It is for these reasons and more that we decided to jump on board and give Helium a go. The prime benefit would be to eliminate the need for our own custom gateway for a field deployment. I will make a note here that there are elements to Helium that are also considered "blockchain", however this part of Helium has nothing to do with our blockchain back-end (Telos) and the Measurement Earth platform. We are only using Helium's radio and packet-forwarding LoRaWAN technology to get our own blockchain transactions to the cloud.
The firmware running on our blockchain AQ sensor devices is a custom-designed solution called Measurement Earth OS (or ME-OS). We added the LoRaMac-node stack from GitHub for the capability to join to and utilize the Helium network. One thing to note here - the blockchain transactions are relatively large, about 195 bytes including all sensor and metadata plus transaction signature. This fits into only the fastest LoRa mode - spreading factor 7. This means we lose a bit of range, but this is where Helium shines again - with such dense deployment coverage the sensor is always within range of a gateway (usually many) in an urban environment.
The last piece of the communications path is to connect the Helium network to the Telos blockchain. Unfortunately there is no built-in way to do this. Even the generic HTTP endpoint integration is not compatible with the Telos blockchain access points. To work around this we partnered with KandaWeather (now AscensionWx) to use their existing MQTT-based Helium to Blockchain binding app server, with some modifications, to complete the "last mile" between our AQ sensors, Helium, and the blockchain itself.
The system has proven to be quite resilient and the data dutifully gets onto the chain visible to all and useable for any purpose.
The extra capability to access LoRaWAN/Helium required more flash and RAM than the Murata modules could offer. Plus, they have been unavailable for quite some time. Our latest iteration of the AQ sensor device - so-called V2 devices - uses the SeeedStudio LORA-E5-MINI board (aka WIO-E5-MINI) that features the new STM32WLE5 MCU. This is an STM32L4 device that integrates the Semtech SX1262 LoRa radio on the same die while offering more than enough SRAM and flash to host ME-OS with Helium and EOSIO transaction generation & signing, along with our STM32 Secure Patching Bootloader to securely manage firmware updates in the field.
Our AQ sensor devices are fully independent - harvesting energy from the sun via solar panels and storing excess energy in a LiPo battery for use overnight and during periods of extended cloud cover. They are using all off-the-shelf available hardware and components, all of which is described in the infographic below. The energy consumption, even with these off-the-shelf components, is low enough that the unit can run for about a week without direct sunlight.
Available at no cost for evaluation on popular development boards from our GitHub repository.
New features
* Support for STM32WLE5 and LORA-E5-DEV and LORA-E5-MINI boards from SeeedStudio.
* Cleaned up postbuild argument list: remove vector offset and multiseg parameters - now located in board library package.
* Added README to board library packages.
The STM32WLE5 is a Cortex-M4 integrating a LoRa radio (SX1262) with 256 KB flash and 64 KB RAM.
With the STM32 Secure Patching Bootloader you can update firmware using delta patch or full images from the application itself. Our easy-to-use API means just about any firmware image transfer method can be used - including wireless and wired protocols.
You can get a powerful IoT bootloader and firmware update system integrated into your project in as little as 1 day. Think of that for your project's scope and planning phase!
]]>The Measurement Earth Trusted Sensor Platform (ME-TSP) is a new kind of IoT sensor platform placing data authenticity and quality at the heart of its design. Leveraging global distributed ledger platforms, sensor data can flow unimpeded around the world creating the most comprehensive view of the Earth as it evolves, now and for the future.
ME-TSP builds on the Measurement Earth Operating System (ME-OS), an OS designed from the ground up to support environmental IoT sensor configurations, communication methods and lower power modes on microcontroller-class processors. ME-OS is the first Oracle Class operating system of its kind in the world.
ME-TSP is by extension an Oracle Class sensing platform and is used to ingest data into on-chain smart contracts. ME-TSP can sign EOSIO blockchain transactions right on STM32 microcontrollers! The Measurement Earth Global IoT Open Data Platform is the first platform to offer IoT data oracle sensors. Our ME-TSP platform includes our own gateway, the ME-TSP-GW-V1 that can deliver the signed transactions directly to the blockchain platform over ethernet from the LoRa radio link!
Our prototype Air Quality Monitoring Station, the ME-TSP-AIR-V1, has been operating since mid 2021, creating a record of our climate. We are working on V2 that will support both Helium LoRaWAN and our own LoRa-based gateway network and will be launching the Measurement Earth Clean Air Challenge! Stay Tuned!
]]>An HSM is a single chip device with non-volatile memory storage and a processing unit internal to the IC package. It runs a program that provides an external interface and communication protocol to its non-volatile memory via I2C and/or SPI to a host MCU (Micro-Controller Unit) running the user application. The HSM's non volatile memory is where the host MCU's secrets can be kept safely. In theory.
Secrets include things like private symmetric encryption/decryption keys, asymmetric signing/authentication keys, cipher metadata like nonces, IVs, and counters that can never be repeated. Any of these things may be required by an application - let's say your application.
Now the standard recommended best practice for securing your secrets goes something like this.
If your secrets are stored on non-volatile memory inside your MCU's IC package, i.e. in internal flash, you can easily protect it from most individuals and organizations by simply disabling local (e.g. device-in-hand) communication to the device through its debug port (JTAG). With STM32 MCU's this is done by enabling ReaD out Protection (RDP) level 2. With JTAG permanently disabled, there is no way that most people, including yourself, can access the content of the internal flash - period. Also let's say your application is a pretty run-of-the-mill embedded system that doesn't offer a user accessible shell with the ability to read memory or execute stuff. Most MCU projects don't have anywhere near this capability so let's assume your application is not an attack vector.
Now I said most people cannot access flash content with JTAG disabled. There are organizations in non-descript office complexes with salaried employees that can access the memory. When these secret extraction projects comes across the desks of the 'extraction team', your device first stops with the hardware engineer. He or she physically disassembles the IC - known as decapping, exposing the silicon die(s) inside to direct probing. With highly specialized equipment, the engineer can read out the flash memory directly, completely bypassing the JTAG port. Once this process is complete, the extracted memory contents containing your firmware application as well as any stored secrets is thrown over the wall to the software engineer in the next cubicle. The software engineer, possibly using custom tools he or she wrote, will execute any applications in simulated environments, examine memory and function calls, and in fairly short order (maybe two or three days including lunch, coffee breaks and that afternoon yoga session) have the secrets fully extracted and delivered to the project manager.
So there you have it, this is what any IoT MCU is vulnerable to. Of course it costs money and time to do this, so the value of the secrets extracted to the "interested parties" must be worth it. Not all secrets are worth this effort, so that plays into the design of your IoT security system.
Alright, so you figure your IoT project is worth it to some "bad guys" to capture and send one of your devices to the non-descript office-complex company with a generic name in the building directory to get your data authentication signing key, or just to get your firmware application to clone onto their device, or look for weaknesses so they can attack other devices in the field and get them to mount a DDoS against Minecraft servers. Or maybe disable a hospital wing or water treatment plant in which your IoT devices are deeply embedded and in control. It would certainly be worthwhile to the "bad guys" to pay the non-descript office-complex managers and employees to help attack your devices if your devices were in control of lives.
Alright, so you build and deploy some life controlling IoT devices, or maybe you just don't want anyone to be able to clone your widget you've invested a lot of money to develop.
You want to put an HSM on your device because you heard they were good to have for security reasons. What does that mean? Well, it means your secret data signing or encryption key is not stored in your MCU's internal flash but instead in the HSM's internal flash, presumably because it is much harder for the non-descript office complex company to implement their extraction procedures on. Remember, though, that an HSM is likely another MCU under the hood. Maybe its got some physical/mechanical guards in place around the die(s). We don't know exactly what it has to protect its secrets because the HSM vendors use security by obscurity (they don't publish what makes their devices more secure than regular MCUs). But let's say for a moment that the non-descript office-complex company salaried employee assigned to this task takes a look and says "sorry boss this HSM is too tough for me - I've gotta pass on this one".
Okay, so the secret is safe in the HSM, for now. But your application needs to access this secret from time to time, and here we find a problem. The application runs on the host MCU - but the secrets are on the HSM. To get the secrets, the host MCU has to make a request over a well-known bus - I2C or SPI - to the HSM, and receive the secret over that same bus. Well hold on! Can't we just attach a logic analyzer to this bus and see the messages and the secrets flying across? Absolutely we can. But the HSM vendors thought of that too. Their solution? Encrypt the link - that aught to do it! If the messages and responses on the I2C/SPI bus are encrypted, the non-descript office-complex salaried employee cannot see the secrets, and cracking the encryption algorithm (AES) is still widely seen as infeasible (your banking system still depends on it) if implemented properly. Let's say the AES is implemented properly.
AES and similar ciphers are known as a symmetric ciphers. Both parties to the link - host MCU and HSM - need to know the key, which must be secret. So what does this mean? It means a secret has to be stored - back here again - on your host MCU's internal flash in order to encrypt and decrypt messages to the HSM where your real secrets are stored. If you think this sounds a bit fishy you would be right. You are now back to square one. The salaried employee at the non-descript office complex company knows this, and immediately gets to work extracting the content of your host MCU's flash memory. The extraction team uses the same process as before, only this time an extra step is added - the software engineer, using the discovered AES cipher key, applies it to the communication link to the HSM and decrypts the HSM's response when it comes back, exposing your super-secret data authentication key without so much as a how do you do. Maybe this takes another day or two - with the project budget upped accordingly. Next!
Disclaimer. I know nothing about how HSMs are actually made beyond what is in published datasheets and I know nothing about the murky workings of the security underworld. But I have no doubt in my mind that activities like this do exist. I build projects based on STM32 microcontrollers, and I know that despite my best efforts at hiding and securing secrets, they can be extracted with enough effort, time and cost. I also know that adding an HSM increases the BOM cost and complexity of my project for very little actual added security if my story above is even partially true.
So what can we do? Well, I think proper security 'architecture' can make a big difference. Let's look at how I implement secure firmware update - with the stm32-secure-patching-bootloader product. Secure firmware update means that the firmware update file itself is encrypted (confidential to protect IP from competitors cloning, copying, etc.), and signed. Signing a firmware update means - with the proper implementation - that your devices will only install firmware signed by your private key - safely stored in your facility (e.g. a build machine) and not anywhere on your devices. What is stored on your devices - and therefore subject to extraction - is the secret encryption (AES) key and the public signing (ECDSA) key. We'll look at the risks associated with storing these two keys on the devices which are outside your control.
Obviously, storing the secret encryption key on your device exposes all your firmware update files to being decrypted should this key be extracted. But note that if the attackers were able to extract this shared secret key, they have also already extracted your firmware - making having the key itself less useful. With the key, they could pull future updates from a public download server and decrypt them. I help to mitigate this download-and-decrypt risk in the stm32-secure-patching-engine by supporting patching firmware updates. With the encryption key known, the patches can be decrypted but do not contain a complete and functional application - making it difficult if not impossible for someone to clone firmware application version 2 knowing just the patch from version 1 to version 2. Sure, the non-descript office-complex employees could keep one of your devices hostage and use as a firmware update incubator - downloading the patches and re-extracting the updated firmware each time. Or they could just apply the patch algorithm directly. Patches are not really a defense against these guys, but if that product-wide AES secret key did get out to the general public, its use by the average hacker would be reduced to using patches instead of complete images for firmware updates since your product is protected by RDP Level 2 and the hacker does not have access to the expensive and specialized equipment used by the non-descript office-complex employees.
We've established that exposure of the secret encryption key in a firmware update system is not going to enable compromises of individual devices. Why? Because there is still the signature. The AES encryption key is not used to allow or disallow an update to occur - for example an attacker knowing your AES key cannot modify a firmware image to cause your product to do something bad and then have your product install it. The signing key prevents this because the attacker cannot create a valid signature that the stm32-secure-patching-bootloader will accept. The attacker cannot create a valid signature because they do not have the secret signing key, which only you have stowed securely away in your office, for example. Remember that what is stored on each of your devices is the public portion of the signing key. The public key enables verification but not signing capability. Again, this is the same security that your banking system uses and relies on. Let's say that the non-descript office-complex employee extracts the public signing key from the device on their desk. What can they do with it? Not much actually. When talking about secure firmware update, the real goal of bad guys is to be able to inject malicious firmware onto devices. But without the private signing key they can't do this locally or remotely (by for example modifying an update, signing it, placing it on a server and then somehow tricking your device to fetch an update from there). Even if they have the public signing key that means nothing because it is by definition public. What they could do is replace the public key on that device on their desk with one of their own, corresponding to a private key that they also control. In this case they could inject their own firmware at will - but only on that one device where they replaced the public key. But wait, haven't they already successfully hacked the device? Could they not just place their own application firmware on the flash directly? Well of course they could. So really what it comes down to is that firmware injection on devices using signed firmware updates - like those using stm32-secure-patching-bootloader - require a specific physical attack on each device onto which firmware is to be injected. This means physically removing a fielded device, bringing into the labs of the non-descript office-complex company and executing the attack project. I don't know about your devices, but if one of my Measurement Earth Air Quality Monitoring devices (which uses the stm32-secure-patching-bootloader) went missing I'd know about it (missing data and/or location has moved, etc.) and I can remotely invalidate that device by disabling its account in the cloud. This means that the security in the stm32-secure-patching-bootloader is an effective defense against a malicious party from pretending to be one of your devices, or gaining control of one or more devices through firmware update.
And all without the use of an HSM.
]]>
An Oracle-Class sensor has the capability to securely generate blockchain transactions on-chip without relying on a middleman or gateway. The data from ME-OS Oracle-Class sensors is ingested into blockchain smart contracts and dApps enabling these distributed and decentralized applications to process and make decisions on trusted data.
Our first ME-OS "GreenField" release offers these features:
You can find ME-OS in environmental sensing and wireless network solutions built for the Measurement Earth Global IoT Open Data Platform.
Stay tuned to this channel for environmental sensing solution announcements and ways you can get involved.
]]>Check out the demo on Hackster.io
Contact us to get this solution integrated into your project quickly and efficiently.
]]>This release offers several performance improvements, code size reductions and new features over v2.0.0
Learn more about the FM-SBSFU on our product page.
]]>Contact us for more information.
]]>
Firmware Modules announces the launch of its most advanced and industry leading Firmware Update System FM-SBSFU for IoT and embedded systems.
This new system features delta patching, external (Q)SPI and multi-segment support for handling advanced applications like TouchGFX for STM32 MCUs of all stripes.
Seamless integration into the STM32CubeIDE build system and support for update methods including USB flash drive means you can get ahead of your competition by offering your product with a professionally designed and supported secure firmware update system with features they can't match.
Get FM-SBSFU integrated into your product by STM32 bootloader and firmware update experts faster and for less cost than doing it yourself.
We have completed an end-to-end demonstration published on Hackster.io you can run yourself on an STM32F769I-DISCO board. This demonstration includes updating an image located on QSPI flash with a patch.
Learn more about this system on our product page.
View our product flyer.
Contact us to get your project started!
]]>
There are many steps on the road ahead. Our Telos Blockchain Worker Proposal is one such step.
View the proposal document here. Don't forget to vote!
]]>Designing a deeply embedded system with eMMC has its rewards as well as its challenges. One of those challenges shouldn't be fixing released vendor driver bugs, but that is what we had to do to verify the eMMC hardware implementation for a client. Read below to find out what needed to be fixed and what might be blocking your eMMC project.
eMMC - or embedded Multi Media Card memory - is a great choice for your STM32-based device when you need GB of non-volatile, on-board and non-removable storage in a cost-effective format.
eMMC memory, based on NAND technology, offers higher capacities along with built-in flash management that you won't find in smaller capacity NOR-based SPI-Flash memories typically found in deeply embedded systems.
However, eMMC requires a new interface with more sophistication than SPI. eMMC memories use a host driven clock, a single dedicated bi-directional command line and from 1 to 8 bi-directional data lines. ST provides hardware-level support in the form of the SDMMC1 peripheral found in many device families including the STM32L4 series.
Commands are 48-bit structures that are delivered to the eMMC module through the data line. The eMMC module can respond with up to 6 different types of responses. These responses are sent back to the STM32 host via the same data line. Commands are used to poll for eMMC capabilities, configure the eMMC or initiate data transactions on the data lines.
The processing of commands, that is, the serialization of command messages and capturing of command responses, is automatically handled by the STM32 SDMMC1 hardware peripheral.
Now, the task of deciding which commands to send and their content is up to the firmware driver. It is the driver that implements the eMMC protocol defined by the JEDEC standard. ST offers a HAL-based driver - comprising stm32l4xx_hal_mmc.c and stm32l4xx_ll_sdmmc.c - as part of their standard Cube offering.
Firing up this driver underneath a FatFS test application on a client's new board yielded an initialization error. What was wrong? The clock was operating. The command bus had traffic, but the driver was reporting an error. Digging deep - very deep - we found two key problems.
The first problem in the STM32L4 HAL MMC driver was found during the initialization sequence:
1. CMD1 (get Operational Capabilities Register - OCR)
2. CMD2 (get the Card ID - CID)
3. CMD3 (Set the Relative Card Address - RCA)
In the STM32L4 HAL driver, CMD3 was attempting to set address 0x1 - correct - but incorrectly attempting to confirm it in the CMD3 response and hence returning 0x0 to be assigned as the RCA in the driver for subsequent commands. Therefore, subsequent commands that require a card address, like CMD7 (Select Card), didn't work.
The second problem was in the sequence of commands that come next, after the initialization sequence. Even if the RCA was correct and CMD7 worked, the driver (note: this error applies to L4 devices only and NOT L4+ devices) was doing this:
4. CMD8 (Get Extended CSD)
5. CMD7 (Select Card)
The card has to be selected before it can return the extended CSD. Swapping the order of commands to CMD7 then CMD8 allows the driver initialization to complete. Note that the order is correct for the newer L4+ device series, for which special handling is differentiated with a #define statement. Both L4 and L4+ devices shared a common path with the incorrect RCA handling, however.
Hopefully resolutions to these issues get baked into CubeL4 firmware for aspiring eMMC users. If you're facing a problem with your project, we suggest looking into your HAL driver and ensuring the resolutions to the issues presented in this blog post are applied.
]]>
https://geohash.measurement.earth/
A geohash is a string or integer representation of a rectangular region on the earth. We like geohashes because they work like hierarchical data structures - the more characters that are added to the string, to more refined the location and smaller the bounding box.
Example
Geohash c3 - 2 characters of precision - specifies a region that covers both the cities of Calgary and Edmonton in Alberta, Canada. It is a large region, spanning a few hundred kilometers in all directions.
If we add characters to region c3, we generate a smaller region within the bounding c3 region. We now know that any IoT location that begins with c3 is related to each other - they are located within the c3 bounding box.
Region c3nf - 4 characters of precision - is a much smaller region and covers most of the city of Calgary. Each character of precision reduces the size of the bounding box by a factor of 32.
Go ahead, try it!
We like to use geohashes to tag IoT data. It is more concise than latitude, longitude pairs and offers the hierarchical relationship that speeds up relational searches and analysis.
The integer form of the geohash is particularly useful in finding locations that are "closest" to one another. For example, we can find out where an IoT device's nearest gateway might be, or nearest complimentary data sensor to correlate captured data better during analysis.
P.S. This geohash website itself is not hosted in a way you might expect! You can also find it here (version 1.2.0):
https://ipfs.io/ipfs/QmQgz4uGonhCKyHKBJUCVa8o6UBYMiovJh8ipVdT2v2nzK/
]]>
Building on our demonstrated expertise developing secure FOTA update solutions, we have leveraged ST's tried and tested X-CUBE-SBSFU reference design to offer our OEM customers the most advanced IoT firmware update system available.
Our turnkey solution works "out of the box" and integrates with your development environment including IAR, Keil, STM32CubeIDE and others.
It is the most cost effective way for you to get a secure FOTA delta patching solution integrated in your STM32-based IoT device lineup. We do all the work and support it through the life of your product.
The solution generates signed and encrypted firmware patches to your on-device application using state-of-the-art ECDSA and AES technology. Delivered over the air to your IoT devices, these patches save you precious network bandwidth time and costs.
Contact us to have an expert integrate and support this turnkey solution in your next IoT project.
Learn more about it and see a demonstration on Hackster.io!
]]>Often I encounter firmware development projects that use a "version.h" header to specify the project's version in terms of numbers. It is a simple scheme but should not be used for any projects that will be or are producing devices at scale. It is completely arbitrary and subject to abuse and human error. The main problem with this scheme is that there is no way to trace what is actually running on a target device to where it came from because a developer can build literally anything by manually setting the version numbers. What does a version of 1.3 mean? 0.9? Are there local changes that have not been captured anywhere? Who knows.
If you follow the simple procedure that I describe below, your firmware release headaches become a thing of the past. No longer will you spend days tracking down issues as a result of some local developer-created changes, or sending the wrong images to production. These are all costly mistakes that can be avoided.
In a nutshell, there is a way to use the Git version control system to setup a fully traceable commit-to-binary versioning scheme to bring your firmware project up to production quality standards.
The first thing you need to get your head around is that while you will likely be releasing firmware under the semantic versioning standard (i.e. major.minor.patch) , which I highly recommend, your firmware's version will still be fundamentally a string and not a series of digits crammed into a uint32_t.
This string will ultimately convey the Git tag name for release builds but could be longer to hold additional tracing information for developer builds.
Think of this string as your firmware's identity - this version string will uniquely identify your firmware binary image from all others - no matter who built it - with direct tracing back to the Git commit that it came from. It will even tell you if a developer tried to sneak in some local uncommitted changes into the build.
Alright, so how do we get this version string and what does it look like?
In your project's build script, you use the git describe command to generate a string that you pass to your compiler as a preprocessor define. Let me show you how.
Windows:
set VERSION_CMD=git describe --tags --always --dirty
for /f "tokens=1" %%a in ('%VERSION_CMD%') do set VERSION=%%a[Compiler Flags]: -DVERSION_STR=\"%VERSION%\"
Linux Makefile:
VERSION := ${shell git describe --tags --dirty --always}
[Compiler Flags]: -DVERSION_STR=\"$(VERSION)\"
The describe command produces a very informative version string. As an example, I am working on a feature branch off of master that had an earlier tagged release of v1.2.3 merged in at some point in the past, and I have made 8 commits to my branch since then and there are also some local changes that I have not yet committed. Here's what my firmware version will be:
v1.2.3-8-g6f239e1-dirty
As you can see, putting this out into the field makes it plain to all that it is a development testing build and should not have moved further than the developer's local test environment.
The string can take several bytes, so it is very important that you plan for that in any communication protocols you may employ. It is very useful to be able to see your device's version from a mobile app if that is your main interface. Or via console/serial/USB when you are running production and need to verify the firmware version at a test station.
Now, how does this tie into a firmware release flow? It's really very straightforward. You should already be using git tags to tag specific points in your repository during releases. If you use GitHub, the "releases" feature requires you to create a release "name", which is just a tag name for that specific release. Git tags refer to specific commits.
Now, using git describe to define your version string, your firmware release is bound immutably to this specific release tag. So, you need only create the tag, setting its name to the version string you desire, checkout that tag, and do your build.
For example, if you create a tag called "v1.3.0", running git describe from a clean checkout of this tag will simply be "v1.3.0", exactly what you want as your firmware production release version. You can tag your local working copy using lightweight tags, then do a release build immediately after, e.g.:
Your tags created locally this way can be pushed to the server with:
I highly recommend, however, that you use a Git hosting platform's service to create the tags like GitHub Releases, where you can later attach the built firmware binaries and other artifacts like release notes.
In summary, I've described a process that I guarantee will eliminate wasting time tracking down issues related to untracked changes during your product lifecycle, and will make your project managers and VPs extremely happy to boot!
Evan works with clients around the world to build world-class IoT devices and embedded systems that work at scale.
]]>With that said, what makes an OTA firmware update system secure? Or put another way, what is it that is being protected by outside threats that require this added capability and complexity?
A secure firmware update system is trying mitigate two main threats to an organization's business:
Execution of either of these threats can destroy an organization's reputation, competitive advantage and ability to effectively operate.
A proper secure OTA firmware update system will be able to prevent firmware cloning through encryption (firmware confidentiality) as well as prevent device hijacking through public key cryptography (firmware authenticity).
Both confidentiality and authenticity can be implemented using symmetric cryptography and shared secrets. An example would be the AES-GCM cipher mode.
However, shared secrets come with risks. Shared secrets offer a huge attack surface to your potential attackers: your entire fleet of devices. Just one device can be moved into a lab in some far corner of the world, attacked mercilessly with methods you have never heard about (but they do exist), eventually yielding that one tiny little secret - too bad it is shared with all your devices. Now the attackers can generate their own firmware, inject it into any one of your devices, and begin to carry out the attack.
This should scare you. It scares me. This is why shared secrets are not good enough. They are, however, necessary for implementing the confidentiality portion of the secure product defense. So yes, any one of your devices can potentially cough up access to an attacker looking to copy or clone your firmware. But with the additional security feature in place that I will talk about next, your attacker will not be able to load firmware onto your existing devices, mitigating a huge threat to your organization's business success.
Asymmetric, also known as public-key, cryptography has a feature that allows a product maker to control who can put firmware onto their devices without placing any secret key material on the devices. Instead, a public key is placed onto the fleet of devices. Because this key is "public", it does not matter if an attacker can learn what it is. Only the owner of the private portion of this key-pair, which is the product maker, can "sign" the firmware in such a way that the devices will accept it.
If an attacker is able to gain access to a device in such a way as to "install" their own public key corresponding to a private key that they control, the best they can do is load their malicious firmware onto that one device. This is a much, much different situation than if one attack compromised your entire fleet of devices by extracting a shared secret. Using asymmetric cryptography, the attacker must duplicate the effort on each device.
Security is never a guarantee. Think of it more as a bar to set for what you are willing to pay in terms of development, implementation, management and product cost versus the likelihood of a successful attack and associated cost to your business should a successful attack be carried out.
Smart Meters may have a higher security bar than pet trackers.
At the end of this story it is sufficient to say, although no surprise to anyone I'm sure, that Firmware Modules has you covered in terms of implementing robust secure OTA firmware update systems for your next IoT project.
]]>
Honorable mention: EOS has such a fantastic, vibrant and positive user and development community.
With this list in mind, the question becomes what are the applications? Over-the-air firmware update campaigns driven by blockchain? Secure data transactions? Proof of time, location and sensor readings? Tokenization of data? Yes to all, and this is just the start.
Check out the RFID Scanner for Blockchain project we completed in collaboration with EOSIoT and THIS. IS. IoT. showing a use case for IoT and blockchain.
This project leverages Node.js and open-source libraries to quickly pull together a solution to control an MFRC522 RFID scanner IC and send the tag data to the EOS blockchain.
Because this was built on a Raspberry Pi, we are able to offer our customers a way to quickly evaluate how this IoT and blockchain solution can solve their problem or open up new applications using easy-to-deploy off-the-shelf hardware and open-source software.
We are looking at building an industrialized firmware core that is able to perform the same function as this demonstration on an ARM Cortex-M MCU for less cost, size and energy. Hand-held RFID, Bluetooth and optical tag scanners for blockchain will be feasible.
]]>Based on some work I had shown in Hackster.io, she asked if an update downloaded over HTTP could be placed into a second region in flash called APP2 and eventually run from there if the update succeeded.
She also mentioned that her current application size was 93K.
Based on this information, I couple of things jumped out at me: the potential lack of a Vector Table Offset Register (VTOR) in the the Cortex-M0 she selected would make it difficult to run an application at any offset other than 0x0 (default starting address on Cortex-M devices). Plus, her application was already almost half the size of the available flash, preventing the use of internal flash as a staging area and necessitating the addition of an external flash to her design.
As it turns out, the STM32L0 line of MCUs are based on the Cortex-M0+ core and do indeed have a VTOR, making a standardized bootloader implementation possible. However it is still possible to design for VTOR-less devices as I discuss below.
I said that her proposed bootloader design is reasonable in principle. After all, I did implement it in several Hackster.io projects: use the empty space on the internal flash to store and run an application when the flash is split into two sections. The program could be downloaded to, and run in, either section. A very robust design, but has some prerequisites that must be met.
In her case, the application is already almost the same size as half the flash: 192/2 = 96K. This would leave very little room for application improvement or enhancement. Plus, the bootloader itself will need one erase sector, which is 4K on that part, effectively leaving her (192-4)/2=94K, and probably not enough space to hold her existing application.
Then I said to execute an application that is not at the start of flash (address 0x0800 0000 in ST Micro MCUs), the MCU needs to support the Vector Table Offset Register (VTOR) to allow interrupt and exception vectors to be located at arbitrary locations in flash, like in APP1 or APP2 sections. The STM32L0 line (Cortex-M0+) does support the VTOR, so this means that applications targeted to this device can be located just about anywhere in flash.
Nevertheless, what if the device was based on a plain vanilla Cortex-M0?
In these situations, it is still possible to update the firmware, but the downloaded firmware would have to be put into either another area in the internal flash, or onto an external flash. I proposed that the main application has a small routine that is put into RAM and executed from there to do the copy of the application code over top of the existing application. There would not need to be a special bootloader application, and she can still use an appropriate OTA firmware download method like a UART interface to HTTP commands on a cellular modem, or a WiFi module.
I suggested that for such a VTOR-less Cortex-M0 part, I thought the most realizable and appropriate OTA update method would be to download the firmware image to an external flash connected over SPI, then copy a section of her (bootloader) application to RAM that copies the downloaded image on the external flash back to the internal flash, overwriting her current application. When complete, it reboots. Most failures during the application update is recoverable because the bootloader portion of the application resides in the first 4K and is the last sector to be updated.
Before main(), and within the first 4K of flash, a few routines comprising a "bootloader" are present. This special "bootloader" startup routine runs before main(), or as the first function in main(), every time the application runs, to check for a download in the external flash and then start the normal copy procedure as described above again.
For Cortex-M0 parts without a VTOR, there are some vector table "jump" designs that manually construct special jump tables to land an interrupt on an application's table located further up into flash.
The design that I have proposed, by combining the bootloader/udpate function into the main application, requires no special jump table construction and allows updating of the bootloader code itself along with the main application (though not necessary).
The only capability a VTOR would add to this design is to allow separation of the bootloader (which I call firmware image manager) from the application. This could allow for a slightly more robust design where the bootloader is never touched during an update process and is always available to recover failed application copy/write attempts.
However, with IoT bootloaders needing to be moderately complex to handle security features such as firmware image signature verification, it is possible that these modern bootloaders need to be updated in the field. Plus, the overall size of the separately combined bootloader and application would be larger than a monolithic design as I've suggested here due to duplication of shared security libraries.
Based on this assessment, and experience designing and implementing secure OTA firmware update systems for IoT devices, I am rolling out a new firmware product that handles in-field over-the-air firmware updates the same way for Cortex-M0/M3/M4x. This product also has patching capability where only the difference between versions needs to be downloaded to the device. This can support seriously small update images.
I call this type of bootloader/OTA update design Self Replicating Firmware. One application has everything it needs to update itself - by reaching out to update sources to download signed patch data, reconstructing a signed update image, and performing the installation of the reconstructed firmware update image.
I will point out that ST's SBSFU has made great strides in standardizing the secure and robust update of firmware on STM32 devices. I have adapted my patching system to work with the SBSFU bootloader. You can find out more details and how to get yours on my secure bootloader website: https://www.firmwaremodules.com/pages/bootloader
]]>Most other IoT sensor deployments send authenticated messages to a relay agent, gateway or intermediate cloud endpoint. Examples include:
In properly implemented typical IoT systems the data is authentic between the sensor and the gateway or intermediate endpoint and manipulating data along that route is not possible. However, these typical IoT deployments require custom translation and processing application software and firmware running on the gateways and relay agents and intermediate servers - greatly increasing the cost of development, maintenance and ownership of the IoT solution - plus opens up security holes and increases the attack surface.
There is no doubt the industry is trending toward true Sensor to Cloud solutions for maximum security and minimum TCO. IoT solutions not offering this capability will fall by the wayside. Firmware Modules is already ahead the game and has a pulse on the leading technologies of IoT and is combining them to offer true Sensor To Cloud security and capability.
]]>Take for example Zigbee. Popular in low-power sensor devices, the device must use Zigbee's specified security domain to transfer messages from the sensor, over it's wireless link, to a coordinator or data concentrator device. This concentrator device will need to transfer the data to another security domain such as TLS in order to transact with a cloud server over a less-constrained link. As a consequence, the concentrator device has access to both the Zigbee/sensor security domain and the TLS/cloud domain. Each domain has its own security protocols and complex implementation standards. If there are any errors or omissions or weaknesses in the implementations in any of the links in this traditional sensor to cloud paradigm, your IoT solution as a whole must be considered insecure.
What we are advocating for and developing is a new blockchain-backed Sensor-to-Cloud paradigm where the device and the cloud are on the same security domain and the only two entities participating in it. As a result, we believe that blockchain offers the perfect security domain for all IoT devices.
A device that can speak "native blockchain" is assured to be operating in a globally recognized and trusted security domain. Let's face it: blockchain security has been more rigorously tested than any other technology ever. The ECDSA cryptography standard that forms the backbone of Bitcoin, Ethereum and EOS, among many others, has stood up to the combined might of the entire planet for a decade.
IoT devices, even the smallest, tiniest, battery powered, energy sipping devices can now implement ECDSA and transact directly to a global IoT platform powered by the blockchain.
Our blockchain-powered Sensor to Cloud technology will eliminate the middlemen and any risks associated with man-in-the middle, replay and other attacks. You and your customers no longer have to trust anyone in the data supply chain that moves your data to your blockchain powered cloud.
Contact us if you are interested in incorporating this ground-breaking technology into your IoT solutions.
]]>
First of all, these things need to connect without wires, and they do that with radio frequency - or RF - technology. There are two fundamental technology "stacks" used to do this, based on the type of RF spectrum:
1. Licensed spectrum, exclusively utilized through cellular technology which we are all familiar with. Cellular technology has been the connectivity workhorse for any connected object outside of the home, office or factory.
2. Unlicensed spectrum, which offers a connectivity playground for just about anyone to play in. Because of the low access barriers, smart people have devised many, many ways to connect devices in the unlicensed spectrum playground.
In the licensed spectrum arena, we are mainly dealing with connection technologies such as (listed in chronological order of rollout) 2G, 3G, 4G, LTE, Cat-M1 and NB-IoT. The latter technology is specifically designed for connecting embedded sensors with low-bandwidth connection requirements and is being rolled out now.
When we look at the unlicensed spectrum, we have a number of technologies to choose from with various energy / range / bandwidth trade-offs. From shorter range higher bandwidth all the way to long range low bandwidth we have WiFi, Bluetooth, Zigbee, Z-Wave, 6LoWPAN, Sigfox, LoRaWAN, Ingenu, Weightless, and others.
In the unlicensed spectrum we also have two main bands globally that devices can communicate in - namely the 2.4 GHz ISM ("Industrial Scientific Medical") band and the sub-GHz ISM band. Around the world the sub-GHz band is a little less uniform, and regulated slightly differently in each jurisdiction, but is the chosen band for any of the long range communication technologies. Generally, 2.4 GHz technologies focus on in-building short range higher bandwidth applications, while the sub-GHz technologies cover anything that is "smart city", outdoors, or mobile.
WiFi, Bluetooth, Zigbee, Z-Wave are short range 2.4 GHz technologies; 6LoWPAN (also known as Thread) is often found in 2.4 GHz devices but is finding applications in medium range solutions employing sub-GHz frequencies; and Sigfox, LoRaWAN, Ingenu, Weightless are exclusively designed to work with sub-GHz radio chipsets.
In another post we'll look at the protocol stacks commonly used to connect IoT devices to the Internet.
]]>
Use The Things Network LoRaWAN smart city low-power wide area network (LPWAN) technology, COLLOS Collaborative Location Service Portal, and MyDevices Cayenne IoT platform to implement a next generation IoT positioning solution that uses only WiFi signals.
This solution does not use GPS. Instead, WiFi signals are scanned with the press of a button and submitted to the cloud via your local LoRaWAN network for lookup by a COLLOS location service provider. With COLLOS, you have the option of using sniffed WiFi data with Skyhook to generate position lattitude and longitude (as is demonstrated in this project), or you can use the LoRaWAN network built-in position capability with TDoA/RSSI techniques. The LoRaWAN network positioning methods works best with high gateway density which may not be available in your area.
Using sniffed WiFi data, the returned location coordinates are usually quite comparable to GPS. However unlike GPS, the system works indoors!
Here's what you're going to need to do to get this up and running:
1. Assemble STMicro Nucleo-64, X-NUCLEO-ID1M01 WiFi module, Semtech LoRa shield.
2. Program the ready-to-go application firmware.
3. Create your The Things Network account and application (create device and application, then get the AppEUI and AppKey). Configure the TTN application with DevEUI, and the application firmware with AppEUI and AppKey.
4. Create your MyDevices Cayenne account, create device, and optionally install the mobile app.
5. Configure the COLLOS and Cayenne integrations in your The Things Network console.
All of this can be done for no fee, except for the hardware cost.
Asset Tracker Hardware Stackup
Attach the X-NUCLEO-IDW01M1 to the NUCLEO-L152RE as shown. Then attach the Semtech LoRa Shield. No other configuration is required. Connect to your PC with a USB mini cable and proceed to step 2.
Download the 'WPS Firmware Image' file from the project releases page
to your PC. With the STM32-NUCLEO, you can drag and drop this file to the 'NODE_L152RE' mass storage device that appears in your file system. Open a terminal to 115200 on the available STLINK virtual COM port. Press the reset button. Observe confirmation of operating firmware (see below expected output) and record the DevEUI. The DevEUI is unique to each and every device. Think of it as a GUID. For ST MCU devices, it is based on the factory programmed unique ID. In this example DevEUI is 2e4d7910848b2cc9.
Starting Intelligent Asset Tracker for LoRaWAN version 1
Configuration:
DevEUI:2e4d7910848b2cc9
SCAN_RANDOM_AP:1
NUM_SCANS:3
MAX_SCAN_RESULTS:20
MAX_AP:6
Cannot start: please set your LoRaWAN AppEui and AppKey settings with 'mta set lora appeui/appkey' command then reboot.
Here you need to have ready the Device's unique identifier called DevEUI - an 8 hex-digit string - so that you can register a new device for it in The Things Network console after creating a new Application. Then you will get the two important hex-string numbers from the Application - the 8 byte AppEUI and the 16-byte AppKey - needed for the application firmware to enable a secure end-to-end connection to your Things Network Application.
Head over to The Things Network and sign up or log in. Add an application with this quick tutorial. Set the Application ID to anything you like. Next, register a new device.
Under the Devices section select "register device". Enter a name (Device ID) for it. Anything will do, e.g. MyAssetTracker. Then paste the DevEUI string obtained in Step 2 into the Device EUI field. Click the Register button. Once that is done, go to the Device Overview for your new device and scroll to the bottom to find "Example Code". This is the easiest way to find the AppEUI and APPKey needed for your firmware. From the example below:
AppEUI is 76B3D57EDABC9574
AppKey is DAC1F3E9EBAC12345678913994C58A4B
const char *appEui = "76B3D57EDABC9574";
const char *appKey = "DAC1F3E9EBAC12345678913994C58A4B";
In the terminal enter the AppEUI and AppKey into the firmware like this:
0000: Contiki> mta set lora appeui 76B3D57EDABC9574
OK
0000: Contiki> mta set lora appkey DAC1F3E9EBAC12345678913994C58A4B
OK
0000: Contiki> mta save
OK
0000: Contiki> mta get
AppKey: [DAC1F3E9EBAC12345678913994C58A4B]
AppEui: [76B3D57EDABC9574]
DevEui: 2e4d7910848b2cc9
0000: Contiki>
Follow the The Things Network guide on how to setup Cayenne, create a suitable device, and add it as an integration. Note! We are not actually sending any payload data to Cayenne, so please ignore payload type (CayenneLPP) field and configuration as it will eventually be changed to custom. It is the COLLOS integration that will funnel position coordinate data to your Cayenne integration.
This is the final critical step to getting your The Things Network Application ready to receive and process your device's WiFi position data!
It is best described by The Things Networkhere. Register for a membership (free). You may have to wait a day or two to receive access. Then follow the Quick Start. For the Collos API endpoint URL, you may use the 'loraSkyhook' one:
https://api.preview.collos.org/localization-lora-recipes/v1/loraSkyhook
Important! To enable WiFi localization, follow the instructions here to setup a custom payload decoder function. This is essential to having your device's sniffed WiFi data (access point MAC and RSSI) sent to the COLLOS system and forwarded to Skyhook.
Testing
Reboot the device and observe to terminal. You should see the followingStarting Intelligent Asset Tracker for LoRaWAN version 1
Configuration:
DevEUI:2e4d7910848b2cc9
SCAN_RANDOM_AP:1
NUM_SCANS:3
MAX_SCAN_RESULTS:20
MAX_AP:6
>> Trial start: 19
Press button to trigger position reading.
Looking for accelerometer...
LSM6DSL not present.
Starting LoRaWAN stack.. wait for join complete
LoRa stack init
REGION_US915_HYBRID init
SXX1272 radio version: 22
Set ADR ON: 0
Set public network: 0
Device join method=OTAA
DevEui: 2e4d7910848b2cc9
AppEui: 76B3D57EDABC9574
AppKey: DAC1F3E9EBAC12345678913994C58A4B
Send JOIN request... 0
Device state: SLEEP
Device JOIN success
Starting wifi module attempt=1.
-- SEND: EMPTY: OK
Device state: SLEEP
Airtime added: 289 ms
TX power: 5 Datarate: 0
Successful transmission
Wifi module started.
Press the blue button on the nucleo to trigger a WiFi sniffer reading. It will try to get 6 unique station IDs into the list with up to 3 scan attempts. Since the WiFi module does not need to associate with any access point, it can be powered down into very deep sleep modes (microamp range) in between readings. The readings themselves only take a few seconds, including module restart from sleep.
(button) scan event 1
>> Running WiFi Scan (0)...
>> Got 6 scan results
--- Sorted results after scan:
[0]: SSID: TELUS1234 MAC: 9c:1e:95:7c:b5:f2 RSSI: -40
[1]: SSID: TELUS4567 MAC: 72:1e:95:7c:b5:f0 RSSI: -41
[2]: SSID: TELUS9876-2.4G MAC: 70:f1:96:9b:f2:2 RSSI: -74
[3]: SSID: SpaceAce MAC: 0:1e:c0:3a:ed:58 RSSI: -80
[4]: SSID: TELUS6671 MAC: 20:76:0:75:d:b4 RSSI: -81
[5]: SSID: MonkeyMan MAC: 10:9f:a9:37:5d:13 RSSI: -90
scanning complete - filled result list (6).
LoRa_sendBuffer: sending 42 bytes
-- SEND: INTERVAL
Time: 155393, Battery: 3330 mV Temp: 29 C
Sending mac tx uncnf port=2 0r=42 len=0... OK
Device state: SLEEP
Airtime added: 113 ms
TX power: 5 Datarate: 3
Successful transmission
A WiFi sniffer device is constructed with a STM32L152 MCU, ST WiFi module and the Semtech SX1272 LoRa transceiver. Firmware is developed and based on the open source Contiki operating system (GitHub link) and LoRaMac-Node reference implementation (GitHub link).
Through a collaboration of 3rd party infrastructure, network and service providers, an end-to-end location-based IoT application is demonstrated. With a MyDevices Cayenne app installed on your mobile device, you would have the ability to demonstrate a complete end-to-end, any-where-in-the-city, device-to-phone tracking solution. This is the bleeding edge of IoT.
We have also posted this project on Hackster.io.
]]>XYFindables - the company behind the network, is already producing a line of Bluetooth Low Energy (BLE) beacon-enabled, smartphone-linked, asset tracking tags. Presumably the company has identified a need for this network based on real-world experience, and XYO is not just an ICO crypto-grab.
What I see in XYO are two key concepts:
However, on closer inspection, the XYO concept is lacking in detail. The elaborate scheme of "Bound Witness", "Proof of Origin", compensation models, and another proof-of-work "XYOMainChain" could, in my opinion, be replaced by BLE beacon location devices utilizing Google's Eddystone secure beacon eID and eTLM, for example.
Furthermore, Bound Witness describes a scheme whereby nodes must register the presence of other nodes in the vicinity. If you know a little bit about how these BLE location devices work, and the value that that market places on battery life (got to XYFindables.com and you'll see a comparison of companies using battery life as a metric) - you will know that if the device has to record another device's BLE beacon, it must turn on its radio - and turning it on will drastically shorten the device's battery life and hence market value.
Transmit-only BLE beacon devices, which the company produces now, have a battery life that depends proportionally with how many beacons are emitted per unit of time. A device that needs to "bind" itself to another device is going to drain its battery a lot faster.
Think of the following as an open letter to the XYO Network.
Two key features of the system are Bound Witness and Proof of Origin/Proof of Origin Chain. The Proof of Origin is rooted in Bound Witness and assumes that the devices are not secure, in other words, a spoof-able unencrypted unique ID is broadcast in each BLE beacon emitted by the device.
Here we go:
A Hashgraph type of system could replace all of this by embedding the Oracle right into the network – with cutting edge IoT systems in the works. Devices that are IP capable could participate directly in the distributed ledger, moving data directly into the smart contract environment – which could then perform the function of the XYO Diviners, all right on the Hashgraph proof-of-stake chain, without any special bridge component. Maybe the 'Archivist' concept still applies to buffer data, or store it as part of the smart contract ledger audit history.
LoRaWAN networks can fulfill a smart contract location function already. The end device securely stores a private key known only to the LoRaWAN network application acting as the oracle. Data is securely and authentically transferred through the LoRaWAN network, consisting of untrusted gateways, public internet, other relay servers, to be stored on the trusted LoRaWAN application server performing the Oracle function.
This LoRaWAN application can be run by a reputable company and thus serve as the trusted location data source for the blockchain smart contract. We can build an incentivization layer on top of that to compensate the components of the data supply chain: the device owner/operators (data producers), LoRaWAN gateway owner operators, cloud infrastructure and application service providers, and eventually the smart contract participants (data consumers).
If you've learned one thing here, it's that IoT, location and blockchain do have a future together and it is unfolding as we speak. It is up to us to make it happen.
]]>
The common language of our connected things is not a communication protocol. We are quickly realizing it is in fact going to be a global cryptocurrency.
The common layer amongst all connected devices will be transactional in nature powered by a secure, decentralized, machine to machine economy. This is Internet 2.0, IoT 2.0 and Bitcoin 2.0 all rolled into one.
If crypto is not on your IoT product roadmap, you need to find a way to get it on there.
So what does this really mean for IoT devices?
LPWAN gateways - whether on residential rooftops or central towers - must accept data from potentially 1000's of devices on the same channel. Occupancy of this channel by any one device will have a negative impact on the gateway's capacity, so devices are designed to minimize channel occupancy with short, infrequent messages. Similarly, the gateway or central tower must also keep its transmissions on this channel to a minimum to keep capacity levels acceptably up. Remember, this is primarily a data mining operating, not a device management service.
When the gateway is transmitting, it is guaranteed that not one single device will get its message through. Devices must get their data through, hence, gateways must not transmit. Really, they should not. A little feedback is good; I think gateways should come up with a protocol for "broadcast acknowledgement" - some sort of bitfield that all devices can reference to determine if they are getting their messages through or not. Currently LoRaWAN specifies a downlink transmission feature for individual nodes that occurs in one of two time slots following an uplink transmission. For each transmission by the gateway to one node, not one single node can send successfully, and they will not know it.
This is actually the bigger problem. A business problem, not a technical one. On a given LoRaWAN network deployment, there will be devices from multiple vendors. All they have to work with, in common, is a protocol specification by the LoRa Alliance. This specification does not contain a firmware update protocol, let alone what kind or size of payload is to be sent. Any two vendors will invariably come up with their own in-house firmware update system, that will transfer some or all of the firmware image bytes that need to reside on the device. This system will have to comprise some sort of cloud management solution outside the scope of any LoRaWAN network operation. The cloud management solution will need to track each device, offering the vendor the option to update one, some or all of them. Listen closely. Vendor A's potential update of all of their devices will need to work simultaneously with vendor B's and C's regular device operation. In fact, vendor B and C would be highly agitated if Vendor A's firmware update operation affected their value proposition in any way. So much so that I believe Vendor B and C would not tolerate a single transmission from a gateway intended solely for Vendor A's device firmware update, because this single transmission will likely cause at least one of their own device's transmissions to be lost.
Device and solution developers want maximum uplink capacity for their devices. Their solutions depend on it. Firmware updates will be a challenge over LPWAN's because they are data mining operations first and we must treat them that way. We will have to come up with clever out-of-band device management schemes that don't impair the uplink performance of the LPWAN network.
That said, the LoRaWAN Alliance and innovative member companies are working on ways to perform firmware updates, primarily useful on closed networks due to the issues described above.
I have previously blogged about The Things Network FOTA approach for LoRaWAN networks. This firmware update system is based on open source work by ARM for the mbed platform. And TrackNet has announced it will soon open source its FOTA update system for LoRaWAN devices, likely based on this prior work by ARM.
Firmware Modules is evaluating these systems and will continue to make improvements to its leading IoT firmware deployment system in the IoT Firmware Core product line. Firmware Modules' IoT firmware deployment system embeds a stream of tokens in the firmware update image that allows for on-board regeneration of relocatable firmware images so that an external flash part is not required for robust dual-section application updates. In other words, the firmware is put down in flash where it will be executed, all without disturbing a running, good firmware image. No verified image transfer from one flash area to another is required by a bootloader, greatly simplifying the bootloader design and entirely eliminating the risky act of erasing known good firmware.
]]>
Components 2 & 4 are provided by the FM_Deploy Module in our IoT Firmware Core product and is ready to go to work with a variety of application-specific schemes.
Component 1 (the server) is customer and application-specific.
Component 3 (the client-server communication protocol) is dependent on the customer's choice of component 1.
The IoT Firmware Core can support various client-server communication protocols to move firmware from cloud to device. For example:
All of these protocols can be implemented with their own (secure) authentication schemes. For example:
The custom protocol can use client request messages of this form:
// +--------+--------+--------+
// | TOKEN | PID | OFFSET |
// +--------+--------+--------+
// 4 1 4
The Token is a 4 byte secret known only to the devices and the server. When the server receives the request with the correct token, it proceeds to decode the PID and OFFSET. It then finds the correct firmware image according to PID and slices it into a byte array consisting of bytes [OFFSET, size]. It then serves up the firmware image by sending the bytes to the client.
For TCP transports, the server can send the whole byte array to the socket and the transport will take care of getting it all to the client. The client will receive chunks of this firmware image as they are passed along by the TCP stack (chunk size is typically a function of stack buffer or firmware update library constraints - whichever is smaller). The firmware update library on the client built into the IoT Firmware Core is designed to handle these chunks and will place them into the correct location in flash and verify it before it is applied and the device reboots to it.
TLS requires no pre-shared keys to operate. The secure session is setup automatically with an algorithm such that both sides of the link receive a secret encryption/decryption key that is generated for that session only. No one in the middle can find this key. This is the confidentiality portion of TLS and can be used to safely send "cleartext" authentication tokens used in any of the protocols described above.
TLS can additionally offer its own authentication feature, and this is quite important because while the link can be secured, it could be that the server on the other end is not who you think it is, and will then receive your cleartext authentication token and then turn around and use it against you. To prevent this kind of attack, most TLS implementations will also authenticate the server. To do that, the TLS client will receive a certificate from the server signed by some recognized authority (could be a regular CA - certificate authority, could be your own private certificate provider). It will then check the signature against a LOCAL COPY of the CA's certificate stored on the device. You must pre-load such server-authentication certificates onto all devices. For example, a common CA is VeriSign. You would then download VeriSign's public certificate from their website, convert it to DER form (a binary X.509 form popular with embedded TLS stacks), then flash it onto the device (or embed it in the firmware image). If the server's certificate was also signed by VeriSign, then your device will only connect to servers that are who they are ACCORDING TO VERISIGN (whom you trust). You can also spin your own certificate-based security system if you can manage the certificates you generate properly (you are your own CA).
The IoT Firmware Core implements a robust, secure firmware update client library and a build-time firmware update binary generation system that works with the client library. The IoT Firmware Core is a complete firmware system in-a-box, and with a single command-line fm release, your application is built, linked and all manufacturing and deployment products are automatically generated: the combined firmware image with bootloader and application(s), and the secure firmware update binary.
Happy updating!
]]>