Application Security Requirements for IoT Devices

Overview

This document presents a set of guidelines and requirements for Internet of Things (IoT) devices intended for deployment or use at Google. These requirements are a collection of the best practices as of the time of writing, and meeting these requirements is not a guarantee of passing a security assessment.

The requirements are currently broken down into 3 categories:

  • Requirements are basic security practices that all devices and services to be deployed must meet, and failing to meet them will require a manual review of any compensating controls and an exception.
  • Recommendations may be required for high-sensitivity devices and are encouraged for all deployments.
  • Guidelines are general practices to improve the security of devices and services.

As the IoT industry matures and the security landscape evolves, it is expected that more recommendations and guidelines will become requirements.

Exceptions may be granted to particular requirements if it can be demonstrated that an exception is either necessary to achieve the business goals associated with the project, or that adequate compensating controls exist.

Contents

Scope

This covers all embedded and “internet of things” devices to be deployed on the Google network or within Google offices or datacenters. These devices are single-purpose embedded computers with networking capabilities. Examples of such devices include:

  • IP Cameras
  • Lighting Controls
  • Occupancy Sensors
  • Door/Access Controllers
  • IoT Gateways

Definitions

Client

Any software making outgoing network connections.

Device

Any physically field-deployed piece of IoT hardware.

Server

Any software accepting incoming connections, including software that may accept incoming connections as part of the software stack running on an individual device.

Service

Any software application stack running as a part of the IoT deployment, including software deployed on devices, or software deployed in a datacenter environment as part of the management or control plane for the deployed devices.

WiFi

The collection of wireless protocols defined by IEEE 802.11 and subsections.

Wireless

Any interface or connectivity allowing communication without the use of a physical connection.  This includes 802.11 WiFi, but also 802.15.4-related protocols (Zigbee, ZWave, Weave, etc.), 900 MHz ISM communications, and any other radio-based communications that may be in use on a device.

Requirements

Best Secure Coding Practices Should be Followed

Developers must take steps to ensure that devices and services do not contain vulnerabilities in the implementation.  For example, steps should be taken to avoid memory corruption vulnerabilities such as buffer overflows and integer overflow/underflow. The OWASP top 10 should be avoided in web applications (please also see Google’s requirements for partner-developed web applications for general guidance), and other secure coding best practices should be followed.

Use of TLS for all Network Communications

All communications on a networking stack with a medium that is shared with other device not part of this deployment (e.g., Ethernet, WiFi) must use at least TLS 1.0, and should use at least TLS 1.2.  All ciphers to be used must provide at least 128 bits of effective strength.  RC4 and DES may not be used.  Clients must verify certificates on connection.  Clients and servers should be able to accept the use of a public certificate authority (CA), a private CA, or a deployment-specific CA.  If devices or services require a console interface, SSHv2 may be used instead of TLS to protect the communications channel.  RSA keys and DH groups must be at least 2048 bits in size.

Verified Firmware Updates

All firmware updates must be cryptographically signed, and devices must verify the signature on update.  The signature must be performed using asymmetric cryptography and the private key must not be present on any device.

Scalable Process for Firmware Updates

All firmware updates must be deployable on a large scale.  In particular, there must not be any step requiring per-device manual intervention.  Firmware update processes should allow applying a firmware to a subset of devices to allow a staged rollout as well as support the ability to rollback if an issue is found.

Strong Authentication Mechanisms

All access to configuration settings, firmware updates and sensitive data in any device or service must be protected by strong authentication.  Examples of strong authentication include usernames and passwords transmitted over TLS (provided that passwords must be properly hashed using a technique such as scrypt, bcrypt, or Argon2), client certificate validation, or challenge-response authentication mechanisms.

Unique MAC Addresses

At all times that a device is present on a wired ethernet or WiFi network (IEEE 802.3 and 802.11), it must use a unique MAC address, and that MAC address must be stable across reboots and configuration changes.  MAC addresses must comply with all IEEE 802 standards for EUI-48 addressing.

No Communication With third-party Servers

Devices and services must not communicate with any third-party server outside of the Google network, except for explicitly approved connections.  Core network services (DHCP, DNS, NTP, etc.) can be expected to be provided within the network, and application-specific communications should take place between devices and services hosted within the Google network.  Required connections must meet all other requirements.

No Hardcoded Credentials

Devices and services must not have hardcoded credentials (“backdoors”).  Any process for a factory reset or lost password on a device must include a physical presence test, such as pressing a button or connecting a jumper.  All credentials that allow access to the device must be documented and must be user configurable.

Unique & Replaceable Certificates

Any cryptographic credential used to represent the identity of the device or service (whether as a TLS certificate for a server or a client credential for authentication) must use a unique private key and certificate, and this private key and certificate must be replaceable in the event of expiration, compromise, or other business need.  Devices and services should allow the use of an arbitrary CA for signing these certificates.  (Note that this does not apply to certificates never presented outside of the device, such as those used for verification of a firmware update or a verified boot process.)

Commitment to Security Updates

Vendors providing devices and services for use in IoT deployments must make a commitment to release security updates in a timely fashion.  Updates should come as soon as practical, but a commitment to security updates should include a deadline of 30 days.  Security issues must not be outstanding longer than 90 days.  Any issues discovered by Google must be subject to our disclosure policy which calls for public disclosure of an issue no later than 90 days after it is reported to the vendor.  This commitment should have a lifetime that is reasonable for the expected installation duration of the device.

