www.ti.

com Table of Contents

Application Report
SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in
Security Features

ABSTRACT
The CC3120/CC3130/CC3135 and CC3220/CC3230/CC3235x devices are part of the SimpleLink™
microcontroller (MCU) platform, which consists of Wi-Fi®, Bluetooth® low energy, Sub-1 GHz and host MCUs.
All share a common, easy-to-use development environment with a single core software development kit (SDK)
and rich tool set. A one-time integration of the SimpleLink platform lets you add any combination of devices from
the portfolio into your design. The ultimate goal of the SimpleLink platform is to achieve 100 percent reuse when
your design requires change. For more information, visit www.ti.com/simplelink.
The SimpleLink MCU portfolio offers a single development environment that delivers flexible hardware, software,
and tool options for customers developing wired and wireless applications. With an ultimate goal of 100 percent
code reuse across host MCUs, Wi-Fi, Bluetooth low energy, Sub-1 GHz devices, and more, choose the MCU or
connectivity standard that fits your design. A one-time investment with the SimpleLink software development kit
(SDK) lets you reuse often, opening the door to create unlimited applications. For more information, visit
www.ti.com/simplelink.

Table of Contents
1 Introduction.............................................................................................................................................................................3
1.1 Terminology........................................................................................................................................................................3
1.2 Internet of Things (IoT) Products and Security.................................................................................................................. 4
1.3 Main Features.................................................................................................................................................................... 6
2 Network Layer Security........................................................................................................................................................10
2.1 Wi-Fi Security...................................................................................................................................................................10
2.2 Secure Socket Layer........................................................................................................................................................ 11
3 File System Security.............................................................................................................................................................18
3.1 Overview.......................................................................................................................................................................... 18
3.2 File System Security Features Description...................................................................................................................... 19
3.3 File Creation Attributes.....................................................................................................................................................23
4 Programming the Device..................................................................................................................................................... 23
4.1 During Development........................................................................................................................................................ 24
4.2 During Production............................................................................................................................................................ 24
5 In-field Software Updates.....................................................................................................................................................25
5.1 File Bundle Protection...................................................................................................................................................... 25
5.2 Secure Content Delivery.................................................................................................................................................. 25
6 Security for Application Layers...........................................................................................................................................28
6.1 Secure Key Storage......................................................................................................................................................... 28
6.2 Hardware Crypto Engines (CC3220/CC3230/CC3235x Devices Only)........................................................................... 28
7 Runtime Binary Protection...................................................................................................................................................30
7.1 CC3220S/CC3230S/CC3235S Devices...........................................................................................................................30
7.2 CC3220SF/CC3230SF/CC3235SF Devices.................................................................................................................... 30
8 Design for Security...............................................................................................................................................................32
8.1 Closing Remarks..............................................................................................................................................................32
Revision History.......................................................................................................................................................................33

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 1
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Trademarks www.ti.com

Trademarks
SimpleLink™, Internet-on-a chip™, Texas Instruments™, and LaunchPad™ are trademarks of Texas Instruments.
Wi-Fi-CERTIFIED™ is a trademark of Wi-Fi Alliance.
Wi-Fi® and Wi-Fi Alliance® are registered trademarks of Wi-Fi Alliance.
Bluetooth® is a registered trademark of Bluetooth SIG.
VeriSign® is a registered trademark of VeriSign, Inc.
GoDaddy® is a registered trademark of GoDaddy Operating Company, LLC.
GeoTrust® is a registered trademark of GeoTrust Inc.
Arm® and Cortex® are registered trademarks of Arm Limited.
All other trademarks are the property of their respective owners.

2 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Introduction

1 Introduction
Internet of Things (IoT) products and systems hold information that may be sensitive and private, thus stressing
the importance of securing the data. This data may include passwords, keys, credentials, configurations,
personal information, vendor intellectual property (IP), and more. Even data that does not seem sensitive or
confidential could potentially reveal information that could be used to design an attack on sensitive data.
The SimpleLink Wi-FiInternet-on-a chip™ family of devices from Texas Instruments™ offers a wide range of built-
in security features to help developers address a variety of security needs, which is achieved without any
processing burden on the main MCU. This document describes these security-related features and provides
recommendations for leveraging each feature in the context of practical system implementation.
The CC3x20 and CC3x3x devices are designed such that the network security software runs within the
dedicated subsystem on the device. This subsystem is an on-chip network processor equipped with a hardware
encryption engine, resulting in a separate execution environment, thus offloading the main MCU of the system.
The security features span a wide variety of activities typical throughout the product life cycle, including
networking activities, data storage, IP protection, cloning protection, and provisions for security during
production. These security features are made available to vendors through an ecosystem that incorporates
simple and concise APIs, tools, and documentation.
1.1 Terminology
Table 1-1 provides brief descriptions of the key terms that are required to understand the security methods and
features.
Table 1-1. Terminology
Term Description
An asset is any piece of information (security-relevant elements) that has value to its owner. It therefore must be
Asset protected by the measures of the target system (by means of confidentiality, integrity, authenticity). Assets may be
proprietary information, personal data, or intellectual property.
Asymmetric key pairs are used in algorithms where one party performs a cryptographic operation with a key that is not
Asymmetric keys the same as the key used to apply the reverse operation. The pairs are defined as public and private keys, and used
mostly for digital signing and symmetric key distribution.
Attack vector A set of actions used to defeat system security measures, thereby gaining control over one or more assets.
Ensures that assets or entities are genuine and authorized to perform a task or used as intended. The verification
Authenticity process usually involves cryptographic algorithms, which check that the entities are who they claim to be. Some
predefined trust mechanism is always part of an authentication scheme.
Certificates are standard-formatted files. They typically contain the public key of the subject, and a CA signature of the
Certificates header and public key. Anyone provided with the CA public key (or sub-CA in case of certificate chain) can verify the
subject’s identity.
Certificate authority
A trusted entity that issues certificates used to verify identities.
(CA)
Certificate chain, A certificate chain consists of a hierarchy of certificates that allows anyone to verify the identity of any certificate
Chain of trust issuer, down to the root certificate.
Cipher suite is a named combination of algorithms used for authentication, key exchange, data encryption, and
Cipher suite
message authentication code. This set of algorithms is used in an SSL handshake and session.
Confidentiality ensures that an asset is not made available or disclosed to unauthorized entities. In most cases,
Confidentiality confidentiality translates into encryption, while in other cases, obfuscation techniques are used to maintain
confidentiality
Exposure point An identified entry point to the system that enables the launch of one or more security attacks (an attack vector).
Integrity Attribute describing an object that remains intact, in its entirety, compared to its original version.
Keys are used for data encryption, key establishment, and digital signatures. The key lengths and types depend on
Keys
the algorithm used, their purpose, and the security level.
PKI Public key infrastructure.
Revoked certificate A certificate that is no longer authorized and valid by its issuer.
The topmost certificate provided by a certificate authority, against which the certificate chain is eventually verified. It is
Root CA
always self-signed and publicly available.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 3
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Introduction www.ti.com

Table 1-1. Terminology (continued)

Term Description
Security measures Measures aiming at providing the intended protection of some assets against some threats.
Symmetric key A key used in algorithms where both parties perform a cryptographic operation with the same key.

1.2 Internet of Things (IoT) Products and Security

An IoT device is by nature a network-connected device, and therefore may serve as a gateway to malicious
access to sensitive data, such as surveillance videos, or control over actuators, such as door locks.
To achieve good security for an internet-enabled product, a security assessment must be performed on the
specific product and its system-level requirements. This assessment should identify the involved assets, analyze
the environment as well as intended and unintended potential usages of the product, and thereby detect
potential vulnerabilities of the product.
This assessment helps the developer define the best protection scheme using the available security capabilities.
The environment, the assets, and the processes are different from one product to another, but generally for IoT
devices there are some common exposure points:
• Internet (or intranet) network connectivity
• Local network connectivity
• Physical access (with or without the ability to manipulate hardware interfaces)
Figure 1-1 shows the common exposure points of an IoT-connected product.

