Security & Privacy
We made every effort to ensure every detail of the security design aligns with our mission, independence, freedom, and privacy for end-users!
Security Highlights
- User, group, and object access control list
- End-to-end encrypted communication to Libertas Hub
- Encourage direct connection through router port-forwarding
- Zero information leak
Libertas-thing Types
Internet of Things include everything connected, including the users.
Libertas system manages things. The types of “things” managed by Libertas system are called “Libertas-things”. Libertas-OS defines five different types of things:
- Physical Device
- Logical Device, Note a physical device may contain many logical devices, such as a multiple-button dimmer switch
- Thing-App
- Thing-App Task
- User
Libertas-OS Security Model
The Libertas-OS security model is custom-designed for IoT applications.
Our security model centers around two aspects:
Users and Groups
Each user or group has a unique ID (UserID).
The diagram below shows the relationship between the following entities:
- User
- User Group
- Password Hash
- Mobile Client
- Object Access Control List (ACL)
Note this is a very clean design, which fits best for IoT applications.
A group contains members. A group member may be a regular user or another group. So, a group could be nested.
Mobile Client
A user may have many mobile clients, such as smartphones and tablets. Each mobile client is bound to a unique device with a unique device ID. In addition, each mobile client has a unique access key. If a device is lost, the administrator can remove that particular device from the system. That device will no longer have access, but the user account and other clients are safe.
Thing Access Control
Access Control List
The access control defines the access flags a user (or user group) to an object
Read - For devices, get status
- For other Libertas-things, know the existence
Control - 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
End-users can assign Object Access to groups. Once a group is assigned to have certain access rights to an object, all members, including members of nested groups, automatically has the same access.
If a user belongs to more than one group with different access control to a thing, 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 anything.
Users may be assigned specific permission to add devices, apps, tasks, scenes, or users.
Account Enabled Flag
The user cannot log into the system if this flag is unchecked. Note this flag is logical “and” across all groups. In other words, 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. The “Account Enabled” flag is more stringent than other flags.
Thing-App Access Control Model
In Libertas Thing-App, the system can enforce access control implicitly or explicitly.
Object Security Model (Implicit)
Libertas Thing-App code can access different types of Libertas-things, 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
- Users
The Object Security Model is implicit; when an end-user adds an object to the Thing-App Task, the system will automatically check if the end-user has enough access permissions to operate. In addition, thing-App may restrict access to Libertas-things (e.g., read/write).
However, if the Thing-App Task tries to access any device that is not in the task config data, the Thing-App will be automatically terminated and flagged with the “Error” state.
This implicit security model protects users against unauthorized access to devices.
For example, in the Task below, since the user specifies one device (“Outdoor”), the Task can only control that device. Accessing any other devices from the Task will raise an error, resulting in Task termination and being marked disabled.
Libertas Thing-App Network Security Model (Explicit)
Any connection to destinations outside the local network is subject to a “white-list check.”
The developer must declare the hostname of every possible external connection explicitly and explain in detail, for each host, what kind of data will be sent to the host and exactly how the data will be used. Such Apps are subject to scrutiny and approval by the Thing-App store before being included.
The explicit model is declared in the form of security-related attributes.
When the user creates Thing-App Tasks, the “explicit declarations” will be promoted to the user for approval. Users will then have a chance to disapprove of the external connection and abort Task creation.
Password Security
Passwordless Design
It is perfectly OK for a user to securely use Libertas Things without a password!
Libertas Things is designed in a way that it can operate without requiring any password from users. As a result, only very few occasions are a password required.
- The administrator must give a password when the Hub is set up. The password can be used for later recovery.
- If a developer wants to publish their Thing-App to the Libertas Thing-App Store, a developer account needs to be registered with a password.
- Users may optionally register their name to the Libertas Network to recover their Libertas Hub accounts outside the Libertas network.
All passwords are heavily encrypted with Argon2 Algorithm.
Network Security
Hornet Devices
Hornet Mesh Network requires mandatory end-to-end encryption between any pair of bound devices.
Each pair of bound devices shall negotiate a unique “application link key.” This concept was defined in Zigbee but has never been properly implemented in any existing wireless protocol.
A multicast “group address” shall also share a unique application link key.
Automatic Link Key Management
If a new Thing-App Task introduces a new interconnection between a pair of devices, the system performs an automatic link key negotiation.
Once the Thing-App Task is removed and the pair of devices no longer need to interconnect, the link key will be automatically removed.
Libertas Hub
End-to-End Encryption
Network security in Libertas Things is the security of remote access through mobile client devices (smartphones).
Mobile clients and Libertas Hub communication is always end-to-end encrypted.
Connecting From Outside
There are three ways the Libertas Hub can be exposed to the outside world:
- Through Libertas Bridge Secure Network - We manage the bridge, and users don’t have to do anything.
- By Port Forwarding - Users may set up “port forwarding” on their home broadband routers.
- Using Static IP - A user may use a static IP for their home. However, the user must still expose a port on their router/firewall.
For more information about smartphone setup, please read “Hub Connection Settings”.
Hub Key Exchange
Through TLS (Local Network Only)
This method is only used in the following scenarios:
- Initial Hub setup
- Admin key recovery (if the admin lost their phone and needs to recover the account on a new phone)
Remote Key Distribution
Admin may create a new account for a user’s new mobile client.
The initial account key is a text blob that needs to be sent over a secure channel (secure chat, etc.).
The user needs to add the new key to the Libertas Smartphone App.
The first time the new key is used, the phone client will renegotiate a new set of keys with the Hub through the X25519 key exchange. After that, the old key will no longer be valid.
Please Note:
- Communication is still fully protected, even for Libertas Bridge. The information is still end-to-end encrypted. To achieve that, every mobile client has two encryption keys. In addition, each mobile client has a unique private encryption key with the Hub. The bridge only performs information delivery and won’t understand the content.
- In “Port Forwarding,” the client needs to get the dynamic IP of the Libertas Hub. The bridge network works as a dynamic DNS server, only more securely. The IP is returned to the client if and only if the client passes authentication. Still, a client encryption key is used for authentication purposes.
- Even if in “Static IP” mode, the Libertas Hub still needs to communicate occasionally 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 must be sent through our network (which Apple requires). 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 designed 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 Smartonlabs’ side. The services can be easily restored by renegotiating the security key, and infrastructure is secured again.
Managing Hub Security
For more information, please refer to “Smartphone User Manual”.