In last weeks blog we covered a couple more LPWAN protocols. To read any other blog in our IoT Series click here.
This week we discuss how to choose the right technology, amongst the LPWAN options available in NZ and the privacy implications of IoT devices.
In summary, the ‘IoT Network’ operates in a spectrum, within the Radio Spectrum, which is also a part of a larger spectrum called the Electromagnetic Spectrum. This is described in detail in our earlier blog, A Lesson in Connectivity. The five IoT technologies we discussed in earlier blogs use different bands of the spectrum.
The higher the frequency band, the lower the range, but the size of data that you can send goes up. Bigger amounts of data result in devices that need more energy, so they suffer worse battery life. These are generalizations and are also hardware dependent.
Most asset tracking solutions, that would need GPS functionality along with 2-way communication are most suited to LoRa-WAN and or NB-IoT. Both these networks are capable of supporting devices with several months of battery life and the ability to send information in the kilobytes which is satisfactory for most uses that do not require audio or video data to be sent.
Every IoT solution requires a combination of connectivity, hardware, and software to achieve its goal.
PRIVACY AND ENCRYPTION
A feature of IoT is the amount of personal information that can be collected and shared as big data, often anonymized. While the different IoT network options are a consideration, privacy starts with hardware that is secure. The networks only facilitate the movement of information. They are simply the highway the information travels on. It is the entrances and exits that need to be locked down. From the hardware the information is being collected on, to the destination system it is being processed on.
IoT devices physically can be quite plain and barebones. The hardware generally needs to be cheap and effective for a single purpose. It is common for manufacturers to use cheap components that are very widely available and exploitable due to their lack of sophistication. In many cases, this is also justifiable since when every customer is buying dozens or hundreds of your product, the cost per unit metrics can make or break the sale.
The on-board storage unit of these devices needs to be encryptable so only the right parties can access information. While there are more than a dozen types of hardware encryption, the details around each type are out of scope of this blog. The evaluation of a hardware device needs to start with – is the hardware encrypted? I.e. can a bad actor remove the device from its location and plug it into a computer to access its on-board storage? Any type of hardware codex that requires a user to authenticate themselves before accessing on-board storage would be a reasonable security measure.
Fortunately, this is generally too cumbersome to ever be a viable threat. The perpetrator would have to steel dozens if not hundreds of physical sensors and manually pull information of each, which is generally very simple information like travel coordinates or temperature for a short duration of time.
All this manually gained information with then will have to be processed to be insightful in the slightest which will be a monumental task.
A much more useful way for a bad actor to breach your systems would be through software. Software has a big vulnerability; it is only as secure as users make it. Using strong and unique passwords can make software exponentially harder to crack. Using two-factor authentication that involves two unique devices to confirm a user’s identity makes systems virtually unhackable.
The structure of how a program is built also can tell us about how secure it is. Luckily IoT information processing applications haven’t been around too long so in the majority of cases are built with more secure programming languages. The security profile of programming languages like Ruby and C++ for example are leagues ahead of its predecessors like C that has been around since 1972. Ruby is over 20 years newer, being released in 1995. In broad strokes, newer programming languages, or better supported programming languages are more secure.
Another thing to note is that everything is 'unhackable' until it is. It is impossible to know what application or technology could have a huge exploitable hole tomorrow. All we can do as providers or users of such devices and services, is make educated decisions, use trusted partners with a safe and vettable history. In most cases it is also important to know that developers are still providing safety patches and upgrading applications after deployment. There are examples of many applications that developers have stopped updating or issuing security patches for since they are old or just not a financially viable use of their time that end up being hacked and costing businesses.
It is important any application we invest in, we understand the lifecycle the developer is ready to commit to, to keep the application running and secure for. Aligning on this idea can be expensive but the alternative, ending up with an application that the developers do not want to support after deploying can be much more expensive. This is essential since a lot of IoT applications are bespoke and require customization.
Next week we look at the importance of software implications IoT solution.
Quadrent provides hassle free technology leasing to help companies achieve their most ambitious goals, whether that be supercharging their current workflows with an IoT infrastructure or empowering staff with . We’d love to have a chat about technology goals. Reach out to Arnold here.
You can read the other blogs within the IOT series here.