x
x
x
x x x
x x

Vendor x
x x

x
x x x
x x

Application Servers

Internet

IoT Devices

User

User

Figure 1-1. Common Exposure Points of IoT Devices

4 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Introduction

1.2.1 Internet Network Connectivity

This exposure point relates to all possible attack channels that originate from the internet connectivity. The
vulnerabilities in this vector could come from all communication channels (such as sockets) and protocols in use.
In general, the potential targets of these attacks are all the resources and information that pass through these
channels. However, be aware that attackers can try to use these resources to widen their exposure points, and
therefore any resource or information on these channels should be examined carefully.
The SimpleLink Wi-Fi device incorporates a variety of features including standard-compliant secure transport
layer (SSL/TLS), also referred to as secure sockets, domain name verification, secure content delivery, and
device-unique identifiers to provide communication security at the network layer.
These features allow not only data encryption, but also authentication of the origin of the data by means of
standard chain of trust verification procedures.
1.2.2 Local Network Connectivity
This exposure point is similar to the internet network connectivity exposure point. The general nature of a local
network lends itself to a specific set of attack vectors. For example, monitoring of the wireless network or
injecting malicious or abusive traffic on the WLAN or LAN.
One vector is based on passive monitoring of traffic over the wireless network, without the attacker being
connected to it. A wireless network can be passively monitored, because some of the headers of communication
packets are not encrypted even in secured wireless networks. These headers might reveal information such as
the MAC addresses of the devices on this network or the temporal properties of the traffic they generate.
The Wi-Fi Alliance® has regulated security and compliance tests as part of its standards. The SimpleLink Wi-Fi
device is a certified Wi-Fi Alliance device, and complies with all these security requirements.
The second vector relates to attacks from another device that is part of the local area network (LAN). This
provides additional opportunity for executing an attack vector that involves network access, and the ability to
legitimately inject traffic over the network and abuse ports and protocols available on the target device. Access
to these ports and protocols is most commonly blocked from the internet, but available on the LAN.
The SimpleLink Wi-Fi device includes features such as an HTTPS server and RX filters to allow developing
additional layers of security for local networks.
1.2.3 Physical Access
In the case of a physical access attack, the exposure is at the product level and there are a couple factors to
consider. Physical access may result in attack vectors such as product-level manipulation and printed circuit
board (PCB) manipulation. The product-level manipulation vector refers to attacks in which the attacker can
control the way the device operates by using the external interfaces that the final product offers (such as power
line, buttons, and so forth). The second vector relates to the ability of the attacker to access the actual board
(PCB) and to monitor the lines or the hardware interfaces. In more serious cases, an attacker may event attempt
to manipulate the wires, replace devices on the PCB, connect to the main controller, and inject signals to trigger
certain actions.
Features such as IP protection, file system security by means of encryption, file integrity checking, cloning
protection, and more are provided in SimpleLink Wi-Fi to help thwart these attack attempts.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 5
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Introduction www.ti.com

1.3 Main Features

The SimpleLink Wi-Fi Internet-on-a chip family of devices offers a wide range of built-in security features. These
security features can enable and assist designers with addressing a variety of security requirements and
reducing the security risk with their intended application. Figure 1-2 shows a high-level diagram of the main
security features offered by the SimpleLink Wi-Fi Internet-on-a chip™ family. The features are organized
according to the exposure level at which they typically apply.
Table 1-2 lists high-level descriptions of the main security features.
Hardware Crypto Engines
Trusted Root Certificate Catalog
Debug Security Secure Sockets (TLS/SSL)
Unique Key ± Cloning Protection Device Identity
File System Security

Software Tamper Detection Secure Key Storage

File Encryption Secure Content Delivery
File Authentication TI Root of Trust Public Key Personal and Enterprise Wi-Fi Security
File Access Control HTTPS Service
Factory Image Recovery
Bundle Protection
Initial Secure Programming

PCB
Peripherals
CC32xx Network Processor + MCU

SPI and I2C MCU Network Processor

GPIO Cortex-M4
UART Application
256KB RAM and Internet Wi-Fi
PWM Optional 1MB XIP Servers
ADC Flash HTTPS MAC Internet
- SSL/TLS Baseband
Serial Flash TCP/IP Radio Vendor
Application
Device Identity
Access Point
HW Crypto Engines
User

STORAGE RUN-TIME TRANSFER

Physical Access Local Network Access Remote Access

Access Distance

Figure 1-2. Security Measures

Table 1-2. Main Security Features

CC3135/ CC3130/
Feature Description CC3120/CC3220
CC3235x CC3230x
Personal and
802.11 standard-compliant security support (WPA/WPA2-PSK/
Enterprise Wi-Fi + + +
WPA2-EAP/WPA2+PMF/WPA3)
security
6 concurrent 16 concurrent 16 concurrent
Secure sockets Transport layer security compliant with SSLv3, TLS1.0/1.1/1.2.
sockets sockets sockets
OCSP is an extension of the TLS protocol that runs during the
OCSP TLS
TLS handshake to check the certificate chain for revoked - + +
extension
certificates. Supports OCSP, OCSP stapling and stapling v2.
Internal HTTPS server running on top of a TLS socket, with
HTTPS server + + +
support for client authentication.
Unmodifiable, unique 128-bit number that TI stores in the
Device identity device during production. It may serve as a unique device + + +
identity (UDID).
Secure key Asymmetric key-pair storage on external flash encrypted by a
+ + +
storage key derived from the unique key of the device.
Trusted root- Built-in mechanism to ensure a CA is trusted as a root of a
+ + +
certificate catalog certificate chain for the purpose of TLS and for file signing.

6 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Introduction

Table 1-2. Main Security Features (continued)

CC3135/ CC3130/
Feature Description CC3120/CC3220
CC3235x CC3230x
The hardware-based mechanism that allows authenticating TI
TI root-of-trust as the genuine origin of certain content (such as software
+ + +
public key service pack, trusted root-certificate catalog) using asymmetric
keys.
File system
File system security for confidentiality and integrity of data. + + +
security
Validate the integrity and authenticity of the runtime binary
Secure boot during boot (CC3220S, CC3220SF, CC3235S, and CC3235SF + + +
only).
Provides an end-to-end ability for delivering confidential
Secure content
information to the system independent of the security of the + + +
delivery
transport layer.
Initial secure Image integrity check and image confidentiality during
+ + +
programming programming, including system configurations and user files.
Blocking the access to debug capabilities such as JTAG
Debug security + + +
interface and file-by-file access from external tools.
Software tamper Detecting and alerting potential unauthorized manipulation of
+ + +
detection secure file content.
Cloning
The file system is encrypted with a device-unique key pair. + + +
protection
The FIPS 140-2 is a U.S. government computer security
FIPS 140-2 level standard used to approve cryptographic modules. The
- + -
1, compliant(1) SimpleLink Wi-Fi device has two sub-chip modules subject to
the FIPS 140-2, level 1.

(1) The FIPS certification is in process, for the latest status refer to https://csrc.nist.gov/projects/cryptographic-module-validation-program/
validated-modules.

The CC3220 and CC323x devices have a unique architecture, with two physically separate MCU and memory
execution environments. Figure 1-3 shows a simple block diagram of the CC3220/CC3230/CC3235x device and
represents the security features they offer.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 7
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Introduction www.ti.com

CC32xx Single Chip Wireless-MCU Solution With Built-In Multi-Layer Security Features
CC32xx Network Processor + MCU
CC32XX Network Processor + MCU

Peripherals SPI and I2C MCU Network

Network Processor
Processor
Cortex-M4
M4 Cortex
GPIO
UART
Physical
Physical Internet
Internet
PWM
ADC Secure
Secure Content
content
Debug Security
security SSL/TLS
- Delivery
delivery

Secure Boot
boot Device Identity
identity

Application
Application Local
Local Area Network
Network

Personal
Personaland
&
HW
HW Crypto
crypto engines
Engines HTTPS Server
server
Enterprise
enterprise Security
security

Cross-Layer
Cross-Layer

