Qualcomm Linux Security Guide

80-70020-11 AC

July 21, 2025

© Qualcomm Technologies, Inc. and/or its subsidiaries. All rights reserved.

Contents

1 Security overview 3
1.1 Qualcomm Linux product security . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Watch video on IoT security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2 Verify the security configurations of Qualcomm Linux 35

2.1 Verify TrustZone/device configuration/Hypervisor image loading . . . . . . . . . . . 35
2.2 Verify secure boot and UEFI secure boot . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3 Verify SELinux status and customize SELinux policies . . . . . . . . . . . . . . . . 37
2.4 Verify PIL image loading - Sample logs . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5 Verify Qualcomm TEE mink/global platform TEE API availability . . . . . . . . . . . 39
2.6 Verify SMC invoke driver status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7 Verify RPMB provisioning status . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.8 Verify Qualcomm WES status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.9 Verify trusted and client applications . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.10 Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Configure security services 43

3.1 Enable device configurations from Qualcomm TEE . . . . . . . . . . . . . . . . . . 43
3.2 Enable secure boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Enable SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.4 Enable UEFI secure boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.5 Install or upgrade the SoftSKU feature packs . . . . . . . . . . . . . . . . . . . . . 117
3.6 Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4 Customize secuity services 123

4.1 Customize memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.2 Customize SEPolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.3 Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

5 Debug Qualcomm TEE and secure devices 125

5.1 Debug Qualcomm TEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.2 Debug trusted and client applications . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.3 Debug on secure devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.4 Flash APDP on device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

80-70020-11 AC May contain U.S. and international export controlled information 2

 Contents

5.5 Qualcomm TEE/TrustZone diag log collection on secure device . . . . . . . . . . . 130

5.6 Qualcomm TEE/TrustZone diag log decryption steps . . . . . . . . . . . . . . . . . 132
5.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6 Develop trusted and client applications 134

6.1 Security APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.2 Use security services examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

7 References 137
7.1 Related documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.2 Acronyms and terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

80-70020-11 AC May contain U.S. and international export controlled information 3

1 Security overview

Qualcomm® Linux® is an advanced security framework designed to protect devices running on

Qualcomm Linux. It integrates several critical components and methodologies to ensure robust
security across various layers of the system.

1.1 Qualcomm Linux product security

The Qualcomm Linux product security provides a comprehensive framework designed to protect
devices from both software and hardware threats. Its security foundations ensure robust protection,
high performance, and energy efficiency.
The following figure shows the major components of the security foundation framework.

Figure : Qualcomm Linux Security foundations

The following list describes each component within the Qualcomm Linux secure foundations:
• Cryptography: Provides enhanced security and faster encryption/decryption operations
through crypto engines and hardware keys.
• Key management: Uses a one-time programmable (OTP) eFuse memory referred as the
Qualcomm fuse programmable read only memory (QFPROM) to store generic information

80-70020-11 AC May contain U.S. and international export controlled information 4

 Security overview

and configurations.
• Storage security: Offers encrypted storage for digital rights management (DRM) keys and
certificates. These keys are securely provisioned. The replay protected memory block
(RPMB) is a separate partition in the universal flash storage (UFS) device designed for
secure data storage.
• Secure boot: Offers image authentication and tamper-resistant root of trust (RoT) in
electronic fuses (eFuse).
• Debug security: Allows debugging in a secure environment. It’s set by an eFuse and restricts
the invasive (INV) and non-invasive (NINV) debug capabilities in commercial products and
reverse engineering. For more information, see Learn the architecture - Before debugging on
Armv8-A.
• Access control: Prevents unauthorized code execution using the access-controlled memory
and peripherals.
• Qualcomm® Trusted Execution Environment (Qualcomm TEE): Isolates the secure and
non-secure software operations. It’s built on the Arm® TrustZone® architecture and has a
rigorously reviewed small code base.
• Qualcomm Hypervisor: Allows many operating system environments to run simultaneously
and independently.
• Qualcomm® wireless edge services (WES): A cloud-based service that ensures trust
throughout the device lifecycle using hardware RoT. Qualcomm WES provides services such
as hardware-based attestation, zero-touch device provisioning, and chipset feature
management.

Note: See Hardware SoCs that are supported on Qualcomm Linux.

1.2 Watch video on IoT security

Introduction to Qualcomm Processor Security
Dive deep into the world of IoT security with our comprehensive guide focused on Qualcomm chip
products. Learn how to optimize and enhance the safety of your IoT products through advanced
security solutions. This video covers everything from understanding potential threats like code
modifications and key exposures to implementing foundational security requirements. Whether you
are dealing with biometric authentication or cloud connectivity, discover how Qualcomm Linux
Security features can safeguard your devices against evolving cyber threats and meet stringent
regulatory standards. Join us to fortify your IoT devices now!

80-70020-11 AC May contain U.S. and international export controlled information 5

 Security overview

Security architecture
Arm® v8 has enhanced the TrustZone technology to incorporate security into its architecture. This
technology offers a security framework that allows a device to handle security threats at both
software and hardware levels.

Note: The architectural information is for comprehension purposes only. You don’t need to
perform any configuration or customization.

Arm’s hardware solution allows the design and deployment of software, applications, or services
within a secure execution environment. This environment is a separate execution unit that ensures
hardware isolation from non-secure execution environments. For more information, see Qualcomm
TEE.
Qualcomm Linux operates on a 64-bit Arm 8.x architecture. In this setup, Arm cores have two
execution modes:
• Non-secure mode: Linux operates in this mode of the Arm core.
• Secure mode: Qualcomm® Trusted Execution Environment (TEE) and trusted applications
operate in this Secure mode of the Arm core.
The secure mode of the Arm core forms the essence of the TrustZone technology. It provides a
hardware-based security environment for a secure OS and separates the secure world from the
non-secure world.
The following figure shows the Qualcomm Linux security software architecture. It shows the
distribution of components or modules across both the rich (user space and kernel space) and
trusted execution environments.

80-70020-11 AC May contain U.S. and international export controlled information 6

 Security overview

Figure : Qualcomm Linux security software components

The Qualcomm Linux security software has the following key components, each operating in
different execution environments.

Table : Execution environments and key components

Exception levels Software components
Non-secure EL0 Linux user space - MINK, key management, client
applications,and Qualcomm® wireless edge services
(WES)
Non-secure EL1 Linux kernel space - SMC invoke and
cryptographic/PRNG driver
Non-secure EL2 Qualcomm Hypervisor
Secure EL0 Qualcomm TEE SDK and trusted application
Secure EL1 Qualcomm TEE MINK
Secure EL3 Secure monitor

80-70020-11 AC May contain U.S. and international export controlled information 7

 Security overview

Linux user space (Non-secure EL0)

This user space includes the primary security modules/interfaces present in the Linux user space,
which operates in non-secure EL0 according to the Arm exception levels.
• MINK - Linux (MINK platform/system listener services/transport mechanism)
• Provides the services and transport mechanism to use the Qualcomm TEE capabilities
through trusted applications.
• Forms the system listener services, designed to extend the Qualcomm TEE functionalities.
The MINK interface is also commonly known as SMC invoke.
• Implements the global platform TEE client APIs for running global platform-based trusted
applications through libGPTEEC and libMTEEClibraries. For more information,
see TEE Client API Specification.
• Implements client applications in a rich execution environment (Linux user space). It interacts
with the trusted application that operates in Qualcomm TEE. The various client applications
include:
– SMC invoke-based/MINK client applications
– Client application that’s developed using MINK/SMC invoke APIs
– Global platform-based client application
– Client application that’s developed using the global platform-based TEE client API
specification
• Key management
• The cryptographic client library (libckteec) interfaces with the PKCS#11
interface of TEE. User space applications running on Linux can use this library for
direct access to the PKCS#11 interface.
• The libckteec library defines the interface between an application and a
cryptographic device, enabling applications to treat cryptographic devices as
tokens and perform cryptographic functions as implemented by these tokens.
• The PKCS#11 interface provides a range of cryptographic services for encryption,
decryption, signature generation, signature verification, and permanent key
storage.
The figure shows key management in the kernel and user space.

80-70020-11 AC May contain U.S. and international export controlled information 8

 Security overview

Figure : Key management in kernel and user space

• For more information about key management, see Qualcomm WES and Storage encryption.
• For more information about the various security software components, see Security features.

80-70020-11 AC May contain U.S. and international export controlled information 9

 Security overview

Linux - Kernel space (Non-secure EL1)

The following are the security-specific kernel drivers:

• SMC invoke driver:
• Provides a Linux abstraction for Qualcomm TEE objects by encapsulating them in file
descriptors.
• Marshalls invocations into the Qualcomm TEE objects in buffers that are shared with
Qualcomm TEE.
• Tracks and dispatches callback invocations to Linux processes.
• Tracks all the shared memory objects, providing information about them to Qualcomm TEE.
• For the CM and cryptographic/PRNG drivers, see the respective kernel documentation.

Qualcomm Hypervisor (Non-secure EL2)

For more information, see Qualcomm Hypervisor.

Qualcomm TEE SDK (Secure EL0)

Qualcomm offers a software development kit (SDK) for developing and building trusted
applications. This SDK includes the necessary build system, header files, and library
dependencies to compile trusted applications.
• Trusted applications. See Qualcomm TEE → Trusted applications.
• To develop the SMC invoke trusted applications, global platform trusted applications, and
IDL/Object-based Qualcomm TEE, service APIs are available to licensed developers with
authorized access. For more information, see Qualcomm Linux Security Guide - Addendum.

80-70020-11 AC May contain U.S. and international export controlled information 10

 Security overview

Qualcomm TEE MINK (Secure EL1)

In a Qualcomm TEE kernel-based system, software operates in one or more communicating

domains, such as the kernel domain or user domain.
These domains vary in their ability to access memory and other system resources.
• One of these domains, referred to as the kernel domain, executes at secure EL1 and has
complete control over the system resources.
• The other domains, known as user domains or processes, run at secure EL0 and have
restricted access to system resources. MINK allows for precise control over the access
granted to a process.
An IPC primitive is an object capability-based synchronous message passing facility, which allows
code execution in one domain to invoke objects running in other domains. The IPC MINK-primitives
enable communication between the domains.

Secure monitor (Secure EL3)

The secure monitor, a component of TrustZone, is responsible for managing the transition between
the secure and non-secure worlds.
It operates in Monitor mode, which is activated by running the secure monitor call (SMC) instruction
from a privileged Arm mode.
The secure monitor ensures correct context saving and restoration when switching between the
non-secure and secure worlds. Additionally, it handles the initial processing of secure interrupts.

80-70020-11 AC May contain U.S. and international export controlled information 11

 Security overview

Security features
Qualcomm Linux incorporates several security features designed to protect devices and
applications. These features are essential for defending against vulnerabilities, ensuring data
integrity and confidentiality, maintaining compliance with industry standards, and supporting overall
system stability.
Qualcomm TEE further enhances these security capabilities. It provides interfaces that enable the
extension of the security feature set through trusted applications. The hardware-supported
TrustZone architecture integrates certain features, providing a system security configuration.
These features can be further customized to meet specific requirements.
Explore the following security features and videos in this section.

Cryptography

Key management

Secure boot

Storage security

Storage encryption

SMC invoke

Access control

Secure peripheral image loading

SELinux

Qualcomm TEE

Qualcomm Hypervisor

Security hardening

Qualcomm WES

Watch a video on secure boot technology

Watch video on Qualcomm® Type-1 Hypervisor and trusted execution environment

80-70020-11 AC May contain U.S. and international export controlled information 12

 Security overview

Cryptography

Qualcomm Linux provides comprehensive cryptographic support, leveraging both

hardware-accelerated and software-based implementations to enhance system security.
The key capabilities include:
• A register and bus access manager with direct memory-based access.
• Interfaces to the cryptographic hardware.
• The Linux kernel crypto driver (qcrypto) provides access to the hardware cryptography
independent of trusted applications.
• The Qualcomm TEE provides the hardware and software cryptographic application
programming interfaces (APIs) to the trusted applications.
Qualcomm TEE supports the following cryptographic algorithms:

Table : Cryptographic algorithms

Algorithm Hardware Software
Hash SHA-1/SHA-256
• SHA-1/SHA-224/SHA-
256/SHA-384/SHA-512
• SM3

Symmetric
cipher • AES-128/AES-256 CBC, ECB, • AES-128/AES-192/AES-256
CTR, CCM, GCM, CBC, ECB, CTR, CCM, XTS,
• Triple-TDES CBC/ECB CFB, OFB, CTS
• Triple-TDES CBC/ECB
• PBKDF2
• SM4

MAC AES-CMAC Hash-based message authentication

(HMAC)
RNG HRNG –
HMAC HMAC-SHA-1/SHA-256 HMAC-SHA-1/SHA-224/SHA-
256/SHA-384/SHA-512

80-70020-11 AC May contain U.S. and international export controlled information 13

 Security overview

Algorithm Hardware Software

Asymmetric –
cipher • RSA with 1024/2048/3072
modulus
• ECDSA with P224, P256,
P384, P521
• ECDH
• SM2

Inline crypto engine

The inline crypto engine (ICE) performs high-throughput cryptographic encryption of storage data.
ICE supports:
• AES 128/AES 256 ECB/XTS
• Multiple crypto streams to meet high throughput
• Multiple AES cores per crypto stream
• Provision of 32 software configurable keys
• Capability to enable symmetric and asymmetric operations

Key management

The Qualcomm Linux Security solution supports public-key cryptography standards through the
implementation of PKCS#11 APIs. This allows applications to manage and use cryptographic keys
and certificates in a platform-independent and standardized manner.
Qualcomm implements PKCS#11 as a global platform interface for running trusted applications
within the Qualcomm TEE. A corresponding implementation is also available in the rich execution
environment (REE), allowing seamless integration and interoperability between secure and
non-secure application domains.
For more information, see the following documents:
• PKCS #11 Cryptographic Token Interface Base Specification
• PKCS #11 Cryptographic Token Interface Usage Guide
Limitations
The following functionalities aren’t supported:
• Random number generator functionality
• P-192 in CKM_ECDSA

80-70020-11 AC May contain U.S. and international export controlled information 14

 Security overview

• RSA PKCS key generation and signing in CKM_RSA_PKCS mode

• EDDSA key generation and signing

Watch a video on secure boot technology

Qualcomm Processor Security: Foundation

Unlock the full potential of Secure Boot technology on Qualcomm devices in this comprehensive
tutorial. From generating cryptographic keys to programming hardware fuses and managing secure
boot status, this video covers every step in detail. Ideal for users aiming to enhance device security
through authenticated boot processes. Learn how to use Qualcomm tools effectively to ensure
your device boots securely every time.

80-70020-11 AC May contain U.S. and international export controlled information 15

 Security overview

Secure boot

Secure boot is the boot up sequence that establishes a trusted platform for the entire software
stack.
See the workflow to understand the secure boot and UEFI secure boot process.

Figure : Secure boot vs UEFI secure boot

This process uses cryptographic authentication to start an immutable sequence that validates the
origin of the code, ensuring the execution of authorized software. This process:
• Confirms the authenticity of all software images (non-Linux images) signed by Qualcomm
and the users. The device carries out this process.
• Prevents any unauthorized or maliciously modified software from running on the device.
The secure boot feature authenticates non-Linux images while UEFI secure boot authenticates the
Linux images.
UEFI secure boot
UEFI secure boot is a feature of the unified extensible firmware interface (UEFI) specification that
defines an interface between an operating system and the platform firmware.
For more information, see UEFI specification.
The features of UEFI secure boot include:

80-70020-11 AC May contain U.S. and international export controlled information 16

 Security overview

• Ensuring that the code run by the device UEFI firmware is secure and trusted before the
operating system begins boot up.
• Defining how the UEFI authenticates images such as the Linux image, the operating system
loader ([Link]), systemd boot ([Link]), and the device tree blob (DTB) image files.
• Ensuring that the images are loaded only when signed by valid and authorized users. This
process also ensures that the Qualcomm Linux security and integrity over systems running
on UEFI-based firmware.
The UEFI secure boot allows the Qualcomm Linux users to:
• Verify the integrity and security of a UEFI loaded image, ensuring it’s loaded in an approved
manner.
• Manage the Qualcomm Linux security policy as defined by the UEFI secure boot
authenticated variables, which includes:
– Platform key (PK)
– Key exchange keys (KEK)
– Allowed database (dB)
– Forbidden database (DBX) (Not supported in this release.)

Storage security

The secure file system (SFS) stores sensitive data, such as keys and biometric data.
SFS
SFS provides confidentiality, integrity, and anti-rollback support to the trusted applications and
securely stores sensitive data. The anti-rollback protection covers the files created or stored under
SFS . The SFS feature:
• Uses an encryption key for each trusted application to ensure the confidentiality of the files.
• Uses an HMAC key for each trusted application to verify the integrity of the files.
Both the encryption and HMAC keys are derived using a device unique key, which depends on the
secure boot state of the device. The SFS anti-rollback protection is enabled by default.
When the devices are secure boot enabled, the SFS uses unique hardware keys for file data
encryption and decryption to ensure they’re secure from each other.
RPMB
RPMB is a physical partition on the UFS/eMMC flash. This partition is used to store sensitive
information and is only accessible from Qualcomm TEE.
To read from and write to the RPMB partition, RPMB key provision is required. This is a one-time
process that can’t be overwritten or erased when completed.

80-70020-11 AC May contain U.S. and international export controlled information 17

 Security overview

Every access to the RPMB is authenticated, allowing the host to store data in an authenticated and
replay-protected manner.

Storage encryption

Storage encryption enhances security by supporting the transparent encryption of files and
directories.
The Qualcomm Linux supports storage encryption with the Inline crypto engine and a
hardware-wrapped key. It provides better efficiency and enhanced key protection.
The storage encryption feature allows:
• Provision of standard keys ranging from 32 bytes to 64 bytes for content encryption
• Encryption of filenames and file content with separate keys
• Generation of 32-byte key identifiers
The Qualcomm universal flash storage (UFS) driver is added to support the fscrypt API.
For more information about the fscrypt API, see Filesystem-level encryption (fscrypt) Linux
kernel documentation.
For related kernel documentation, see the following files:
• Inline encryption
• I/O control (IOCTL) support for storage encryption
You can invoke the storage encryption functionality using the open-source fscryptctl tool.

SMC invoke

The secure monitor call (SMC) invoke is used to expose the services and interfaces implemented
in Qualcomm TEE to Linux clients. It provides identification information about the requesting
processes to Qualcomm TEE.
The SMC invoke is an object-oriented, capability-based framework that enables communication
between Linux clients, TrustZone, and the TrustZone applications, which use mini-kernel (MINK)
invoke objects.
During the SMC invoke process, the following objects are involved:

80-70020-11 AC May contain U.S. and international export controlled information 18

 Security overview

Table : Objects - SMC invoke

Objects Owner execution Description
environment
Remote TrustZone Linux obtains references to remote objects
through the invoked operations. For example,
an AppLoader, which is a remote object.
Callback Linux Linux sends references of the required callback
objects through the invoked operations to the
TrustZone, which may invoke these objects as
needed.
Memory Linux These memory objects are useful for efficiently
sharing large buffers between TrustZone and
Linux.

The figure shows the SMC invoke architecture:

Figure : SMC invoke architecture

The SMC invoke has the following components:
• Linux kernel:

80-70020-11 AC May contain U.S. and international export controlled information 19

 Security overview

The SMC invoke driver in the kernel is responsible for transporting user space requests
between the TrustZone and the Linux user space clients. It exposes the following input/output
controls (IOCTL).
– SMCINVOKE_IOCTL_INVOKE_REQ
– SMCINVOKE_IOCTL_ACCEPT_REQ
– SMCINVOKE_IOCTL_SERVER_REQ
– SMCINVOKE_IOCTL_ACK_LOCAL_OBJ
• Linux user space:
The SMC invoke in the user space includes [Link] and the SSGTZD
daemon.

Table : SMC invoke modules

Module Description
SMCInvoke client This client communicates with the trusted applications in
Qualcomm TEE through the SMC invoke driver.
TA client This client communicates with the TrustZone applications
through the SMC invoke driver.
Libminkdescriptor
• The module creates a bridge between the user
space client and kernel.
• A client using SMC invoke must use
libminkdescriptor to communicate with
the kernel.
• The [Link] is available at /
usr/lib/[Link]

SMCInvoke driver
• The driver in the Linux kernel communicates with
application clients and the trusted applications in
the TrustZone.
• The SMC invoke driver source code is available at
/kernel/drivers/soc/qcom/smcinvoke/
smcinvoke.c.

80-70020-11 AC May contain U.S. and international export controlled information 20

 Security overview

Access control

