Security in IoT, being already a hot topic, will continue to be a focal point as IoT solutions around us continue to emerge and scale. As more IoT devices get connected to various solutions and more IoT systems get linked at the back-end using APIs, security is becoming an increasingly important consideration for any company working on implementing an IoT project.
This article will detail the key security elements and mechanisms of flespi that exist today. As we evolve, we’ll continually update this information to reflect the current state and hopefully instill confidence in the high level of security we offer to our customers.
Given that flespi is a middleware/back-end and typically ties an IoT device with the application end-point, we will separately look at security mechanisms between devices and flespi and flespi and downstream applications. We’ll also specifically cover flespi tokens and subaccounts capability.
Device to flespi security
Flespi has the ability to work with devices that encrypt transmitted data using TLS. Generic HTTP and MQTT channels already support connections over TLS. As device manufacturers roll out support for TLS in device firmware, we continuously accommodate on the flespi side. The most recent version TLS 1.3 is supported and recommended to use. However, if certain legacy IoT/telematics devices require older TLS versions, those can likely be accоmmodated.
Every flespi channel (end-point for incoming device connections) has a unique hostname and port pair. Such hostname and port pairs never overlap between flespi users. Using hostname as opposed to IP address allows our engineering team to protect service from DDoS attacks by swapping out targeted IPs during such attacks.
Additionally, flespi users may white list device source IP addresses in the channel to restrict its usage from the specific location of the Internet.
Flespi to downstream application security
Data consumption from flespi into downstream applications is implemented using three different methods — pull-based REST API, push-based streams (generic and platform-specific), and MQTT API. All these methods support standard security options:
REST API works only via HTTPS protocol
MQTT API may work via a secure connection (preferred way) as well as via a non-secure connection (non-recommended way). We do not force TLS-only usage and it is up to the MQTT client whether to enable encryption or not.
Generic streams (HTTP and MQTT) work well over TLS if the recipient side supports the corresponding connection format. Platform-specific options such as client certificates or private keys are supported too.
Flespi tokens
All REST API requests and all MQTT connections have to be authorized by a 64-byte flespi security token. More specifically:
Each REST API call must contain a flespi token in the header.
MQTT connection can only be established by providing a token in the user name. Note: There is a workaround for MQTT devices with limited memory capabilities: they may use token ID value as user name and shortened token version (first 16 characters) as password. This works only for ACL tokens.
Tokens allow for very flexible and granular access rights management to design secure access protocols and procedures. There are three types of tokens:
Master. Gives read and write access rights to all flespi entities within the account or subaccount it’s generated for. Master token also allows users to log into the flespi.io panel and perform actions via the flespi.io interface. No other token type allows the user to log into the flespi.io panel.
Standard. Gives access to all the flespi objects except other tokens and subaccounts.
ACL. Allows to very granularly define what system entities can be read, modified, written into. For example, you can create a token that is only authorized to connect to flespi MQTT broker and only subscribe to a very particular topic. We encourage our users to take full advantage of such flexibility and only issue tokens specific to the actions expected to be performed.
If you want to restrict web access for your token to the set of specific websites all you have to do is just mention specific websites as HTTP origins (e.g. https://your-webside.domain) as allowed origins for this token. Any attempt to perform a request from disallowed origin will be blocked. Note: this option relates only to the request originated from the web browsers.
You may also specify a list of allowed IP addresses and/or IP address wildcard masks. All attempts to use a token from a non-specified address are then forbidden.
Subaccounts
Subaccounts come in handy when it is necessary to separate different projects/departments, segment customers, or define a task-specific namespace.
Every subaccount may be assigned its own limits: API usage limits, maximum traffic throughput, number of allowed channels, devices, streams, etc. It’s especially important if your sub-accounts are controlled by your customers, whom you don’t closely monitor. Such limits protect your other projects/customers and your root account from getting blocked and your monthly billing from being excessive.
***
We hope this provides you with a good understanding of various security aspects of flespi. Should you have questions on anything that hasn’t been covered here or need clarifications, feel free to reach out to us via flespi chat in your flespi.io panel or by emailing us at info@flespi.com.