Trusted
Trusted Root
root
Secure
Secure Key
key Storage
storage
Certificate
certificate catalog
Catalog

Separate Execution
execution Enhanced
Enhanced File
file TI root-of-trust
Environment
environment System
system Security
security public key

Software
Software Tamper
tamper
Initial secure programming Cloning Protection
protection
Detection
detection

Figure 1-3. CC3220/CC3230/CC3235x Device Security Features

8 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Introduction

Figure 1-4 shows a block diagram of the security features offered by the CC3120/CC3130/CC3135 device.
CC31xx Networking Processor With Built-In Multi-Layer Security Features

CC31xx

Peripherals SPI and I2C Network Processor

GPIO
UART
Internet
PWM
ADC Secure content
MCU SSL/TLS
- per customer UART/SPI
delivery
selection
Device identity

Local Area Network

Personal and
HTTPS server
enterprise security

Separate execution
environment Cross-Layer

Trusted root
Secure key storage
certificate catalog

Enhanced file TI root-of-trust

system security public key

Software tamper
Cloning protection
detection

Initial secure
programming

Figure 1-4. CC3120/CC3130/CC3135 Device Security Features

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 9
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Network Layer Security www.ti.com

2 Network Layer Security

The SimpleLink device is a Wi-Fi-based device, which supports 802.11 security protocols for the local segment
of the network (between the node and the AP) and TLS/SSL for the transport layer when using TCP/IP for node-
to-node communication. TLS/SSL can address confidentiality, data integrity, and authenticity between nodes
across the network.
Figure 2-1 shows common security traffic layers.

Figure 2-1. Network Security Topology

2.1 Wi-Fi Security

The Wi-Fi layer of the SimpleLink device complies with 802.11 security to ensure the integrity and confidentiality
of the frames (L2 data units) in transactions between AP and STA, or between two peers in the case of Wi-Fi
direct mode. The security protocols are described in the IEEE 802.11 specifications and its extensions.
The Wi-Fi subsystem of the SimpleLink device provides support for both personal and enterprise security
paradigms, including RADIUS-based authentication (802.1X).
The SimpleLink device is Wi-Fi-CERTIFIED™ and complies with Wi-Fi Alliance (WFA) security standards and
test suites. Table 2-1 lists the supported Wi-Fi security-related capabilities.
Table 2-1. Wi-Fi Security
Type Wi-Fi Security

AES (WPA2-PSK/WPA2+PMK/WPA3-PSK)
Personal TKIP (WPA-PSK)
WEP

EAP Fast
EAP PEAPv0 MSCHAPv2
EAP PEAPv0 TLS
Enterprise EAP PEAPv1 TLS
EAP TLS
EAP TTLS TLS
EAP TTLS MSCHAPv2

10 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Network Layer Security

All wireless passwords are stored in an encrypted form on the serial flash. These passwords are solely
consumed by the network processor (NWP) and not available to the host through APIs or any debug channel.

Note
WEP security is flawed by design and has been compromised. TI strongly recommends not using it. It
is supported by the SimpleLink product for legacy compliance reasons only.

2.2 Secure Socket Layer

The SimpleLink device provides a secure transport layer (secure sockets) based on a standard-complaint
implementation of SSL and TLS protocols, which are network protocols that involve cryptographic paradigms
designed to provide communications security over a TCP/IP connection. In most systems, the SSL/TLS is
implemented as a layer on top of the transport layer. In the SimpleLink device, the SSL/TLS is embedded into
the BSD socket layer, allowing seamless access to secure socket facilities. Extensions to the APIs provide the
user some level of control over the SSL/TLS behavior and configuration.
The SSL/TLS runs on the network processor subsystem. By design, the architecture of the device is such that
the networking processor is a physically separate process subsystem, creating a separate execution
environment. Hardware accelerators are used to offload the intense arithmetic calculations involved in the
cryptographic algorithms.
Table 2-2 provides a brief description of the supported SSL/TLS specification in the SimpleLink device.
Table 2-2. Supported SSL Specifications
Protocol Versions SSL v3, TLS 1.0, TLS 1.1, TLS 1.2

SL_SEC_MASK_SSL_RSA_WITH_RC4_128_SHA
SL_SEC_MASK_SSL_RSA_WITH_RC4_128_MD5
SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA
SL_SEC_MASK_TLS_DHE_RSA_WITH_AES_256_CBC_SHA
SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
SL_SEC_MASK_TLS_ECDHE_RSA_WITH_RC4_128_SHA
SL_SEC_MASK_TLS_RSA_WITH_AES_128_CBC_SHA256
SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA256
SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
SL_SEC_MASK_TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
SL_SEC_MASK_TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
Ciphers suites SL_SEC_MASK_TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
SL_SEC_MASK_TLS_RSA_WITH_AES_128_GCM_SHA256
SL_SEC_MASK_TLS_RSA_WITH_AES_256_GCM_SHA384
SL_SEC_MASK_TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
SL_SEC_MASK_TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SL_SEC_MASK_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
SL_SEC_MASK_TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
SL_SEC_MASK_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
SL_SEC_MASK_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
SL_SEC_MASK_TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Maximum secure sockets 16 on CC3x3x , 6 on CC3x20x

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 11
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Network Layer Security www.ti.com

Table 2-2. Supported SSL Specifications (continued)

Protocol Versions SSL v3, TLS 1.0, TLS 1.1, TLS 1.2

Server authentication
Client authentication
Other Domain name verification
Separate execution environment
OCSP (on CC3x3x only)

2.2.1 SSL/TLS Certificate Handling and Other Security Files

Certificate files, DH (Diffie-Hellman) parameters, and keys must be stored on the file system of the device to
enable some of the SSL/TLS capabilities in accordance with the selected cipher suite (see Table 2-3).
Certificates are standard-formatted files carrying public keys of an asymmetric key-pair, and are thus not
confidential by nature. Private keys, on the other hand, are confidential and should be kept encrypted. Access
control restrictions should be applied to these files, limiting read access to the rightful owner (see Section 3.2.4).
The keys and certificates are used internally by the SSL sockets when the handshake occurs. The host must
only bind the related files to the SSL/TLS socket using APIs.
Table 2-3 lists the files supported by the SimpleLink SSL/TLS socket.
Table 2-3. SSL/TLS Files
File How Used by Client How Used by Server
Validates the server chain of trust. Enables client verification if installed.
Root CA file: ESECSNOVERIFY warning is returned if not installed, but ESEC_NO_PEER_CERT event is issued by
A self-signed certificate that connection is not implicitly terminated. the device if the client failed to provide the
signs the chain of the remote proper chain of trust to match the installed
peer CA certificate.
Format: PEM/DER Format: PEM/DER
This certificate file is used as a client certificate if the server This certificate file is used as a server
requires client authentication. certificate or certificate chain.
If the file does not exist and the server requires a client The certificate should be the first in the list.
Certificate file: authentication, the server returns an ALERT of peer verify
A certificate issued to this error.
entity A private key must be programmed with this file, or else the The file must be configured. If it is not
connection fails with ESECBADPRIVATEFILE. configured, it results in error
EBADCERTFILE.
Format: PEM/DER Format: PEM
Used as a client private key if the server requires client Used as the private key of the server. Must
authentication. be programmed to connect to the server
Private KEY file: using SSL/TLS.
RSA or ECDSA key ESECBADCERTFILE if a matching public certificate file is EBADCERTFILE is returned if not available.
not installed with this file.
Format: PEM/DER Format: PEM/DER
Programming this file enables the domain verification by full Used as DH Param file, enables the use of
server certificate comparison. DH-based ciphers.
This certificate is compared to the one presented by the
PEER Certificate,
server certificate during the SSL/TLS handshake process, to
DH Param (client, server)
protect from MITM attack. It is used to validate that this is the
expected server to which connection was attempted.
Format: PEM/DER Format: PEM/DER

12 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Network Layer Security

2.2.2 SSL/TLS Handshake Overview

