Building with Security First on the SmartThings Platform
SmartThings Developers
One of Samsung’s missions is to keep the integrity of developers’ work secure. The SmartThings platform allows developers to work on a secure and trustful platform. As I discussed during my presentation at SDC, there are a few essential guidelines developers should follow at the blueprint stage of designing and building the framework for their devices.
Identifying the Device
For optimal security, developers should uniquely identify the device during the blueprint stage. Developers can use an X.509 certificate, which provides a device UUID, or ED25519 public key, which provides validation signatures and serial numbers.
Depending on your use case, different security levels can apply to devices. A low level of security would apply to a temperature sensor, a medium level of security to a light control, and a high level of security to a video camera. Regardless of security level, a device requires identification.
Requirements for the Device Security Levels
The level of security developers want their devices to have should be decided when initially designing the framework of the device. This is because the hardware of the device will contain the level of security chosen, thus implementing security from the start. L1 Security validates integrity of the executables and allows updates while checking signatures of the updates. L2 and L3 use the hardware Root-of-Trust to validate executables as well as validate updates.
Devices must allow for secure updates. IoT devices that fall short of secure updates lose their integrity and security, thus making them vulnerable to attackers.
User Interface Considerations
Two-factor authentication is necessary for devices with voice activation. While some devices are able to recognize voices of authorized users, there is always a chance that anonymous voices will be able to activate commands.
Developers must decide if the device UI should be private or public. Consider the intended use case of the device. If the device is mobile, consider the event that the device is left in a public place (such as a coffee shop).In the worst-case scenario, anyone would be able to locate the owner's home and unlock the front door with the device UI.
How long should a UI be displayed on a screen? In another scenario, if your alarm UI is permanently displayed on your television and a passerby sees that the alarm is off, your house then becomes an enticing target.
SmartThings and the of Principle of Least Privilege (PoLP)
This is where the oxymoron “less is more” applies. Developers should ask for access to the fewest actions as possible to accomplish the end product’s goal. With a home security system, for example, separate access to arm the system from access to disarm the security system. Applying PoLP to your devices and integrations bolsters security for the end-user.
Understanding SmartThings Scopes
SmartThings capabilities include attributes (which indicate device status and parameters) and commands (which act on the device).When building integrations, you set authorization scopes that determine access to read and execute commands, as well as write and change parameters on the device; or the Developer can make it very specific that the users are only granting limited access. See Authorization and permissions to see the possible scopes.
As a general rule, request the fewest permissions possible when designing an integration. Again, remember that “less is more.”
Sign up now now to learn how SmartThings can help you achieve your IoT vision.