Access control ensures only authorized entities can access specific resources under defined
conditions, using policies, technologies, and trust models.
The access control trust model ensures ongoing security by managing access control
configurations among various assets, interfaces, SoC (system on chip) components, and images.
This model helps support the integrity and confidentiality of sensitive information.
• The Qualcomm access control uses an external protection unit (xPU) to control access from
the secondary side for registers, fixed address, and dynamic memory regions.
• The system memory management unit (SMMU) controls access from the primary side for
content protection and subsystem memory sharing use cases.
Access control domains
The two levels of control are:
1. The TrustZone manages the TrustZone-domains and controls access from the secondary
side using xPUs.
• An xPU is a combination of many security blocks known as protection units. It allows
conditional access based on a set of programmable access control registers.
• If the system denies access, the xPU generates an error output signal and, if necessary,
an interrupt request signal.
2. The hypervisor (EL2) manages the non-secure domains, including the content protection
zone (CPZ) that’s designed to prevent access to premium videos.
• It configures access control from the primary side through the second-stage page
tables through the SMMU.
• It manages stage-2 mappings to protect assets across all primary domains (Linux,
display, GPU, and video). The Linux kernel manages stage-1 mappings to protect the
assets in applications that run at the user privilege level.
The figure shows the access control domains.

80-70020-11 AC May contain U.S. and international export controlled information 21

 Security overview

Figure : Access control domains

Secure peripheral image loading

The secure peripheral image loading (PIL) of a TrustZone authenticates different images and
configures the xPUs for all subsystems such as audio, camera, and video.
For more information about xPU, see Access control.

SELinux

SELinux is a security enhancement for Linux, providing greater control over system access. It
implements mandatory access control (MAC) in the Linux kernel using the Linux security modules
(LSM) framework.
For more information, see What’s SELinux?
The LSM framework includes the following controls:
• Discretionary access control (DAC)
– This is the standard form of Linux access control. The data owner has full control over the
resource (such as data and files) and can update or modify the data.
– Some applications (with root privilege) can override this control. Some resources, like the
socket, are unchecked.
– Access controls are provided with limited granularity, based on user and group identity. For
example, File mode -rwxr-xr-x-.
• MAC
– A system-wide security policy determines the Linux access controls for all processes,
objects, and operations.

80-70020-11 AC May contain U.S. and international export controlled information 22

 Security overview

– The policy can confine flawed and malicious applications or incautious users. It can even
prevent users from escalating privilege such as root or UID 0.
– MAC provides finer granularity to access controls, allowing access to many more
resources other than files with more specific controls. For example, unlink, append only,
or move a file.
The figure shows the steps in the decision-making chain for DAC and MAC:

Figure : Linux security modules: DAC and MAC

SELinux supports three modes:
• Enforcing mode: In this mode, the SEPolicy is enforced on the system. If the SEPolicy rules
aren’t met when software is run, access is prevented. The kernel logs an attempted access
violation as an access vector cache (AVC) denial message to dmesg and journalctl.
• Permissive mode: In this mode, the SEPolicy isn’t enforced on the system. All denials are
logged into dmesg and journalctl logs, but access of a process or software isn’t
disallowed.
• Disable mode (Default): In this mode, the SEPolicy isn’t enforced or logged.
For information about enabling SELinux, see Enable SELinux. To configure the SELinux modes,
see SELinux configuration.

80-70020-11 AC May contain U.S. and international export controlled information 23

 Security overview

SELinux layers
The SELinux dynamic layer incorporates essential SELinux-specific code modifications that
activate and initialize the device when SELinux is enabled with a monolithic design.

Figure : SELinux layers

This layer is built on top of the meta-SELinux layer, which is part of the Yocto upstream. It includes:
• The recipe-kernel, which contains the recipe to enable the required kernel configuration flags
for SELinux.
• The recipe-security includes:
– Policies for booting the device to the shell
– Policies for Qualcomm services and test applications
– Policies of upstream services in the form of patches
– A recipe to handle compilation of Qualcomm policies
SEPolicy
SEPolicy is a directory that contains the core SELinux policy configuration.
The upstream SEPolicy is defined in sepolicy, which is downloaded during the build and
amended with Qualcomm SEPolicy at: layers/meta-qcom-hwe/dynamic-layers/
selinux/recipes-security/sepolicy/.
The upstream directory structure is adhered to, with apps/kernel/system/services added
to the respective directory.
The figure shows the high-level directory structure that’s merged and compiled to generate
policy.33, which is the SEPolicy binary used or loaded during boot.

80-70020-11 AC May contain U.S. and international export controlled information 24

 Security overview

Figure : SEPolicy high-level directory

For more information, see Customize memory and SEPolicy.

80-70020-11 AC May contain U.S. and international export controlled information 25

 Security overview

Watch a video on Qualcomm Type-1 Hypervisor and trusted execution environment

Qualcomm Processor Security: TEE and Chipset Services

Learn how to use Qualcomm Type-1 Hypervisor and Trusted Execution Environment in this
comprehensive tutorial. Dive deep into platform virtualization, secure communication, and the
extensive security features offered by Qualcomm. Learn how to develop secure applications using
Qualcomm tools and APIs, and understand the critical security use cases and compliance
standards that Qualcomm supports. Perfect for users aiming to enhance device security and
functionality.

Qualcomm TEE

Qualcomm TEE is the software that operates within the Arm TrustZone environment on the
Qualcomm device.
The TrustZone is a hardware-based security architecture enabled through a Secure mode of the
Arm processor. It establishes two execution environments with system-wide hardware-enforced
isolation. For more information, see What’s TrustZone?.
Qualcomm offers a 64-bit Arm 8.x processor system with hardware virtualization to run TrustZone.
In the TrustZone architecture, there are two security states:
• Secure
• Non-secure
At the EL0, EL1, and EL2 exception levels, the processor can be in either the secure state or the
non-secure state while EL3 is always in the secure state.
The operating system runs in non-secure EL1. The transition from Non-secure to Secure mode is

80-70020-11 AC May contain U.S. and international export controlled information 26

 Security overview

facilitated through a Secure Monitor mode.

Qualcomm TEE provides the following features:
• Operation from hardware-protected memory
• Support for power-collapse of security blocks such as the crypto engine, PRNG, inline crypto
engine, and external protection units (xPU)
• Support for a secure peripheral image loader (PIL)
• Support for subsystem restart
• Provision of content protection
• Support for running trusted applications
• Support for fuse management
Trusted applications
Trusted applications (TA) offer services within a secure environment for Linux clients that aren’t
secure. Qualcomm TEE extends the following services to TA:
• Support for trusted applications to operate in the secure world at EL0
• Sand-boxing environment for trusted applications
• Position-independent loading of trusted applications
• Message passing between different trusted applications
TA operates from the memory that’s protected by the hardware. However, the applications that
require more memory can use double data rate (DDR) memory for loading and running. By default,
an application is set to run from hardware-protected memory.

80-70020-11 AC May contain U.S. and international export controlled information 27

 Security overview

Qualcomm Hypervisor

Qualcomm Hypervisor provides a modern virtualization framework that allows multiple operating
systems to run independently and concurrently, delivering high performance.
Qualcomm Type-1 Hypervisor facilitates the hosting of multiple trusted execution environments for
secure use cases. The figure shows the Qualcomm Hypervisor software architecture, components,
and virtual machines. It also includes an example of one guest virtual machine using the Linux
kernel.

Figure : Hypervisor architecture

Qualcomm Type-1 Hypervisor, also known as a native Hypervisor, does the following:
• Provides enhanced security compared to Type 2 (hosted) Hypervisors
• Supports multi-core, real-time operations that are independent of Linux
• Operates distinctly, independently, and with higher privileges than Linux
• Has a minimal impact on the performance
The architecture of the Type-1 Hypervisor includes Qualcomm Hypervisor access control, which
supports:
• Multiple operating systems
• Smaller attack surface

80-70020-11 AC May contain U.S. and international export controlled information 28

 Security overview

The figure shows a Type-1 Hypervisor.

Figure : Type-1 Hypervisor

Virtualization
Virtual machines and CPUs provide flexibility and abstraction. The Qualcomm Hypervisor provides
the following virtualization features:

80-70020-11 AC May contain U.S. and international export controlled information 29

 Security overview

Table : Qualcomm Hypervisor virtualization features

Feature Description
Memory management
• Qualcomm Hypervisor manages
stage-2 page tables and translates
the intermediate physical address
(IPA) to the physical address (PA)
• It also isolates memory between
virtual machines

Interrupt virtualization It virtualizes and maps interrupts to

the correct and independent virtual
machines
Scheduling The virtualization CPU (VCPU)
scheduler prevents virtual machine
starvation during failure
Interprocess communication (IPC) This includes shared memory, message
passing (IPC) APIs, and virtual interrupts
Power management It supports multiple virtual machines and
adopts the lowest common denominator
power state

Qualcomm Hypervisor BSP

Qualcomm Hypervisor supports the following features within the board support package (BSP):
• PIL
• Access to SoC AC policy
• System MMU driver
• Pathway support for SMC TrustZone communication
The figure shows all the features of a Qualcomm Hypervisor and the BSP, which collectively
provide a complete hypervisor solution:

80-70020-11 AC May contain U.S. and international export controlled information 30

 Security overview

Figure : Qualcomm Hypervisor and BSP

Resource manager
The exception level 1 (EL1) resource manager performs the following functions:
• Creates and manages virtual machines
• Handles and assigns the virtual machine admission control policy
• Manages the I/O pass-through, which includes:
– I/O space mapping and isolation
– Interrupt routing configuration
For more information, see Qualcomm Linux Kernel Guide.

80-70020-11 AC May contain U.S. and international export controlled information 31

 Security overview

Security hardening

Security hardening is a process that minimizes the risk of system attacks by making it more
challenging for attackers to exploit the system vulnerabilities.
Kernel security hardening aligns with upstream kernel guidelines. Key kernel flags like KASLR,
hardened user copy, stack protector, and permissions (RWX) are enabled.
User space hardening
The security_flags.inc file, a part of the Yocto Project is used to enable security compiler and linker
flags for a build.
To extend this feature to the Qualcomm modules, add the following command to
qcom-security_flags.inc (file path: qcom-security_flags.inc):

require conf/distro/include/security_flags.inc

Adding these flags may result in warnings or errors that can disrupt a build. However, Yocto
provides a way to disable certain compiler flags for problematic packages. Modern compilers such
as GCC and Clang offer a wide range of compiler flags that can make it more difficult for an
attacker to exploit certain types of vulnerabilities.
The following are the example flags with GCC:
• The Wformat flag adds compile-time checks to detect issues related to the format of string
arguments in common library functions such as printf, scanf, and strftime.
• The D_FORTIFY_SOURCE flag adds compile and runtime checks to detect buffer overflows
in memory and string functions.
• The Fstack-protector flag adds runtime checks to detect buffer overflows and stack
smashing.
• The Fpie flag enables position-independent code, which allows for loading the binary at
randomized locations, thus making certain types of attacks (like return-oriented
programming) more difficult.
• The Wl,-z,relro,-z,now flag makes it harder to abuse a binary global offset table.
If there are warnings and errors, customizing these flags for some modules can break a build. The
binaries in a file system can be verified if the compiler exploit mitigation features are applied using
the Checksec tool.
For information about making images more secure, see The Yocto Project Documentation.

80-70020-11 AC May contain U.S. and international export controlled information 32

 Security overview

Qualcomm WES

Qualcomm WES is a suite of trusted services, rooted in hardware, which securely connects and
manages devices.
It provides the following services:
• Feature licensing enables device features identified by a feature ID and an alias feature
name. These features are enabled by installing the corresponding feature licenses or
certificates.
• Device attestation provides cryptographically signed and encrypted data items that describe
the security state of the device and its software. These data items are useful for risk engines
and other similar applications.
• Secure provisioning enables the generation and use of cryptographic keys that are secured
using unique device keys. These keys are used to:
– Securely provision data to the device post-sale and over-the-air (OTA).
– Sign data on the device.
To install or upgrade QCS5430 SoftSKU feature packs, see: Install or upgrade SoftSKU feature
packs.
To develop applications that offer hardware-based attestation, zero-touch device provisioning, and
chipset feature management, see: Qualcomm Linux Wireless Edge Services Guide. This feature is
available to licensed users with authorized access.

Security tools
To build secure software on Qualcomm devices using TrustZone and secure boot, the key tools
needed are SecTools v2 and LLVM compiler for Arm® , targeting the Snapdragon® devices.
SecTools v2 is a suite of Qualcomm security tools designed to support secure boot, image
authentication, debug policy creation, and fuse programming across Qualcomm SoCs. The LLVM
compiler for Qualcomm TEE is a specialized toolchain used to build secure software components
for TEE on Qualcomm devices.

Build system

For more information about the toolchain, build process, and compilation, see Qualcomm Linux
Build Guide.

80-70020-11 AC May contain U.S. and international export controlled information 33

 Security overview

Set up SecTools v2 for secure boot

1. Go to the SecTools v2 folder.

Use the following path structure to locate the tools.
<chipset>.LE.X.x/common/sectoolsv2/ext/<platform>
This folder has the binaries and scripts required for secure boot, image signing, and other
security operations.
2. Locate the security Profile XML.
Find the <chipset>_security_profile.xml security profile file in meta.
<chipset>.LE.X.x/common/sectoolsv2
This XML file defines the security configuration used by SecTools.

Note: The minimum SecTools version required is 1.17 or later.

The table lists the documentation for SecTools v2.

Table : SecTools v2
Document Description
SecTools V2: Metabuild Secure Image Perform the secure-image operations on metabuild
User Guide software images.
SecTools V2: Fuse Blower User Guide Create and sign the fuse blower images. When
a device uses a fuse blower image, it blows the
specified fuse.
SecTools V2: ELF Tool User Guide Generate, add segments, and combine the ELF
software images.
SecTools V2: MBN Tool User Guide Add the modem configuration binary (MBN) headers
to binary images.
SecTools V2: ELF Consolidator User Create the consolidated ELF software images.
Guide A consolidated ELF has the contents of many
subsystem images.
SecTools V2: Secure Image User Guide Sign, encrypt, and inspect Qualcomm software
images.
SecTools V2: Secure Debug User Guide Generate and sign the debug policy images to
enable device debugging and authentication.

Note: The SecTools guides are available to licensed users with authorized access.

80-70020-11 AC May contain U.S. and international export controlled information 34

 Security overview

Next steps

• To initialize and configure the hardware for running securely on Linux, see Verify security
configurations.
• To configure Qualcomm TEE for securing devices that handle sensitive data and run trusted
applications, see Configure security services.

1.3 Next steps

• To learn about TrustZone and security framework, see Security architecture.
• To explore the full range of integrated protections and capabilities, see Security features.
• To learn about security tools and how to integrate them into your workflows, see Security
tools.

80-70020-11 AC May contain U.S. and international export controlled information 35

2 Verify the security configurations of
Qualcomm Linux

The security verification process involves checking and validating the security features of hardware
and software components to ensure they operate securely on Qualcomm Linux. This process
ensures that the listed security features meet the necessary requirements to make the system
robust and secure.
Prerequisites
• Build and load the software on the device.
• Enable the secure shell (SSH) in permissive mode to securely access your host device.

2.1 Verify TrustZone/device configuration/Hypervisor image

loading
By verifying the TrustZone (secure) environment, you ensure that the device’s security architecture
is robust and reliable, providing a foundation for secure operations.
The following XBL logs contain information about the TrustZone/Device configuration/Hypervisor
image loading.
For example:
• Device configuration (DEVCFG)
B - 1206031 - QSEE Dev Config - Image Load, Start
D - 763 - Auth Metadata
D - 549 - Segments hash check
D - 13054 - QSEE Dev Config - Image Loaded, Delta -
(53248 Bytes)
• TrustZone
B - 1228113 - QSEE - Image Load, Start
D - 26382 - Auth Metadata

80-70020-11 AC May contain U.S. and international export controlled information 36

 Verify the security configurations of Qualcomm Linux

D - 22234 - Segments hash check

D - 88999 - QSEE - Image Loaded, Delta - (4027792 Bytes)
• Hypervisor
B - 1402237 - QHEE - Image Load, Start
D - 26383 - Auth Metadata
D - 7045 - Segments hash check
D - 35258 - QHEE - Image Loaded, Delta - (1491024 Bytes)
• APDP
B - 978348 - APDP - Image Load, Start
D - 42212 - Auth Metadata
D - 458 - Segments hash check
D - 48434 - APDP - Image Loaded, Delta - (17332 Bytes)

2.2 Verify secure boot and UEFI secure boot

• Secure boot feature is designed to ensure that a device boots using only software that’s
trusted by the manufacturer.
• UEFI secure boot is an extension of secure boot that operates within the unified extensible
firmware interface (UEFI) environment.
• Enabling secure boot for the hardware is crucial for achieving hardware security and
protecting intellectual property. For instructions, see Enable secure boot and Enable UEFI
secure boot.
• The XBL logs contain the secure boot status of the device. The logs include information
about the boot interface, secure boot status, boot configuration, JTAG_ID, OEM_ID, and
serial number.

S - Format: Log Type - Time(microsec) - Message -

Optional Info
S - Log Type: B - Since Boot(Power On Reset), D - Delta,
S - Statistic
S - QC_IMAGE_VERSION_STRING=[Link].1.0.c1-00037-
KODIAKLA-1
S - IMAGE_VARIANT_STRING=SocKodiakLAA
S - OEM_IMAGE_VERSION_STRING=hu-apasunur-hyd
S - Boot Interface: USB **
S - Secure Boot: On **

80-70020-11 AC May contain U.S. and international export controlled information 37

 Verify the security configurations of Qualcomm Linux

S - Boot Config @ 0x00786070 = 0x000000c1

S - JTAG ID @ 0x00786130 = 0x001970e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x00786134 = 0x4172f1dd

2.3 Verify SELinux status and customize SELinux policies

• Security-Enhanced Linux (SELinux) is a security architecture integrated into the Linux kernel
that provides a mechanism for supporting access control security policies.
• Verifying the SELinux status for the device software prevents unauthorized access to critical
software modules or drivers. For instructions, see Enable SELinux.
• SEPolicy is the SELinux policy that defines rules for process and user interactions with
system resources, enforcing mandatory access controls (MAC) in Linux.
• Default SEPolicy may not address all the specific requirements of your applications. By
creating custom policies, you can define precise rules that align with your application’s
requirements. For instructions, see Customize SEPolicy.
• To verify the SELinux status, do the following:
1. Verify the kernel configuration.

CONFIG_SECURITY_SELINUX=y

2. Connect to the device using SSH.

3. View the SELinux enable status and other details, by running the seinfo
commands.

Statistics for policy file: /sys/fs/selinux/policy

Policy Version: 33 (MLS enabled)
Target Policy: selinux
Handle unknown classes: allow
Classes: 131 Permissions:
423
Sensitivities: 16 Categories:
1024
Types: 4376 Attributes:
319

4. Verify the SELinux enforce status from the console or connect to the device
using SSH.

80-70020-11 AC May contain U.S. and international export controlled information 38

 Verify the security configurations of Qualcomm Linux

getenforce
enforcing - if selinux is set to enable

2.4 Verify PIL image loading - Sample logs

The following sample logs show the initialization and status of various remote processors and
hardware components, which are part of the boot process managed by the primary image loader
(PIL). The PIL is responsible for loading and verifying these components to ensure they’re secure
and functioning correctly.

WLAN (remoteproc1) 730, 0x00000000000459B4

| 8.700828: remoteproc
remoteproc1: Remote
processor 8a00000.
Remoteproc is now up
cDSP (remoteproc3) 735, 0x00000000000465A3
| 8.794052: remoteproc
remoteproc3: Remote
processor a300000.
Remoteproc is now up
aDSP (remoteproc2) 741, 0x00000000000469FC
| 8.828033: remoteproc
remoteproc2: Remote
processor [Link]
is now up
MODEM (remoteproc0) 1035, 0x000000000006B78B
| 13.433955: remoteproc
remoteproc0: Remote
processor 4080000.
Remoteproc is now up
A660_zap sh-5.1# dmesg | grep gfx
[7.822629] kgsl-iommu SoC@0:
QCOM, kgsl-iommu@3da0000:
gfx3d_user: Adding to iommu
group 15
[7.870446] kgsl-3d 3d00000.
qcom, kgsl-3d0: bound SoC@0:
QCOM, kgsl-iommu@3da0000:
gfx3d_user (ops kgsl_mmu_cb_
component_ops [msm_kgsl])

80-70020-11 AC May contain U.S. and international export controlled information 39

 Verify the security configurations of Qualcomm Linux

Video (Vpu20_1v.mbn) sh-5.1# dmesg | grep video

[7.094229] videodev: Linux
video capture interface: v2.
00
[7.847469] qcom-iris
[Link]-codec: Adding
to iommu group 17
[7.856647] qcom-iris
[Link]-codec: no
reset clocks found
[10.131119] [drm] [msm-dsi-
warn]: [nt36672e LCD video
mode DSI novatek panel with
DSC] fall back to default
te-pin-select
[10.188079] [drm:dsi_
display_bind [msm_drm]]
[msm-dsi-info]: Successfully
bind display panel 'QCOM,
mdss_dsi_nt36672e_fhd_plus_
120_video '

2.5 Verify Qualcomm TEE mink/global platform TEE API

availability
Qualcomm TEE uses various APIs to manage secure applications and interactions with secure
peripherals. GlobalPlatform provides standardized APIs for Qualcomm TEE that ensures
interoperability and security across devices. The verification process involves checking that these
APIs are correctly implemented and available for use.
1. Verify the availability of the library on the device.