After establishing a TCP connection between two peers, the SSL protocol takes place in negotiating the session
security parameters and authenticating the peers.
A short description of this handshake process follows. This handshake is performed by the SimpleLink device,
and remains transparent to the user:
1. A client hello message is sent with the following parameters:
• Protocol version to be used – SSLv3, TLS1.0, TLS1.1, TLS1.2
• Cipher suites supported by the client
• Extensions, used for different applications of the SSL
2. The server chooses the protocol version and a cipher suite from the client hello cipher list, and sends a
ServerHello message to the client.
3. The server sends the certificate chain (except for the root CA) to the client.
4. The client may verify the chain by checking the signature of each certificate in the chain, starting with the root
CA held by the client. The server may request a certificate from the client for a client authentication.
5. The client and server establish session (symmetric) keys and can then start transferring encrypted data.
Figure 2-2 shows the SSL/TLS handshake process.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 13
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Network Layer Security www.ti.com

Client Server

Establish security
Client hello
capabilities
including protocol
version and Cipher
Server hello
Suite

Certificate

Server may send

Server key-exchange
certificate, key
exchange, and
request certificate
Certificate request
from the client

Server hello done

Certificate Client sends

certificate if
requested, sends
Client key-exchange key exchange, and
may send
certificate
Certificate verification verification

Change cipher spec

Finished Server and client

change cipher suite
and finish
Change cipher spec handshake protocol

Finished

Figure 2-2. SSL/TLS Handshake

14 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Network Layer Security

2.2.3 SSL/TLS Handshake With the SimpleLink Device

The SSL/TLS protocol is an integral part in the network stack of the SimpleLink device, running within the
networking subsystem, thus creating a separate execution environment. The only interface to this layer is
through API calls from the application processor.
2.2.3.1 SSL/TLS Handshake Supported Capabilities
Table 2-4 lists the SSL/TLS handshake features.
Table 2-4. SSL/TLS Main Handshake Features
Operation Client Server
Authenticating the peer √ √
STARTTLS √ √
Server domain verification √ N/A
Trusted root-certificate catalog √ N/A
Time and date validation √ N/A
OCSP √ N/A

2.2.3.2 Basic SSL/TLS Connection

On most systems, the SSL/TLS protocol is implemented on top of the TCP layer. In the SimpleLink device, the
SSL/TLS socket is embedded into the TCP layer, and retains the look and feel of a standard TCP socket. The
entire SSL/TLS handshake is triggered automatically during the connect session (when the connect() or accept()
APIs are invoked). This method simplifies the work with secure sockets. Opening a socket with a security
parameter in the protocol argument and then calling the connect or accept commands establishes a secure
connection to the other peer.
In server mode, a server certificate or certificate chain and a private key must be supplied. This chain is sent in
the handshake. Absence of these files raises an error when sl_Accept is called.
In client mode, a client certificate and its private key can be supplied in case the remote server policy requires
client-side authentication.
2.2.3.3 Errors and Warnings
The BSD commands return detailed errors on any fault, including the secure socket handshakes.
Some of the error codes reflect security-related warnings, without blocking the process. The developer is urged
to consider the following warnings because they indicate a potential security problem:
• SL_ERROR_BSD_ESECSNOVERIFY – Connected without server verification
• SL_ERROR_BSD_ESECDATEERROR – Connected with certificate date validation error
• SL_ERROR_BSD_ESECUNKNOWNROOTCA – Connected but the root CA is untrusted
2.2.3.4 Authenticating the Peer
A basic connection to a server leads to an error received on the sl_Connect command –
SL_ERROR_BSD_ESECSNOVERIFY. This means that the data flow is encrypted from now on, but the
SimpleLink device did not validate that the remote side is an authentic server.
In this case, the data is encrypted and is now confidential from an eavesdropper, but the server identity is not
verified. Without verifying the server identity, Man-In-The-Middle (MITM) attacks or phishing attacks could still be
carried out.
Setting a root CA that signed the server certificate triggers a signature check on the server chain of trust, also
called a full chain of trust verification. If the validation fails, the connection is terminated.
If the SimpleLink device is in server mode, it can verify clients by setting the root CA that signed the client
certificate. If the validation fails, the connection is terminated.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 15
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Network Layer Security www.ti.com

2.2.3.5 Domain Name Verification

Chain of trust evaluation ensures that communication is carried out with a trusted entity. However, it does not
assure it is the identity with which communication was intended.
This is achieved by domain name verification. Domain name verification can be used to verify that the identity
with which communication was intended is the one with which communication is actually carried out. This is
achieved by comparing the content of the certificate presented by the server and the expected prestored
certificate.
If the comparison fails, a security warning is triggered and connection is kept. The way the warning is handled is
up to the developer.
2.2.3.6 Trusted Root-Certificate Catalog
The trusted root-certificate catalog is a file, provided and signed by TI, that contains a list of known and trusted
root CAs (a complete list is available as part of TI SDK and collateral). The catalog holds trusted root certificates
from commonly trusted CAs (such as VeriSign®, GoDaddy®, GeoTrust®, and more). The trusted root-certificate
catalog also holds a list of revoked certificates known to TI. The trusted root-certificate catalog is used only in
client mode. When acting as a server, using a self-signed root CA to authenticate a client is allowed.
When a root CA is unknown to the trusted root-certificate catalog, the sl_Connect command returns the warning
SL_ERROR_BSD_ESECUNKNOWNROOTCA, which means that the connection was successful, but the root
CA used to verify the server chain of trust is unknown. In this case, the developer should choose to either
terminate the connection explicitly or proceed at its own risk.
When a revoked certificate has been received during the SSL/TLS connection (all the certificate chain is
checked) or if the root CA that has been set by the user is revoked, the handshake is terminated, and the
SL_ERROR_BSD_ESECCERTIFICATEREVOKED is returned by the sl_Connect command.
The trusted root-certificate catalog is stored as a file in the file system, and can be updated to a newer version
only.
Figure 2-3 shows the relationship between the certificate files and the trusted root-certificate catalog. A list of the
root CAs that are approved by TI are available as part of the SDK, and can also be found in the SimpleLink
CC3120/CC3220 Root Certificate Catalog.

SFLASH Files (Authentication)

Trusted root-certificate catalogue

HASH
SSL Client

ROM Certificate
Authentication
Process
Root CA

Service Certificate Chain

Figure 2-3. Certificate Files and Relationship With the Trusted Root-Certificate Catalog

16 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Network Layer Security

2.2.3.7 Validating the Date of the Server

Every certificate has an expiration date. When connecting to a server in client mode, the server time validation
occurs if the root CA was set. If the time validation fails, the sl_connect command returns an error
SL_ERROR_BSD_ESECDATEERROR, “connected with time and date validation error.” The user can set the
time and date of the device, and this is used in the certificate time and date validation. The date and time are
kept in hibernate mode.
Setting a date and time results in a write operation to the serial flash, and should therefore be part of flash
endurance considerations.
2.2.3.8 OCSP
OCSP is an extension of the TLS protocol that runs during the TLS handshake to check the certificate chain for
revoked certificates. The SimpleLink Wi-Fi devices (CC3x3x) support OCSP, OCSP stapling, and OCSP stapling
v2. The modes are automatically selected according to the server's capabilities. The whole certificate chain is
checked for revocation when this feature is enabled. This feature is disabled by default.
2.2.4 Maximum Number of SSL/TLS Connections
The CC3120, CC3220R, CC3220S, and CC3220SF devices limit the maximum concurrently connected SSL/TLS
client sockets to 6. In the case of a server socket, the accept socket (the socket on which the server is listening
for new connections) is not counted.
In CC3130, CC3230S, CC3230SF, CC3135, CC3235S, and CC3235SF devices, all 16 sockets can be secured.
2.2.5 Selecting SSL Parameters
It is possible to set the SSL versions allowed to use a specific cipher list for different implementations. Some
cipher algorithms are done by hardware and others by software. The Simpelink interface is making it easy to
choose only the hardware-accelerated algorithm.
2.2.6 Security Changes on Socket (STARTTLS)
A regular TCP socket can be upgraded to an SSL/TLS socket. In order to upgrade, the user must trigger the
SSL/TLS handshake explicitly, irrespective of the socket connection (triggered by either sl_connect or sl_accept
APIs). This implementation is usually used in applications that use STARTTLS to upgrade a connected session
to a secured connection.
An example of this application is the SMTP on port 587. A secured socket can be downgraded to an unsecured
TCP socket only if an SSL/TLS shutdown alert is received from the peer. The SimpleLink device user cannot
initiate an SSL/TLS shutdown on a secured connection. If a socket is upgraded or downgraded, an
asynchronous event is issued to the host indicating the new state.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 17
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
File System Security www.ti.com

