Security & Privacy
We made every effort to ensure Liberty-IoT-OS is secure and privacy-preserving.
As a result. Liberty-IoT-OS is designed to be able to operate with zero information leak.
Our security model centers around device and data access.
Libre OS Security Model
The Liberty-IoT-OS security model is custom designed for IoT applications.
Diagram below shows the relationship among the following entities:
- User Group
- Password Hash
- Mobile Client
- Object Access Control List (ACL)
Note this is a very clean design and this design fits best for IoT applications.
Users and Groups
Each user or group has a unique ID (UserID).
A group contains members. Group member may be regular user or another group. So gorup could be nested.
A user may have many mobile clients, such as smartphones, tablets. Each mobile client is bound to a unique device with unique device ID. Each mobile client has a unique access key. If a device is lost, the administrator can simply remove that particular device from the system. That device will no longer have access but the user account and other clients are still safe.
Liberty-IoT-OS defines 5 different types of objects:
- Physical Device
- Logical Device; note a physical device may contain many logical devices, such as a multiple-button dimmer switch
- Application Task
Access Control List
The access control defines the access flags a user (or user group) to an object
- For devices, get status
- For other objects, know the existence
- For devices, control
- For tasks, turn on/off
- For users, send messages
- Remove; user can remove this object from system
- Config; user can manage the object
- For devices, change attributes
- For tasks, edit the task arguments
- For users, change user attributes; for groups, edit the group members
Assigning Object Access to Groups
Object Access can be assigned to groups. Once a group is assigned to have certain access right to an object, all members, including members of nested groups, automatically has the same access.
If a user belongs to more than one groups with different access control to a system object, then the user’s access will be logically “or”ed from all groups.
Note we encourage managing access based on groups. That’s why we designed our security model to support nested groups.
Super User and Special Permissions
A user may be assigned a special “System Admin” flag. A user with that special flag can add, remove and config any system object.
A user may be assigned a specific permission to add devices, apps, tasks, scenes or users.
Account Enabled Flag
If this flag is unchecked, user will not be able to login to the system. Note this flag is logically “and” across all groups. In another word, if a group is disabled, all members (including indirect members through nested sub-groups) will be denied login.
Note: If a user belongs to two groups, and one group is disabled, the user will be disabled, even though another group is not disabled. “Account Enabled” flag is more stringent than other flags.
App Access Control Model
In Libre App, the access control can be enforced implicitly, or explicitly.
Object Security Model (Implicit)
Libre App code can access different types of objects, such as
- Physical devices, e.g. a WIFI/ethernet device, such as a network enabled TV or receiver
- Logical devices, e.g. a load device, a scene, a button on a multi-button switch
Object Security Model is implicit, the access is controlled by the user who creates the task, implicitly.
Each App takes some input data with pre-defined structure by developer.
It is up to the users to specify input data when users creating App Tasks.
If the App requires some devices as part of input, and user chooses some devices when creating tasks, the App Task will be able to access those devices (may subject to additional access control, e.g. Read/Write).
However, if the App Task tries to access any device not in the input data, the App will be automatically terminated and flagged with “Error” state.
This implicit security model protects users against unauthorized access to devices.
For example, in the task below, since user specifies two devices (“Guest Lamp Left” and “Guest Lamp Right”), the Task can control those two devices. If those two devices are only devices user specified for the task, accessing any other devices from the Task will raise an error and result in Task termination and being marked disable.
Libre App Network Security Model (Explicit)
Any connection to destinations outside the local network is subject to “white-list check”.
Developer is required to explicitly declare the host name of every possible external connection, and explain in detail, for each host, what kind of data will be sent to the host and exactly how the data is going to be used. Such Apps are subject to scrutiny and approval by the App store before they can be included.
The explicit model are declared in form of security related attributes.
At the time of user creating App Tasks, the “explicit declarations” will be promoted to user for approval. Users will then have a chance to disapprove the external connection and abort Task creation.
It is perfectly OK for a user to securely use Libre Home without need for a password, ever!
Libre Home is designed in a way that it can operate without requiring any password from users. There are only few occasions that a password is required.
- Administrator is required to give a password at the time the Hub is first set up. The password can be used for later recovery.
- If developer wants to publish their App to the Libre App Store, a developer account needs to be registered with a password.
- User may optionally register their name to the Libre Network so that they can recover their Liberty IoT Hub accounts outside through Libre Home network.
All passwords are heavily encrypted with Argon2 Algorithm, which is considered the best so far.
The network security in Libre Home is the security of remote access through mobile client devices (smartphone).
The communication between mobile clients and Liberty IoT Hub is always end-to-end encrypted.
There are 3 ways the Liberty IoT Hub can be exposed to the outside world:
- Through Libre Home Bridge Secure Network - The bridge is managed by us, user doesn’t have to do anything.
- By Port Forwarding - User has to set up “port forwarding” on their home broadband routers.
- Using Static IP - User has a static IP for his/her home. User still need to expose a port on their router/firewall.
For more information about smartphone setup, please read “Hub Connection Settings”.
- Communication is still fully protected even for Libre Home Bridge. The information is still end-to-end encrypted. In order to achieve that, two encryption keys are used, so that the bridge will not understand the content. Bridge only performs information delivery.
- In “Port Forwarding” the client needs to get the dynamic IP of the Liberty IoT Hub. The bridge network works like a dynamic DNS server, in a more secure way. The IP is returned to client if and only if the client passes authentication. Still, a client encryption key is used for authentication purpose.
- Even if in “Static IP” mode, the Liberty IoT Hub still need to occasionally communicate to our bridge network. The reason is that the Hub may send all kinds of notifications to clients. At least for iOS devices (Apple iPhone and iPad), the notification has to be sent through our network (which is required by Apple). Still, we will use end-to-end encryption to deliver the actual notifications. For more information, read “Messaging & Notification”.
At last, please rest assured, that our security model is design solely for the best interest of users. The user is so protected that even if our network infrastructure is completely compromised and all keys and credentials are stolen, only our service may be affected, i.e. users may not be able to control their home from outside or receive notifications from outside. But the user’s Hubs are still secure. The Hubs won’t be compromised with any information on Libre Home’s side. And the services can be easily restored by renegotiating security key only infrastructure is secured again.
Managing Security from Smartphone Clients
For more information, please refer to “Smartphone User Manual”.