Skip to main content

Security Requirements for Direct Connected Devices

Introduction​

Direct Connected Devices are diverse - ranging from small sensors to a high-end device that can interact with end-user. As a consequence, security is a major concern in the deployment and management. This document aims to establish the security guidelines for the IoT devices connecting to the SmartThings cloud with the goal to protect the cloud services and the end users. OEMs for Direct Connected Devices must implement the necessary security functions in order to complete Works with SmartThings Certification.

We define three levels of security requirements to provide a wide spectrum of data sensitivity (e.g. indoor video camera, presence sensors, level of dimness etc.) and breach impact (e.g. unable to view live video feed, getting locked out of home, fake motion events etc.) these devices create. A higher security level inherits all requirements from lower levels.

Security LevelL1 (Low level)L2 (Medium level)L3 (High level)
Data SensitivityLow sensitive data.Moderately sensitive data.Highly sensitive data or regulated data. For example, PII, financial data, video feed, Lock/unlock state.
DescriptionLow impact environments and do not involve storage, processing or transmission of any sensitive, Personally Identifiable Information (PII), or regulated data.No security focused functions, health care, or other regulated environments but may deal with moderately sensitive information.Highly sensitive information; or operate in security focused functions, health care, or other regulated environments. For regulated environments, each device must be in compliance with each regulation and the requirements described in this documentation must be superseded by each regulation.

1. Hardware Root-of-Trust​

Requirement 1-1 (Secure Boot): The first bootloader to get executed by the processor on power-on must be implemented on ROM and the provision of the secure boot parameters must be implemented in hardware during the manufacturing process. (L2, L3)

2. Trust Chain​

  • Requirement 2-1 (Trust CA – L3): Each device must be equipped with an X.509 certificate issued by Samsung IoT Device CA or third-party CA accredited by Samsung. (L3) - Requirement 2-1-1: The third-party CA must submit an audit result when its CA certificate is initially registered to the cloud. (L3)
  • Requirement 2-2 (Trust CA – L1/L2): Each device must be equipped with an X.509 certificate issued by the third-party CA that meets the following requirements. (L1, L2)
    • Requirement 2-2-1: The third-party CA must issue certificates for end-entities only, and must not issue certificates for CAs. (L1, L2)
    • Requirement 2-2-2 (CA Operation): The operation of the third-party CA must be conducted in a secure manner to be compliant with the industry standard. (L1, L2)
    • Requirement 2-2-3 (CA Operation): If device key pair is generated outside device (injection), an archival backup of private key pair must only be maintained in encrypted form. (L1, L2)
    • Requirement 2-2-4 (Certificate Issuance): The third-party CA certificates must be globally uniquely identified independently based on its subject names and certificate serial number. (L1, L2)
    • Requirement 2-2-5 (Certificate Issuance): The certificate subject names issued by the third-party CA must be unique. Device certificates must include a unique device identifier in the CN field as part of the subject name, and must also have unique <certificate serial number, issuer name> pairs. (L1, L2)
    • Requirement 2-2-6 (Revocation List): The third-party CA must provide a way to check the validity of each certificate for known compromised devices either through a certificate revocation list (or CRL) or OCSP. (L1, L2)

3. Device Integrity Protection and Detection​

  • Requirement 3-1 (Secure Boot): Each device must provide secure boot to validate the integrity of the security critical executables and stop the boot process if any integrity of security critical executables is compromised. The hardware Root-of-Trust must be based for validation of the integrity. (L2, L3)
  • Requirement 3-2 (Integrity Validation – L1): Each device must provide the integrity validation mechanism to validate the integrity of the security critical executables. The key used for validating the integrity must be pinned at the least to the validating software module. (L1)
  • Requirement 3-3 (Secure Update): Each device must be able to update its firmware; and the hardware Root-of-Trust must be based for validation of the integrity and authenticity of signed updates. (L2, L3)
  • Requirement 3-4 (Secure Update – L1): Each device must be able to update its firmware; and the key used to validate the integrity and authenticity of signed updates must be pinned at the least to the validating software module. (L1)

4. Protected Communication​

  • Requirement 4-1 (Protected Communication): All transmitted data between each device and the SmartThings cloud must be protected. (L1, L2, L3)

5. Protected Storage​

  • Requirement 5-1 (Secure Storage): Each device must provide secure storage to guarantee the confidentiality and integrity of data from any unauthorized access. (L1, L2, L3)
  • Requirement 5-2 (HW Protection): Secure storage of sensitive data must be hardware backed and all cryptographic keys must be stored encrypted in hardware backed secure storage. (L3)
  • Requirement 5-3 (SW Protection): Secure storage of sensitive data must be protected at the least in software; and all cryptographic keys must be stored encrypted in a secure storage. (L1, L2)

6. Authentication​

  • Requirement 6-1 (Device Identity): Each device must be identified uniquely. (L1, L2, L3)
  • Requirement 6-2 (Mutual Authentication): Each device must provide certificate-based mutual authentication with SmartThings cloud. (L1, L2, L3)

7. Protected Local Ports​

  • Requirement 7-1 (Protected Local Ports): Device’s local ports (for example, I/O and debug ports including USB, serial, JTAG etc.) must be disabled or protected from unauthorized use. When a port is used for field diagnostics, the port input must be deactivated and the output must not provide any sensitive information (for example, WIFI password/keys, tokens) which could compromise the device. (L1, L2, L3)