3 File System Security

3.1 Overview
The SimpleLink solution has an externally-attached non-volatile memory (NVM) in the form of a serial flash
device. Data on the SFLASH is organized in a file system and the device provides APIs to access it. The file
system can be used by the host application for creating, writing, and reading files. The file system is also used
by the networking subsystem to store configuration and temporary files.
System files are created during the programming process or by the device to retain the device state and
configurations through a power-cycle. These files are inaccessible from the host.
The file system has built-in capabilities designed to keep content protected. Some of these capabilities are
inherently applied, while other capabilities leave control for the user.
The following features comprise the device file system security feature set:
• Encryption – Files are stored and encrypted using a standard AES-128 encryption.
• Cloning protection – The entire file system content, including the application binary image, is encrypted with a
device-unique key.
• File system integrity verification – The integrity of the file system structure is verified to check whether the file
system was manipulated.
• Software tamper detection – Content integrity can be validated by the file system, and an alert is triggered
when a malicious access to a file is detected.
• Access control – File access may be restricted to the rightful owner, per access type.
• Origin authentication – Files can be defined to restrict update eligibility only with a valid certificate provided.
• Recovery mechanism – The file system can be restored to an initial programmed configuration.
The service pack and the trusted root-certificate catalog are system files which must be created as secure files.
Those files can only be read by the device. Files which contain confidential data as keys for the SSL/TLS
connection should also be created as secure files.

18 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com File System Security

3.2 File System Security Features Description

3.2.1 Encryption
Confidentiality is possible through data encryption. In this case, only the encrypted version of the file is kept on
the serial flash. The AES-128-CTR is the selected encryption method. Keys are inherently generated by the
device using a True Random Number Generator (TRNG) hardware engine. Decryption is inherent and is
executed on-the-fly while reading the file.
3.2.2 Cloning Protection
The file system metadata is encrypted with a device key, which is unique per device. This key is unique per
device, and thus moving a file system that was created on one device to another device is not possible. Doing so
results in a security violation detection during the boot sequence, and the device enters a lock state.
3.2.3 Integrity Verification
An integrity check is applied for secure files created with the secure-and-authenticate flag. The integrity is
conducted by the SimpleLink device. Upon each change of the file, a new hash is executed and the result is a
file signature. When the file is opened for read, the file content is verified against this signature.
System files and the file system structure are also protected, and their integrity is tested by the device. The
integrity validation of system files is done by using the HMAC-SHA-256 algorithm.
If the device identifies a verification failure, a system security alert is triggered.
If the device identifies a verification failure of the file system structure or a system file, it changes its state to a
locked state.
3.2.4 Access Control
Each secure file has several access levels; the access levels define restrictions over how the file can be used.
Tokens are used to control the access to the secure files.
When a secure file is created, four different tokens (32-bit number) are generated. Each token provides a
different access level to the file, as listed in Table 3-1.
Table 3-1. Tokens
Type Description
Enables full access to the file. A secure file can be deleted only with the master token. The
Master token
master token is unchanged, as long as the file exists.
Enables read and write access. This token is generated automatically when the file has been
Read/write token
changed.
Enable write access only. Used for producer-oriented files, such as a private key. This token
Write only token
is generated automatically when the file has changed.
Enables read access only. Used for consumer-oriented files, such as a public key. This token
Read only token
is generated automatically when the file has changed.

The network processor automatically generates the tokens for secure files. The master token is the output
parameter of the file creation function, and is received by the host.
The Get Info function enables the host to retrieve all the accessible file tokens by providing a valid file token as
an input. Only tokens with lower priority than the input one can be retrieved.
The default system behavior is to regenerate all the file tokens, except for the master token, each time the file is
opened for a write operation. This default behavior can be changed by the file creation flags. The file creation
flags can override the default behavior of the token creation. File creation is explained in Section 3.3.
When a secure file is opened for write, the open-write function returns the new generated token. The returned
token is on the same level as the input token.
For example, for a file opened for write with the write token as input, the new file write token is returned.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 19
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
File System Security www.ti.com

3.2.5 Trusted Source Verification

The file system provides another layer of protection by ensuring that the origin of the file signature is trusted by a
public root CA. This procedure is applied by default on secure files.
The authentication method used for this process follows PKI with a key size of either 128 or 256. The file
signature verifies both the file integrity and the chain of trust used to sign this file.
To create a digital signature for the authentication process, the vendor must have an RSA key-pair. The
certificate that holds the public key must be signed by a certificate chained up to a known root-certificate
authority (CA). The entire chain of trust for this certificate is verified by the device, and the signature of the root
CA is compared to the expected hash using the trusted root-certificate catalog.

Note
The certificate expiration date is not validated during this file authentication process, because there is
no absolute way to ensure the local date and time validity can work in all use cases.

When creating a new secure file, there is an option to skip the file authentication default behavior. This is done
by using a dedicated creation flag: SL_FS_CREATE_NOSIGNATURE.
Figure 3-1 shows the file authentication process.

SFLASH Files (Authentication)

Contains only HASH
of the root certificates

HASH
Trusted root-certificate
catalogue

ROM Certificate

Root CA

Secure User File

CA

File
The signature is used
only during write

Authentication
Process
Vendor Certificate
µ
Signature

Figure 3-1. Validate File Signature

20 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com File System Security

3.2.5.1 Origin Authentication for the Service-Pack and the Trusted Root-Certificate Catalog
The service pack and the trusted root-certificate catalog are files provided and signed by TI only.
Writing the service pack and the certificate store files requires a signature; the signatures for those files are
supplied by TI. Certificate material is preinstalled on the device.
The trusted root-certificate catalog contains a list of revoked certificates. If a certificate from this list is
encountered in the course of an SSL/TLS connection, the connection is terminated and the device triggers an
event to the host.
3.2.6 Recovery Mechanism
The SimpleLink device embeds an internal recovery mechanism that allows the file system to be rolled back to a
predefined image programmed during production.
The recovery image is a system file kept on the serial flash. The file is stored as a secure file. The recovery
image file is listed as part of the files list, but is inaccessible from the host.
The following methods can be used to trigger the recovery procedure:
• Setting the SOP
• Function call from the host to sl_DeviceSet
The recovery mechanism supports several modes; the device recovery mode is configured during the creation of
the file system image.
The supported recovery modes are:
• None – No recovery settings; in this case, the recovery image file is not kept.
• Enable restore to factory-default.
• Enable restore to factory-image and factory-default.
Restore to factory-image – The factory image file contains the programmed image files, which includes the
service pack, host application (in the case of the CC3220/CC3230/CC3235x), configuration files, and user files.
Once invoked, the device is formatted and reprogrammed. The content of all files is replaced with the factory
image files. Files that do not exist in the original image are deleted. The restore to factory-image can be invoked
by a host command or by setting the SOP.
Restore to factory-default – Restore to factory-default is similar to restore to factory-image. The difference is that
the service pack and the host application (in the case of the CC3220/CC3230/CC3235x) are not restored, so the
latest service pack and the latest host application are used. When using this method, any file that the host app
might use is restored to the programmed content.
The restore-to-factory process is fail-safe, and it resumes even if a power failure occurs during the operation.
3.2.7 Tamper Alerts
The SimpleLink device provides a data-tampering procedure with a security-alert counter. This procedure
detects integrity violations when accessing the file system, for system files and files that are created as secure
and authenticate.
Access violations (such as attempts to access files with an invalid or improper token) are also monitored and
detected as a tamper attempt.
When the system reaches the predefined limit of security alerts, the device is locked and an asynchronous event
is triggered.
To recover from a locked state, the device must be reprogrammed or restored to factory image.
The security alerts counter is persistent and its value is set to 0 as part of the programming process, or as part of
the restore-to-factory functions only.
The security alert threshold can be configured during image creation (using the image creator tool).
The host can retrieve the current number of security alerts in the system using the sl_deviceGet API.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 21
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
File System Security www.ti.com