/usr/lib/
libmink*
libGPMTEE*
libGPTEE*

2. Verify if the mink listener service is running.

ps -ef | grep qtee_supplicant and qtee_supplicant is running

ps -ef | grep ssgtzd

80-70020-11 AC May contain U.S. and international export controlled information 40

 Verify the security configurations of Qualcomm Linux

2.6 Verify SMC invoke driver status

The secure monitor call (SMC) invoke driver facilitates communication between the TrustZone and
the operating system. The SMC invoke driver status includes information about the initialization
steps, any errors encountered, and the successful setup of secure communication channels. To
verify the SMC invoke driver status, do the following:
1. Connect to the device using SSH.
2. Verify if the /dev/smcinvoke node is present:

ls -l /dev/smcinvoke

2.7 Verify RPMB provisioning status

The replay protected memory block (RPMB) is a secure partition in storage devices. The RPMB
provisioning ensures that the RPMB is correctly provisioned and ready to securely store and
retrieve data. To verify the RPBM provisioning status, do the following:
1. Connect to the device using SSH and run the following command.

sh-5.1# rpmbClient smci -p 1

The following message is displayed.

SMCINVOKE INTERFACE WARNING!!!

You are about to provision the RPMB key.
This is a ONE time operation and CANNOT be reversed.
______________________________________________________

0 -> Provision Production key

1 -> Provision Test key
2 -> Check RPMB key provision status
______________________________________________________

2. Select an option to proceed: 2 RMPB Key status: RPMB_KEY_NOT_PROVISIONED (f)

80-70020-11 AC May contain U.S. and international export controlled information 41

 Verify the security configurations of Qualcomm Linux

Caution: Once RPMB is provisioned with test keys on a non-secure device, it becomes
irreversible. As a result, secure boot can’t be enabled on such devices.

2.8 Verify Qualcomm WES status

• Qualcomm WES helps deploy many edge devices easily and manage them without manual
intervention. It includes services like plug-and-play setup, on-demand updates, emergency
and routine upgrades, and enabling third-party services throughout the device life-cycle.
• If you need to develop applications that offer hardware-based attestation, zero-touch device
provisioning, and chipset feature management, see Develop trusted and client applications.
• To install or upgrade QCS5430 SoftSKU feature packs, see Install or upgrade SoftSKU
feature packs.

Note: This feature is available to licensed users with authorized access to verify the Qualcomm
WES status. If you have access, see Qualcomm Linux Wireless Edge Services Guide.

2.9 Verify trusted and client applications

• Trusted applications function within a trusted execution environment (TEE), offering a secure
and isolated environment to keep the integrity and confidentiality of code and data.
• Client applications function within the normal world operating system, communicating with
trusted applications using TEE client APIs to perform secure services.
• To execute the security-critical applications in the secure world (TrustZone), you must
develop your own trusted applications. You must have access to the Qualcomm TEE
software development kit (SDK) to develop corresponding client applications that launch the
trusted applications. For more information, see Develop trusted and client applications.

Note: This feature is available to licensed users with authorized access to develop and run trusted
and client applications. If you have access, see Qualcomm Linux Security Guide - Addendum.

2.10 Next steps

• To configure Qualcomm TEE for securing devices that handle sensitive data and run trusted
applications, see Configure security services.

80-70020-11 AC May contain U.S. and international export controlled information 42

 Verify the security configurations of Qualcomm Linux

• To customize memory and SEPolicy, see Customize secuity services.

80-70020-11 AC May contain U.S. and international export controlled information 43

3 Configure security services

Qualcomm Linux Security provides a wide range of security configurations aimed at enhancing
device security, ensuring software authenticity and integrity, and protecting critical and sensitive
information for both developers and users.
This section guides you through the following configuration workflows.

Enable secure boot

Enable UEFI secure boot

Enable device configuration from Qualcomm TEE

Enable SELinux

Install or upgrade SoftSKU feature packs

3.1 Enable device configurations from Qualcomm TEE

Configuring Qualcomm TEE is essential for maintaining the security, compliance, performance, and
flexibility of devices that manage sensitive data and run trusted applications. Qualcomm TEE
configurations can be adjusted using the device configuration (devcfg) framework, which provides a
centralized way to manage and adjust device-specific settings.
Prerequisites
• Build and compile the software on the device.
• Enable the secure shell (SSH) in permissive mode to securely access your host device.

80-70020-11 AC May contain U.S. and international export controlled information 44

 Configure security services

Compile devcfg image from TrustZone

1. Select the configuration options that TrustZone offers through the built in [Link] XML
files. For example: trustzone_images/ssg/securemsm/trustzone/qsee/mink/
oem/config/<chipset>/oem_config.xml.
2. Use the command to compile the devcfg image from [Link].5.29.1.

cd trustzone_images/build/ms

python3 build_all.py -b [Link].5.0 CHIPSET=<chipset> <devcfg> --

cfg=build_config_deploy_<chipset>.xml

This steps generates the [Link] images at trustzone_images/build/ms/

bin/<build_flavor>. Use the following build flavors and commands.
Build flavors

QCS5430/QCS6490

EACAANAA

IQ-9075/IQ-9100

MAKAANAA

IQ-8275/IQ-8300

FAQAANAA

IQ-615

GABAANAA

Build commands

80-70020-11 AC May contain U.S. and international export controlled information 45

 Configure security services

QCS5430/QCS6490

python3 trustzone_images/build/ms/build_all.py
CHIPSET=kodiak devcfg

IQ-9075/IQ-9100

python3 trustzone_images/build/ms/build_all.py
CHIPSET=lemans devcfg

IQ-8275/IQ-8300

python3 trustzone_images/build/ms/build_all.py
CHIPSET=monaco devcfg

IQ-615

python3 trustzone_images/build/ms/build_all.py
CHIPSET=talos devcfg

Note: Use the following devcfg files:

<devcfg> is
• devcfg for QCS6490
• devcfg_iot for IQ-9100

Important: The devcfg_iot.mbn file isn’t being generated by default. Apply the following changes
to build devcfg_iot.mbn.

trustzone_images/build/ms/build_config_deploy_lemans.xml
@@ -60,9 +60,12 @@
<alias build-once="false" disable="false" internal-test=
"false" recompile="true" strip="false" name="devcfg_auto_
sgvm">
<artifact name="devcfg_auto_sgvm"/>
</alias>
+ <alias build-once="false" disable="false" internal-test=

80-70020-11 AC May contain U.S. and international export controlled information 46

 Configure security services

"false" recompile="true" strip="false" name="devcfg_iot">

+ <artifact name="devcfg_iot"/>
+ </alias>

Customize device using configuration parameters

Use the configuration parameters listed in the following table to customize the device as needed.

Configuration parameters Description

OEM_pil_secure_app_load_region_ Customizes the TA size.
size
OEM_pil_subsys_load_region_start Customizes the PIL load start address when
there is any change from the default memory
map.
OEM_pil_subsys_load_region_size Customizes the PIL size when there is any
change from the default memory map.
OEM_enable_app_fatal_err Forces a TrustZone system to fatal error when
a specific TA crashes. Use with OEM_crash_
ta_name.
OEM_crash_ta_name Replaces the entry with the TA name that
crashed and the TA on which the secure kernel
is expected to crash.
OEM_sec_wdog_bark_time Changes the default configuration of the device
for secure watchdog bark time.
OEM_sec_wdog_bite_time Changes the default configuration of the device
for secure watchdog bite time.
OEM_tz_log_level Sets the TrustZone log level:
• Fatal: 0
• Error: 1
• Debug: 2

80-70020-11 AC May contain U.S. and international export controlled information 47

 Configure security services

Enable RPMB-based SFS anti-rollback protection

To enable or disable the RPMB-based SFS anti-rollback protection, use the following configuration
parameter and the XML file.
Configuration parameter
cmnlib_gppo_rpmb_enablement, can be set to Enabled or Disabled, where the default value
is Enabled and must be changed only when required.
XML file location
trustzone_images/ssg/securemsm/trustzone/qsee/mink/oem/config/common/
cmnlib_oem_config.xml

80-70020-11 AC May contain U.S. and international export controlled information 48

 Configure security services

Next steps
• To enable secure boot and to ensure only trusted applications runs on the device, see Enable
secure boot.
• To enable secure boot, QFPROM fuses must be blown. This is a one-time, irreversible
process that permanently sets these values. For more information, see Set the QFPROM
fuses.

3.2 Enable secure boot

Secure boot is enabled by blowing a set of hardware fuses that are part of QFPROM. The hash of
the root certificate is blown into the hardware fuse, which serves as the primary RoT.
To understand the off-target preparation and the on-device execution, see the workflow.

Figure : Secure boot workflow

Secure boot is guaranteed only after blowing a QFPROM, which is an eFuse. The eFuse

80-70020-11 AC May contain U.S. and international export controlled information 49

 Configure security services

configuration required to enable platform secure boot includes:

• Enabling image authentication and anti-rollback protection.
• Disabling debug and JTAG access.
• Blowing disable read/write permission fuses for the QFPROM regions.

Enable secure boot by blowing the QFPROM fuse

1. Obtain the unique OEM_ID from Qualcomm.
The ID is required when using the code authorization signing services (CASS) or Qualcomm
WES services. Or, you can use 0 as the value for the OEM_ID.
2. Generate and configure signing assets such as keys and certificates.
3. Generate a signed ELF ([Link]) for blowing fuses.
4. Sign firmware images.
5. Flash [Link] and signed images to the device.
Images that aren’t based on Linux are signed using SecTools v2 and a local signer. This process
requires signing certificates and keys to be present on the local machine where the signing takes
place. However, these keys aren’t secure and can be exposed during and after the signing process
on the machine running SecTools.

Note: Qualcomm doesn’t provide guidance on how to secure these keys. It’s recommended to
follow standard security protocols, obtain keys/certificates from a trusted certification authority
(CA), and protect these keys using a hardware security module (HSM).

Keys and certificates that are self-generated using the OpenSSL tool don’t have a link to any
certificate authority.

Enable secure boot using SecTools

1. Set up the environment variable for SecTools v2. For more information, see Security tools.
The following code snippets are provided as references. Replace <chipset> and
<chipset>.LE.X.x according to the build in use. For example, <[Link].1.0>.

Note: The terms metabuild, meta, and meta paths are used interchangeably to indicate the
path from the Qualcomm ChipCode™ Portal. The metabuild denotes the complete
Qualcomm ChipCode release for a build.

For Linux:

80-70020-11 AC May contain U.S. and international export controlled information 50

 Configure security services

setenv SECTOOLS=/<chipset>.LE.X.x/common/sectoolsv2/ext/
linux/sectools

export SECTOOLS=/<chipset>.LE.X.x/common/sectoolsv2/ext/
linux/sectools

2. Use SecTools v2 from the following path:

<chipset>.LE.X.x/common/sectoolsv2/ext/<platform>
• The <chipset>_security_profile.xml file is located in the meta at
<chipset>.LE.X.x/common/sectoolsv2
• The minimum SecTools version required is 1.17 or later.
4. It’s recommended to use a hardware security module (HSM). However, if a LOCAL (insecure)
signer is used, see the LOCAL signing option with -signing-help in SecTools V2: Secure
Image User Guide.
5. All the keys and certificate generation commands are run using OpenSSL 1.1.1g (21 Apr
2020). It’s a prerequisite to install OpenSSL.
6. Ensure that you enable secure boot on a device that’s not RPMB provisioned. See Check
RPMB provision status.
RPMB will be automatically provisioned with production keys after secure boot fuses are
blown.

Note: The SecTools guides are available to licensed users with authorized access.

Set the QFPROM fuses

QFPROM fuses store cryptographic keys that authenticate software images during the secure boot
process. This ensures that only authorized software can run on the device.
QFPROM uses a fusing mechanism to program registers by blowing fuses, thereby storing
permanent data This is a one-time operation that can’t be undone. The following table captures the
QFPROM fuse values and details, which enable secure boot after blowing the fuses.

80-70020-11 AC May contain U.S. and international export controlled information 51

 Configure security services

QCS5430/QCS6490

Fuse name Start Bit Fuse blow Description

address number value

Read permissions
Secondary Key 7801A8 24 1 After provisioning the SKDK,
derivation Key Read blow this bit to secure the
disable secondary key from being
read back. A secure path
hardware exists from SKDK
to the crypto engine.

Write permissions
Read permissions 7801B0 6 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
FEC enables write 7801B0 8 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM configuration 7801B0 9 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
Public key hash 0 write 7801B0 17 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM secure boot write 7801B0 23 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
Secondary key 7801B0 24 1 Blow this bit after the region
derivation key write has been provisioned to
disable disable further QFPROM
changes to this region.

FEC enable

80-70020-11 AC May contain U.S. and international export controlled information 52

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM secure boot FEC 7801B8 23 1 To enable FEC for OEM
enable secure boot region, blow this
bit. Ensure that the complete
region is provisioned before
FEC is enabled.
Secondary key 7801B8 24 1 To enable FEC for the
derivation key FEC secondary KDF key, blow
enable this bit. Ensure that
the complete region is
provisioned before FEC is
enabled.

OEM Config
WDOG_EN 7801C0 14 1 Prevents the WDOG_
DISABLE GPIO from
disabling WDOG, freeing up
the GPIO and preventing
potential abuse by an
attacker.
SHARED_QSEE_ 7801C0 30 1 A shared Qualcomm
SPIDEN_DISABLE TEE secure invasive
debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_QSEE_ 7801C0 31 1 A shared Qualcomm
SPNIDEN_DISABLE TEE secure non-invasive
debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_MSS_ 7801C4 32 1 A shared MSS invasive
DBGEN_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 53

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
SHARED_MSS_ 7801C4 33 1 A shared MSS non-invasive
NIDEN_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
SHARED_CP_DBGEN_ 7801C4 34 1 A shared CP invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_CP_NIDEN_ 7801C4 35 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
SHARED_NS_DBGEN_ 7801C4 36 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_NS_NIDEN_ 7801C4 37 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
APPS_DBGEN_ 7801C4 38 1 Blow this bit for a secure
DISABLE solution. This configuration
disables the application
processor global invasive
debug capabilities (JTAG
and monitor mode). The
OVERRIDE registers can
override this configuration.

80-70020-11 AC May contain U.S. and international export controlled information 54

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
APPS_NIDEN_ 7801C4 39 1 Blow this bit for a
DISABLE secure solution. This
configuration disables
the application processor
global non-invasive debug
capabilities (trace and
performance monitoring).
This configuration can
be overridden with the
OVERRIDE registers.
SHARED_MISC_ 7801C4 40 1 A shared miscellaneous
DEBUG_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
EKU_ENFORCEMENT_ 7801C8 30 1 To enable enforcement of the
EN EKU field in the certificate,
blow this device.
OEM_HW_ID[0:15] 7801CC [32:47] 0 Represents the OEM
hardware ID. Bits 15:0.
OEM_PRODUCT_ 7801CC [48:63] 0 Represents the OEM product
ID[0:15] ID. Bits 15:0.
ANTI_ROLLBACK_ 7801D4 32 1
FEATURE_EN[0] • Bit 0 - BOOT_ANTI_
ROLLBACK_EN
ANTI_ROLLBACK_ 7801D4 33 1 • Bit 1 - TZAPPS_
FEATURE_EN[1] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 7801D4 34 1 • Bit 2 - PILSUBSYS_
FEATURE_EN[2] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 7801D4 35 1 • Bit 3 - MSA_ANTI_
FEATURE_EN[3] ROLLBACK_EN

PK hash
PK hash 0[0:383] 780248 [0:383] The OEM-specific root
• certificate PK hash value.

OEM secure boot

80-70020-11 AC May contain U.S. and international export controlled information 55

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM_SECURE_ 780728 4 1 When this bit is ‘1’, use the
BOOT1_PK_HASH_ value stored in OEM_PK_
IN_FUSE HASH for the root certificate
hash.
OEM_SECURE_ 780728 5 1 To enable secure boot for
BOOT1_AUTH_EN apps and other peripheral
images, blow this bit. When
this bit is ‘1’, it enables
authentication for any code
that references secure boot
configuration 1.
OEM_SECURE_ 780728 12 1 For boot configuration 2:
BOOT2_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
If this bit is ‘1’, use the value
stored in OEM_PK_HASH for
the root certificate hash.
OEM_SECURE_ 780728 13 1 To enable the secure boot,
BOOT2_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot.
OEM_SECURE_ 780728 20 1 For boot configuration 3:
BOOT3_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
When this bit is ‘1’, use
the value stored in OEM_PK_
HASH for the root certificate
hash.
OEM_SECURE_ 780728 21 1 To enable the secure boot,
BOOT3_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot configuration 3.

80-70020-11 AC May contain U.S. and international export controlled information 56

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value

Sec key derivation key

Sec Key 780738 [0:255] This 256-bit value is used as
derivation the secondary key derivation
Key[0:255] input, which is used to
generate the secondary
key for the crypto engine.
When running in an insecure
mode (no secure boot or
Debug enabled), the SKDK
is fed into the key derivation
function to generate a unique
non-secure secondary key
for use by the crypto engine.
When running in a secure
mode (secure boot and
debug disabled), the SKDK
is fed directly to the crypto
engine as the secondary key.
After the SKDK value
has been correctly
programmed, the SKDK
Read Disable must be blown
to permanently protect the
SKDK value. The software
reads the SKDK value from
the QFPROM before this
correction is made.
The SBL fuse blow API can
automatically generate a
random number for use as
the SKDK, ensuring that
the SKDK value is never
available outside of the
device.

80-70020-11 AC May contain U.S. and international export controlled information 57

 Configure security services

IQ-9075/IQ-9100

Fuse name Start Bit Fuse blow Description

address number value

Read permissions
Secondary Key 780190 31 1 After provisioning the SKDK,
derivation Key Read blow this bit to secure the
disable secondary key from being
read back. A secure path
hardware exists from SKDK
to the crypto engine.

Write permissions
Read permissions 780198 5 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
FEC enables write 780198 7 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM configuration 780198 8 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
Public key hash 0 write 780198 24 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM secure boot write 780198 30 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
Secondary key 780198 31 1 Blow this bit after the region
derivation key write has been provisioned to
disable disable further QFPROM
changes to this region.

FEC enable

80-70020-11 AC May contain U.S. and international export controlled information 58

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM secure boot FEC 7801A0 30 1 To enable FEC for OEM
enable secure boot region, blow this
bit. Ensure that the complete
region is provisioned before
FEC is enabled.
Secondary key 7801A0 31 1 To enable FEC for the
derivation key FEC secondary KDF key, blow
enable this bit. Ensure that
the complete region is
provisioned before FEC is
enabled.

OEM Config
WDOG_EN 7801A8 14 1 Prevents the WDOG_
DISABLE GPIO from
disabling WDOG, freeing up
the GPIO and preventing
potential abuse by an
attacker.
SHARED_QSEE_ 7801A8 30 1 A shared Qualcomm
SPIDEN_DISABLE TEE secure invasive
debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_QSEE_ 7801A8 31 1 A shared Qualcomm
SPNIDEN_DISABLE TEE secure non-invasive
debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_MSS_ 7801AC 32 1 A shared MSS invasive
DBGEN_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 59

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
SHARED_MSS_ 7801AC 33 1 A shared MSS non-invasive
NIDEN_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
SHARED_CP_DBGEN_ 7801AC 34 1 A shared CP invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_CP_NIDEN_ 7801AC 35 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
SHARED_NS_DBGEN_ 7801AC 36 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_NS_NIDEN_ 7801AC 37 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
APPS_DBGEN_ 7801AC 38 1 Blow this bit for a secure
DISABLE solution. This configuration
disables the application
processor global invasive
debug capabilities (JTAG
and monitor mode). The
OVERRIDE registers can
override this configuration.

80-70020-11 AC May contain U.S. and international export controlled information 60

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
APPS_NIDEN_ 7801AC 39 1 Blow this bit for a
DISABLE secure solution. This
configuration disables
the application processor
global non-invasive debug
capabilities (trace and
performance monitoring).
This configuration can
be overridden with the
OVERRIDE registers.
SHARED_MISC_ 7801AC 40 1 A shared miscellaneous
DEBUG_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
EKU_ENFORCEMENT_ 7801B0 30 1 To enable enforcement of the
EN EKU field in the certificate,
blow this device.
OEM_HW_ID[0:15] 7801B4 [32:47] 0 Represents the OEM
hardware ID. Bits 15:0.
OEM_PRODUCT_ 7801B4 [48:63] 0 Represents the OEM product
ID[0:15] ID. Bits 15:0.
ANTI_ROLLBACK_ 7801BC 32 1
FEATURE_EN[0] • Bit 0 - BOOT_ANTI_
ROLLBACK_EN
ANTI_ROLLBACK_ 7801BC 33 1 • Bit 1 - TZAPPS_
FEATURE_EN[1] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 7801BC 34 1 • Bit 2 - PILSUBSYS_
FEATURE_EN[2] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 7801BC 35 1 • Bit 3 - MSA_ANTI_
FEATURE_EN[3] ROLLBACK_EN