Minimum Service Exposure

Any service not required for the proper functioning of the device or service must not be exposed on a network interface.  In particular, unnecessary exposure of services like telnet, ftp, or database servers must be avoided.  Exposed services must not have undocumented extra functionality that may pose a security risk.

WiFi Must Use WPA2

Any WiFi connections must support the use of WPA2.  WPA2-PSK must be supported, and WPA2-EAP should be supported.  Implementations must be compliant with IEEE 802.11i.  There must not be any device-imposed limitations on the supported cipher suites, passphrase lengths, or other security features of the implementation.

Bluetooth Security

Devices supporting Bluetooth must support Bluetooth 4.0 or higher.  Bluetooth interfaces providing a PAN profile or access to configuration interfaces must provide a secure pairing mechanism.

Sync Clocks with NTP

All device clocks must be synced to a Network Time Protocol (NTP) server.  This ensures proper certificate validation for TLS, proper log timestamps for events occurring on the device, and results in lower administrative overhead.  NTP servers must be obtained via DHCP options or user-configurable hostname.  The NTP implementation should be compliant with IETF RFC 5905.

No External Network Connectivity

Devices and services must not provide network connectivity that would bypass network firewalls.  This includes, but is not limited to, cellular network connectivity, VPN connections to third-party endpoints, or other techniques for tunneling communications.

Use of Non-WiFi Wireless Interfaces

Many IoT devices make use of Non-WiFi wireless interfaces in the 900 MHz or 2.4 GHz ISM bands, including technologies like 802.15.4.  Such interfaces must not directly route traffic between the non-WiFi interface and a WiFi or wired ethernet interface.  Any traffic should be proxied through an application-layer proxy to minimize the risk of maliciously crafted packets on the shared network.  These interfaces must take reasonable steps to provide confidentiality and integrity of communications.  These interfaces must also use the minimum amount of power necessary for the task ahead to minimize the range of wireless signals, such as making options available to tune power for the particular installation. Options to disable specific interfaces should be present.

Identification and Delivery of Open Source Components

Any open-source software components must be identified with the name of the project, license, and version being used.  Any components with a copyleft license (e.g., GPL) must have source included at the time of delivery.

Graceful Degradation

In the event of a lack of network connectivity or other communications failure, the device must degrade into a reasonable state that maintains security.  The device must not fall back to unencrypted or unauthenticated communications, but should function locally in a manner appropriate for the type of device.

Test Resilience

All devices must be able to handle network traffic conditions that are artificially generated for testing, such as security tests and authentication retries.  This includes arbitrary network traffic, including that which leaves hung connections or sends unexpected traffic.  Should said traffic exceed the capacity of the tested device, the device should gracefully degrade its functionalities and automatically resume normal operation when the traffic is back to normal.

Recommendations

Provide Facilities for Remote Logging

Devices should provide support for remotely logging events.  In particular, all configuration changes, session authentication events, and any security alerts should be logged.  This logging should be provided in syslog format in compliance with IETF RFC 5424.

IEEE 802.1x Support with Certificates

Devices should support IEEE 802.1x authentication for wired and WiFi networking.  If present, such support must include both username and password and certificate-based authentication mechanisms.

Certificate-Based Mutual Authentication

TLS connections should be made using certificate-based mutual authentication with proper validation of the certificates.  This provides adequate implementation of both the verification requirement in “Use of TLS for all Network Communications” and authentication as described in “Strong Authentication Mechanisms”.  If this is supported, then replaceable certificates with arbitrary certificate authorities must also be supported.

Perfect Forward Secrecy Support

TLS connections should use a key exchange that guarantees Forward Secrecy, such as ECDHE or DHE key exchanges.

IPv6 Support

Devices should fully support IPv6 as described in IETF RFC 2460 and related RFCs.  Dual stack devices must make it possible to disable either IPv4 or IPv6 as needed.  The set of TCP or UDP ports that is exposed on one stack should be the same as on the other stack.

Honor DHCP/IPv6 RA Options

Numerous DHCP or IPv6 RA options will make device configuration and management easier.  These include DNS and NTP servers, timezone settings, log server, and others.  Where applicable to the device and provided by the DHCP server, devices should honor these fields.

Transparent Patch Management

All devices should provide means to remotely audit their patch status via a well documented protocol. This audit should not disrupt the normal operation of the device. See the Reliability requirement.

Guidelines

IEEE 802.1AR Secure Device Identity

IEEE 802.1AR provides a mechanism for devices to cryptographically assert their identity.  Devices should implement this mechanism for verifying the identity of a remote peer.

Secure/Verified Boot

Devices should support a secure or verified boot process based on public key signatures.  The private keys for such signatures must not be present on any device or service outside the control of the device manufacturer, with the exception of key escrow with a trusted third party.

Manufacturer Usage Descriptions

Device should implement support for manufacturer usage descriptions as described in the IETF draft draft-ietf-opsawg-mud-05 (or subsequent revisions).  It is expected that this will become a requirement once the standard leaves draft state and becomes an RFC.  This mechanism allows devices to describe capabilities in a portable way, allowing for auto-configuration of network policies and more efficient device inventory and management.