Table 3-2 lists the different security alerts.

Table 3-2. Security Alerts
Type Description
The device is locked immediately regardless of the alert counter threshold.
Explicit alerts are created when detecting the following tamper events:
Explicit alerts (critical) • File system structure integrity error
• System file integrity error
• Cloned SFLASH

The device is locked when the alert counter crosses the alerts threshold.
Implicit alerts are created when detecting the following tamper events:
• Invalid or improper access token
Implicit alerts • Integrity violation of a file created as a secure and authenticate file when opened for
read
• Setting an invalid signature or invalid certificate when updating the content of a secure
and authenticate file

3.2.8 Special System Files

Table 3-3 lists the files with a special treatment by the SimpleLink device.
Table 3-3. Special Treatment Files
Type Description
The service pack is created as secure-signed-public write.
Service pack The signature of this file is provided by TI and validated by the device using the hardware-
based root of trust.
The trusted root-certificate catalog is created as secure-signed-public write. The signature of
this file is provided by TI and validated by the device using the hardware-based root of trust.
Trusted root-certificate catalog
The file is also protected against downgrade; the host cannot write an older version than the
one installed.
The runtime binary file must be created as secure-signed.
Runtime binary (host application)
The vendor is responsible for creating the host signature and supplying a signed certificate.

3.2.9 File Security Levels

The host can create files on the SimpleLink device file system and set the security level of the created files.
Table 3-4 lists the possible security levels.
Table 3-4. File Security Levels
Type Description
The data is stored as plaintext.
None
There is no validation on the data.
The file content is stored encrypted.
Secure file
Access to the file requires a token.
The file content is stored encrypted.
Access to the file requires a token.
Secure-and-Authenticate file The integrity of the file is tested each time the file is opened for read.
The origin of the file authentication and the integrity of the file is validated with each change
of the file.

22 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com File System Security

3.3 File Creation Attributes

The file attributes are defined during creation, including security properties of the file. This sets the security-
related treatment of the file. The file attributes are based on creation flags and cannot be changed.
Table 3-5 is a list of creation flags.
Table 3-5. Creation Flags
Type Description
A file opened with fail-safe has space on the file system allocated for two copies, but only
one copy is considered to be active at a time. Each time the file is opened for write, the
SL_FS_CREATE_FAILSAFE
inactive location is erased. If the system is powered off while writing a file with fail-safe, the
old instance leaves the active one.
A file created as secure has its content encrypted on the SFLASH. Access to the file is
SL_FS_CREATE_SECURE
limited, and requires a file token.
The flag is relevant only for secure files. By default, a secure file requires a signature during
SL_FS_CREATE_NOSIGNATURE write. This signature is used to authenticate the origin of the file. This flag lets the user skip
the authentication check during write.
Relevant only for secure files. This flag changes the default behavior of the file tokens
SL_FS_CREATE_STATIC_TOKEN
creation: with this flag, the file token is not changed each time a file is opened for write.
Relevant only for secure files. This flag changes the default behavior of the file tokens
SL_FS_CREATE_VENDOR_TOKEN
creation: with this flag, the file master token is set by the host.
Relevant only for secure files. This flag changes the default behavior of the file tokens
SL_FS_CREATE_PUBLIC_WRITE
creation: with this flag, the file can be written without a token.
Relevant only for secure files. This flag changes the default behavior of the file tokens
SL_FS_CREATE_PUBLIC_READ
creation; with this flag, the file can be read without a token.

Table 3-6 is a list of flags that are not creation flags. These noncreation flags can be set every time a file is
opened for write.
Table 3-6. Noncreation Flags
Type Description
SL_FS_WRITE_BUNDLE_FILE Used for the bundle commit feature.
SL_FS_WRITE_ENCRYPTED Used for secure content delivery.

4 Programming the Device

The process of programming the device has a major impact on the system integrity. To ensure the integrity of the
system, the SimpleLink device applies an image-based programming methodology. The device programming
procedure uses a single image file, which contains all device configurations, the runtime binary, and other
complementary data files. The ability to pack all these into a single file, which is then used for programming,
ensures that there is no situation in which the device is partially configured.
Image creation is handled by a cross-platform external tool provided by TI. The tool takes all the material that
composes the image as an input, and outputs an image binary file that can then be flashed onto the serial flash
attached to the device.
The actual burning process is independent of the image structure. The process can therefore be carried out
either by the tool, or any other standard flashing tool.
This image serves as the factory image for recovery discussed in Section 3.2.6, if this option is used.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 23
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Programming the Device www.ti.com

4.1 During Development

To allow easy development with the SimpleLink device while not compromising the security features, the
SimpleLink device enables a separate methodology for development (debug security).
During development mode, all security capabilities are available for use, however to allow for the proper debug
environment, all debug interfaces are available, and it is possible to modify the file system content on a file-by-
file basis (to avoid the burden of regenerating and programming a new image for each change).
To avoid surrendering the device-unique key material, a separate set of keys is used while in this mode.
The device is put into development mode through the image type, which is determined through the image
creation. The development image is device-unique. The image is tightly coupled with the target device onto
which it is programmed (according to its hardware-defined MAC address). This inhibits wide use of a
development image for production.
The following functionality is exposed in development mode:
• File access is permitted from the image creation tool (file-by-file access).
• File list can be accessed from the image creation tool.
• JTAG interface is enabled (CC3220/CC3230/CC3235x device only).
4.2 During Production
A production image is appropriate for mass production, and can be programmed to many devices
simultaneously. This image is deflated upon first boot of the device and transformed into a device-unique image.
The JTAG interface is blocked.
4.2.1 Programing Methods
The SimpleLink device offers the following programming methods:
• Image creation tool (using UART transport)
• Host programming (using host APIs)
• External programming (such as "gang" programming)
4.2.1.1 External Programming (Gang Programming) Details
To operate in this method:
1. The serial flash is programmed using a third-party programmer while it is not assembled on the target PCB.
The third-party programmer tool is required to support standard file formats (Intel hex or binary raw).
2. The programmed serial flash is assembled on the target PCB.
3. During first power up, the SimpleLink device detects the image, ensures its integrity, and starts deflation.
It is possible to encrypt this image to make it confidential from the third party handling the gang programming. In
this case, the key is provided during image creation and the output image is encrypted with this key. In
production, upon image detection, the device awaits activation from the OEM by providing the key for decrypting
the image over the UART lines. Once the image is authenticated, deflation may commence.

Note
The CC32xx LaunchPad™ Development Kit is equipped with a connector to allow attaching an
external programmer to test this method.

24 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com In-field Software Updates

5 In-field Software Updates