PK hash
PK hash 0[0:383] 7802A0 [0:383] The OEM-specific root
• certificate PK hash value.

OEM secure boot

80-70020-11 AC May contain U.S. and international export controlled information 61

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM_SECURE_ 780D78 4 1 When this bit is ‘1’, use the
BOOT1_PK_HASH_ value stored in OEM_PK_
IN_FUSE HASH for the root certificate
hash.
OEM_SECURE_ 780D78 5 1 To enable secure boot for
BOOT1_AUTH_EN apps and other peripheral
images, blow this bit. When
this bit is ‘1’, it enables
authentication for any code
that references secure boot
configuration 1.
OEM_SECURE_ 780D78 12 1 For boot configuration 2:
BOOT2_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
If this bit is ‘1’, use the value
stored in OEM_PK_HASH for
the root certificate hash.
OEM_SECURE_ 780D78 13 1 To enable the secure boot,
BOOT2_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot.
OEM_SECURE_ 780D78 20 1 For boot configuration 3:
BOOT3_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
When this bit is ‘1’, use
the value stored in OEM_PK_
HASH for the root certificate
hash.
OEM_SECURE_ 780D78 21 1 To enable the secure boot,
BOOT3_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot configuration 3.

80-70020-11 AC May contain U.S. and international export controlled information 62

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value

Sec key derivation key

Sec Key 780D88 [0:255] This 256-bit value is used as
derivation the secondary key derivation
Key[0:255] input, which is used to
generate the secondary
key for the crypto engine.
When running in an insecure
mode (no secure boot or
Debug enabled), the SKDK
is fed into the key derivation
function to generate a unique
non-secure secondary key
for use by the crypto engine.
When running in a secure
mode (secure boot and
debug disabled), the SKDK
is fed directly to the crypto
engine as the secondary key.
After the SKDK value
has been correctly
programmed, the SKDK
Read Disable must be blown
to permanently protect the
SKDK value. The software
reads the SKDK value from
the QFPROM before this
correction is made.
The SBL fuse blow API can
automatically generate a
random number for use as
the SKDK, ensuring that
the SKDK value is never
available outside of the
device.

80-70020-11 AC May contain U.S. and international export controlled information 63

 Configure security services

IQ-8275/IQ-8300

Fuse name Start Bit Fuse blow Description

address number value

Read permissions
Secondary Key 780190 31 1 After provisioning the SKDK,
derivation Key Read blow this bit to secure the
disable secondary key from being
read back. A secure path
hardware exists from SKDK
to the crypto engine.

Write permissions
Read permissions 780198 5 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
FEC enables write 780198 7 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM configuration 780198 8 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
Public key hash 0 write 780198 24 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM secure boot write 780198 30 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
Secondary key 780198 31 1 Blow this bit after the region
derivation key write has been provisioned to
disable disable further QFPROM
changes to this region.

FEC enable

80-70020-11 AC May contain U.S. and international export controlled information 64

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM secure boot FEC 7801A0 30 1 To enable FEC for OEM
enable secure boot region, blow this
bit. Ensure that the complete
region is provisioned before
FEC is enabled.
Secondary key 7801A0 31 1 To enable FEC for the
derivation key FEC secondary KDF key, blow
enable this bit. Ensure that
the complete region is
provisioned before FEC is
enabled.

OEM Config
WDOG_EN 7801A8 14 1 Prevents the WDOG_
DISABLE GPIO from
disabling WDOG, freeing up
the GPIO and preventing
potential abuse by an
attacker.
SHARED_QSEE_ 7801A8 30 1 A shared Qualcomm
SPIDEN_DISABLE TEE secure invasive
debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_QSEE_ 7801A8 31 1 A shared Qualcomm
SPNIDEN_DISABLE TEE secure non-invasive
debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_MSS_ 7801AC 32 1 A shared MSS invasive
DBGEN_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 65

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
SHARED_MSS_ 7801AC 33 1 A shared MSS non-invasive
NIDEN_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
SHARED_CP_DBGEN_ 7801AC 34 1 A shared CP invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_CP_NIDEN_ 7801AC 35 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
SHARED_NS_DBGEN_ 7801AC 36 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
SHARED_NS_NIDEN_ 7801AC 37 1 A shared CP non-invasive
DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
APPS_DBGEN_ 7801AC 38 1 Blow this bit for a secure
DISABLE solution. This configuration
disables the application
processor global invasive
debug capabilities (JTAG
and monitor mode). The
OVERRIDE registers can
override this configuration.

80-70020-11 AC May contain U.S. and international export controlled information 66

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
APPS_NIDEN_ 7801AC 39 1 Blow this bit for a
DISABLE secure solution. This
configuration disables
the application processor
global non-invasive debug
capabilities (trace and
performance monitoring).
This configuration can
be overridden with the
OVERRIDE registers.
SHARED_MISC_ 7801AC 40 1 A shared miscellaneous
DEBUG_DISABLE debug disable bucket. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
EKU_ENFORCEMENT_ 7801B0 30 1 To enable enforcement of the
EN EKU field in the certificate,
blow this device.
OEM_HW_ID[0:15] 7801B4 [32:47] 0 Represents the OEM
hardware ID. Bits 15:0.
OEM_PRODUCT_ 7801B4 [48:63] 0 Represents the OEM product
ID[0:15] ID. Bits 15:0.
ANTI_ROLLBACK_ 7801BC 32 1
FEATURE_EN[0] • Bit 0 - BOOT_ANTI_
ROLLBACK_EN
ANTI_ROLLBACK_ 7801BC 33 1 • Bit 1 - TZAPPS_
FEATURE_EN[1] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 77801BC 34 1 • Bit 2 - PILSUBSYS_
FEATURE_EN[2] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 7801BC 35 1 • Bit 3 - MSA_ANTI_
FEATURE_EN[3] ROLLBACK_EN

PK hash
PK hash 0[0:383] 7802A0 [0:383] The OEM-specific root
• certificate PK hash value.

OEM secure boot

80-70020-11 AC May contain U.S. and international export controlled information 67

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM_SECURE_ 780DA8 4 1 When this bit is ‘1’, use the
BOOT1_PK_HASH_ value stored in OEM_PK_
IN_FUSE HASH for the root certificate
hash.
OEM_SECURE_ 780DA8 5 1 To enable secure boot for
BOOT1_AUTH_EN apps and other peripheral
images, blow this bit. When
this bit is ‘1’, it enables
authentication for any code
that references secure boot
configuration 1.
OEM_SECURE_ 780DA8 12 1 For boot configuration 2:
BOOT2_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
If this bit is ‘1’, use the value
stored in OEM_PK_HASH for
the root certificate hash.
OEM_SECURE_ 780DA8 13 1 To enable the secure boot,
BOOT2_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot.
OEM_SECURE_ 780DA8 20 1 For boot configuration 3:
BOOT3_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
When this bit is ‘1’, use
the value stored in OEM_PK_
HASH for the root certificate
hash.
OEM_SECURE_ 780DA8 21 1 To enable the secure boot,
BOOT3_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot configuration 3.

80-70020-11 AC May contain U.S. and international export controlled information 68

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value

Sec key derivation key

Sec Key 780DB8 [0:255] This 256-bit value is used as
derivation the secondary key derivation
Key[0:255] input, which is used to
generate the secondary
key for the crypto engine.
When running in an insecure
mode (no secure boot or
Debug enabled), the SKDK
is fed into the key derivation
function to generate a unique
non-secure secondary key
for use by the crypto engine.
When running in a secure
mode (secure boot and
debug disabled), the SKDK
is fed directly to the crypto
engine as the secondary key.
After the SKDK value
has been correctly
programmed, the SKDK
Read Disable must be blown
to permanently protect the
SKDK value. The software
reads the SKDK value from
the QFPROM before this
correction is made.
The SBL fuse blow API can
automatically generate a
random number for use as
the SKDK, ensuring that
the SKDK value is never
available outside of the
device.

80-70020-11 AC May contain U.S. and international export controlled information 69

 Configure security services

IQ-615

Fuse name Start Bit Fuse blow Description

address number value

Read permissions
Secondary Key 780150 22 1 After provisioning the SKDK,
derivation Key Read blow this bit to secure the
disable secondary key from being
read back. A secure path
hardware exists from SKDK
to the crypto engine.

Write permissions
Read permissions 780158 3 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
FEC enables write 780158 5 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM configuration 780158 10 1 Blow this bit after the region
write disable has been provisioned to
disable further QFPROM
changes to this region.
Public key hash 0 write 780158 12 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
OEM secure boot write 780158 20 1 Blow this bit after the region
disable has been provisioned to
disable further QFPROM
changes to this region.
Secondary key 7801B0 22 1 Blow this bit after the region
derivation key write has been provisioned to
disable disable further QFPROM
changes to this region.

FEC enable

80-70020-11 AC May contain U.S. and international export controlled information 70

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM secure boot FEC 7801B8 20 1 To enable FEC for OEM
enable secure boot region, blow this
bit. Ensure that the complete
region is provisioned before
FEC is enabled.
Secondary key 7801B8 22 1 To enable FEC for the
derivation key FEC secondary KDF key, blow
enable this bit. Ensure that
the complete region is
provisioned before FEC is
enabled.

OEM Config
WDOG_EN 780188 14 1 Prevents the WDOG_
DISABLE GPIO from
disabling WDOG, freeing up
the GPIO and preventing
potential abuse by an
attacker.
APPS_APB_DFD_ 780188 30 1 When blown will disable
DISABLE Qualcomm® Kryo™ B
Scandump using APB bus.
A corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
DCC_DEBUG_ 780188 31 1 When blown will be used to
DISABLE disable DCC IP in hardware.
A corresponding Qualcomm
fuse can override this
OEM-controlled fuse.
DEBUG_BUS_ 78018C 32 1 When blown will be used
DISABLE to disable debug bus from
appearing on GPIOs. A
corresponding Qualcomm
fuse can override this
OEM-controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 71

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
AOSS_AOP_DFD_ 78018C 33 1 When blown will disable the
DISABLE scan dump of RPMh. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
EUD_DISABLE 78018C 34 1 When blown will disable
EUD. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
DAP_DEVICEEN_ 78018C 35 1 When blown will disable the
DISABLE external debugger access to
APB-AP port of QDSS DAP.
A corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
APPS_DBGEN_ 78018C 36 1 When blown will disable the
DISABLE non-secure invasive debug
facilities of APPS (including
the APPS processor)
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
DAP_DBGEN_ 78018C 37 1 When blown will block the
DISABLE NS=1 transactions from both
AXI-AP port of DAP, and
ETR, of QDSS subsystem.
It also prevents the STM
block of QDSS to generate
any back pressure on the
bus it receives the event
traces. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
LPASS_TURING_ 780188 38 1 When blown will disable the
DBGEN_DISABLE invasive debug facilities of
LPASS as well as Turing.
A corresponding Qualcomm
fuse can override this OEM-
controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 72

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
WCSS_DBGEN_ 78018C 39 1 When blown will disable
DISABLE the non-secure invasive
debug facilities of WCSS
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
AOSS_AOP_DBGEN_ 78018C 40 1 When blown will disable the
DISABLE non-secure invasive debug
facilities of AOSS AOP. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
CAM_ICP_DBGEN_ 78018C 41 1 When blown will disable the
DISABLE non-secure invasive debug
facilities of camera A5. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
SSC_DBGEN_ 78018C 42 1 When blown will disable the
DISABLE non-secure invasive debug
facilities of Snapdragon
sensor core subsystem. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
VENUS_0_DBGEN_ 78018C 44 1 When blown will disable the
DISABLE non-secure invasive debug
facilities of ARM9 processor
in spectra subsytem. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
A5x_ISDB_DBGEN_ 78018C 45 1 When blown will disable the
DISABLE non-secure invaisive debug
facility of ISDB block of A5X
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 73

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
MSS_DBGEN_ 78018C 46 1 When blown will disable
DISABLE the modem-secure invasive
debug facilities of Modem
subsystem (including Q6
processor). It also blocks the
MSA = 1 transactions from
AXI-AP port of QDSS DAP.
A corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
APPS_NIDEN_ 78018C 47 1 When blown will disable the
DISABLE non-secure non-invasive
debug facilities of APPS
(including APPS processor)
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
DAP_NIDEN_ 78018C 48 1 When blown will instruct
DISABLE QDSS STM to drop the
non-secure event traces. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
LPASS_TURING_ 78018C 49 1 When blown will disable
NIDEN_DISABLE the non-secure non-
invasive debug facilities
of LPASS as well as Turing.
A corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
WCSS_NIDEN_ 78018C 50 1 When blown will disable the
DISABLE non-secure non-invasive
debug facilities of WCSS
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 74

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
AOSS_AOP_NIDEN_ 78018C 51 1 When blown will disable the
DISABLE non-secure non-invasive
debug facilities of AOSS
AOP. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
CAM_ICP_NIDEN_ 78018C 52 1 When blown will disable the
DISABLE non-secure non-invasive
debug facilities of Camera
A5. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
SSC_NIDEN_ 78018C 53 1 When blown will disable
DISABLE the non-secure non-
invasive debug facilities
of Snapdragon sensor core
(including Q6 processor)
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
MSS_NIDEN_ 78018C 54 1 When blown will disable the
DISABLE modem secure non-invasive
debug facilities of MSS
(including Q6 processor)
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
APPS_SPNIDEN_ 78018C 55 1 When blown will disable
DISABLE the secure non-invasive
debug facilities of APPS
(including APPS processor)
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
DAP_SPNIDEN_ 78018C 56 1 When blown will instruct
DISABLE QDSS STM to drop the
secure event traces. A
corresponding Qualcomm
fuse can override this OEM-
controlled fuse.

80-70020-11 AC May contain U.S. and international export controlled information 75

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
APPS_SPIDEN_ 78018C 60 1 When blown will disable
DISABLE the secure invasive
debug facilities of APPS
(including APPS processor)
subsystem. A corresponding
Qualcomm fuse can override
this OEM-controlled fuse.
DAP_SPIDEN_ 78018C 61 1 When blown will block the
DISABLE NS = 0 transactions from
both AXI-AP port of DAP, and
ETR, of QDSS subsystem.
It also prevents the STM
block of QDSS to generate
any backpressure on the bus
it receives the event traces.
A corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
LLCC_DSRW_ 78018C 63 1 When blown will disable
DISABLE the secure invasive debug
facilities of LLCC’s DSRW.
A corresponding Qualcomm
fuse can override this OEM-
controlled fuse.
EKU_ENFORCEMENT_ 780190 30 1 To enable enforcement of the
EN EKU field in the certificate,
blow this device.
OEM_HW_ID[0:15] 7801CC [32:47] 0 Represents the OEM
hardware ID. Bits 15:0.
OEM_PRODUCT_ 7801CC [48:63] 0 Represents the OEM product
ID[0:15] ID. Bits 15:0.
ANTI_ROLLBACK_ 7801D4 32 1
FEATURE_EN[0] • Bit 0 - BOOT_ANTI_
ROLLBACK_EN
ANTI_ROLLBACK_ 7801D4 33 1 • Bit 1 - TZAPPS_
FEATURE_EN[1] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 7801D4 34 1 • Bit 2 - PILSUBSYS_
FEATURE_EN[2] ANTI_ROLLBACK_EN
ANTI_ROLLBACK_ 7801D4 35 1 • Bit 3 - MSA_ANTI_
FEATURE_EN[3] ROLLBACK_EN

80-70020-11 AC May contain U.S. and international export controlled information 76

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value

PK hash
PK hash 0[0:383] 7801C8 [0:383] The OEM-specific root
• certificate PK hash value.

OEM secure boot

OEM_SECURE_ 780360 4 1 When this bit is ‘1’, use the
BOOT1_PK_HASH_ value stored in OEM_PK_
IN_FUSE HASH for the root certificate
hash.
OEM_SECURE_ 780360 5 1 To enable secure boot for
BOOT1_AUTH_EN apps and other peripheral
images, blow this bit. When
this bit is ‘1’, it enables
authentication for any code
that references secure boot
configuration 1.
OEM_SECURE_ 780360 12 1 For boot configuration 2:
BOOT2_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
If this bit is ‘1’, use the value
stored in OEM_PK_HASH for
the root certificate hash.
OEM_SECURE_ 780360 13 1 To enable the secure boot,
BOOT2_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot.

80-70020-11 AC May contain U.S. and international export controlled information 77

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
OEM_SECURE_ 780360 20 1 For boot configuration 3:
BOOT3_PK_HASH_ If this bit is ‘0’, use the
IN_FUSE internal ROM hash index
and OEM_SECURE_BOOT1_
ROM_PK_HASH_IDX[3:0]
for the root certificate hash.
When this bit is ‘1’, use
the value stored in OEM_PK_
HASH for the root certificate
hash.
OEM_SECURE_ 780360 21 1 To enable the secure boot,
BOOT3_AUTH_EN blow this bit. When this bit is
‘1’, it enables authentication
for any code that references
secure boot configuration 3.

Sec key derivation key

80-70020-11 AC May contain U.S. and international export controlled information 78

 Configure security services

Fuse name Start Bit Fuse blow Description

address number value
Sec Key 780398 [0:255] This 256-bit value is used as
derivation the secondary key derivation
Key[0:255] input, which is used to
generate the secondary
key for the crypto engine.
When running in an insecure
mode (no secure boot or
Debug enabled), the SKDK
is fed into the key derivation
function to generate a unique
non-secure secondary key
for use by the crypto engine.
When running in a secure
mode (secure boot and
debug disabled), the SKDK
is fed directly to the crypto
engine as the secondary key.
After the SKDK value
has been correctly
programmed, the SKDK
Read Disable must be blown
to permanently protect the
SKDK value. The software
reads the SKDK value from
the QFPROM before this
correction is made.
The SBL fuse blow API can
automatically generate a
random number for use as
the SKDK, ensuring that
the SKDK value is never
available outside of the
device.

80-70020-11 AC May contain U.S. and international export controlled information 79

 Configure security services

Next steps

• To ensure the that the cryptographic keys and certificates are generated and managed in a
secure and trusted environment, see Generate keys and certificates.
• To ensure the authenticity and integrity of software images and to write a complete software
image, see Sign and flash the images.

Generate keys and certificates

Generate local (insecure) root key and certificate

The version 3 (v3 and v3_attest) extensions define the certificate format and establish the
Certificate Authority (CA). This process allows you to create a local CA with specific attributes and
constraints set by the v3 extensions, allowing you to issue certificates for testing and development
purposes.
Follow these steps to generate a local root key and certificate.
1. Create an [Link] using the following sample OpenSSL configuration file:
OpenSSL is an open-source toolkit for secure sockets layer (SSL) and transport layer
security (TLS) protocols, offering cryptographic functions and a command-line tool.
The following sample OpenSSL configuration file is used for generating certificate requests
and managing a Certificate Authority (CA).

#
# Copyright (c) 2013 Qualcomm Technologies, Inc.
# All Rights Reserved.
# Confidential and Proprietary - Qualcomm Technologies,
Inc.
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate
requests.
#

# This definition stops the following lines choking if

HOME isn't
# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info:

#oid_file = $ENV::HOME/.oid
oid_section = new_oids

80-70020-11 AC May contain U.S. and international export controlled information 80

 Configure security services

# To use this configuration file with the "-extfile"

option of the
# "openssl x509" utility, name here the section
containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=[Link]
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

#########################################################
###########
[ ca ]
default_ca = CA_default # The default ca section

#########################################################
###########
[ CA_default ]

dir = ./demoCA # Where everything is kept

certs = $dir/certs # Where the issued certs
are kept
crl_dir = $dir/crl # Where the issued crl are
kept
database = $dir/[Link] # database index file.
#unique_subject = no # Set to 'no' to allow
creation of
# several certificates with same subject.
new_certs_dir = $dir/newcerts # default place for
new certs.

certificate = $dir/[Link] # The CA certificate

serial = $dir/serial # The current serial
number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL

80-70020-11 AC May contain U.S. and international export controlled information 81

 Configure security services

crl = $dir/[Link] # The current CRL

private_key = $dir/private/[Link]# The private key
RANDFILE = $dir/private/.rand # private random
number file

x509_extensions = usr_cert # The extensions to add

to the cert

# Comment out the following two lines for the

"traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field
options

# Extension copying option: use with caution.

# copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator

chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext

default_days = 365 # how long to certify for

default_crl_days= 30 # how long before next
CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering

# A few different ways of specifying how similar the

request should look
# For type CA, the listed attributes must be the same,
and the optional
# and supplied fields are just that :-)
policy = policy_match

# For the CA policy

