The usual attack on Sigfox network is related to the “security”. Behind this large concept, for real, the only point is related to the use of clear payload over the air. As a consequence some are extending this to the possible replay after 2048 frames so regarding a standard use of Sigfox is will be about 6 month later…
That said, for real, all of this is just ignorance from these pseudo “security” experts and developer laziness. Don’t beat me for saying that, I’m part of the lazy developer, the only difference is I’m not complaining and I’m aware the solution is in my own hands.
Because, for real, the payload encryption exists as documented in the post I’ve published on May 2017 and detailed on the Feb 2017 technical security paper published by Sigfox or like in this document.
So saying the Sigfox is not proposing payload encryption is wrong and this option is also fixing any 6 months later message replay. It’s like saying WiFi is not secured because you can create an open-network.
So now, let’s see why encryption is not the default option, why a network encryption standard is not the best option and then see how to stop to be a lazy developer and make encryption working.
When you write an IoT firmware, there are different things you may never forget to think about… The coming 10 things you can’t ignore are coming from my experience of smart object creation and the associated field experience.
The field experience is unfortunately the real step where you will improve your firmware and discover all you have forgotten when you have written the firmware and tested it in your laboratory. In laboratory everything is perfect.
The following 10 things you can’t ignore when writing a Firmware is a non exhaustive checklist of points to verify before pushing your code to the field. It is also a list of test conditions you can execute to validate a Firmware / device made by a third party.
STM32 solution for using Sigfox is actually one of the best offer on the market has the solution is powerful, low consumption and allows global coverage with the use of the last Sigfox library versions including Monarq, Bubble… Different module providers are actually designing solutions based on this platform.
In this post we are going to see how to configure the STM32 platform, starting from a STM32L053 devkit plus a S2LP extension. Using a eclipse/gcc environment. The environment installation is described in this post about installing Eclipse for STM32.
For the second year I had the chance to introduce the IoT and LPWAN networks to a group of 150 students in computer engineering school. This year we add a longer time to detail a bit the Sigfox and LoRaWan solution and I’ve added a part on the IoT security.
I’ve tried to propose a different point of view on security aspect, not based on fear but practical things to do and a larger contextual aspect. I’ll try to make video on this specific topic on my Youtube (where you can find in french most of the content of these slides).
So … here are the slides, for my students who joined or not the conferences, and for those who would like to join this course.
In a previous post, I was complaining a bit about the Sigfox API. At this time Sigfox was already working on a new version of the APIs.
Today Sigfox released the API version 2 for managing devices, subscriptions, messages… And this new version based on REST and JSON standards is a really positive rupture compared to the previous one.
More than a new version of the API set it’s also the full deployment of some of the new backend components now accessible by the API deployment. As part of this the 2018 deployed new Group entity, the asynchronous device creation/edition processing and the coming replacement of the callback duplicates to the equivalent with API.
As part of this APIs also some coming features like different level of geolocation precision, payload encryption and many more…
Posted in Sigfox
Tagged API, SigFox
This was the more expected announcement for Sigfox Connect event: the availability of the micro-gateway: a Sigfox gateway you can buy, own and deploy on your own location.
This was expected to be introduce has it has already been disclosed once FCC certification made it public as it has been noticed by Nestor Ayuso on twitter some days ago.
This model is standard for LoRaWan ecosystem running on private network as on public network. For Sigfox it has always been possible to expend the network but it was a little bit complex because you had to rent the basestation from Sigfox and the basestation itself was an operator equipment: something made for being installed on a roof, not in your office.
Sigfox is now proposing the micro-gateway !
As part of the R&D announcement during Sigfox Connect 2018 a passive Sigfox tag has been introduced. I’ve seen the demo made by Christophe Fourtet and the technology is really promising.
Basically a passive tag is a tag with no battery. The one actually seen it really near to be a passive tag. This tag is receiving power from a radio signal and with this power respond with a radio message. In the Sigfox context this radio message is a Sigfox message. What is really strong with this technology is the low level of power to be provided to get it working. I’ve seen it working with less than a watt and a distance larger than 10 meters with not any radio optimization on the prototypes. The radio message, thanks to the Sigfox communication technology can reach a distant basestation getting benefit of the large Sigfox radio range. The use in conjunction of a micro-gateway sounds a good idea. The global solution looks to be a low cost and easy to deploy solution for asset management & tracking.
Posted in Sigfox
Tagged rfid, SigFox
As a coming soon produit, widely available as an open design, Sigfox has introduce during the Sigfox Connect conference the Bubbles: They are basically a Sigfox Beacon.
Working on the technological basis of the Monarch technology the bubble allows a device to identify the zone where it is. This is basically a kind of solution existing on bluetooth, LoRa but Sigfox was not positioned on it. This is now fixed with the Sigfox Bubble technology.
Compared to bluetooth the Sigfox solution is offering a large range of operations: thanks to the long range communication capability, you can imagine to cover a zone like a complete building or a parking as a single cell ; this is for future as the current technical offering is covering 10 meters max. Like on bluetooth you can manage the beacon power to reduce the cell (bubble) size to 1 or 2 meters and get your device position on this range. On top of this with no technology addition, you get access to the Atlas service locating your device on public area with the usual 1km precision.
The main difference with other technologies comes with the service proposal. Bubble is not just a technology ! Following the Sigfox business model, Bubble is a manage service: you have your bubble devices managed by Sigfox, you are able to share positions with business partner across the bubble global network and you get benefits of the public Bubble network operating on different point of interest.
This service is where the disruption starts !