The SimpleLink device provides methods for in-field software updates while maintaining system integrity, and
validates the origin of the software update using a CA-based chain of trust.
5.1 File Bundle Protection
The bundle protection is a method offered by the SimpleLink device for keeping the system integrity while
updating a collection of files referred to as a bundle. A bundle allows applying an update to the entire collection,
or rolling back to a previous version. As a result, an intermediate mixture is avoided.
5.1.1 File Bundle Update Workflow
All files belonging to a bundle must be created as FAILSAFE. Only a single bundle can be updated at any certain
point.
1. Start the update procedure by writing the new version of each file in the bundle with the bundle flag set.
2. Restart the device.
3. Upon failure, the bundle can be rolled back to its previous version, rendering it rejected. In this case, all the
files are recovered to their previous content.
The process of updating the bundle files is fail-safe, and an unintentional reset during the process is considered
as an abort of the bundle update procedure. As a result, automatic rollback is triggered and all the bundle files
are reverted to their previous copy.
New files can be created in the course of a file bundle update. If the bundle is rolled back, the new files are
deleted.
5.2 Secure Content Delivery
The secure content delivery capability provides yet another level of security at the application layer, and enables
the exchange of confidential content to the device. The content is decrypted by the device, and no entity along
the way carries the knowledge to decipher it. This capability is useful in cases such as over-the-air (OTA)
updates. Secure content delivery lets the user program content that has been encrypted by a remote device and
decrypted on-the-fly inside the NWP, while the private key used for the process is kept inaccessible, inside the
SimpleLink Networking subsystem, with no access from the host. As this capability is applied at the application
layer, it allows transferring a file to the system on unsecured tunnel.
5.2.1 Process Description
The process description for the secure content delivery capability follows:
1. Generate a key-pair using the NetUtils APIs.
2. Retrieve a temporary ECC public key.
3. Send the public key to the application remote server.
4. Receive an encrypted file.
5. Open a new file with a special flag indicating secure content delivery is about to be written.
6. Write the encrypted file content sequentially.
7. Close the file.
At the end of this process, the file is saved on the SFLASH, and the file is encrypted as a normal secured file
with a different key and method than the one used for the reception process.
Figure 5-1 shows the secure content delivery process.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 25
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
In-field Software Updates www.ti.com

TRANSFER RUN- TIME STORAGE

SimpleLink CC3220 Internet-on-a-chip Solution

CC32xx Network Processor + MCU

Peripherals
SPI and I2C MCU Network Processor
Application GPIO Cortex-M4
Servers UART Crypto Utils
PWM 256KB RAM + ECC Keys
ADC Optional 1MB XIP
- Flash Storage
Internet Application Secure File System
Vendor Access Point Serial Flash
HW Crypto Engines

User

Server Device - APP Device - NWP

Generate Priv-Pub key pair.

Get key
Generate temp pair

Get public key

Public key
Public key
Generate ECDHE secret.

Encrypt data using secret.

Send encrypted data

Open file for write

Write data
(cipher text)

Generate ECDHE secret.

Decrypt data using secret.

Encrypt using normal file system

methods.

Close file

Use the private data.

PLAIN TEXT CIPHER TEXT PLAIN TEXT CIPHER TEXT

Figure 5-1. Secure Content Delivery – Process Description

26 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com In-field Software Updates

5.2.2 Encrypted File Format

The file delivered with this process should have a special format. Figure 5-2 shows this format.

RAW data size 4 Bytes

Padding 4 Bytes

ECC X9.63 Public Key 65

(SECP256R1) Bytes

32
SHA256 on RAW data
Bytes

AES256

RAW data
(AES256) n Bytes

Figure 5-2. Secure Content Delivery – File Format

5.2.3 Further Details

• The temporary ECC key from the Networking subsystem is nonpersistent. The current temporary key
becomes invalid when a new process is started, the SimpleLink device is restarted, or the host requested a
new key. Once the key is cleared, there is no way to recover it and content with this key is not be allowed.
• The ECC key follows the SECP256R1 named curve.
• The AES key is generated using the ECDHE algorithm with the NWP public key and the encoder private key.
• The encrypted file write should be in a sequential order with no possibility for offset writing (the offset field in
the write API is ignored).

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 27
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Security for Application Layers www.ti.com

6 Security for Application Layers

6.1 Secure Key Storage
The SimpleLink device supports asymmetric key-pair storage on the external flash with built-in crypto
acceleration and crypto services to assist in some common cryptographic-related operations.
These crypto services provide a mechanism to manage up to eight ECC key-pairs and use them to sign or verify
data buffers. This capability could be used for authenticating the device identity, among other usage options.
There are three types of supported key-pairs:
• Device-unique key-pair: A single 256-bit unique key of the device, embedded in hardware
• Temporary key-pair: Created upon request using the internal TRNG engine
• Installed key-pair: Installed and maintained by the vendor
The system key storage comprises eight indexed key-pairs.
Index 0 is reserved for the device-unique key-pair which is hardware-based. Indexes 1 to 7 are for temporary or
installed key-pairs, according to the application needs.
All keys are ECC keys using the SECP256R1 curve.
For all key pairs, the private key is not exposed and can only be applied indirectly when using it for signing and
decrypt operations. The public key may be retrieved by the host application.
6.2 Hardware Crypto Engines (CC3220/CC3230/CC3235x Devices Only)
The SimpleLink CC3220/CC3230/CC3235x MCU includes a set of hardware crypto engines to enhance the
performance of applications that require custom or application-level security. These engines offload the Arm®
Cortex®-M4 MCU from the complex and time-consuming arithmetic involved in cryptographic algorithms.
The device includes the following hardware crypto engines:
• Advanced encryption standard (AES)
• Data encryption standard (DES)
• Secure hash algorithm/message digest algorithm (SHA/MD5)
• Cyclic redundancy check (CRC)
• True random number generator (TRNG)
For more information on the hardware crypto engines, see the CC3220 SimpleLink™ Wi-Fi and Internet of
Things Technical Reference Manual or the SimpleLink Wi-Fi CC323x Technical Reference Manual.
6.2.1 Advanced Encryption Standard (AES)
The AES module provides hardware-accelerated encryption and decryption operations based on a binary key.
The AES is a block cipher module that supports 128-, 192-, and 256-bit keys for both encryption and decryption.
The module supports the following AES functionality:
• Basic AES encrypt and decrypt operations
• Key sizes: 128, 192, and 256 bits
• Key scheduling in hardware
• Feedback modes:
– Electronic code book mode (ECB)
– Cipher block chaining mode (CBC)
– Counter mode (CTR)
– Cipher feed back mode (CFB), 128-bit
– F8 mode
• AES-XTS
• AES-GCM (using AES-CTR mode and GHASH)
• AES-CCM (using AES-CTR mode and AES-CBC-MAC)

28 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Security for Application Layers

• Authentication-only modes CBC-MAC, f9

• Basic GHASH operation (selecting no encryption)
6.2.2 Data Encryption Standard (DES)
The DES module provides hardware-accelerated data encryption and decryption functions. The DES can run
either the single DES algorithm or the triple DES (TDES or 3DES) algorithm.
The DES algorithm generates block ciphers which operate on blocks of plaintext and cipher text. The DES has
an 8-byte (64-bit) block size. The DES key consists of 64 binary digits, but only 56 bits are actually used directly
by the algorithm. The other 8 bits may be used for error detection.
The triple DES is DES used three times in a row, using three keys, so that key length is effectively 168 bits. Each
triple DES encrypt or decrypt operation is a compound of DES encrypt and decrypt operations.
The DES accelerator includes the following main features:
• DES encryption and decryption
• Triple DES (or 3DES) encryption and decryption
• Feedback modes: ECB, CBC, CFB
6.2.3 Secure Hash Algorithm/Message Digest Algorithm (SHA/MD5)
SHA/MD5 is a hardware cryptographic accelerator used for hashing and message authentication.
This module can run the following algorithms:
• MD5 message digest algorithm
• SHA-1 algorithm
• SHA-2 (SHA-224 and SHA-256)
• Hash message authentication code (HMAC) operation using MD5, SHA-1, and SHA-2
The algorithms produce a condensed representation of a message or a data file, called digest or signature,
which can then be used to verify the message integrity.
• MD5 hash
• SHA-1, SHA-224, or SHA-256 hash algorithm
• Automatic HMAC key preprocessing for HMAC keys up to 64 bytes
• Host-assisted HMAC key preprocessing for HMAC keys larger than 64 bytes
6.2.4 Cyclic Redundancy Check (CRC)
CRC is an error-detection-code commonly used with data transfers and safety system checks, and also in
conjunction with AES and DES.
The CRC module supports the following features:
• Supports major CRC polynomials
– CRC-16-IBM
– CRC-16-CCITT
– CRC-32
– CRC-32C
– TCP checksum
• Supports half word and byte swapping
• Allows byte and word feed
6.2.5 True Random Number Generator
The TRNG is a physical random number generator used to generate true random numbers. It can be used by
the host to generate keys or any other application where true randomness is needed.

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 29
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Runtime Binary Protection www.ti.com