[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied

80-70020-11 AC May contain U.S. and international export controlled information 82

 Configure security services

emailAddress = optional

# For the 'anything' policy

# At this point in time, you must list all acceptable
'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

#########################################################
###########
[ req ]
default_bits = 1024
default_keyfile = [Link]
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extensions to add to the
self signed cert

# Passwords for private keys if not present they will be

prompted for
# input_password = secret
# output_password = secret

# This sets a mask for permitted string types. There are

several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or
UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on
BMPStrings or UTF8Strings
# so use this option with caution!
string_mask = nombstr

req_extensions = v3_req # The extensions to add to a

80-70020-11 AC May contain U.S. and international export controlled information 83

 Configure security services

certificate request

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2

stateOrProvinceName = State or Province Name (full

name)
stateOrProvinceName_default = Some-State

localityName = Locality Name (eg, city)

[Link] = Organization Name (eg, company)

0.organizationName_default = Internet Widgits Pty Ltd

# we can do this but it is not needed normally :-)

#[Link] = Second Organization Name (eg,
company)
#1.organizationName_default = World Wide Web Pty Ltd

organizationalUnitName = Organizational Unit Name

(eg, section)
#organizationalUnitName_default =

commonName = Common Name (eg, YOUR name)

commonName_max = 64

emailAddress = Email Address

emailAddress_max = 64

# SET-ex3 = SET extension number 3

[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20

unstructuredName = An optional company name

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

80-70020-11 AC May contain U.S. and international export controlled information 84

 Configure security services

# This goes against PKIX guidelines but some CAs do it

and some software
# requires this to avoid interpreting an end user
certificate as a CA.

basicConstraints=CA:FALSE
keyUsage = nonRepudiation, digitalSignature,
keyEncipherment

# Here are some examples of the usage of nsCertType. If

it is omitted
# the certificate can be used for anything *except*
object signing.

# This is OK for an SSL server.

# nsCertType = server

# For an object signing certificate this would be used.

# nsCertType = objsign

# For normal client use this is typical

# nsCertType = client, email

# and for everything including object signing:

# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.

# keyUsage = nonRepudiation, digitalSignature,
keyEncipherment

# This will be displayed in Netscape's comment listbox.

nsComment = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all

certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.

# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.

80-70020-11 AC May contain U.S. and international export controlled information 85

 Configure security services

# subjectAltName=email:move

# Copy subject details

# issuerAltName=issuer:copy

#nsCaRevocationUrl = [Link]
pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

[ v3_req ]

# Extensions to add to a certificate request

subjectKeyIdentifier=hash

#authorityKeyIdentifier=keyid:always,issuer:always

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature,
keyEncipherment

[ v3_ca ]

# Extensions for a typical CA

# PKIX recommendation.

subjectKeyIdentifier=hash

#authorityKeyIdentifier=keyid:always,issuer:always

# This is what PKIX recommends but some broken software

chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true

80-70020-11 AC May contain U.S. and international export controlled information 86

 Configure security services

# Key usage: this is typical for a CA certificate.

However since it will
# prevent it from being used as a test self-signed
certificate, it is best to be
# left out as a default.
keyUsage = cRLSign, keyCertSign

# Some might want this also

# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX

recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!

# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any
sense in a CRL.

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

[ proxy_cert_ext ]
# These extensions should be added when creating a proxy
certificate

# This goes against PKIX guidelines but some CAs do it

and some software
# requires this to avoid interpreting an end user
certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If

it is omitted

80-70020-11 AC May contain U.S. and international export controlled information 87

 Configure security services

# the certificate can be used for anything *except*

object signing.

# This is OK for an SSL server.

# nsCertType = server

# For an object signing certificate this would be used.

# nsCertType = objsign

# For normal client use this is typical

# nsCertType = client, email

# and for everything including object signing:

# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.

# keyUsage = nonRepudiation, digitalSignature,
keyEncipherment

# This will be displayed in Netscape's comment listbox.

nsComment = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all

certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

# This stuff is for subjectAltName and issuerAltname.

# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details

# issuerAltName=issuer:copy

#nsCaRevocationUrl = [Link]
pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

80-70020-11 AC May contain U.S. and international export controlled information 88

 Configure security services

# This really needs to be in place for it to be a proxy

certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,
pathlen:3,policy:foo

2. To create the [Link] and v3_attest.ext extensions, use the following:

• [Link]: This extension can be found at /docs/manmaster/man5/x509v3_config.html
([Link]), and include the following settings:

authorityKeyIdentifier=keyid,issuer
subjectKeyIdentifier=hash
basicConstraints=CA:true,pathlen:0
keyUsage=keyCertSign

• v3_attest.ext: This extension can be found at /docs/manmaster/man5/x509v3_

[Link] ([Link]), and include the following settings:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE,pathlen:0
keyUsage=digitalSignature
extendedKeyUsage=codeSigning

3. Prepare the environment, create a directory named OEM-KEYS to generate all certificates
and keys at one location.
• For Linux, use the following commands:

cd /path/to/sectools/$ mkdir ./OEM-KEYS &&

cp /download/[Link] ./OEM-KEYS &&
cp /download/[Link] ./OEM-KEYS &&
cp /download/v3_attest.ext ./OEM-KEYS

• For Windows, copy [Link], [Link], and v3_attest.ext to the

OEM-KEYS directory.
The table lists the supported cryptographic algorithms.

Table : Cryptographic algorithms

IQ-615 QCS5430/QCS6490, IQ-9075/IQ-9100, IQ-8275/IQ-
8300
RSA Only ECDSA, RSA

The table lists the supported configuration by cryptographic algorithms.

80-70020-11 AC May contain U.S. and international export controlled information 89

 Configure security services

Table : Configurations for cryptographic algorithms

- ECDSA RSA
Key Size/Curve SECP384R1 Curve 2048, 4096
Signature Algorithm Support SHA384 SHA256
Exponent NA 65537

Note: The PK HASH used for fusing in QFPROM region is SHA-384 for all configurations,
irrespective of the signature algorithm used.

Generate a key pair for secure boot

Select one of the supported algorithms to enable secure boot on the device using either ECDSA or
RSA.
• Option 1: Generate ECDSA root key and certificate.
• Option 2: Generate RSA client application key pair and certificate.
For support cryptographic algorithms see the Cryptographic algorithms table.

Note: ECDSA is recommended over RSA for better security, if supported.

Option 1: Generate ECDSA root key and certificate

ECDSA offers superior security and performance compared to the RSA signature algorithm. As a
result, the default configuration in SecTools supports ECDSA signing.
The following types of keys are created with ECDSA: - The public key, which is accessible to
everyone. - The private key, which is only known to the owner of the key pair.
You can modify and run the following ECDSA-specific commands to generate the root key and
certificate:
1. Go to the OEM-KEYS directory and generate the ECDSA root key and certificate:

cd ./OEM-KEYS

openssl ecparam -genkey -name secp384r1 -outform PEM -out qpsa_

[Link]

openssl req -new -key qpsa_rootca.key -sha384 -out rootca_pem.

crt -subj '/C=US/CN=Generated OEM Root CA/OU=CDMA Technologies/
OU=General Use OEM Key (OEM should update all fields)/L=San

80-70020-11 AC May contain U.S. and international export controlled information 90

 Configure security services

Diego/O=SecTools/ST=California' -config [Link] -x509 -

days 7300 -set_serial 1

openssl x509 -in rootca_pem.crt -inform PEM -out qpsa_rootca.cer

-outform DER

2. Generate the intermediate Certificate Authority (CA) key pair and certificate:

openssl ecparam -genkey -name secp384r1 -outform PEM -out qpsa_

[Link]

openssl req -new -key qpsa_attestca.key -out [Link] -subj '/

C=US/ST=California/CN=Generated OEM Attestation CA/O=SecTools/
L=San Diego' -config [Link] -sha384

openssl x509 -req -in [Link] -CA rootca_pem.crt -CAkey qpsa_

[Link] -out ca_pem.crt -set_serial 1 -days 7300 -extfile v3.
ext -sha384 -CAcreateserial

openssl x509 -inform PEM -in ca_pem.crt -outform DER -out qpsa_
[Link]

Option 2: Generate RSA client application key pair and certificate

RSA is an encryption algorithm that uses a pair of keys to encrypt and decrypt data, ensuring
secure data transmission.
A private key and a public key are created with RSA:
• The public key is accessible to anyone.
• The private key is only known to the owner of the key pair.
Either the public or private key can encrypt the data, and the other key decrypts it. Follow these
steps to generate an RSA client application key pair and certificate.
1. To generate the root client application key pair and certificate, run the following commands:
The key size used is 2048. However, a key size of 4096 is also supported.

openssl genrsa -out qpsa_rootca.key 2048

openssl req -new -sha256 -key qpsa_rootca.key -x509 -out rootca_

[Link] -subj /C=US/ST=California/L="San Diego"/OU="General Use
Test Key (for testing 13 only)"/OU="CDMA Technologies"/
O=QUALCOMM/CN="QCT Root CA 1" -days 7300 -set_serial 1 -config

80-70020-11 AC May contain U.S. and international export controlled information 91

 Configure security services

[Link] -sigopt rsa_padding_mode:pss -sigopt rsa_pss_

saltlen:-1 -sigopt digest:sha256

openssl x509 -in rootca_pem.crt -inform PEM -out qpsa_rootca.cer

-outform DER

openssl x509 -text -inform DER -in qpsa_rootca.cer

2. To generate the attestation client application key pair and certificate, run the following
commands using RSA with a key size of 2048:

openssl genrsa -out qpsa_attestca.key 2048

openssl req -new -key qpsa_attestca.key -out [Link] -subj

/C=US/ST=CA/L="San Diego"/OU="CDMA Technologies"/O=QUALCOMM/CN=
"QUALCOMM Attestation CA" -days 7300 -config [Link]

openssl x509 -req -in [Link] -CA rootca_pem.crt -CAkey

qpsa_rootca.key -out attestca_pem.crt -set_serial 5 -days 7300 -
extfile [Link] -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_
pss_saltlen:-1 -sigopt digest:sha256

openssl x509 -inform PEM -in attestca_pem.crt -outform DER -out

qpsa_attestca.cer

Generate SHA-384 hash for RSA and ECDSA

The SHA-384 hash is crucial in cryptographic applications for several reasons, including enhancing
security strength, creating digital signatures, ensuring compliance with standards, and
future-proofing. SHA-384 will be used as the RoT and ensure the authenticity and integrity of
software images
To generate the SHA-384 hash of the root certificate, run the following command:

openssl dgst -sha384 qpsa_rootca.cer >[Link]

80-70020-11 AC May contain U.S. and international export controlled information 92

 Configure security services

Next steps

• To ensure the authenticity and integrity of software images and to write a complete software
image, see Sign and flash the images.
• To enforce strict access controls, see Enable SELinux.

Sign and flash the images

Sign the images

Image signing is a security process that involves adding a cryptographic signature to a digital
image. This signature serves as a unique identifier, verifying the authenticity, integrity, and origin of
the image. Without image signing, there is no assurance of an image’s integrity or trusted origin,
leading to potential security breaches and data loss.
Follow these steps to sign the images.
1. You can sign the images using SecTools V2. Different signing methods and secure image
functionality are available. For more information see SecTools V2: Secure Image User Guide.
2. You can generate the keys and certificates using a local signer. For more information,
see Generate local (insecure) root key and certificate.
3. To sign a single image, run the following command, where [Link] is used as an example.

Note: You can replace the values of oem-id “0x1” and oem-product-id “0xabcd”
according to your requirement.

<meta>/common/sectoolsv2/ext/linux/sectools secure-image --sign

/path/to/[Link] --image-id=TZ --security-profile <meta>/common/
sectoolsv2/<chipset>_security_profile.xml --oem-id=0x1 --oem-
product-id=0xabcd --anti-rollback-version=0x0 --signing-
mode=LOCAL --root-certificate=./OEM-KEYS/qpsa_rootca.cer --ca-
certificate=./OEM-KEYS/qpsa_attestca.cer --ca-key=./OEM-KEYS/
qpsa_attestca.key --outfile ./signed_images_out/[Link]

The following is a sample command for IQ-9075/IQ-9100.

<meta>/common/sectoolsv2/ext/linux/sectools secure-image
--sign /path/to/[Link] --image-id=TZ --security-profile
<meta>/common/sectoolsv2/lemans_security_profile.xml --
oem-id=0x1 --oem-product-id=0xabcd --anti-rollback-
version=0x0 --signing-mode=LOCAL --root-certificate=./
OEM-KEYS/qpsa_rootca.cer --ca-certificate=./OEM-KEYS/
qpsa_attestca.cer --ca-key=./OEM-KEYS/qpsa_attestca.key -

80-70020-11 AC May contain U.S. and international export controlled information 93

 Configure security services

-outfile ./signed_images_out/[Link]

4. Check for images with the pil_split flag in the [Link] file.
Example: pil_split = "adsp"
For images that should be split, use the --pil-split option.
5. For signing the complete metabuild, use the following commands.

./sectools metabuild-secure-image --image-finder /common/

build/app/image_finder.py --sign --oem-id=0x1 --oem-
product-id=0xabcd --anti-rollback-version=0x0 --signing-
mode LOCAL --root-certificate=./OEM-KEYS/qpsa_rootca.cer
--ca-certificate=./OEM-KEYS/qpsa_attestca.cer --ca-key=./
OEM-KEYS/qpsa_attestca.key --chipset KODIAK --outdir
meta_signing_output/ --storage ufs

For more information, see SecTools V2: Metabuild Secure Image User Guide.

Note: The SecTools guides are available to licensed users with authorized access.

Generate the signed [Link] image

Generating a signed [Link] image involves creating a secure executable and linkable format (ELF)
file with a cryptographic signature. Signing this image ensures its authenticity, integrity, and origin.
A fuse blower binary is used to permanently disable certain functionalities or components of a
device for security reasons. Generating a signed [Link] image along with a fuse blower binary
involves a series of steps to ensure both the integrity of the firmware and the security of the device.
To generate fuse blower binary, see SecTools V2: Fuse Blower User Guide.

Integrate the sample commands using SecTools

This section provides sample commands only. The following are sample commands for SecTools
on Windows.

Note:
• You can replace the values of oem-id “0x1” and oem-product-id “0xabcd” according to your
requirement.
• You can replace the value of --fuse-pk-hash-0 with the SHA384 of OEM-KEYS/qpsa_
[Link].

80-70020-11 AC May contain U.S. and international export controlled information 94

 Configure security services

To calculate the correct PK_HASH value, use the following command:

openssl dgst -sha384 qpsa_rootca.cer

For more information, see Generate SHA-384 hash for RSA and ECDSA.
• Replace the digest generated here from the user Root cert in the [Link] generation
command below.

• Stage 1: Basic secure boot (image authentication + OEMID + MODEL ID)

Run the following command:

QCS5430/QCS6490

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
-security-profile <meta>/common/sectoolsv2/kodiak_
security_profile.xml --fuse-pk-hash-0=<sha384 of OEM-
KEYS/qpsa_rootca.cer> --fuse-oem-secure-boot1-pk-hash-in-
fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-secure-
boot2-pk-hash-in-fuse --fuse-oem-secure-boot2-auth-en --
fuse-oem-secure-boot3-pk-hash-in-fuse --fuse-oem-secure-
boot3-auth-en --fuse-oem-hw-id=0x0001 --fuse-oem-product-
id=0xabcd --generate --sign --signing-mode=LOCAL --root-
certificate=./OEM-KEYS/qpsa_rootca.cer --ca-certificate=.
/OEM-KEYS/qpsa_attestca.cer --ca-key=./OEM-KEYS/qpsa_
[Link] --oem-id=0x1 --oem-product-id=0xabcd --
outfile basic_sec.elf

IQ-9075/IQ-9100

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
-security-profile <meta>/common/sectoolsv2/lemans_
security_profile.xml --fuse-pk-hash-0=<sha384 of OEM-
KEYS/qpsa_rootca.cer> --fuse-oem-secure-boot1-pk-hash-in-
fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-secure-
boot2-pk-hash-in-fuse --fuse-oem-secure-boot2-auth-en --
fuse-oem-secure-boot3-pk-hash-in-fuse --fuse-oem-secure-
boot3-auth-en --fuse-oem-hw-id=0x0001 --fuse-oem-product-
id=0xabcd --generate --sign --signing-mode=LOCAL --root-
certificate=./OEM-KEYS/qpsa_rootca.cer --ca-certificate=.
/OEM-KEYS/qpsa_attestca.cer --ca-key=./OEM-KEYS/qpsa_
[Link] --oem-id=0x1 --oem-product-id=0xabcd --

80-70020-11 AC May contain U.S. and international export controlled information 95

 Configure security services

outfile basic_sec.elf

IQ-8275/IQ-8300

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
-generate --security-profile <meta>/common/sectoolsv2/
monaco_security_profile.xml --fuse-oem-secure-boot1-pk-
hash-in-fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-
secure-boot2-pk-hash-in-fuse --fuse-oem-secure-boot2-
auth-en --fuse-oem-secure-boot3-pk-hash-in-fuse --fuse-
oem-secure-boot3-auth-en --fuse-oem-hw-id=0x1 --fuse-oem-
product-id=0xabcd --fuse-pk-hash-0=<sha384 of OEM-KEYS/
qpsa_rootca.cer> --sign --signing-mode=LOCAL --root-
certificate=./OEM-KEYS/qpsa_rootca.cer --ca-certificate=.
/OEM-KEYS/qpsa_attestca.cer --ca-key=./OEM-KEYS/qpsa_
[Link] --outfile basic_sec.elf

IQ-615

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
-security-profile <meta>/common/sectoolsv2/talos_
security_profile.xml --fuse-pk-hash-0=<sha384 of OEM-
KEYS/qpsa_rootca.cer> --fuse-oem-secure-boot1-pk-hash-in-
fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-secure-
boot2-pk-hash-in-fuse --fuse-oem-secure-boot2-auth-en --
fuse-oem-secure-boot3-pk-hash-in-fuse --fuse-oem-secure-
boot3-auth-en --fuse-oem-hw-id=0x0001 --fuse-oem-product-
id=0xabcd --generate --sign --signing-mode=LOCAL --root-
certificate=./OEM-KEYS/qpsa_rootca.cer --ca-certificate=.
/OEM-KEYS/qpsa_attestca.cer --ca-key=./OEM-KEYS/qpsa_
[Link] --oem-id=0x1 --oem-product-id=0xabcd --
outfile basic_sec.elf

• Stage 2: Complete secure boot (basic secure boot + debug disable + anti-rollback + write
permission disable):
Run the following commands.

80-70020-11 AC May contain U.S. and international export controlled information 96

 Configure security services

QCS5430/QCS6490

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
-security-profile <meta\>/common/sectoolsv2/kodiak_
security_profile. xml --fuse-pk-hash-0=<sha384 of OEM-
KEYS/qpsa_rootca.cer> --fuse-oem-secure-boot1-pk-hash-in-
fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-secure-
boot2-pk-hash-in-fuse --fuse-oem-secure-boot2-auth-en --
fuse-oem-secure-boot3-pk-hash-in-fuse --fuse-oem-secure-
boot3-auth-en --fuse-oem-secure-boot-fec-enable --fuse-
wdog-en --fuse-shared-qsee-spiden-disable --fuse-shared-
qsee-spniden-disable --fuse-shared-mss-dbgen-disable --
fuse-shared-mss-niden-disable --fuse-shared-cp-dbgen-
disable --fuse-shared-cp-niden-disable --fuse-shared-ns-
dbgen-disable --fuse-shared-ns-niden-disable --fuse-apps-
dbgen-disable --fuse-apps-niden-disable --fuse-shared-
misc-debug-disable --fuse-eku-enforcement-en --fuse-anti-
rollback-feature-en=0xF --fuse-sec-key-derivation-
key=RANDOM --fuse-read-permissions-write-disable --fuse-
oem-configuration-write-disable --fuse-secondary-key-
derivation-key-read-disable
--fuse-write-permissions-write-disable
--fuse-public-key-hash-0-write-disable --fuse-oem-secure-
boot-write-disable --fuse-secondary-key-derivation-key-
write-disable --fuse-secondary-key-derivation-key-fec-
enable --fuse-fec-enables-write-disable --generate --sign
--fuse-oem-hw-id=0x0001 --fuse-oem-product-id=0xabcd --
signing-mode=LOCAL --root-certificate=./OEM-KEYS/qpsa_
[Link] --ca-certificate=./OEM-KEYS/qpsa_attestca.cer
--ca-key=./OEM-KEYS/qpsa_attestca.key --oem-id=0x1 --oem-
product-id=0xabcd --outfile [Link]

IQ-9075/IQ-9100

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
-security-profile <meta>/common/sectoolsv2/lemans_
security_profile.xml --fuse-pk-hash-0=<sha384 of OEM-
KEYS/qpsa_rootca.cer> --fuse-oem-secure-boot1-pk-hash-in-
fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-secure-
boot2-pk-hash-in-fuse --fuse-oem-secure-boot2-auth-en --
fuse-oem-secure-boot3-pk-hash-in-fuse --fuse-oem-secure-
boot3-auth-en --fuse-oem-secure-boot-fec-enable --fuse-
wdog-en --fuse-shared-qsee-spiden-disable --fuse-shared-

80-70020-11 AC May contain U.S. and international export controlled information 97

 Configure security services

qsee-spniden-disable --fuse-shared-mss-dbgen-disable --
fuse-shared-mss-niden-disable --fuse-shared-cp-dbgen-
disable --fuse-shared-cp-niden-disable --fuse-shared-ns-
dbgen-disable --fuse-shared-ns-niden-disable --fuse-apps-
dbgen-disable --fuse-apps-niden-disable --fuse-shared-
misc-debug-disable --fuse-eku-enforcement-en --fuse-anti-
rollback-feature-en=0xF --fuse-sec-key-derivation-
key=RANDOM --fuse-read-permissions-write-disable --fuse-
oem-configuration-write-disable --fuse-secondary-key-
derivation-key-read-disable --fuse-public-key-hash-0-
write-disable --fuse-oem-secure-boot-write-disable --
fuse-secondary-key-derivation-key-write-disable --fuse-
secondary-key-derivation-key-fec-enable --fuse-fec-
enables-write-disable --fuse-write-permissions-write-
disable --generate --sign --fuse-oem-hw-id=0x0001 --
fuse-oem-product-id=0xabcd --signing-mode=LOCAL --root-
certificate=./OEM-KEYS/qpsa_rootca.cer --ca-certificate=.
/OEM-KEYS/qpsa_attestca.cer --ca-key=./OEM-KEYS/qpsa_
[Link] --oem-id=0x1 --oem-product-id=0xabcd --
outfile [Link]

IQ-8275/IQ-8300

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
-generate --security-profile <meta>/common/sectoolsv2/
monaco_security_profile.xml --fuse-secondary-key-
derivation-key-read-disable --fuse-read-permissions-
write-disable --fuse-write-permissions-write-disable --
fuse-fec-enables-write-disable --fuse-public-key-hash-0-
write-disable --fuse-secondary-key-derivation-key-write-
disable --fuse-oem-secure-boot-fec-enable --fuse-
secondary-key-derivation-key-fec-enable --fuse-wdog-en --
fuse-eku-enforcement-en --fuse-oem-configuration-write-
disable --fuse-oem-secure-boot-write-disable --fuse-anti-
rollback-feature-en=0xf --fuse-shared-qsee-spiden-disable
--fuse-shared-qsee-spniden-disable --fuse-shared-mss-
dbgen-disable --fuse-shared-mss-niden-disable --fuse-
shared-cp-dbgen-disable --fuse-shared-cp-niden-disable --
fuse-shared-ns-dbgen-disable --fuse-shared-ns-niden-
disable --fuse-apps-dbgen-disable --fuse-apps-niden-
disable --fuse-shared-misc-debug-disable --fuse-usb-pipo-
disable --fuse-oem-secure-boot1-pk-hash-in-fuse --fuse-

80-70020-11 AC May contain U.S. and international export controlled information 98

 Configure security services

oem-secure-boot1-auth-en --fuse-oem-secure-boot2-pk-hash-
in-fuse --fuse-oem-secure-boot2-auth-en --fuse-oem-
secure-boot3-pk-hash-in-fuse --fuse-oem-secure-boot3-
auth-en --fuse-oem-hw-id=0x1 --fuse-oem-product-id=0xabcd
--fuse-pk-hash-0=<sha384 of OEM-KEYS/qpsa_rootca.cer> --
fuse-sec-key-derivation-key=RANDOM --sign --signing-
mode=LOCAL --root-certificate=./OEM-KEYS/qpsa_rootca.cer
--ca-certificate=./OEM-KEYS/qpsa_attestca.cer --ca-key=./
OEM-KEYS/qpsa_attestca.key --outfile [Link]

IQ-615

<meta>/common/sectoolsv2/ext/Linux/sectools fuse-blower -
security-profile <meta>/common/sectoolsv2/talos_security_
[Link] --fuse-pk-hash-0=<sha384 of OEM-KEYS/qpsa_
[Link]> --fuse-oem-secure-boot1-pk-hash-in-fuse --
fuse-oem-secure-boot1-auth-en --fuse-oem-secure-boot2-pk-
hash-in-fuse --fuse-oem-secure-boot2-auth-en --fuse-oem-
secure-boot3-pk-hash-in-fuse --fuse-oem-secure-boot3-
auth-en --fuse-oem-secure-boot-fec-enable --fuse-wdog-en
--fuse-apps-apb-dfd-disable --fuse-dcc-debug-disable --
fuse-debug-bus-disable --fuse-aoss-aop-dfd-disable --
fuse-eud-disable --fuse-dap-deviceen-disable --fuse-apps-
dbgen-disable --fuse-dap-dbgen-disable --fuse-lpass-
turing-dbgen-disable --fuse-wcss-dbgen-disable --fuse-
aoss-aop-dbgen-disable --fuse-cam-icp-dbgen-disable --
fuse-ssc-dbgen-disable --fuse-venus-0-dbgen-disable --
fuse-a5x-isdb-dbgen-disable --fuse-mss-dbgen-disable --
fuse-apps-niden-disable --fuse-dap-niden-disable --fuse-
lpass-turing-niden-disable --fuse-wcss-niden-disable --
fuse-aoss-aop-niden-disable --fuse-cam-icp-niden-disable
--fuse-ssc-niden-disable --fuse-mss-niden-disable --fuse-
apps-spniden-disable --fuse-dap-spniden-disable --fuse-
apps-spiden-disable --fuse-dap-spiden-disable --fuse-
llcc-dsrw-disable --fuse-read-permissions-write-disable -
-fuse-oem-configuration-write-disable --fuse-secondary-
key-derivation-key-read-disable --fuse-public-key-hash-0-
write-disable --fuse-oem-secure-boot-write-disable --
fuse-secondary-key-derivation-key-write-disable --fuse-
secondary-key-derivation-key-fec-enable --fuse-sec-key-
derivation-key=RANDOM --fuse-fec-enables-write-disable --
generate --sign --fuse-oem-hw-id=0x0001 --fuse-oem-

80-70020-11 AC May contain U.S. and international export controlled information 99

 Configure security services

product-id=0xabcd --signing-mode=LOCAL --root-

certificate=./OEM-KEYS/qpsa_rootca.cer --ca-certificate=.
/OEM-KEYS/qpsa_attestca.cer --ca-key=./OEM-KEYS/qpsa_
[Link] --oem-id=0x1 --oem-product-id=0xabcd --
outfile [Link]

Note: The SecTools guides are available to licensed users with authorized access.

Encrypt the unified image encryption

Unified image encryption (UIE) is designed to protect image integrity by encrypting image files,
thereby preventing unauthorized tampering. This mechanism ensures that only authorized devices
can decrypt and access the original images.
For command-line usage related to UIE encryption, see SecTools V2: Secure Image User Guide.
UIE encryption isn’t supported for IQ-9075/IQ-9100 and IQ-8275/IQ-8300.

Note: The SecTools guides are available to licensed users with authorized access.

Generate your own key for encryption

1. The user UIE keys are the standard AES 128 keys and can be generated using the OpenSSL
tool.
Use the command:

openssl enc -aes-128-cbc -k <secret> -P -md sha1

Where:
• openssl enc: Invokes the OpenSSL encryption tool.
• -aes-128-cbc: Specifies the encryption algorithm — AES with a 128-bit
key in the cipher block chaining (CBC) mode.
• -k secret: Provides the password (secret) from which the key and
initialization vector (IV) are derived.
• -P: Prints the derived key and IV instead of performing an encryption or
decryption.
• -md sha1: Specifies the message digest algorithm (sha1) used in the key
derivation function (KDF).

80-70020-11 AC May contain U.S. and international export controlled information 100
 Configure security services

For example:

openssl enc -aes-128-cbc -k "secret_passphrase" -P

-md sha1

• salt=E2A1F3C4D5B6A798
• key=5F4DCC3B5AA765D61D8327DEB882CF99
• iv =AABBCCDDEEFF00112233445566778899
2. Copy the key to a file to make your key.
echo "5F4DCC3B5AA765D61D8327DEB882CF99" > l1_key.key
Generate a UIE [Link] file
1. Use the command to generate a UIE [Link] file.

./sectools fuse-blower --security-profile <chipset>_security_

[Link] --outfile uie_sec.elf --fuse-image-encryption-enable
--generate --sign --signing-mode TEST --fuse-oem-image-
encryption-key=0x5F4DCC3B5AA765D61D8327DEB882CF99 --fuse-oem-
image-encryption-key-fec-enable

2. Update the security profile XML appropriate to the chipset.

3. Use the signing mode as LOCAL or PLUGIN according to the requirement.
4. Update the encryption key according to your key.
Once the UIE [Link] file is generated, you can flash it onto the non-secure device. After flashing
the UIE [Link], you should then flash the secure boot enablement [Link] along with the other
fuses.
Encrypt the binaries
To encrypt the binaries with the test keys, use the following arguments along with the signing
command.

--encrypt --encryption-mode TEST

To encrypt the binaries with the local keys, use the following arguments along with the signing
command.

--encrypt --encryption-mode LOCAL --l1-key l1_key.key

80-70020-11 AC May contain U.S. and international export controlled information 101
 Configure security services

Flash the images

Flashing images involves writing an entire image, including partitions, file systems, and data, onto a
storage device. This process helps keep the functionality, security, and performance of the device.
Follow these steps to flash the images:
1. See Set QFPROM fuses for the list of fuses to configure.
2. Replace all binaries with the signed non-Linux binaries generated in Sign the images,
including prog_firehose_ddr.elf.
To replace the PIL images, replace the existing PIL images with their corresponding signed
versions generated earlier.
• Extract the <chipset_name.LE.x.x>/common/build/ufs/bin/<chipset_
name>_fw.zip file.
• Replace the PIL split binaries and the .mdt files generated in the signed output into the
extrcted directory <chipset_name.LE.x.x>/common/build/ufs/bin/
<chipset_name>_fw/lib/firmware/qcom/<chipset_name>.
• Zip the <chipset_name.LE.x.x>/common/build/ufs/bin/<chipset_
name>_fw directory with <chipset_name>_fw.zip name.
• Recompile the Yocto build.
3. To flash all the signed binaries to the device, see Qualcomm Linux Build Guide.
4. After generating the signed images and [Link], enable secure boot:
a. Flash the signed images first without [Link] and ensure that the device boots
successfully.
b. Flash [Link] by updating the [Link] file as:
<program start_sector="207781" size_in_KB="28.0"
physical_partition_number="4" partofsingleimage="false"
file_sector_offset="0" num_partition_sectors="7"
readbackverify="false" filename="[Link]"
sparse="false" start_byte_hex="0x32ba5000" SECTOR_SIZE_
IN_BYTES="4096" label="secdata"/>
b. Flash the signed images and [Link] using the flash procedure from Qualcomm
Linux Build Guide.
c. Flash the image using PCAT.
d. Verify that the secure boot is enabled using Bring up → Verified secure boot.
5. When the secure boot is enabled, the device expects images to be flashed using a secure
programming method called validated image programming (VIP). In this release, you can
proceed with flashing the images on the secure device by disabling VIP using the following

80-70020-11 AC May contain U.S. and international export controlled information 102
 Configure security services

workaround programmer (prog_firehose_ddr.elf) image at: <>/[Link].1.0.

c1/boot_images/boot/QcomPkg/Library/DevPrgLib/devprg_transfer.c
6. Set the vip->state to VIP_DISABLED irrespective of the secure boot enable check in
the following function:

int devprg_transfer_init(void)
{
int secboot, result;
struct vip_data *vip = &vip_data;
devprg_init_vip_state();
secboot = devprg_is_secure_boot_enabled();
// if (secboot == 0) /*comment this to set vip state to VIP_
DISABLED
vip->state = VIP_DISABLED;
result = devprg_transport_init();
return result;
}

7. To rebuild prog_firehose_ddr.elf, see Qualcomm Linux Build Guide.

8. If any of the PIL signed images aren’t flashed using PCAT, follow these steps to push the PIL
images manually using SCP:

push adsp, cdsp, modem, wlan, ipa pil split binaries

For instructions, see Qualcomm Linux Build Guide.

a. Copy and replace the PIL split bins and the .mdt files generated in the signed output to
the <<[Link].x.x>/common/build/ufs/bin/QCM6490_
fw/lib/firmware/qcom/qcm6490/ directory.
b. Connect to the device as the root using SSH. For instructions, see Qualcomm Linux
Build Guide.
Run the following command:

mount -o rw,remount /
scp <[Link].x.x>/common/build/ufs/bin/QCM6490_fw/lib/
firmware/qcom/qcm6490/. root@<IP_address>:/lib/firmware/qcom/
qcm6490/
Push gfx (a660_zap) pil split binaries, a660_zap.mdt and
a660_zap.mbn from signed outout
scp <a660_zap signed output folder>/. root@<IP_address>:/lib/
firmware/
Push signed Venus binary:
scp vpu20_1v.mbn root@<IP_address>:/lib/firmware/qcom/vpu-2.

80-70020-11 AC May contain U.S. and international export controlled information 103
 Configure security services

0/
reboot

9. To check for PIL loading success, check for the following logs in dmesg:

[ 7.597009] remoteproc remoteproc0: Booting fw image

qcom/qcs6490/[Link], size 6052
[ 8.095883] remoteproc remoteproc0: remote processor
[Link] is now up
[ 5.938938] remoteproc remoteproc1: Booting fw image
qcom/qcs6490/[Link], size 4612
[ 6.088524] remoteproc remoteproc1: remote processor
[Link] is now up
[ 5.951047] remoteproc remoteproc2: Booting fw image
qcom/qcs6490/[Link], size 6852
[ 6.107310] remoteproc remoteproc2: remote processor
[Link] is now up
[ 5.977966] remoteproc remoteproc3: Booting fw image
qcom/qcs6490/[Link], size 5252
[ 6.135802] remoteproc remoteproc3: remote processor
[Link] is now up

Next steps

• To enforce strict access controls, see Enable SELinux.

• To ensure that only the verified and trusted applications are loaded during the startup
process, see Enable UEFI secure boot.

80-70020-11 AC May contain U.S. and international export controlled information 104
 Configure security services

Next steps
• To enable secure boot, QFPROM fuses must be blown. This is a one-time, irreversible
process that permanently sets these values. For more information see Set the QFPROM
fuses.
• To ensure the that the cryptographic keys and certificates are generated and managed in a
secure and trusted environment, see Generate keys and certificates.

3.3 Enable SELinux

When SELinux is enabled, all system objects, including files, directories, processes, sockets,
drivers, and more, are labeled with a security context.
A security context consists of a user, role, type identifier, and optional sensitivity, separated by
colons.
For example: user:role:type:sensitivity

Note: User is unrelated to a Linux user, and Type is unrelated to the kind of object it is.

• A set of valid users, roles, and types is defined in the policy.

• Different objects are labeled with the same security context.
• The MAC mechanism of SELinux security policies is implemented using:
– Type enforcement (TE)
– Role-based access control (RBAC)
– Multilevel security (MLS)
• Types enable the policy to specify the allowed operations.

Figure : SELinux process

The following procedures explains how to verify and enable SELinux and modify SELinux modes.

80-70020-11 AC May contain U.S. and international export controlled information 105
 Configure security services

Note: By default, SELinux is disabled to simplify the validation process while working with the
SoC and SDK. For commercial use, it’s recommended to enable the SELinux security feature.

Verify and modify SELinux mode

Caution: If SELinux is enabled, you may not be allowed to update the anti-rollback protection
flag.

1. Check the current SELinux configuration of the device (Enforcing or Permissive mode):

getenforce

2. If it’s set to the Enforcing mode, run the setenforce command to change the mode.
a. Connect to the device using SSH.
b. Change the SELinux mode by using the following commands.
• To switch the device to Enforcing mode:

setenforce 1

• To switch the device to Permissive mode:

setenforce 0

• To recheck the current configuration of the device (Enforcing or Permissive mode):

getenforce

80-70020-11 AC May contain U.S. and international export controlled information 106
 Configure security services

Configure SELinux (Enable, disable, and switch modes)

To switch to Enforcing mode (restrictive) or Permissive mode (non-restrictive with logging), follow
these steps:
1. To enable or disable SELinux:
• To disable SELinux for the build, delete the lines of code. By default, these lines are
already removed from the distro section, which results in SELinux being disabled.
• To enable SELinux, add the lines of code as shown in the figure to enable SELinux.
• Use policy version 33.
• To add policies for SELinux, see upstream refpolicy. The following figure shows the
steps in a SELinux:

2. Check the system status with getenforce on target. This command returns one of the
three values:
• Enforcing
• Permissive
• Disabled
3. To change the mode, select a mode at runtime by running setenforce with a number (this
change won’t persist after reboot).

Command Result
setenforce 1 Switch to Enforcing mode
setenforce 0 Switch to Permissive mode

a. To persist after reboot:

i. Connect to the device using SSH. For instructions, see Qualcomm Linux Build
Guide.
ii. Edit SELINUX= to one of the three supported values: enforcing, permissive,
or disabled in /etc/selinux/config.
iii. Reboot the device using the following command:

80-70020-11 AC May contain U.S. and international export controlled information 107
 Configure security services

reboot

b. To specify the SELinux mode in the build: Change the DEFAULT_ENFORCING build
flag to one of the three supported values: enforcing, permissive, or disabled.

conf/distro/include/[Link]
-- DEFAULT_ENFORCING = "permissive"
++ DEFAULT_ENFORCING = "enforcing"

4. The SELinux Disabled mode leaves behind many code paths that go through the SELinux
framework. These code paths aren’t useful for KPI testing or verifying bugs in the SELinux
framework. It also doesn’t allow any more access than Permissive mode.
To disable the feature for testing, remove SELinux from DISTRO_FEATURES:

conf/distro/include/[Link]
-- DISTRO_FEATURES:append = " selinux"

Next steps
• To ensure that only the verified and trusted applications are loaded during the startup
process, see Enable UEFI secure boot.
• For chipset feature management and to upgrade the chipset feature packs, see Install or
upgrade SoftSKU feature packs.

3.4 Enable UEFI secure boot

UEFI secure boot enhances the security and reliability of the system by ensuring that only the
verified and trusted software loads during startup.

80-70020-11 AC May contain U.S. and international export controlled information 108
 Configure security services

Configure an UEFI secure boot to generate keys and certificates

You can setup an initial UEFI secure boot configuration and convert the keys and certificates into a
format that UEFI can understand. See the workflow to understand the off-target preparation and
the on-device execution.

Figure : UEFI secure boot workflow

Note: Secure communications and cryptography are facilitated by the OpenSSL toolkit, while keys
and signatures for UEFI secure boot are managed by efitool.

Install OpenSSL and efitools

1. Install OpenSSL 0.9.80 June 2010 (or later version) on the Linux host computer.
2. Install the efitools using the following:
• cert-to-efi-sig-list: converts OpenSSL certificates to EFI signature lists
• sign-efi-sig-list: signs the EFI signature list
• hash-efi-sig-list: creates a hash signature list entry from a binary

80-70020-11 AC May contain U.S. and international export controlled information 109
 Configure security services

Generate key and certificate

To enable UEFI secure boot, generate a pair of keys and certificates for signing and authentication.
The key generation supports the following algorithms:
• RSA 2048/4096 with SHA-256/SHA384 hash algorithm
• ECDSA secp256r1/secp384r1
The following procedures provide instructions to generate keys and certificates with RSA 2048 and
SHA-256 as an example.

Note:
• Create a directory and run the commands in the same location to perform these steps on a
Linux machine.
• For ECC, replace rsa:2048 with ec:secp384r1 or ec:secp256r1. For SHA384,
replace -sha256 with -sha384 in the following commands.

Generate UID
You can generate a GUID and create three new keys with self-signed certificates in CRT/PEM
format and keys in .key format:
GUID uses uuidgen to generate the signature owner GUID:

uuidgen --random > [Link]

Create PK key
1. Create a PK key pair (RSA-2048) and certificate:

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Custom PK/" -

keyout [Link] -out [Link] -days 3650 -nodes -sha256

2. Convert the .crt file into the .cer file:

openssl x509 -outform der -in [Link] -out [Link]

3. Convert the .crt file into the .esl file:

cert-to-efi-sig-list -g "$(< [Link])" [Link] [Link]

4. Sign and generate the .auth file with the .crt, .esl, and .key files:

sign-efi-sig-list -k [Link] -c [Link] PK [Link] [Link]

80-70020-11 AC May contain U.S. and international export controlled information 110
 Configure security services

Create KEK key

1. Create a KEK key pair (RSA-2048) and certificate:

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Custom KEK/"

-keyout [Link] -out [Link] -days 3650 -nodes -sha256

2. Convert the .crt file into the .cer file:

openssl x509 -outform der -in [Link] -out [Link]

3. Convert the .crt file into the .esl file:

cert-to-efi-sig-list -g "$(< [Link])" [Link] [Link]

4. Sign and generate the .auth file with the .crt, .esl, and .key files:

sign-efi-sig-list -k [Link] -c [Link] KEK [Link] [Link]

Create dB key
1. Create a dB key pair (RSA-2048) and certificate:

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Custom DB

Signing Key 1/" -keyout [Link] -out [Link] -days 3650 -nodes -
sha256

2. Convert the .crt file into the .cer file:

openssl x509 -outform der -in [Link] -out [Link]

3. Convert the .crt file into the .esl file:

cert-to-efi-sig-list -g "$(< [Link])" [Link] [Link]

4. Sign and generate the .auth file with the .crt, .esl, and .key files:

sign-efi-sig-list -k [Link] -c [Link] db [Link] [Link]

80-70020-11 AC May contain U.S. and international export controlled information 111
 Configure security services

Sign images and copy (.auth) key/signed files to EFI partition

The EFI system partition consists of EFI, loader, and ostree with information relevant to EFI when
using systemd-boot. The DTB partition consists of dtb directories.
The EFI system partition holds essential files for booting the system and managing updates, while
the DTB partition contains hardware configuration information. This section provides instructions
to:
• Sign various images.
• Copy (.auth) key and signed files to EFI partition and DTB partition directories.
• Signed and executable images such as the [Link] file (systemd-boot) are placed
in the efimountedbin/EFI/BOOT/ directory and the [Link] file (Linux)
image is placed in the efimountedbin/ostree/poky-xxx/[Link]
directory.
The systemd-boot validates the signed images and is also used to enroll the following:
• UEFI secure boot keys are placed in a specific directory in /keys for key enrollment. The
systemd-boot uses these keys and provisions them in the RPMB or UEFI variable store
during UEFI boot time services.
• You can configure the wait time (in seconds) in the systemd-boot loader configuration. Kernel
loading is delayed during the wait time, allowing you to review and select available options in
the systemd-boot menu.
• Device tree files are stored in the dtbmountedbin/dtb directory. These files are used by
UEFI during runtime, and the device tree files are initialized. While signing, .sig files are
created and placed in the same directory as these files are non- PE images.

Table : EFI system partition ([Link])

/EFI /Loader /ostree
/Boot/[Link] [Link] poky-xxx/vmlinuz-x.
[Link]
/keys/authkeys/db.
auth
/keys/authkeys/KEK.
auth
/keys/authkeys/PK.
auth

Table : DTB partition ([Link])

[Link] [Link] /loader

80-70020-11 AC May contain U.S. and international export controlled information 112
 Configure security services

/keys/authkeys/db.
auth
/keys/authkeys/KEK.
auth
/keys/authkeys/PK.
auth

Place signed images and keys in EFI partition

Follow these steps to place the signed images and keys in an EFI partition on a Linux host
machine.
1. Locate the [Link] and [Link] file paths in the [Link], file to obtain the
[Link] and [Link]` files from the meta.
2. Mount the [Link] file into the <workspace> directory and create an efimountedbin
directory within the <workspace> directory.
3. Mount the [Link] file into the <workspace> directory and create a dtbmountedbin
directory within the <workspace> directory.
4. Mount the [Link] file:

sudo mount [Link] efimountedbin

cd efimountedbin

5. Mount the [Link] file:

sudo mount [Link] dtbmountedbin

cd dtbmountedbin

6. Create an authkeys directory within the <workspace>/efimountedbin/loader/keys

directory to enroll keys.
7. Select and copy the .auth files ([Link], [Link], and [Link]) to the authkeys
directory.

sudo cp <selected algo PK/KEK/DB auth files from the files

location>
<workspace>/efimountedbin/loader/keys/authkeys/

8. Create an authkeys directory within the

<workspace>/dtbmountedbin/loader/keys directory to enroll keys.
9. Select and copy the .auth files ([Link], [Link], and [Link]) to the authkeys

80-70020-11 AC May contain U.S. and international export controlled information 113
 Configure security services

directory in dtbmountedbin.

sudo cp <selected algo PK/KEK/DB auth files from the files

location> <workspace>/dtbmountedbin/loader/keys/authkeys/

10. Sign the [Link], [Link] and dtb, [Link], and

[Link] image files with the keys and copy to the respective directories in the
efimountedbin directory.
a. Sign efi images:
The sbsign tool is designed for signing EFI boot images, such as [Link]
[Link] that follow EFI specifications. This tool, which is used for UEFI secure boot
signing is available for download and use on Linux systems. It’s important to note that
sbsign can only sign PE images with a .efi extension.
i. Copy the [Link] file from the /efimountedbin directory /EFI/BOOT
and the [Link] file from the /ostree/poky-xxx/vmlinuz.x.x.
xx ` directory to the :file:`images directory on your Linux machine.
ii. Sign the images:

cd <workspace>/images

sudo sbsign --key <workspace>/keys/[Link] --cert

<workspace>/keys/[Link] [Link] --output
<workspace>/[Link]

sudo sbsign --key <workspace>/keys/[Link] --cert

<workspace>/keys/[Link] [Link] --output
<workspace>/[Link]

b. Sign the dtb image:

All images authenticated by UEFI secure boot are regular APIs and typically in the PE
format. The signature header and size are appended to the existing PE header, and the
signature is appended at the end of the signed file.
However, when images in non- PE formats require UEFI secure boot authentication, the
absence of the PE header and its magic number to recognize the image format fail. As
a result, it’s not possible to use standard tools and paths for image verification.
Currently, among the list of images that UEFI secure boot verifies, only the dtb files are
in non- PE format images. As an alternative to the sbsign tool, you can use the
OpenSSL cms command to generate signature files for signing images in non- PE
format.
Follow these steps for signing non-EFI images:

80-70020-11 AC May contain U.S. and international export controlled information 114
 Configure security services

i. To sign the dtb file and signature file, run the following command:

openssl cms -sign -inkey < .key file > -signer < .
crt file > -binary -in <input dtb file>-out < Output
.[Link] file > -outform DER

ii. To sign the image, run the following command:

cd <workspace>/images

sudo openssl cms -sign -inkey <workspace>/keys/db.

key -signer <workspace>/keys/[Link] -binary -in
[Link] --out [Link] -outform DER

11. Copy the signed [Link], [Link], and [Link] images

back to their respective directories (dtbmountedbin/,
efimountedbin/ostree/poky-xxx/, and efimountedbin/EFI/BOOT/).
12. Configure the wait time in systemd-boot:
a. Open and edit the [Link] file at /loader/[Link] with sudo access:

sudo vi [Link]

b. Add the line timeout 2 to set the boot menu timeout and save the file.
13. To unmount the EFI binary to retrieve the latest [Link] file, run the command:

sudo umount efimountedbin

14. To unmount the DTB binary to retrieve the latest [Link] file, run the command:

sudo umount dtbmountedbin

15. Securely place the signed images and keys in the EFI partition on target.
Bring the device into the Fastboot mode and flash the latest [Link] file with the
fastboot command:

fastboot flash efi <efi binary location>

fastboot flash dtb_a <dtb binary location>

For more information, see quic/host-signing-tool.

80-70020-11 AC May contain U.S. and international export controlled information 115
 Configure security services

Enable UEFI secure boot from systemd-boot menu

The EFI binary is composed of signed images and secure boot keys, which are generated and then
flashed into the system. For more details, see Sign images and copy (.auth) key/signed files to EFI
partition.
When the UEFI is loaded and run during the next bootup, the systemd-boot manager displays the
EnrollSecure Boot keys: authkeys and Ubuntu1 8.04.6 LTS menu options on the screen.

Note: These options are displayed when a timeout is configured. For more information, see
[Link] settings in Sign images and copy (.auth) key/signed files to EFI partition.

Figure : Systemd-boot menu options

You can use the volume +/- buttons to navigate and select the appropriate option to enroll the keys.
When the key is successfully enrolled, UEFI automatically switches from SetupMode to
UserMode. The logs for the UEFI secure boot enablement are listed in the serial logs when the
systemd-boot triggers a system reset to apply the changes.
By default, UEFI starts in UserMode, and the UEFI secure boot is initialized during the next boot
cycle. The logs for the UEFI secure boot enablement are listed in the serial logs when
thesystemd-boot transfers control to the KERNEL EFI STUB.

Figure : UEFI secure boot enablement information from serial log

The option to enroll with systemd-boot is only available once. This release doesn’t support the
reprovisioning and updating of UEFI secure boot keys.

80-70020-11 AC May contain U.S. and international export controlled information 116
 Configure security services

Hash unsigned images and update DB for image authentication

UEFI secure boot allows image authentication. This authentication is achieved through the hash of
images stored in the signature database (dB), even if the images aren’t signed or the certificates in
the images aren’t present in the dB.
This process is reserved for content that can’t be signed or altered from its vendor-provided state.
If the image hash is available in the database deny (dBX) list, the trust of signed binaries can be
removed without having to revoke the corresponding certificates or keys. This is useful, for
example, when dealing with an earlier signed boot loader that’s vulnerable to recent exploits.
It’s redundant to apply a signature and create a dB hash for the same binary. Follow these steps if
the image composition doesn’t require any changes, meaning no new keys and certificates are
being added or modified in the image, and no UEFI secure boot authentication is needed for the
existing images.
You can calculate the hash of images and generate an allowed signature dB file.
Generate [Link] file for unsigned images
1. Generate a hash of all images to be verified and convert the hash into an .esl file:

hash-to-efi-sig-list <list of efis to be hashed> <output file

name with .esl extension>

2. Sign the .esl hash file with the dB key:

sign-efi-sig-list -k < .key file location > -c < .crt file

location > <secure variable name> <Above generated .esl file>
<o/p .auth file>

3. Copy the generated [Link] file into the EFI binary and provision the keys into the device.
For example, on a Linux host machine:
1. Mount the [Link] file to the <workspace> directory and create an efimountedbin
folder in the <workspace> directory.
2. Create a testkeys folder in the <workspace> directory on the Linux machine and copy
the pre-existing keys to it.
3. Sign the images:

hash-to-efi-sig-list <workspace>/efimountedbin/EFI/BOOT/
[Link] <workspace>/efimountedbin/EFI/Linux/[Link]
[Link]
sign-efi-sig-list -k keys [Link] -c [Link] db [Link] db.
auth

4. Copy the [Link] file to the qckeys folder at

80-70020-11 AC May contain U.S. and international export controlled information 117
 Configure security services

<workspace>/efimountedbin/loader/keys/qckeys.
5. Follow the dtb signing steps and sign the dtb images to generate a new [Link] file. For
more information, see Sign images and copy (.auth) key/signed files to EFI partition.
6. For a Linux host machine on the target:
a. Erase any existing UEFI secure boot keys and flash the EFI binary with fastboot.
b. Provision keys with systemd-boot. For more information, see Enable UEFI secure boot
from systemd-boot menu.

Note: All unsigned files are signed with other keys and authenticated with UEFI using
this method.

Next steps
• For chipset feature management and to upgrade the chipset feature packs, see Install or
upgrade SoftSKU feature packs.
• To customize memory and SEPolicy, see Customize secuity services.
• For common logging and debugging techniques, see Debug Qualcomm TEE and secure
devices.

3.5 Install or upgrade the SoftSKU feature packs

You can upgrade the QCS5430 soft stock keeping unit (SKU) feature packs using the Qualcomm
WES license. For more information about the feature packs, see QCS5430: Feature packs.

Important: This feature is applicable to QCS5430.

80-70020-11 AC May contain U.S. and international export controlled information 118
 Configure security services

Download the evaluation license

The figure shows the process of downloading and upgrading the QCS5430 SoftSKU feature packs.

Figure : Upgrade QCS5430 SoftSKU feature packs

The table lists the feature packs along with the corresponding links to download their evaluation
licenses.

Table : Download evaluation license

Feature packs Download links to license files
FP2 QCM5430 FP2.0
FP2.5 QCM5430 FP2.5
FP3 QCM5430 FP3.0

80-70020-11 AC May contain U.S. and international export controlled information 119
 Configure security services

Prepare the device

1. Set up the Wi-Fi on the device and get the device-ip-address.
2. Connect to the device using SSH:
ssh root@device-ip-address
For instructions, see Qualcomm Linux Build Guide.
3. Remount the file system with read/write permissions:

mount -o rw,remount /

4. Push the license to the device:

scp /path/to/<QCM5430 FP*>.pfm root@device-ip-address:/data/

Install the evaluation license

1. Ensure that the following prerequisites are met:
• RPMB is provisioned.
To verify if RPMB is provisioned, see Verify RPMB provision status.
• The qwes_cli tool is available in the device.
2. Install the Qualcomm WES command-line interface tools:
• Help: qwes_cli -help.
• Default tools shipped with the Qualcomm Linux software product.
3. Install the evaluation license:

ssh root@device-ip-address
qwes_cli -f /data/<QCM5430 FP*>.pfm install

4. Verify license installation:

qwes_cli list

80-70020-11 AC May contain U.S. and international export controlled information 120
 Configure security services

Command Output
Check the serial number: # qwes_cli list
qwes_cli list Running GetAllSerialNumber
test with multithread Disabled
Success. Len = 25
Parsing 2 serial numbers
Serial Number: 15b3
Serial Number:
3e52b512f2f47851a40fa5b30000018c86261aa1

5. Ensure you restart the device for the license to take effect.

Verify the feature pack upgrade

The two ways to verify the feature packs are:
• Verify the feature pack upgrade by using the following commands:

ssh root@device-ip-address
cat /proc/device-tree/model

The feature pack ID model is displayed in the output:

– FP2: Qualcomm Technologies, Inc. qcs5430 fp2 addons
rb3gen2 platforms
– FP2.5: Qualcomm Technologies, Inc. qcs5430 fp2p5 addons
rb3gen2 platform
– FP3: Qualcomm Technologies, Inc. qcs5430 fp3 addons
rb3gen2 platform

Note: The feature pack and model ID mapping will be {Feature Pack2: fp2
; Feature pack2.5: fp2.5; Feature pack 3: fp3}.

• Verify feature pack ID from the following UEFI logs:

FP1 SoftSKU ID is disabled. The default setting is 1.

FP2 SoftSKU ID is enabled. updated here: 2
FP2.5 SoftSKU ID enabled. updated here: 8
FP3 SoftSKU ID enabled. updated here: 3

80-70020-11 AC May contain U.S. and international export controlled information 121
 Configure security services

Manage the device licenses

You can perform the following operations to manage your device licenses:
• Upgrade the feature pack or apply a new license.
– Multiple licenses can be installed.
– License with the highest feature pack will be enforced by design.
– You can upgrade or downgrade the feature pack license among the offered.
– To downgrade, remove the license with the higher feature pack and apply the license for
the required feature pack.
• Remove the evaluation license.
– Get the license serial number:

qwes_cli list
Running GetAllSerialNumber test with multithread
Disabled
Success. Len = 25
Parsing 2 serial numbers
Serial Number: 15b3
Serial Number: 3e52b512f2f47851a40fa5b30000018c86261aa1

– Remove the license:

ssh root@device-ip-address
qwes_cli -s 3e52b512f2f47851a40fa5b30000018c86261aa1
remove
Serial number length 20
Remove License is successful.

– Verify if the removed license serial number doesn’t appear in the license list:

qwes_cli list
Running GetAllSerialNumber test with multithread
Disabled
Success. Len = 4
Parsing 1 serial numbers
Serial Number: 15b3

–Ensure you restart the device for the removal of the license to
take effect.

80-70020-11 AC May contain U.S. and international export controlled information 122
 Configure security services

Feature pack license - Persistence over software upgrades

• The license is installed in persistent secure storage, RPMB.
• When the license is installed successfully, its metadata is stored in RPMB, and a copy is
maintained in the data partition.
• Even if user data is erased, the license remains preserved in RPMB, ensuring that the device
functionality isn’t impacted.

Note: This feature is available to licensed users with authorized access to manage feature pack
licenses. If you have access, see Qualcomm Linux Wireless Edge Services Guide.

See also
• To learn about Qualcomm WES, see Qualcomm WES.
• To develop applications that offer hardware-based attestation, zero-touch device
provisioning, and chipset feature management, see: Qualcomm Linux Wireless Edge
Services Guide. This feature is available to licensed users with authorized access.

3.6 Next steps

• To adjust Qualcomm TEE configurations, see Enable device configuration (Devcfg) from
Qualcomm TEE.
• To enable secure boot and to ensure only trusted applications runs on the device, see Enable
secure boot.
• To enforce strict access controls, see Enable SELinux.
• To ensure that only the verified and trusted applications are loaded during the startup
process, see Enable UEFI secure boot.
• To install or upgrade QCS5430 SoftSKU feature packs, see: Install or upgrade SoftSKU
feature packs.

80-70020-11 AC May contain U.S. and international export controlled information 123
4 Customize secuity services

Customization is supported for memory and SEPolicy. For a large-size trusted application, you can
customize the memory regions.

4.1 Customize memory

To customize memory, this feature is available to licensed users with authorized access. If you
have access, see Qualcomm Linux Security Guide - Addendum.

4.2 Customize SEPolicy

Qualcomm SEPolicy depends on the upstream SEPolicy. Therefore, the upstream SEPolicy’s make
system is used for building and customizing the SEPolicy.
Any customization to upstream code must be stored in the patches directory as a path to the
upstream code. You can find the upstream code at SELinuxProject/refpolicy.
The Qualcomm code is configured to the monolithic SEPolicy mode and SELinux types as
targeted. To modify the SEPolicy mode and the SELinux types, do the following:
• To change the SELinux type and mode, you can edit the Qualcomm base file.
• To add the SEPolicy patches, add it to the patches folder and update the respective selinux_
type bbappend files ([Link] or [Link]), which aren’t
set by default. Add selinux enablement code in distro and then edit PREFERRED_
PROVIDER_virtual/refpolicy.
Compile SEPolicy
1. To compile the SEPolicy, run the following commands:

export SHELL=/bin/bash

2. Set up the build environment. For instructions, see Qualcomm Linux Build Guide.
3. Based on the SELinux type, compile only the SEPolicy with bitbake refpolicy-mls or
bitbake refpolicy-targeted.

80-70020-11 AC May contain U.S. and international export controlled information 124
 Customize secuity services

bitbake <recipe_file_name>

Modify and build

You can also modify and build incrementally.
The audit2allow and research tools on Ubuntu 18 or 20 don’t support policy version33. The policy
version33 is supported from Ubuntu 23. If you aren’t using Ubuntu 23, you can use a docker setup
or a virtual machine to run audit2allow.
Install docker
The following command is used to install docker on Ubuntu with lower version.

sudo docker pull ubuntu:23.04

sudo docker run -ti --rm ubuntu /bin/bash
apt-get update
apt-get -y install policycoreutils
apt-get install -y policycoreutils-python-utils

Then run audit2allow on this shell .

Pull the policy version33 from the target /etc/selinux/mls/policy/policy.33. This
policy is also available in the build tree. Use the mountbind or docker copy commands to share the
policy with the docker.
Capture denials
If the command prompt doesn’t change when policy.33 is pulled from the target /build,
and if [Link] is a file capturing the denials, use the following command:

audit2allow -i [Link] -p policy.33

Command not found

If this command isn’t found, then use the following command to install the required package:

sudo apt install policycoreutils-python-utils

4.3 Next steps

• For common logging and debugging techniques, see Debug Qualcomm TEE and secure
devices.
• To learn how to develop and run trusted and client applications, and for sample code and
examples, see Develop trusted and client applications.

80-70020-11 AC May contain U.S. and international export controlled information 125
5 Debug Qualcomm TEE and secure
devices

Debug provides a set of common logging and debugging techniques to troubleshoot issues in
Qualcomm TEE, trusted and client applications, and secure devices.

Note: Run all the SSH commands in the SELinux Permissive mode. The Enforcing mode will be
supported in the future. For instructions on how to connect to the device, see Qualcomm Linux
Build Guide.

5.1 Debug Qualcomm TEE

Qualcomm TEE kernel logs, also known as the TrustZone diag log, can be used to debug errors
that occur in Qualcomm TEE.
The TrustZone diag log is available in the Linux kernel driver, which redirects the logs.
1. Connect to the device as the root using SSH.
2. Capture the TrustZone logs using the following command:

cat /proc/tzdbg/log > tzbsp_log.txt

The error codes in tzbsp_log.txt are encoded in hexadecimal. You can run the following tool
to decode tzbsp_log.txt from hexadecimal to string.
1. Go to <[Link].X.X path>/trustzone_images/ssg/bsp/tz/build/tz/A53_
64/<BuildFlavor>
2. Run the following commands using python 3.

python3 print_tz_log.py -l tzbsp_log.txt -e [Link] -

t <[Link].X.X path> -o tzbsp_log_decode.txt

For example:

80-70020-11 AC May contain U.S. and international export controlled information 126
 Debug Qualcomm TEE and secure devices

Python3 print_tz_log.py -l tzbsp_log.txt -e [Link] -

t //crmhyd/nsid-hyd-05/[Link].5.0-07927-KODIAKAAAAANAAZT-1 -o
tzbsp_log_decode.txt

For device log collection, the TrustZone diag log buffer is part of the RAM dump, which can be
parsed using [Link] from [Link] software in the crash dump parser tool. For offline or
off-device log collection, the TrustZone diag log buffer is part of the RAM dump, which can be
parsed using [Link] (trustzone_images/ssg/bsp/qsee/build/${tz_bid:EACAANAA}) from the
[Link] software in the crash dump parser tool.
Debug using secure crash dump
You can debug Qualcomm TEE using the RAM dump. The execution region dump of Qualcomm
TEE is collected using secure crash dumps.
Devices that trigger the fuse with stage 2 [Link] are known as secure boot-enabled devices. To
debug on these devices, see SecTools v2: Secure Debug User Guide.

Note: The SecTools guides are available to licensed developers with authorized access.

5.2 Debug trusted and client applications

The trusted application logs, also known as Qualcomm TEE logs, are used to debug the errors in
trusted applications. To debug errors in the client application, the kernel and journalctl logs are
used.
For online or on-device log collection, Linux collects the Qualcomm TEE/kernel logs at runtime.
You can connect to the device using SSH and use the following commands:
• To collect the Qualcomm TEE logs from Linux:

cat /proc/tzdbg/qsee_log > qsee_log.txt

• For client applications, to collect the kernel and logcat logs:

cat /dev/kmsg > kernel_log.txt

journalctl > [Link]

• For offline or off-device log collection, the Qualcomm TEE log is available in RAM dumps
along with the kernel and journalctl logs.

80-70020-11 AC May contain U.S. and international export controlled information 127
 Debug Qualcomm TEE and secure devices

5.3 Debug on secure devices

As part of the secure boot procedure, blowing debug disable fuses disable debugging capabilities
on the devices. This includes RAM dumps, INV, and NINV debug on the subsystems.
The debug policy feature allows control over the debug capability for a device enabled with secure
boot.
The debug policy image allows debug capabilities such as JTAG re-enable (INV debug), RAM
dump, and TrustZone logging (NINV debug) on commercial secure devices.
For security reasons, the serial number of the device controls the debug policy for secure RAM
dumps, Qualcomm TEE logs, and JTAG.
Enabling JTAG on the Qualcomm TEE subsystem disables the device security with respect to
hardware key generation. As a result, existing secure storage like user data, SFS, and RPMB
becomes inaccessible. Sometimes, the device may prompt for a factory data reset. Use the
following command to debug on secure devices:

<meta>/common/sectoolsv2/ext/linux/sectools secure-debug --security-

profile <meta>/common/sectoolsv2/<chipset>_security_profile.xml --
generate --outfile apdp_out.mbn --all-flags --sign --signing-mode
LOCAL --oem-id=0x1 --root-certificate=./RSA-OEM-KEYS/qpsa_rootca.cer
--ca-certificate=./RSA-OEM-KEYS/qpsa_attestca.cer --ca-key=./RSA-OEM-
KEYS/qpsa_attestca.key --oem-product-id=0xabcd --serial-
number=0xabcdabcd

Ensure that you configure the OEM_ID, PRODUCT_ID, serial number and keys, and certification
paths appropriately.
For more information, see SecTools v2: Secure Debug User Guide.

Note: The SecTools guides are available to licensed developers with authorized access.

5.4 Flash APDP on device

To flash APDP on the device, run the following command:

Fastboot flash apdp_a <path to [Link]>

80-70020-11 AC May contain U.S. and international export controlled information 128
 Debug Qualcomm TEE and secure devices

Table : Debug policy flags for dump collection

Stage Mini dump
Full dump
Stage Applications Modem/Qualcomm TZDiag –
(DCC and scan TEE/Secure
dump) dump
aDSP/Video/RPM/
SLPI
Non-secure No debug No debug No debug No debug policy needed
policy needed policy needed policy needed
Stages 1 No APDP image needed
secure No APDP image needed

80-70020-11 AC May contain U.S. and international export controlled information 129
 Debug Qualcomm TEE and secure devices

Stage Mini dump

Full dump
Stages 2 -- –offline-crash QCS6490/QCS5430:
secure nonsecure- dumps with “–logs” with • Apps minidump:
crash- device serial device serial --apps-
dumps number number encrypted-
QCS9075: mini-dumps
“–tz-diag-logs” • Modem and
with device WLAN: *
serial number --mpss-
Or encrypted-
Encrypted mini-dumps
TZDiag with * --wlan-
-- encrypted-
nonsecure- mini-dumps
crash- • aDSP minidump:
dumps + --adsp-
TZDiag encrypted-
encryption mini-dumps
public key/exp • cDSP minidump:
in devcfg can --cdsp-
be configured encrypted-
in the following mini-dumps
location:
/
trustzone_
images/
ssg/
securemsm/
trustzone
/
qsee/
mink/
oem/
config<chipset>/
oem_
config.
xml

See KBA-191202045020-1 (ZIP). For more information, see MiniDump Software User Guide.

80-70020-11 AC May contain U.S. and international export controlled information 130
 Debug Qualcomm TEE and secure devices

Note: The SecTools and MiniDump guides are available to licensed user with authorized access.

5.5 Qualcomm TEE/TrustZone diag log collection on secure

device
On the secure device, the Qualcomm TEE/TrustZone log that’s collected from Linux is disabled by
default. Qualcomm provides an encrypted log feature for logging. Follow these steps for enabling
this feature:
1. Generate an RSA key for encryption using:

openssl genrsa -out rsa_key 2048

2. Show RSA key information and modulus using:

openssl rsa -in rsa_key -text

openssl rsa -in rsa_key -modulus
Private-key: (2048 bit)
modulus: 00:a0:48:99:99:83:26:65:57:fc:75:52:25:45:53:
92:fc:27:29:cb:14:35:94:7c:89:bc:d4:0a:c6:3d:
0d:6d:8a:7d:72:1d:e3:4f:f0:32:66:41:a9:f6:c1:
2f:79:aa:58:ea:57:3b:29:6d:cf:40:33:4e:ad:ec:
bf:78:44:4b:28:52:c8:e3:6e:77:01:e5:a3:c6:25:
65:8c:8b:cc:32:20:2d:29:58:03:f0:d5:b7:f4:c0:
d6:09:b2:8e:59:c1:3c:ac:e5:61:04:36:78:e3:da:
95:b3:e3:b7:71:90:50:ee:a9:70:5a:15:1a:af:d9:
a5:4f:c2:70:f1:f8:f1:67:d1:78:0e:b8:95:6e:93:
73:6a:23:f1:31:e1:e2:49:ff:18:54:a3:73:d0:70:
91:de:7a:92:53:11:aa:cb:b0:f9:d0:e1:83:9f:74:
67:bc:1a:89:6d:b1:d2:de:4f:ab:3c:1c:63:c9:bc:
75:f0:c0:80:fc:db:73:d1:8a:e3:f4:60:57:dd:66:
f1:3a:fa:18:ed:7f:47:72:3e:49:50:94:8e:19:ae:
6b:69:62:3d:74:ca:44:fb:d4:1c:1d:59:43:30:31:
0d:fb:ab:70:44:9d:d9:d0:ce:cb:43:f3:2a:98:a4:
83:e7:76:ae:a8:b8:ea:63:64:e1:11:1b:99:92:b3: 9b:3f
publicExponent: 65537 (0x10001)

Note: The modulus is used in the pub_mod in oem_config.xml file. The pub_exp
exponent is usually 65537. 0x10001 is known as the publicExponent.

80-70020-11 AC May contain U.S. and international export controlled information 131
 Debug Qualcomm TEE and secure devices

3. Set the RSA public key (exponent and modulus) in the trustzone_
images/ssg/securemsm/trustzone/qsee/mink/oem/config/<chipset>/
oem_config.xml file.
Enable this feature by adding the following lines to the oem_config.xml file using:

<driver name="NULL">
<global_def>
<var_seq name="pub_mod" type=DALPROP_DATA_TYPE_STRING>
a048999983266557fc755225455392fc2729cb1435947c89bcd40ac63d0d6d
8a7d721de34ff0326641a9f6c12f79aa58ea573b296dcf40334eadecbf7844
4b2852c8e36e7701e5a3c625658c8bcc32202d295803f0d5b7f4c0d609b28e
59c13cace561043678e3da95b3e3b7719050eea9705a151aafd9a54fc270f1
f8f167d1780eb8956e93736a23f131e1e249ff1854a373d07091de7a925311
aacbb0f9d0e1839f7467bc1a896db1d2de4fab3c1c63c9bc75f0c080fcdb73
d18ae3f46057dd66f13afa18ed7f47723e4950948e19ae6b69623d74ca44fb
d41c1d594330310dfbab70449dd9d0cecb43f32a98a483e776aea8b8ea6364e1
111b9992b39b3f
</var_seq>
<var_seq name="pub_exp" type=DALPROP_DATA_TYPE_STRING>
000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000100
01
</var_seq>
</global_def>

Note: When the public key in the oem_config.xml file is updated, ensure that there are
no new line characters, tabs, or spaces inserted between due to the Notepad or Wordpad
editors.

4. Enable the encryption feature configuration flag from the trustzone_images/ssg/

securemsm/trustzone/qsee/mink/oem/config/<chipset>/oem_
[Link] file, using:

< props name="OEM_log_encr_enable" type=DALPROP_ATTR_TYPE_

UINT32>
1
</props>

5. To build the TrustZone devcfg image, enter the OEM_ID field value and sign the
[Link] image.

80-70020-11 AC May contain U.S. and international export controlled information 132
 Debug Qualcomm TEE and secure devices

6. Flash the signed [Link] image using:

fastboot flash devcfg_a [Link]

Note: Use [Link] for QCS6490 and devcfg_iot.mbn for QCS9100.

7. Collect the Qualcomm TEE/TrustZone log using:

cat /proc/tzdbg/qsee_log > qsee_log.txt

cat /proc/tzdbg/log > tz_log.txt

5.6 Qualcomm TEE/TrustZone diag log decryption steps

1. Download the Python decryption tool decrypt_tzdiag_qsee_log_tools.py from
KBA-200917004544-1 (ZIP).
2. To install, run the following commands:

Python Version 3.x

pip install pycryptodome
pip install cryptography

3. To decrypt, run the following command:

python decrypt_tzdiag_qsee_log_tools.py -pk <RSA private key

file> -a RSA -I <input encrypted qsee/tz diag log collected from
device> -o <decrypted qsee/tzdiag log filename>

4. After successful decryption:

a. Navigate the plain text of the Qualcomm TEE log to a readable string format.
b. Convert the hexadecimal encoded error codes to string, using:

print_tz_log.py

5.7 See also

• To learn how to develop and run trusted and client applications, see Develop trusted and
client applications.
• To configure Qualcomm TEE for securing devices that handle sensitive data and run trusted
applications, see Configure security services.

80-70020-11 AC May contain U.S. and international export controlled information 133
 Debug Qualcomm TEE and secure devices

• To customize memory and SEPolicy, see Customize secuity services.

80-70020-11 AC May contain U.S. and international export controlled information 134
6 Develop trusted and client applications

You can develop and run trusted and client applications using default files in the global platform
interfaces. The trusted applications run in a secure Trusted Execution Environment (TEE) to keep
the code and data integrity. Where as the client applications operate in the normal OS, using TEE
client APIs to perform secure services.
This feature is available to licensed users with authorized access to develop and execute trusted
applications and client applications. If you have access, see Qualcomm Linux Security Guide -
Addendum.
For developing applications that offer hardware-based attestation, zero-touch device provisioning,
and chipset feature management, see Qualcomm Linux Wireless Edge Services Guide. This
feature is available to licensed users with authorized access.

6.1 Security APIs

The security APIs offer the ability to interface with the Linux kernel and the device hardware. They
also facilitate various software services that can be run in a trusted execution environment.
User space APIs
The user space APIs are the functions that the Linux OS accesses to interact with the kernel.
This feature is available to licensed developers with authorized access. If you have access,
see Qualcomm Linux Security Guide - Addendum.
Interfaces exposed for PKCS#11
See Cryptographic Token Interface Usage Guide and Cryptographic Token Interface Base
Specification.
Kernel APIs
The kernel APIs are the functions that allow the Qualcomm Linux software to interact with the
device hardware.
Cryptographic APIs
The [Link] driver is on the device at /lib/modules/<version>/kernel/drivers/
crypto/qce. Both kernel-level and user-level APIs can access the crypto engine. For the APIs,
see the kernel crypto documentation at Index of crypto documentation.

80-70020-11 AC May contain U.S. and international export controlled information 135
 Develop trusted and client applications

The following cryptographic algorithms are supported:

• RFC 4309 (CCCM (AES))
• CCM (AES)
• Authenc (HMAC (SHA-256), CBC (AES))
• Authenc (HMAC (SHA-256), CBC (DES3_EDE))
• Authenc (HMAC (SHA-256), CBC (DES))
• Authenc (HMAC (SHA-1), CBC (DES3_EDE))
• Authenc (HMAC (SHA-1), CBC (DES))
• HMAC (SHA-256)
• HMAC (SHA-1)
• SHA-256
• SHA-1
• CBC (DES3_EDE)
• ECB (DES3_EDE)
• CBC (DES)
• ECB (DES)
• XTS (AES)
• CTR (AES)
• CBC (AES)
• ECB (AES)
For more information about the Qualcomm crypto core, see Cryptography.
For more information, see [Link] → 𝐶𝑟𝑦𝑝𝑡𝑜𝐴𝑃 𝐼 .
Hardware random generator APIs
Qualcomm Linux supports a true random number generator using the qcom-rng Linux driver. The
random number generated from qcom-rng uses kernel crypto for the random number generator
API.
In the user space, a random number can be accessed at /dev/hwrng. For more information
about the hardware random number generator, see the kernel documentation at Linux support for
random number generator in i8xx chipsets.
For PRNG APIs, see Qualcomm Linux Security Guide - Addendum. This feature is available to
licensed developers with authorized access.

80-70020-11 AC May contain U.S. and international export controlled information 136
 Develop trusted and client applications

Qualcomm TEE APIs

Qualcomm TEE provides a collection of APIs that offer services to secure applications. These
services include heap management, logging, secure file system access, listener interactions, and
cryptography and hashing functions.
This feature is available to licensed developers with authorized access. If you have access,
see Qualcomm Linux Security Guide - Addendum.

6.2 Use security services examples

To run security services, sample code and examples to load client and trusted applications using
different interfaces are available to licensed users with authorized access. If you have access,
see Qualcomm Linux Security Guide - Addendum.

6.3 See also

• To initialize and configure the hardware for running securely on Linux, see Verify security
configurations.
• To configure Qualcomm TEE for securing devices that handle sensitive data and run trusted
applications, see Configure security services.
• To customize memory and SEPolicy, see Customize secuity services.

80-70020-11 AC May contain U.S. and international export controlled information 137
7 References

7.1 Related documents

Title Document number

MiniDump Software User Guide 80-P8754-71
Qualcomm Linux Build Guide 80-70020-254
Qualcomm Linux Kernel Guide 80-70020-3
Qualcomm Linux Security Guide - Addendum 80-70020-11A
Qualcomm Linux Wireless Edge Services Guide 80-70020-11B
SecTools v2: Secure Debug User Guide 80-NM248-23
SSecTools V2: Metabuild Secure Image User Guide 80-NM248-17
SecTools V2: Fuse Blower User Guide 80-NM248-9
SecTools V2: ELF Tool User Guide 80-NM248-18
SecTools V2: MBN Tool User Guide 80-NM248-19
SecTools V2: ELF Consolidator User Guide 80-NM248-20
SecTools V2: Secure Image User Guide 80-NM248-12

Note: MiniDump, Qualcomm Linux Security - Addendum, Qualcomm Linux Wireless Edge
Services, and SecTools guides are available to licensed users with authorized access.

7.2 Acronyms and terms

Acronym or term Definition

API Application programming interfaces
CBC Cipher block chaining
DRM Digital rights management
EL0, EL1, EL2, and EL3 Exception levels
eMMC Embedded multimedia card

80-70020-11 AC May contain U.S. and international export controlled information 138
 References

Acronym or term Definition

GPCE General purpose cryptographic engine
HAL Hardware abstraction layer
HLOS High-level operating system
HMAC Hashed message authentication code
I2C Inter integrated circuit
ICE Inline crypto engine
IOCTL I/O control
KDF Key derivation function
KEK Key exchange keys
MAC Message authentication code
MINK Mini kernel
MPU Memory protection unit
OCIMEM On-chip internal memory
OEM Original equipment manufacturer
PIL Peripheral image loader
pIMEM Protected memory
PRNG Pseudo-random number generator
RMA Returned material for analysis
QRNG Qualcomm-random number generator
Qualcomm TEE Qualcomm Trusted Execution Environment
Qualcomm WES Qualcomm wireless edge services
RPMB Replay protected memory block
SELinux Security enhanced Linux
SEL0 and SEL1 Secure exception levels
SFS Secure file system
SKU Stock keeping unit
SMC Secure monitor call
SPI Serial peripheral interface
SSL Secure sockets layer
TZBSP TrustZone board support package
UEFI Unified extensible firmware interface
UFS Universal flash storage
UIE Unified image encryption
XBL eXtensible Boot Loader
xPU External protection unit

80-70020-11 AC May contain U.S. and international export controlled information 139
 LEGAL INFORMATION

Your access to and use of this material, along with any documents, software, specifications, reference board files, drawings, diagnostics and other
information contained herein (collectively this “Material”), is subject to your (including the corporation or other legal entity you represent,
collectively “You” or “Your”) acceptance of the terms and conditions (“Terms of Use”) set forth below. If You do not agree to these Terms of Use,
you may not use this Material and shall immediately destroy any copy thereof.

1) Legal Notice.
This Material is being made available to You solely for Your internal use with those products and service offerings of Qualcomm Technologies, Inc.
(“Qualcomm Technologies”), its affiliates and/or licensors described in this Material, and shall not be used for any other purposes. If this Material is
marked as “Qualcomm Internal Use Only”, no license is granted to You herein, and You must immediately (a) destroy or return this Material to
Qualcomm Technologies, and (b) report Your receipt of this Material to [Link]@[Link]. This Material may not be altered,
edited, or modified in any way without Qualcomm Technologies’ prior written approval, nor may it be used for any machine learning or artificial
intelligence development purpose which results, whether directly or indirectly, in the creation or development of an automated device, program,
tool, algorithm, process, methodology, product and/or other output. Unauthorized use or disclosure of this Material or the information contained
herein is strictly prohibited, and You agree to indemnify Qualcomm Technologies, its affiliates and licensors for any damages or losses suffered by
Qualcomm Technologies, its affiliates and/or licensors for any such unauthorized uses or disclosures of this Material, in whole or part.

Qualcomm Technologies, its affiliates and/or licensors retain all rights and ownership in and to this Material. No license to any trademark, patent,
copyright, mask work protection right or any other intellectual property right is either granted or implied by this Material or any information disclosed
herein, including, but not limited to, any license to make, use, import or sell any product, service or technology offering embodying any of the
information in this Material.

THIS MATERIAL IS BEING PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESSED, IMPLIED, STATUTORY OR OTHERWISE. TO
THE MAXIMUM EXTENT PERMITTED BY LAW, QUALCOMM TECHNOLOGIES, ITS AFFILIATES AND/OR LICENSORS SPECIFICALLY DISCLAIM ALL
WARRANTIES OF TITLE, MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, COMPLETENESS
OR ACCURACY, AND ALL WARRANTIES ARISING OUT OF TRADE USAGE OR OUT OF A COURSE OF DEALING OR COURSE OF PERFORMANCE.
MOREOVER, NEITHER QUALCOMM TECHNOLOGIES, NOR ANY OF ITS AFFILIATES AND/OR LICENSORS, SHALL BE LIABLE TO YOU OR ANY THIRD PARTY
FOR ANY EXPENSES, LOSSES, USE, OR ACTIONS HOWSOEVER INCURRED OR UNDERTAKEN BY YOU IN RELIANCE ON THIS MATERIAL.

Certain product kits, tools and other items referenced in this Material may require You to accept additional terms and conditions before accessing
or using those items.

Technical data specified in this Material may be subject to U.S. and other applicable export control laws. Transmission contrary to U.S. and any other
applicable law is strictly prohibited.

Nothing in this Material is an offer to sell any of the components or devices referenced herein.

This Material is subject to change without further notification.

In the event of a conflict between these Terms of Use and the Website Terms of Use on [Link], the Qualcomm Privacy Policy referenced
on [Link], or other legal statements or notices found on prior pages of the Material, these Terms of Use will control. In the event of a
conflict between these Terms of Use and any other agreement (written or click-through, including, without limitation any non-disclosure agreement)
executed by You and Qualcomm Technologies or a Qualcomm Technologies affiliate and/or licensor with respect to Your access to and use of this
Material, the other agreement will control.

These Terms of Use shall be governed by and construed and enforced in accordance with the laws of the State of California, excluding the U.N.
Convention on International Sale of Goods, without regard to conflict of laws principles. Any dispute, claim or controversy arising out of or relating
to these Terms of Use, or the breach or validity hereof, shall be adjudicated only by a court of competent jurisdiction in the county of San Diego,
State of California, and You hereby consent to the personal jurisdiction of such courts for that purpose.

2) Trademark and Product Attribution Statements.

Qualcomm is a trademark or registered trademark of Qualcomm Incorporated. Arm is a registered trademark of Arm Limited (or its subsidiaries) in
the U.S. and/or elsewhere. The Bluetooth® word mark is a registered trademark owned by Bluetooth SIG, Inc. Other product and brand names
referenced in this Material may be trademarks or registered trademarks of their respective owners.

Snapdragon and Qualcomm branded products referenced in this Material are products of Qualcomm Technologies, Inc. and/or its subsidiaries.
Qualcomm patented technologies are licensed by Qualcomm Incorporated.