7 Runtime Binary Protection

The SimpleLink CC3220S, CC3220SF, CC3230S, CC3230SF, CC3235S, and CC3235SF devices provide
measures for protecting the host application runtime binary by leveraging the security features of the file system.
7.1 CC3220S/CC3230S/CC3235S Devices
On the SimpleLink CC3220S/CC3230S/CC3235S device, the application runtime binary is stored on an external
serial flash. This file is loaded upon boot to internal SRAM and executed from there.
The file is stored in the file system as a secure file with public write permissions and the fail-safe attribute set. As
such, all properties of a secure file apply to it. This includes encryption and the authenticity check.
The authenticity is achieved based on the trusted root-certificate catalog, and validated during programming. If
the signature of an image is invalid, the programming fails.
7.2 CC3220SF/CC3230SF/CC3235SF Devices
On the SimpleLink CC3220SF/CC3230SF/CC3235SF device, the application runtime binary can be stored on an
on-chip flash and directly executed from it (as with XIP). The device manages the on-chip flash internally, and
external direct access is prohibited unless development mode is applied.
During programming, the image is first downloaded onto the serial flash (to a predefined filename with the
name /sys/mcuflashimg.bin), where it is kept signed and encrypted. Upon first boot, the bootloader reads the
encrypted image from serial flash, then decrypts it and writes it onto the on-chip flash.
To ensure complete image integrity, a hash of the application binary is generated and stored on the file system
(as a secure system file). This hash is used during boot time to verify that the image stored on the on-chip flash
corresponds with the image that was properly programmed. The hash makes a link between the image on the
on-chip flash and the serial flash content. Changes in the serial flash after the image is copied onto the on-chip
flash are detected based on this hash and regarded as a tamper attempt. In this case, the on-chip flash is
erased.
The device supports a maximum size of 1022KB for the runtime binary. The application binary must be supplied,
with a signature, to the image creation tool. The authenticity is achieved based on the certificate store capability,
and validated during programming. If the signature of an image is invalid, the programming fails.
Figure 7-1 captures a simplified view of the image transfer process, from the serial flash to the on-chip flash in a
CC3220SF/CC3230SF/CC3235SF device.

30 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Runtime Binary Protection

SFLASH ON-CHIP FLASH

Application code
Application code image linked to run
The bootloader scans and detects from 0x0100_0800
a new image on the serial flash and copies it
/sys/mcuflashimg.bin to the on-chip flash.

Reset Vector (PC) Reset vector (PC)

Initial stack pointer (SP) Initial stack pointer (SP)

Image SHA pattern

The bootloader computes and stores the

hash of the on SFLASH in a new file.
2KB header 32-bit JTAG image pattern

32-bit image size

/sys/mcuflashimghash.bin Hash

32-bit header valid pattern

Figure 7-1. On-Chip Flash Programming and Update

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 31
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
Design for Security www.ti.com

8 Design for Security

8.1 Closing Remarks
Internet connectivity is often considered protected if the correct network configuration or firewalls are used. This
assumption is wrong and far from reality. The problem is that even if the network configuration or firewalls block
the access to the devices on the network level, or block some protocols and ports, the internet connectivity can
still exploit some application-level vulnerabilities (for example, by sniffing the traffic that passes through the
firewalls and configuration pages).
Protection based on firewalls or installation policies alone can lead to security breaches when the instructions
are not entirely clear, or when other devices in the network require looser security settings.
In the IoT era, basing the protection on these kinds of policies alone is even worse, because most of the
installations would likely be performed by unprofessional end users. This does not mean that this network
configuration is not required; however it does mean that the protection cannot rely on this alone, and must also
be designed in other layers.
In the last few years, the situation has become even worse, because most of these devices also enable remote
software updates (in the common terminology: OTA updates). These updates put at risk not only the specific
device that is updated, but also could give malicious users access to the local network. When an attacker
succeeds in replacing the software of an internet-enabled device (even a device that seems immaterial or
insignificant in terms of privacy and security), the attacker gains access to the local network, and therefore to
other devices on the local network. This kind of attack should be considered part of the local network security
assessment.
The common perception is that the local network connectivity is safe: only permitted devices or users are
connected to this network, and there is a network boundary to the internet. In reality, the major vulnerability of
LANs is a poor network security configuration. The availability of Wi-Fi networks among home users and
organizations make this kind of poor network security configuration much worse, because they allow everyone
access the local network without having a physical connection to an outlet inside the home or office. The only
requirement for the malicious user is to have a reasonable distance to this area (tenths of meters).
The LAN provides access to connected devices, ports, and protocol, which are mostly blocked from the WAN or
internet and by that provide much wider exposure points. A secured networking application should consider all
these vulnerabilities, and mitigate them with other layers of security.
In general, the overall OTA application firmware update process is outside of the scope of this document and
must be defined by the OEM. However, TI strongly recommends that the host application verifies the software
update origin by supporting the following:
• Verify the domain name of the OTA server.
• Authenticate the OTA server.
• Use secure tunnel (such as SSL/TLS) for content delivery.
To summarize, TI recommends following these designed-for-security best practices:
1. Identify your assets.
2. Identify possible vulnerabilities.
3. Protect what must be protected.
4. Use only well-known security practices.
5. Disable all unused services and functionality (for example, the HTTP server)

32 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
www.ti.com Revision History

Revision History
NOTE: Page numbers for previous revisions may differ from page numbers in the current version.
Changes from Revision B (May 2018) to Revision C (September 2020) Page
• Changed the document title and throughout document to include CC3230 devices.......................................... 3
• Changed the descriptions of the "Personal and Enterprise Wi-Fi security" and "Cloning protection" rows in
Table 1-2, Main Security Features ..................................................................................................................... 6
• Changed the AES entry in the "Personal" row in Table 2-1, Wi-Fi Security .....................................................10
• Changed the "Cloning protection" list item in Section 3.1, Overview ...............................................................18
• Changed the first sentence in Section 3.2.2, Cloning Protection .....................................................................19

SWRA509C – FEBRUARY 2017 – REVISED SEPTEMBER 2020 SimpleLink™ Wi-Fi® CC3x20, CC3x3x Built-in Security Features 33
Submit Document Feedback
Copyright © 2020 Texas Instruments Incorporated
 IMPORTANT NOTICE AND DISCLAIMER
TI PROVIDES TECHNICAL AND RELIABILITY DATA (INCLUDING DATA SHEETS), DESIGN RESOURCES (INCLUDING REFERENCE
DESIGNS), APPLICATION OR OTHER DESIGN ADVICE, WEB TOOLS, SAFETY INFORMATION, AND OTHER RESOURCES “AS IS”
AND WITH ALL FAULTS, AND DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION ANY
IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT OF THIRD
PARTY INTELLECTUAL PROPERTY RIGHTS.
These resources are intended for skilled developers designing with TI products. You are solely responsible for (1) selecting the appropriate
TI products for your application, (2) designing, validating and testing your application, and (3) ensuring your application meets applicable
standards, and any other safety, security, regulatory or other requirements.
These resources are subject to change without notice. TI grants you permission to use these resources only for development of an
application that uses the TI products described in the resource. Other reproduction and display of these resources is prohibited. No license
is granted to any other TI intellectual property right or to any third party intellectual property right. TI disclaims responsibility for, and you
will fully indemnify TI and its representatives against, any claims, damages, costs, losses, and liabilities arising out of your use of these
resources.
TI’s products are provided subject to TI’s Terms of Sale or other applicable terms available either on ti.com or provided in conjunction with
such TI products. TI’s provision of these resources does not expand or otherwise alter TI’s applicable warranties or warranty disclaimers for
TI products.
TI objects to and rejects any additional or different terms you may have proposed. IMPORTANT NOTICE

Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2022, Texas Instruments Incorporated